Question on fragmentation and ALTER INDEX REBUILD/REORGANIZE not effecting it

The problem I ran into was troubleshooting a sporadically slow singleton lookup on a Clustered Index in a table with about 8 million rows, which is a separate issue I may need to submit for help. That aside, during that troubleshooting I noticed fragmentation
on the Unique Clustered Index (it's a VARCHAR(20)), and then noticed the fragmentation in other indexes on this table. See sys.dm_db_index_physical_stats and DBCC SHOWCONTIG results below.
SELECT
 substring(OBJECT_NAME(i.object_id),1,30) AS TableName,
 substring(i.name,1,40) AS TableIndexName,
 i.index_id, phystat.index_level,
 phystat.avg_fragmentation_in_percent 
FROM
 sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat inner JOIN sys.indexes i 
ON i.object_id = phystat.object_id 
AND i.index_id = phystat.index_id WHERE
OBJECT_NAME(i.object_id) = 'CONSUMERS'
TableName                      TableIndexName                           index_id    index_level avg_fragmentation_in_percent
CONSUMERS                      UNI2K_CONSUMERS                          1           0      
    0.154827346202469
CONSUMERS                      UNI2K_CONSUMERS                          1           1      
    35.2941176470588
CONSUMERS                      UNI2K_CONSUMERS                          1           2      
    0
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           0           0.336078590685822
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           1           100
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           2           0
CONSUMERS                      UNI1K_CONSUMERS                          3           0      
    0.156451316031658
CONSUMERS                      UNI1K_CONSUMERS                          3           1      
    61.1510791366906
CONSUMERS                      UNI1K_CONSUMERS                          3           2      
    0
CONSUMERS                      IDX1_CONSUMERS                           4           0      
    0.215271389144434
CONSUMERS                      IDX1_CONSUMERS                           4           1      
    40
CONSUMERS                      IDX1_CONSUMERS                           4           2      
    100
CONSUMERS                      IDX1_CONSUMERS                           4           3      
    0
CONSUMERS                      IDX2_CONSUMERS                           5           0      
    0.222614710968834
CONSUMERS                      IDX2_CONSUMERS                           5           1      
    38.6281588447653
CONSUMERS                      IDX2_CONSUMERS                           5           2      
    75
CONSUMERS                      IDX2_CONSUMERS                           5           3      
    0
(17 row(s) affected)
DBCC SHOWCONTIG('CONSUMERS') WITH ALL_INDEXES
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 70401
- Extents Scanned..............................: 8827
- Extent Switches..............................: 8843
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.51% [8801:8844]
- Logical Scan Fragmentation ..................: 0.15%
- Extent Scan Fragmentation ...................: 23.76%
- Avg. Bytes Free per Page.....................: 47.2
- Avg. Page Density (full).....................: 99.42%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 2, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 27077
- Extents Scanned..............................: 3402
- Extent Switches..............................: 3402
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.47% [3385:3403]
- Logical Scan Fragmentation ..................: 0.34%
- Extent Scan Fragmentation ...................: 11.88%
- Avg. Bytes Free per Page.....................: 24.1
- Avg. Page Density (full).....................: 99.70%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 3, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 54330
- Extents Scanned..............................: 6803
- Extent Switches..............................: 6805
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.79% [6792:6806]
- Logical Scan Fragmentation ..................: 0.16%
- Extent Scan Fragmentation ...................: 7.03%
- Avg. Bytes Free per Page.....................: 50.3
- Avg. Page Density (full).....................: 99.38%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 4, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 54350
- Extents Scanned..............................: 6808
- Extent Switches..............................: 6837
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.36% [6794:6838]
- Logical Scan Fragmentation ..................: 0.22%
- Extent Scan Fragmentation ...................: 7.17%
- Avg. Bytes Free per Page.....................: 53.2
- Avg. Page Density (full).....................: 99.34%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 5, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 54354
- Extents Scanned..............................: 6804
- Extent Switches..............................: 6846
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.24% [6795:6847]
- Logical Scan Fragmentation ..................: 0.22%
- Extent Scan Fragmentation ...................: 7.13%
- Avg. Bytes Free per Page.....................: 53.8
- Avg. Page Density (full).....................: 99.33%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
This fragmentation I found shocking because I reorg nightly and have a weekly rebuild task running that I set up through the Maintenance Plan wizard (which I've verified has been running). So I attempted to reorg these manually (especially index ID: 1)
and to my shock the fragmentation % did not change at all. I then took the SQL provided by the Maintenance Plan for rebuilding the indexes and found that after running that it didn't change the fragementation % at all either (commands run shown below).
ALTER INDEX [IDX1_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = ON, SORT_IN_TEMPDB = ON )
GO
ALTER INDEX [IDX2_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = ON, SORT_IN_TEMPDB = ON )
GO
ALTER INDEX [UNI1K_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, IGNORE_DUP_KEY  = OFF, ONLINE = ON, SORT_IN_TEMPDB
= ON )
GO
ALTER INDEX [UNI2K_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, IGNORE_DUP_KEY  = OFF, ONLINE = ON, SORT_IN_TEMPDB
= ON )
GO
Fragmentation did not change until I performed a "CREATE ... DROP_EXISTING = ON" on the 4 non PK indexes and a manual rebuild of Primary Key offline not specifying any other parameters, which all seemed completely overkill to ensure the defragmentation
actually got done. Final sys.dm_db_index_physical_stats and DBCC SHOWCONTIG results below.
SELECT
 substring(OBJECT_NAME(i.object_id),1,30) AS TableName,
 substring(i.name,1,40) AS TableIndexName,
 i.index_id, phystat.index_level,
 phystat.avg_fragmentation_in_percent 
FROM
 sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat inner JOIN sys.indexes i 
ON i.object_id = phystat.object_id 
AND i.index_id = phystat.index_id WHERE
OBJECT_NAME(i.object_id) = 'CONSUMERS'
TableName                      TableIndexName                           index_id    index_level avg_fragmentation_in_percent
CONSUMERS                      UNI2K_CONSUMERS                          1           0      
    0.0213458562356583
CONSUMERS                      UNI2K_CONSUMERS                          1           1      
    11.2426035502959
CONSUMERS                      UNI2K_CONSUMERS                          1           2      
    0
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           0           0.0460971112476951
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           1           14.2857142857143
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           2           0
CONSUMERS                      UNI1K_CONSUMERS                          3           0      
    0.0225314031431307
CONSUMERS                      UNI1K_CONSUMERS                          3           1      
    10.6194690265487
CONSUMERS                      UNI1K_CONSUMERS                          3           2      
    0
CONSUMERS                      IDX1_CONSUMERS                           4           0      
    0.0225318262045139
CONSUMERS                      IDX1_CONSUMERS                           4           1      
    10.7296137339056
CONSUMERS                      IDX1_CONSUMERS                           4           2      
    0
CONSUMERS                      IDX1_CONSUMERS                           4           3      
    0
CONSUMERS                      IDX2_CONSUMERS                           5           0      
    0.0225314031431307
CONSUMERS                      IDX2_CONSUMERS                           5           1      
    12.0171673819742
CONSUMERS                      IDX2_CONSUMERS                           5           2      
    0
CONSUMERS                      IDX2_CONSUMERS                           5           3      
    0
(17 row(s) affected)
DBCC SHOWCONTIG('CONSUMERS') WITH ALL_INDEXES
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 56217
- Extents Scanned..............................: 7029
- Extent Switches..............................: 7028
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.99% [7028:7029]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.44%
- Avg. Bytes Free per Page.....................: 32.4
- Avg. Page Density (full).....................: 99.60%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 2, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 26032
- Extents Scanned..............................: 3256
- Extent Switches..............................: 3255
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.94% [3254:3256]
- Logical Scan Fragmentation ..................: 0.05%
- Extent Scan Fragmentation ...................: 0.31%
- Avg. Bytes Free per Page.....................: 11.1
- Avg. Page Density (full).....................: 99.86%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 3, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 53259
- Extents Scanned..............................: 6659
- Extent Switches..............................: 6658
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.98% [6658:6659]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.35%
- Avg. Bytes Free per Page.....................: 40.5
- Avg. Page Density (full).....................: 99.50%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 4, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 53258
- Extents Scanned..............................: 6659
- Extent Switches..............................: 6658
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.98% [6658:6659]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.53%
- Avg. Bytes Free per Page.....................: 40.3
- Avg. Page Density (full).....................: 99.50%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 5, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 53259
- Extents Scanned..............................: 6659
- Extent Switches..............................: 6658
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.98% [6658:6659]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.59%
- Avg. Bytes Free per Page.....................: 40.5
- Avg. Page Density (full).....................: 99.50%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
For the record, here's the version I'm running:
select @@VERSION
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 
 Jun 17 2011 00:54:03 
 Copyright (c) Microsoft Corporation
 Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
In summary my question is - why didn't ALTER INDEX ... REBUILD/REORGANIZE modify the index_level 1 fragmentation as reported by sys.dm_db_index_physical_stats, nor would it correct the Extent Scan Fragmentation as reported by DBCC SHOWCONTIG?

Hi Brian.cs ,
SQL Server will not rebuild indexes that are not large enough. Could you please have a look a the
fragment_count which is  one of the fields in the
sys.dm_db_index_physical_stats view to check whether it is low or not ?
Best Regards,
Peja
Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Peja, here's the information you requested, and of course this was after I dropped/recreated because rebuild didn't seem to actually address the fragmentation - the index I was most concerned about at index_level = 0 showed a fragment_count = 8922. FYI this
table has over 8 million rows. And apologies for the delayed response, was on vacation over the near year.
SELECT
 substring(OBJECT_NAME(i.object_id),1,30) AS TableName,
 substring(i.name,1,40) AS TableIndexName,
 i.index_id, phystat.index_level,
 phystat.avg_fragmentation_in_percent, fragment_count 
FROM
 sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat inner JOIN sys.indexes i 
ON i.object_id = phystat.object_id 
AND i.index_id = phystat.index_id WHERE
OBJECT_NAME(i.object_id) = 'CONSUMERS'
TableName                      TableIndexName                           index_id    index_level avg_fragmentation_in_percent
fragment_count
CONSUMERS                      UNI2K_CONSUMERS                          1           0        
  0.259780818806428            8922
CONSUMERS                      UNI2K_CONSUMERS                          1           1        
  39.4190871369295             86
CONSUMERS                      UNI2K_CONSUMERS                          1           2        
  0                            1
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           0           0.240887634434766    
       5182
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           1           80.3738317757009    
        84
CONSUMERS                      PK__CONSUMER__7F6B0B8B286302EC           2           2           0          
                 1
CONSUMERS                      UNI1K_CONSUMERS                          3           0        
  0.0661472879611936           8532
CONSUMERS                      UNI1K_CONSUMERS                          3           1        
  53.4883720930233             86
CONSUMERS                      UNI1K_CONSUMERS                          3           2        
  0                            1
CONSUMERS                      IDX1_CONSUMERS                           4           0        
  0.192426334498663            8598
CONSUMERS                      IDX1_CONSUMERS                           4           1        
  31.5315315315315             95
CONSUMERS                      IDX1_CONSUMERS                           4           2        
  85.7142857142857             7
CONSUMERS                      IDX1_CONSUMERS                           4           3        
  0                            1
CONSUMERS                      IDX2_CONSUMERS                           5           0        
  0.189494094835184            8613
CONSUMERS                      IDX2_CONSUMERS                           5           1        
  31.8840579710145             97
CONSUMERS                      IDX2_CONSUMERS                           5           2        
  85.7142857142857             7
CONSUMERS                      IDX2_CONSUMERS                           5           3        
  0                            1

Similar Messages

  • Alter index rebuild

    Hello, I want to rebuild an index :
    SQL> alter index APPLSYS.WF_LOCAL_ROLES_N1 REBUILD ;
    alter index APPLSYS.WF_LOCAL_ROLES_N1 REBUILD
    ERROR at line 1:
    ORA-14086: a partitioned index may not be rebuilt as a whole
    What is wrong with my sql instruction ? Should I give partition name may be ? Where can I find partition name for that index ? Many thanks before.

    [linuxas oracle test10]$ oerr ora 14086
    14086, 00000, "a partitioned index may not be rebuilt as a whole"
    // *Cause:  User attempted to rebuild a partitioned index using
    //          ALTER INDEX REBUILD statement, which is illegal
    // *Action: Rebuild the index a partition at a time (using
    //          ALTER INDEX REBUILD PARTITION) or drop and recreate the
    //          entire index
    [linuxas oracle test10]$To see partition names for an index :
    SQL> select partition_name from USER_IND_PARTITIONS
      2* where index_name = '<YOUR INDEX>';Paul

  • 'alter index rebuild' paralellism problem

    Hi,
    I have this problem described in example. I am using interMedia Text version 8.1.7 on Win32 platform ,
    Imagine two tables with the same structure, but in first there are big pdf files(size more than 1MB, lot of files) and in the second there are small files(less than 10KB, imagine few files).
    There are same preferences used for indexing( file_datastore, inso_filter..).
    If I run the alter index for first table, it usually takes long time. Than if I run the alter index for the second table, it always begin after the first will finish.
    Other combination work correctly :
    Running create index for first table and create index for second is done paralelly, runnig combination of create index and alter index (no matter for which table) is done paralelly too.
    The only problem is with runnig two alter indexes at the same time.
    The problem is about to index around 100 GB of documents by small steps - documents are added and indexed using alter index. Using create index is not possible, because whole system is backed up and switched off during night.
    So indexing process is interrupted.
    Thanks for every reply..
    Milan

    Please put your question in the Oracel text forumn for a quicker, more expert answer.

  • Alter index rebuild reverse duration

    Hi,
    I'm working on an Oracle Database 11g Release 11.1.0.6.0 - 64bit Production With the Real Application Clusters option.
    I would need to rebuild reverse 2 indexes, 60gb each.
    Is it possibile to forecast somehow the opreation duration?
    The alter index rebuild is locking (insert on those tables are locked), doesn't it?
    Thanks in advance,
    Samuel

    You can rebuild it online, but it will demand extra temporary space, and can take more time.
    ALTER INDEX INDX REBUILD ONLINE

  • Alter index rebuild calculates statistics?

    Hi
    Does anyone know if ALTER INDEX REBUILD gathers statistics on the index automatically? Does it do it at a 100% by default?
    Thanks for your help!!!

    On 10g+ the alter index command defaults to compute statistics which to the best o my knowledge is a 100% sample. With lower versions you need to specify that you want statistics: alter index owner.index_name rebuild compute statistics;
    HTH -- Mark D Powell --

  • TS1424 itunes purchase security questions & answers reset and answered correctly.  Can not log in with updated answers which state one or both are incorrect.

    Can anyone help with this situation?
    itunes purchase security questions & answers reset and answered correctly.  Can not log in with updated answers which state one or both are incorrect.

    You need to contact Apple to get the questions reset. Click here, phone them, and ask for the Account Security team, or fill out and submit this form.
    (94948)

  • Alter index rebuild question

    Hello experts,
    I have a simple question regarding rebuilding indexes...
    First, I am running 11.2.0.2 on Solaris 10.
    My reason for rebuilding is to relocate the indexes to their own tablespace, and while I recognize this is a subjective reason as far as performance is concerned, it makes administration easier.
    That being said, my question is in regards to use of "compute statistics" and also "online", and "nologging".
    Since I do want to minimize he impact to our users, and this table is one of the most used tables in the database, my syntax was going to be as follows:
    alter index <schema>.<index> rebuild online nologging tablespace <ts_idx> compute statistics;
    Questions:
    1.   does doing the rebuild online preclude queries against the table during the duration of the rebuild?
    2.   does use of nologging improve speed of rebuilding
    3.   is it advisable to include the "compute statistics".  I believe I read on Jonathan Lewis' page that statistics are gathered automatically and to include "compute statistics" was not necessary when rebuilding an index.
    And I guess one final question is whether I can include all the options in the same rebuild statement as I have shown above?
    I've tested the above in our test database, but it seems to hang when using the online option (with all the other options).
    Thanks in advance.

    Excellent resource.  Thanks for the link.  While I've read most of those discussions on either Jonathan's or Richard's web sites already, it is a good presentation and reference.
    Unfortunately, it does not answer either of the questions that I asked.  The reason I asked those questions is because the answers you gave contradict what i read in Oracle documentation (although it might be version specific).
    Also, it does seem to be slightly faster to rebuild using nologging (in my test environment).
    I've tested this with multiple indexes and the timing is slightly improved consistently.
    {quote}
    SQL> ALTER INDEX ARADMIN."T2179_C1_0944_1037" REBUILD LOGGING TABLESPACE REMEDY_IDX;
    Index altered.
    Elapsed: 00:00:10.68
    SQL> ALTER INDEX ARADMIN."T2179_C1_0944_1037" REBUILD nologging TABLESPACE REMEDY_IDX;
    Index altered.
    Elapsed: 00:00:08.50
    {quote}
    The use of online, however, seems to "hang" for some reason, even in my test database while no one else is logged into the database except me.
    Referencing Oracle's documentation, it says that rebuilding an index online does not allow queries against the base table.  This is why I asked this question, but your answer is different than Oracle's.  In this case, however, it is for Oracle 10.2, so not sure if this is still true for 11.2.
    Ref.  Oracle Text SQL Statements and Operators
    [ONLINE]
    ONLINE enables you to continue to perform updates, inserts, and deletes on a base table; it does not enable you to query the base table.
    You cannot use PARALLEL with ONLINE. ONLINE is only supported for CONTEXT indexes.
    Now, regarding the use of "compute statistics", I am pretty sure I recall reading either in Jonathan's papers, or in Richard's papers, that this is not necessary and/or is redundant.  But then why would Oracle include this as an option.  This is counter intuitive, which again is why I'm asking.  Do you know if any reference that can clear this up?

  • Alter index rebuild with online option

    I created a spatial index with the following statement:
    SQL> create index A3_IX1_A on A67(GEOMETRIE) indextype is mdsys.spatial_index parameters ('sdo_non_leaf_tbl=TRUE; sdo_dml_batch_size =
    2 1000');
    I want to rebuild the index with the next statement:
    SQL> alter index ttnl.A3_IX1_A rebuild online parameters ('index_status=cleanup;sdo_dml_batch_size=1000');
    the result is the next error message:
    alter index ttnl.A3_IX1_A rebuild online parameters ('index_status=cleanup;sdo_dml_batch_size=1000')
    ERROR at line 1:
    ORA-29871: invalid alter option for a domain index
    Can some one help me?

    Hi,
    This is only supported in the next release (11.x).
    In the release upto 10.2, this functionality is not supported for Spatial indexes.
    siva
    Message was edited by:
    sravada

  • Question about cname and google indexing?

    I hope someone can help me out with this.
    I use a web address and have it forwarded to my .Mac hosted website. I have always been told that when getting indexed on Google and others, you need to use your iWeb domain name/address for it to accurately find you on the web. With the new cname, can you now use your redirected web domain for indexing in Google? Will Google find the regular web address now?
    Thanks.
    Todd

    from my understanding google will pick it up

  • Indexing rebuild does not work

    The Windows.edb file is 49GB now.  I want to erase this file and rebuild the search index.  I clicked the Rebuild button, but nothing happens.  Could anyone shed some light on this?
    Hong

    Hi,
    Sorry for not being clear, the KB2836988 is just applied to Windows 8 or Windows server 2012 indeed. What I mean above is suggest you follow its following method to reduce Window.edb file size:
    How to delete and rebuild index
    How to offline defrag the index
    On the other hand, the kb already note that:
    This update is preventative, but not corrective. To reduce the size of a Windows.edb file that is already affected by this issue, you must rebuild the search index after you install this update.
    Therefore, it's a better choice to follow these two method fix this problem.
    Roger Lu
    TechNet Community Support

  • Clearing browser pushed content and cookies...​not effective

    I use my BB browser for buying stuff of the internet. As added protection I log out faithfully and clear my browser cache operations and history constantly. I've also unenabled push content on my Browser push. When I go to a website, after I've cleared every thing, the home page comes up with my country !!!!! How can this company still know where I'm from if all history and caches have cleared from my browser and I should be starting with a clean slate ? How can Big Brother still be watching me... ?

    Since you already tried the clear Cache and Youtube cookie trick.
    Try making the youtube url as http'''s''':// if a youtube video is still giving the black screen.
    It is apparently a issue with Youtube as people with other browsers are getting the same. http://www.google.com/support/forum/p/youtube/thread?hl=en&tid=3cda4dac122b8f13

  • ALTER INDEX  .. REORGANIZE vs.REBUILD

    What is the difference between ALTER INDEX .. REORGANIZE and ALTER INDEX .. REBUILD ?
    Thanks, Christine & Danny

    Are you talking about Oracle here?
    There is no REORGANIZE with ALTER INDEX. Its valid command for SQLServer.
    If you are talking about SqlServer here, then, read the article from the below link:
    http://msdn2.microsoft.com/en-us/library/ms189858.aspx
    If you are concerned about Oracle's ALTER INDEX REBUILD, read my blog about functionality/machanism of rebuilding index online and normally, Part 1 and Part 2.
    http://jaffardba.blogspot.com/search/label/Indexes

  • Alter index ... rebuild was failing - getting corrupt blocks

    Database: 9.2.0.5
    OS: HPUX-ia64
    Hello,
    i rebuilded a index, announced from UpdatStats in DB13, and get a ORA-01114: IO error writing block to file 2045 (block # 319154) and
    ORA-27072: skgfdisp: I/O error in my sqlplus session.
    -> i do a alter index SAPR3."xxx~0" rebuild online parallel 4 nologging;
    -> System was up and running
    After that, the DBVerify marked some blocks corrupt, here one example:
    BR0398E DBVERIFY detected corrupted blocks in /oracle/XXX/sapdata22/btabi_95/btabi.data95
    We checked all corrupted blocks - all in free space.
    So we fixed that with creating a table with next extend size from the corrupted blocksize.
    I think we had not enough space in the tablespace where the index is, okay ... and what we also found, the PSAPTEMP datafiles was created as SPARSE files ...!!
    -> PSAPTEMP-Datafile: 10GB in the System - 2,5GB maximum on OS-Level, no more space.
    But my question is why i am getting corrupt blocks when a "alter index ... rebuild ..." is failing ?!?!
    Thank you for your support.
    Regards,
    Markus
    Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
    Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
    Edited by: Markus Dinkel on Oct 9, 2008 12:59 PM

    Thany you for the answer.
    I cant find any "cor" entries in the last DBVeriy log.
    I think (hope) we dont' have anymore corrupted blocks in the system.
    We get a response from SAP to update to 9.2.0.8.
    My customer wanna do a update to oracle 10 in march/april 2009, so he send me the question if we need a update to 9.2.0.8 ASAP or can we wait for the update to oralce10.
    But the important question from my customer and me is, why we get corrupt blocks after failing the alter index rebuild?
    Regards,
    Markus

  • Goldengate Extracts reads slow during Table Data Archiving and Index Rebuilding Operations.

    We have configured OGG on a  near-DR server. The extracts are configured to work in ALO Mode.
    During the day, extracts work as expected and are in sync. But during any dialy maintenance task, the extracts starts lagging, and read the same archives very slow.
    This usually happens during Table Data Archiving (DELETE from prod tables, INSERT into history tables) and during Index Rebuilding on those tables.
    Points to be noted:
    1) The Tables on which Archiving is done and whose Indexes are rebuilt are not captured by GoldenGate Extract.
    2) The extracts are configured to capture DML opeartions. Only INSERT and UPDATE operations are captured, DELETES are ignored by the extracts. Also DDL extraction is not configured.
    3) There is no connection to PROD or DR Database
    4) System functions normally all the time, but just during table data archiving and index rebuild it starts lagging.
    Q 1. As mentioned above, even though the tables are not a part of capture, the extracts lags ? What are the possible reasons for the lag ?
    Q 2. I understand that Index Rebuild is a DDL operation, then too it induces a lag into the system. how ?
    Q 3. We have been trying to find a way to overcome the lag, which ideally shouldn't have arised. Is there any extract parameter or some work around for this situation ?

    Hi Nick.W,
    The amount of redo logs generated is huge. Approximately 200-250 GB in 45-60 minutes.
    I agree that the extract has to parse the extra object-id's. During the day, there is a redo switch every 2-3 minutes. The source is a 3-Node RAC. So approximately, 80-90 archives generated in an hour.
    The reason to mention this was, that while reading these archives also, the extract would be parsing extra Object ID's, as we are capturing data only for 3 tables. The effect of parsing extract object id's should have been seen during the day also. The reason being archive size is same, amount of data is same, the number of records to be scanned is same.
    The extract slows down and read at half the speed. If normally it would take 45-50 secs to read an archive log of normal day functioning, then it would take approx 90-100 secs to read the archives of the mentioned activities.
    Regarding the 3rd point,
    a. The extract is a classic extract, the archived logs are on local file system. No ASM, NO SAN/NAS.
    b. We have added  "TRANLOGOPTIONS BUFSIZE" parameter in our extract. We'll update as soon as we see any kind of improvements.

  • Index rebuild - temporary segment

    Hi,
    I am getting an error while rebuilding the indexes, like unable to allocate extents in temporary segment. Kindly help me to solve this.
    Regards,
    Mathew Collins

    You should never drop an index with the intention of recreating it without first checking the size of the index against the size of the available temp tablespace sort area.
    If you are using an alter index rebuild to reorganize the index then unless you specify a new tablespace in the command the existing tablespace must have enough free space to hold the entire original index and the rebuilt index. An alter index rebuild also uses temporary (sort) tablespace so you still need to ensure that your index has not outgrown your temp tablespace.
    HTH -- Mark D Powell --

Maybe you are looking for