Why Indexing Rebuild Again and Again

Hi Team,
I am facing issue outlook stander ed edition 2010 indexing rebuilding again and again on local system due to this unable to search old email it happens twice in a week or in two days.
Please help me to resolve the same thanks to you all.

Hi,
Please make sure your Outlook is fully patched. And we can try the following changes:
1. Create a new Outlook profile:
http://support.microsoft.com/kb/829918
2. Start Outlook in safe mode:
Click Start > Run > Outlook /safe
3. If it doesn’t work, please perform a clean boot in Windows:
http://support.microsoft.com/kb/929135/en-us
4. Then rebuild Indexing in Outlook 2010 until it is complete:
Click File > Options > Search > Indexing Options > Advanced > Rebuild.
Regards,
Winnie Liang
TechNet Community Support

Similar Messages

Index rebuild

Hi Team,
Please tell me any difference b/w alter index <index> rebuild or alter index <index> rebuild move.
Is there any difference that more space will be released if I move index to diffrenet tablespace and move move back to orginal tablespace.
I know that if we use move option we can move index to different tablespace,
Regards,
jit

Even if you would do lots of dml's, that's not certainly means that you need the rebuilding of the index. If your assertion is based on this that there would be some "holes" within the leaf blocks which wont be reused and would require a rebuild, it's wrong then since Oracle would take care of these things on its own. So again, what criteria, other than an OLTP db you used to conclude that you need rebuilding of indexes?
But I just wanted to know If I go for alter index rebuild or alter index rebuild move and move back the indexes, which option will be best for me mean by which option I can reclaim more space.Well, I am sorry to say but I think you really don't know very well both the commands. The commands don't differ in the space reclaim given by them but in the way they do the rebuild. Please read the documentation to know what both commands do and how? BTW, from where you picked the command alter index rebuild move since I am not sure that such command exists?
Aman....

I have downloaded Firefox 4.0 several times and after a short amount of time (days) it reverts back to 3.6.16. Why does it happen and how do I prevent it from happening again?

The Firefox 4.0 on my laptop reverts back to 3.6.16. This has happened several times. Why does this happen and/or how do I prevent it from happening again?

Thanks for the link. I just downgraded to the absolute shtfest that's 4.0. I WAS just fuming about how gawdawful this "new" version is, but after wasting so much time trying to sort thru all the issues caused by this 4.0 downgrade (past updates have always been seamless and troublefree - not so for this shtfest!) I'm flat-out RAGING!!! Fortunately the laptop still has 3.6.xx running - it's the LAST version of Firefox it will EVER see. I switched to Firefox so many years ago to get away from the insanity and frustration of Explorer - if this 4.0 crapshoot is the "future" of Firefox, then the incompetent nimrods responsible for it know where they can ram it. I'm starting the search for a new browser now - so long Firefox, it's been fantastic while it lasted, but you've gone and screwed the pooch, you've ruined a superb browser!
I'll attempt a reload of 3.6.xx on the desk machine, and if successful I'll run it till it drops, or I find a suitable replacement browser, but 4.0 won't be coming back - GOOD RIDDANCE!!!

The last 3 or 4 times I have tried to access my account, it has told me it has been deactivated and I have to reset each time, or give credit card info again. Why is this happening and how do I stop it?

The last 3 or 4 times I have tried to access my account, it has told me it has been deactivated and I have to reset each time, or give credit card info again. Why is this happening and how do I stop it?

You must contact iTunes support to get the problem resolved.
http://www.apple.com/support/itunes/contact/
If there is a problem with your account or payment info, you cannot
download anything (including free apps or updates) until the matter
is resolved.
In countries where the iTunes Store only sells apps, the accepted payment methods are Visa, MasterCard, and American Express. Other payment types such as gift cards, store credit, monthly allowances, ClickandBuy, and PayPal are not accepted. Depending on your App Store country, prices may be listed in your local currency, US Dollars, or Euros. http://support.apple.com/kb/HT5552

