{"id":3949,"date":"2014-10-20T16:37:40","date_gmt":"2014-10-20T14:37:40","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/"},"modified":"2014-10-20T16:37:40","modified_gmt":"2014-10-20T14:37:40","slug":"what-about-alter-index-shrink-space","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/","title":{"rendered":"What about ALTER INDEX &#8230; SHRINK SPACE ?"},"content":{"rendered":"<h2>By Franck Pachot<\/h2>\n<p>.<br \/>\nI have <a href=\"\/how-i-measure-oracle-index-fragmentation\">recently<\/a> published a script to check index fragmentation. But then, do you COALESCE or REBUILD? Well, there also is another option: ALTER INDEX SHRINK SPACE. Let&#8217;s compare all those index defragmentation operations.<\/p>\n<h3>Fragmented index<\/h3>\n<p>I have an index created when the table had 1 million rows. Then, I deleted 90% of the rows. Here is the index state from:<\/p>\n<ul>\n<li>dbms_space.space_usage<\/li>\n<li>index_stats after an analyze index validate structure<\/li>\n<li>my index fragmentation checking script with 4 buckets<\/li>\n<\/ul>\n<p>and here are the results:<\/p>\n<pre><code>      :UNF       :FS1       :FS2       :FS3       :FS4      :FULL  BLOCKS\n---------- ---------- ---------- ---------- ---------- ---------- -------\n         0          0          1          0          0       2230    2304\n&nbsp;\n HEIGHT  BLOCKS    LF_ROWS  LF_BLKS  BR_ROWS  BR_BLKS DEL_LF_ROWS USED_SPACE PCT_USED\n------- ------- ---------- -------- -------- -------- ----------- ---------- --------\n      3    2304     100404     2226     2225        5         404    1622013       10\n&nbsp;\n         N to          N rows\/block bytes\/block %free space  blocks free\n---------- -- ---------- ---------- ----------- ----------- ------- -----\n        10 -&gt;     250280         45         714          91     557 oooo\n    250730 -&gt;     500370         45         714          91     557 oooo\n    500820 -&gt;     750010         45         714          91     556 oooo\n    750460 -&gt;     999660         45         714          91     556 oooo\n<\/code><\/pre>\n<p>I have 2226 leaf blocks, the index height is 3 with 5 branch blocks. The leaves are only 91.<br \/>\nHowever dbms_space shows only full blocks: the deleted entries are still there, just marked as deleted, and the blocks are still seen as full.<\/p>\n<h3>COALESCE<\/h3>\n<p>Now let&#8217;s COALESCE:<\/p>\n<pre><code>SQL&gt; alter index DEMO_N coalesce;\n<\/code><\/pre>\n<p>And before checking the same values about the index space I measure the amount of work that has been done by the operation (from v$mystat):<\/p>\n<pre><code>NAME                                                                  VALUE\n---------------------------------------------------------------- ----------\nredo entries                                                          22067\ndb block gets                                                         32818\nsession logical reads                                                 32886\ndb block changes                                                      40601\nundo change vector size                                            35199264\nredo size                                                          47878800\n&nbsp;\n      :UNF       :FS1       :FS2       :FS3       :FS4      :FULL  BLOCKS\n---------- ---------- ---------- ---------- ---------- ---------- -------\n         0          0       2004          0          0        227    2304\n&nbsp;\n HEIGHT  BLOCKS    LF_ROWS  LF_BLKS  BR_ROWS  BR_BLKS DEL_LF_ROWS USED_SPACE PCT_USED\n------- ------- ---------- -------- -------- -------- ----------- ---------- --------\n      3    2304     100000      223      222        5           0    1591530       88\n&nbsp;\n         N to          N rows\/block bytes\/block %free space  blocks free\n---------- -- ---------- ---------- ----------- ----------- ------- -----\n        10 -&gt;     248690        452        7170          11      56\n    253200 -&gt;     500800        450        7158          11      56\n    505310 -&gt;     752020        449        7132          11      56\n    756530 -&gt;     998730        443        7038          12      55\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>COALESCE is an online operation that defragments the leaf blocks. We have now only 223 leaf blocks that are 90% full (because my pctfree is the default 10%). But the index stil has the same height and still has 2300 blocks. Where are the reclaimed 2000 blocks? They are available when the index needs a new block (for a block split). They are seen as FS2 (at least 25 to 50% free space) by dbms_space because they still contain the deleted rows, and haven&#8217;t been touched but only unlinked from the B*Tree structure (parent branch + prev\/next leaf), but space is available when needed by the index.<\/p>\n<h3>SHRINK SPACE COMPACT<\/h3>\n<p>Back with the same table, and doing a SHRINK SPACE COMPACT instead of COALESCE:<\/p>\n<pre><code>NAME                                                                  VALUE\n---------------------------------------------------------------- ----------\nredo entries                                                          28794\ndb block gets                                                         40940\nsession logical reads                                                 41527\ndb block changes                                                      49387\nundo change vector size                                            36990460\nredo size                                                          51848880\n&nbsp;\n      :UNF       :FS1       :FS2       :FS3       :FS4      :FULL  BLOCKS\n---------- ---------- ---------- ---------- ---------- ---------- -------\n         0          0          1          0       2003        227    2304\n&nbsp;\n HEIGHT  BLOCKS    LF_ROWS  LF_BLKS  BR_ROWS  BR_BLKS DEL_LF_ROWS USED_SPACE PCT_USED\n------- ------- ---------- -------- -------- -------- ----------- ---------- --------\n      3    2304     100000      223      222        5           0    1591530       88\n&nbsp;\n         N to          N rows\/block bytes\/block %free space  blocks free\n---------- -- ---------- ---------- ----------- ----------- ------- -----\n        10 -&gt;     248690        452        7170          11      56\n    253200 -&gt;     500800        450        7158          11      56\n    505310 -&gt;     752020        449        7132          11      56\n    756530 -&gt;     998730        443        7038          12      55\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>So what is the difference? Slightly more work (about 20% more logical reads and block changes) for the same result. Except that now the reclaimed blocks are in FS4 (75 to 100% free space). Actually, what is different from COALESCE is that those blocks were not only unlinked from the B*Tree structure but also moved out of the end of the segment (to COMPACT it) with the goal to reduce the segment size with SHRINK SPACE. More info on <a href=\"https:\/\/richardfoote.wordpress.com\/2008\/02\/08\/index-rebuild-vs-coalesce-vs-shrink-space-pigs-3-different-ones\/\" rel=\"noopener noreferrer\" target=\"_blank\">Richard Foote blog<\/a>.<\/p>\n<p>&nbsp;<\/p>\n<h3>SHRINK SPACE<\/h3>\n<p>What if we use SHRINK SPACE instead of SHRINK SPACE COMPACT?<\/p>\n<p>&nbsp;<\/p>\n<pre><code>NAME                                                                  VALUE\n---------------------------------------------------------------- ----------\nredo entries                                                          29352\ndb block gets                                                         45496\nsession logical reads                                                 46190\ndb block changes                                                      50032\nundo change vector size                                            36981524\nredo size                                                          51901500\n&nbsp;\n      :UNF       :FS1       :FS2       :FS3       :FS4      :FULL  BLOCKS\n---------- ---------- ---------- ---------- ---------- ---------- -------\n         0          0          1          0          0        227     240\n&nbsp;\n HEIGHT  BLOCKS    LF_ROWS  LF_BLKS  BR_ROWS  BR_BLKS DEL_LF_ROWS USED_SPACE PCT_USED\n------- ------- ---------- -------- -------- -------- ----------- ---------- --------\n      3     240     100000      223      222        5           0    1591530       88\n&nbsp;\n         N to          N rows\/block bytes\/block %free space  blocks free\n---------- -- ---------- ---------- ----------- ----------- ------- -----\n        10 -&gt;     248690        452        7170          11      56\n    253200 -&gt;     500800        450        7158          11      56\n    505310 -&gt;     752020        449        7132          11      56\n    756530 -&gt;     998730        443        7038          12      55\n<\/code><\/pre>\n<p>With tables, theSHRINK SPACE lowers the high water mark. Here it is the same idea: in addition to the SHRINK SPACE COMPACT operation, the reclaimed blocks are removed from the end of the segment, not allocated anymore to the index, and can be used for other segments in the tablespace. We see that from dbms_space: the index is now 240 blocks only.<\/p>\n<h3>REBUILD<\/h3>\n<p>The previous requires a lock only for a short duration (according that we did the shrink space compact before). The rebuild needs a Share lock on the table during the whole operation, blocking concurrent DML.<\/p>\n<pre><code>NAME                                                                  VALUE\n---------------------------------------------------------------- ----------\ndb block gets                                                           953\nredo entries                                                           1832\ndb block changes                                                       1906\nsession logical reads                                                  4019\nundo change vector size                                                9152\nredo size                                                            173732\n&nbsp;\n      :UNF       :FS1       :FS2       :FS3       :FS4      :FULL  BLOCKS\n---------- ---------- ---------- ---------- ---------- ---------- -------\n         0          0          1          0          0        222     256\n&nbsp;\n HEIGHT  BLOCKS    LF_ROWS  LF_BLKS  BR_ROWS  BR_BLKS DEL_LF_ROWS USED_SPACE PCT_USED\n------- ------- ---------- -------- -------- -------- ----------- ---------- --------\n      2     256     100000      222      221        1           0    1591520       90\n&nbsp;\n         N to          N rows\/block bytes\/block %free space  blocks free\n---------- -- ---------- ---------- ----------- ----------- ------- -----\n        10 -&gt;     248690        452        7170          11      56\n    253200 -&gt;     501250        451        7170          11      56\n    505760 -&gt;     749300        451        7170          11      55\n    753810 -&gt;     997350        448        7117          11      55\n<\/code><\/pre>\n<p>The result is the same as the previous operation (SHRINK SPACE) except that the index height has decreased. A rebuild is the right operation if the index blevel has become too high. And we did that offline but with much less work. Minimal undo and redo. And small blocks to read (when the index is still usable the rebuild can use the current index to rebuild the new segment).<\/p>\n<p>&nbsp;<\/p>\n<h3>REBUILD ONLINE<\/h3>\n<p>Last operation, possible only in Enterprise Edition, is the rebuild online which doesn&#8217;t need to lock the table.<\/p>\n<p>&nbsp;<\/p>\n<pre><code>NAME                                                                  VALUE\n---------------------------------------------------------------- ----------\nredo entries                                                            660\ndb block changes                                                        876\ndb block gets                                                          1419\nsession logical reads                                                  4989\nundo change vector size                                               24932\nredo size                                                            114924\n&nbsp;\n      :UNF       :FS1       :FS2       :FS3       :FS4      :FULL  BLOCKS\n---------- ---------- ---------- ---------- ---------- ---------- -------\n         0          0          1          0          0        222     256\n&nbsp;\n HEIGHT  BLOCKS    LF_ROWS  LF_BLKS  BR_ROWS  BR_BLKS DEL_LF_ROWS USED_SPACE PCT_USED\n------- ------- ---------- -------- -------- -------- ----------- ---------- --------\n      2     256     100000      222      221        1           0    1591520       90\n&nbsp;\n         N to          N rows\/block bytes\/block %free space  blocks free\n---------- -- ---------- ---------- ----------- ----------- ------- -----\n        10 -&gt;     248690        452        7170          11      56\n    253200 -&gt;     501250        451        7170          11      56\n    505760 -&gt;     749300        451        7170          11      55\n    753810 -&gt;     997350        448        7117          11      55\n<\/code><\/pre>\n<p>Here we don&#8217;t see an overhead to do it online. This is because my table is small (my testcase has only one column which is the indexed one). On a real table you will probably see that the online rebuild takes longer than the offline one, because it cannot use the current index. But anyway, the fact that it is online means that the duration is not a big issue.<\/p>\n<h3>Conclusion<\/h3>\n<p>This is an example on a table that had a massive purge: all blocks were touched. In that case the REBUILD is the right solution. However if you are in Standard Edition and cannot do it online, then you will probably do a SHRINK SPACE COMPACT because it lets you do a SHRINK SPACE (need a quick locks but for a very short duration &#8211; to do on a period of low activity).<br \/>\nCOALESCE will make sense here only if you know you will insert back a lot of rows, so that you don&#8217;t need to deallocate the blocks from the index.<\/p>\n<p>Now, what to do if the free space to reclaim is only on small part of the index blocks? As in the following case:<\/p>\n<pre><code>         N to          N rows\/block bytes\/block %free space  blocks free\n---------- -- ---------- ---------- ----------- ----------- ------- -----\n        10 -&gt;      50468        374        5974          26     112 o\n     50917 -&gt;     100756        449        7179          11     112\n    101205 -&gt;     151044        449        7179          11     112\n    151493 -&gt;     201332        449        7179          11     112\n    201781 -&gt;     251620        449        7179          11     112\n    252069 -&gt;     301908        449        7179          11     112\n    302357 -&gt;     351747        449        7179          11     111\n    352196 -&gt;     401586        449        7179          11     111\n    402035 -&gt;     451425        449        7179          11     111\n    451874 -&gt;     501264        449        7179          11     111\n    501713 -&gt;     551103        449        7179          11     111\n<\/code><\/pre>\n<p>In that case a COALESCE is probably the best because you keep the blocks allocated to the index for future growth. And the few blocks reclaimed will probably not change the index height anyway. However, if you did a small purge that concern only a small part of the index and want to reclaim the space for other segments, then the SHRINK SPACE is the right solution. But do you really need to reclaim space in that case?<\/p>\n<p>Now you see the usage for my index fragmentation script: I don&#8217;t need only the average free space. I need to have a clear picture of the fragmentation in order to decide what to do and how.<\/p>\n<h3>Update Jan. 23th 2015<\/h3>\n<p>There is something else important in the INDEX SHRINK vs. COALESCE when there are concurrent DML activity. COALESCE just skip the blocks where some index entries are locked. SHRINK will wait on them.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Franck Pachot . I have recently published a script to check index fragmentation. But then, do you COALESCE or REBUILD? Well, there also is another option: ALTER INDEX SHRINK SPACE. Let&#8217;s compare all those index defragmentation operations. Fragmented index I have an index created when the table had 1 million rows. Then, I deleted [&hellip;]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[198,59],"tags":[480,96,209,67],"type_dbi":[],"class_list":["post-3949","post","type-post","status-publish","format-standard","hentry","category-database-management","category-oracle","tag-index-fragmentation","tag-oracle","tag-oracle-12c","tag-performance"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.2) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>What about ALTER INDEX ... SHRINK SPACE ? - dbi Blog<\/title>\n<meta name=\"description\" content=\"Index Coalesce vs. Shrink Space vs. Rebuild\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What about ALTER INDEX ... SHRINK SPACE ?\" \/>\n<meta property=\"og:description\" content=\"Index Coalesce vs. Shrink Space vs. Rebuild\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2014-10-20T14:37:40+00:00\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"What about ALTER INDEX &#8230; SHRINK SPACE ?\",\"datePublished\":\"2014-10-20T14:37:40+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/\"},\"wordCount\":922,\"commentCount\":0,\"keywords\":[\"Index fragmentation\",\"Oracle\",\"Oracle 12c\",\"Performance\"],\"articleSection\":[\"Database management\",\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/\",\"name\":\"What about ALTER INDEX ... SHRINK SPACE ? - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2014-10-20T14:37:40+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"description\":\"Index Coalesce vs. Shrink Space vs. Rebuild\",\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"What about ALTER INDEX &#8230; SHRINK SPACE ?\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"What about ALTER INDEX ... SHRINK SPACE ? - dbi Blog","description":"Index Coalesce vs. Shrink Space vs. Rebuild","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/","og_locale":"en_US","og_type":"article","og_title":"What about ALTER INDEX ... SHRINK SPACE ?","og_description":"Index Coalesce vs. Shrink Space vs. Rebuild","og_url":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/","og_site_name":"dbi Blog","article_published_time":"2014-10-20T14:37:40+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"What about ALTER INDEX &#8230; SHRINK SPACE ?","datePublished":"2014-10-20T14:37:40+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/"},"wordCount":922,"commentCount":0,"keywords":["Index fragmentation","Oracle","Oracle 12c","Performance"],"articleSection":["Database management","Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/","url":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/","name":"What about ALTER INDEX ... SHRINK SPACE ? - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2014-10-20T14:37:40+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"description":"Index Coalesce vs. Shrink Space vs. Rebuild","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/what-about-alter-index-shrink-space\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"What about ALTER INDEX &#8230; SHRINK SPACE ?"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/3949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=3949"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/3949\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=3949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=3949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=3949"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=3949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}