I'm missing thumbnails... have rebuilt twice... then did a permissions repair before I try and rebuild again... any suggestions?

Need help with missing thumbnails...Iphoto11... have rebuilt twice, which took hours... rebuild works but when I close app and reopen, they are missing again. Did a premission repair in disk utilty and Iphoto, getting ready to rebuild again to see if it sticks this time... if not, any suggestions? I don't want to lose my images. Thumbnails are blank, but clicking image shows they are there.... so I know they are still on the computer.... not sure what to try next????

Download iPhoto Library Manager and use its rebuild function. This will create a new library based on data in the albumdata.xml file. Not everything will be brought over - no slideshows, books or calendars, for instance - but it should get all your albums and keywords back.
Because this process creates an entirely new library and leaves your old one untouched, it is non-destructive, and if you're not happy with the results you can simply return to your old one.

Rebuild Index VS Drop and Rebuild?

Hey all,
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation) for specific indexes that get massive updates. The old process has proved to be able to fix and maintain reports performance.
In this process we rebuild specific indexes using the below command:
Alter index index_name rebuild online;
This command takes around 10 min for selected indexes.
Testing the below took 2 min for 6 or 7 indexes.
Drop Index Index_Name;
Create Index Index_Name on Table_name (Col1, col, ..);
I know that indexes might not be used, and the application performance would be degraded with stale or non-existent stats. But our production and all our test DBs have procedures that daily gather stats on them.
I tested the below script to make sure that execution plan does not change:
SELECT ProductID, ProductName, MfrID FROM PRODUCT WHERE MFRID = 'Mfr1';
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 37 | 3737 | 13 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| PRODUCT | 37 | 3737 | 13 (0)|
| 2 | INDEX RANGE SCAN | PRODUCT_X1 | 37 | | 3 (0)|
dropping PRODUCT_X1 and recreating it only changed the cost to 12.
Gathering the stats again took the cost to 14.
No performance issues were faced and index was still used.
My question is: Is there any oracle recommendation that requires rebuilding the index instead of dropping and recreating it?
Is there any side effect to my approach that I did not consider?
Thank you

Charlov wrote:
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation)Nice. Not only have you defined and located index fragmentation but have also measured the rate at which it occurs.
Could you please share your definition of index fragmentation, how you detect it, and how you measure the rate of change of this fragmentation.
I am curious about all this since it can be repeatedly shown that Oracle btree indexes are never fragmented.
http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth-ii.pdf
The old process has proved to be able to fix and maintain reports performance.Great so you have traces and run time statistics from before and after the rebuild that highlight this mysterious fragmentation and show how the fragmentation caused the report to be slow, details what effects the rebuild had that caused the reports to perform better.
Please share them as these would be an interesting discussion point since no one has been able to show previously how an index rebuild caused a report to run faster or even show the fragmentation that caused it to be slow in the first place.
I mean it would be a pity if the report was just slow because of an inefficient plan and compressing an index or two that probably shouldn't be used in teh first place appears to temporarily speed it up. Could you imagine rebuilding indexes every week, because some developer put the wrong hint in a query? That would be pretty funny.

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

My ipad 3 keeps on downloading all my emails that is already downloaded, why donwload it again if I already downloaded it.

My ipad constantly download emails that is already downloaded in my ipad.
I never delete any mails as I use my ipad for business and need to go back to confirm emails and orders.
A 1000 emails gets downloaded every day at least 3 times, why download it again if its already downloaded.

Gryphon65 wrote:
Does that means that if the developer have 2 version, on for iPad and another for iPhone, i have to pay for both copy?
If the developer makes two versions of the app, one for the iPhone and one for the iPad, rather than a universal app and the developer choses to charge for both, you will have to pay for both if you want both.

Why are photos again available on the fotostream even that I have deleted them?

Hi,
why are photos again available on the Fotostream, even that I have deleted them with using an iphone?

Hi Ghallsa,
I don't know why you believe that emails would be using 6go if you deleted them all. I think you concluded this from the available space left and what you know is using space. You have to understand that what is taking storage space is not only apps, music and emails. There is also the iOS which is taking space as well as a lot of data cached on your devices that will usually be shown as 'Other' category if you are to look at your space usage from iTunes.
If the total 'Other' space appears excessive, I suggest you should 'restore' your device (after a full recent backup); this sometimes helps to remove any data left behind. But before this, try a look at Settings->General->Usage->Manage Storage. This will list apps from the most space consuming to the less. It could also help you to identify which apps may take to much of your precious space not only by apps size but also from the data the apps had stored.
good luck,

Different b/w index rebuild and index rebuild online

hi..guys could u plz tel me difference between index rebuild and index rebuild online

There is no difference in both the commands. Both will rebuild the index structure from the scratch.But in the first case with only Rebuild, as long as the index, its temporary segment is not prepared and merged together, index is not available for the other users for use. The Online clause makes the index available for others even while being rebuild.
Rebuilding index online has the same concept of creating them online to some extent,
http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/indexes.htm#3062
HTH
Aman....

Difference between "REBUILD ONLINE" and "REBUILD" while altering index

Hi Everyone,
Please go through this link.
[http://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes004.htm#i1006864]
Now if Rebuilding online enables you to update base tables at the same time that you are rebuilding, then when the base table is getting updated while Rebuilding without online option?
Regards,
BS2012

Hi,
I believe it work like this way
rebuild without online option => table and index is locked in exclusive mode preventing any translations on the table.
With online index rebuild, transactions can still access the table and index.

How to find out if an INDEX is corrupt and how to rebuild it ?

How can I find out (from SQL script) if a given INDEX is corrupt and needs to be rebuild ?
And how do I rebuild it ?

How can I find out (from SQL script) if a given INDEX is corruptin 9i (not sure about 10g):
ANALYZE INDEX index_name VALIDATE STRUCTURE ;

Gathering schema Statistics and Index rebuilding

I want to know after how much time we must gather the schema Statistics and Index rebuilding.
In our system approximately 7 logfile generates in one day
Please suggest me

Index rebuilding sounds so much Oracle 7! Indexes today generally take care of themselves quite well, throughout inserts, deletes and updates. It rebalances itself automatically when necessary, without requiring any rebuild. As for the stats, run it for sure after large data movements (i.e. deletes and inserts). Besides that, implement table monitoring for your tables, and run once in a while dbms_stats with the options parameter as GATHER STALE. That way, Oracle will automatically know which objects need their stats refreshed.
Daniel

When rebuild table and index

Hi,
how to know if for a table we should rebuild table and index ?
Many thanks.

Safi, I would be less sure than that. There were many many very long threads in database general forum about that subject. If you observed that fact once, that is not very often the case.
@OP,
Assuming the question was not about performance, but more on AppDesigner side (because of rebuild table), what I can say is :
1. Peoplesoft store all the storage definition for all the objects in its own metamodel tables
2. when you are changing field definition (column's definition) or indexes definition, the new definition is stored in the Peoplesoft metamodel tables
3. On the table/index build, AppDesigner compare the Peoplesoft metamodel definition for that particular object with in the Oracle (or what ever else database you are using) definition of that same object.
4. If the defintions reported on step 3 are different, then AppDesigner will fill a file with all the (re)build statements of the objects you are rebuilding (and different).
5. Finally, you just have to run the generated script.
Of course, you can bypass the comparison by enforcing AppDesigner the (re)build the record/index in all cases, however, it is not always (do not say never) recommanded.
Now, when you have to rebuild table (or record in AppDesigner's word) or indexes ? Basically, by the previous explanation I gave above, you could understand this is when you are changing a field/table/index definition through AppDesigner.
Nicolas.

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.

Why Indexing Rebuild Again and Again

Similar Messages

Maybe you are looking for