Online Rebuild Index Vs Shrinking With Compact Segment with Release space

Hi All,
I want to know which is the better option from these as far as availabiltiy of index
is concerned
I have been doing online INdex rebuild and haven't faced much problems but new to Shrinking
What Grid COntrol says about shrinking is
"This will first compact the segments and then release the recovered space to the tablespace.
During the short space release phase, any cursors referencing this segment may be
invalidated and queries on the segment could be affected"
I dont know how much is that affect...Can anybody share their experience and knowledge
about shrinking .....
My Idea is to reclaim the space from the INdexes
Thanks
Gagan

It depends on many factors of which you have mentioned none.
The affect of cursor invalidation, for example, might be different on Monday than on Tuesday.
You should test this in as real a simulated environment as you can but likely any issues will be minimal.
Just don't be surprised by a surprise or two.

Similar Messages

Will Rebuild Index (use brspace) also release hard disk space ?

Dear all,
I use brspace to rebuild my SAP Oracle table weekly, I just want to know :
Other than index reubuild, will brspace also release hard disk space to me because I found some times, after having index reubild, my free hard disk space increases.
Am I correct ?

> I use brspace to rebuild my SAP Oracle table weekly, I just want to know :
Why the heck are you doing that? Too much time?
> Other than index reubuild, will brspace also release hard disk space to me because I found some times, after having index reubild, my free hard disk space increases.
Whatever freed space on your harddisk, it had nothing to do with the Index rebuilds!
Once allocated Oracle won't ever release space in the filesystem unless you drop or resize datafiles.
regards,
Lars

Multiple objects with same name when rebuilding index online

I am looking for advice on how to handle a race-condition in sql server, related to reading metadata while an online index rebuild is being performed.
The problem is as follows:
At some point we execute the following statement:
SELECT
obj.object_id AS id,
scm.name AS scm,
obj.name AS name,
obj.type AS type,
ds.name AS dataspace_name,
prop.value AS description,
part.data_compression_desc as compression_desc
FROM sys.objects AS obj
INNER JOIN sys.schemas AS scm ON obj.schema_id = scm.schema_id
INNER JOIN sys.indexes AS idx ON obj.object_id = idx.object_id AND idx.type IN (0,1)
INNER JOIN sys.data_spaces AS ds ON idx.data_space_id = ds.data_space_id
INNER JOIN (SELECT object_id, data_compression_desc FROM sys.partitions WHERE index_id IN (0,1) /*Heap, Clustered*/) AS part ON part.object_id = obj.object_id
LEFT OUTER JOIN sys.extended_properties AS prop ON obj.object_id = prop.major_id AND prop.minor_id = 0 AND prop.class = 1 AND prop.name = 'Description'
WHERE obj.type = 'U' OR obj.type = 'S'";
The statement returns some metadata for indexes (indices?), the purpose of wich is not the subject.
When executed while an online index rebuild is running, a race condition occurs: When the rebuilding enters the final phase, the new index, which have the same name, becomes visible and thus results in two rows with the same name (from sys.object). I am unaware
if this only occurs for clustered index (which is what we have observed).
We became aware of this behaviour, as we added the metadata to a .Net Dictionary using name as key, and received a duplicate key exception. We have, hoewever, not been able to reproduce the situation, due to the nature of the race condition, and we found very
little documentation on the subject.
What we would like to do now, is to differentiate between the two. We see two options:
1) We could just use the first of the rows and ignore the second. This solution would require that the metadata for both rows are identical.
2) We could discern the "real" index from the "rebuilding" index. This requires some kind of extension of the Where-part.
We have not been able to determine if the requirements for either option is present, as we havent found any documentation, nor have we been able to test for differences, as we cannot reproduce the situation.
We would also like some way of reproducing the situation, so ideas as to how to do that is welcome.
Can anyone direct me to relevant documentation, or alternate solutions.
HRP

1. Use the index with the lower fragmentation to identify the newly rebuilt index (as it almost always will have lower fragmentation)
2. To reproduce, block the online index rebuild process by trying to alter the table's definition in a transaction (and don't commit, which will place schema lock on the table)
Satish Kartan http://www.sqlfood.com/

Seqment shrink with function based indexes - 10.2.0.3

I see 10g Rel 2 limiation with function based index while doing segment shrink. Is their a workaround? I tried to drop the function based index before shrink, still shrink is taking several hrs to complete.
Any help is appreciated.
Thanks,
Siva

Hi,
Analogy: suppose you have 1 million barrels filled with water near 85% maybe less, now you spilled ...say 40% the total water, maybe you have 400,000 empty barrels or the equivalent (here comes the overhead) you are going to concentrate the water in 600,000 barrels and return the empty ones to the "Oracle Server" store, just to reclaim them gradually until you have the starting 1 million barrel.
Our advise: keep the objects as they are, both table and index. Oracle will use released space as efficiently as he can, which is (at that level) better than us.
You're worried about the index space? much better leave it now, that's the structure which may cause the major part of overhead.
Regards
Ignacio
http://oracledisect.blogspot.com

Shrink Database (Rebuild Indexes)

Hi
I would like to know that, If I shrink my DB and started rebuilding indexes how much time it would require to rebuild a DB of size 1 GB.
Thanks ...
Manish

Why to shrink, as you probably know after rebuilding in may grow again :-)))
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence

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.

Issue in rebuilding index after restoring database from sql server 2005 to 2012

Hi All,
We have recently restored a database named DBA_admin from our sql server 2005 instance to sql server 2012 and we have added the database to out weekly maintenance plan. After adding the database to maintenance plan the job is failing every weekend due to
below error message.
Error message from maintenance plan history:
Executing the query "ALTER INDEX [PK_lsttype] ON [dbo].[lstAssign..." failed with the following error: "Invalid object name 'admin.dbo.databaselog'.
ALTER_INDEX - dbo.PK_lsttype". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Below is the code within the maintenance plan which the rebuild index task is using for database dba_admin:
USE [dba_admin]
GO
ALTER INDEX [PK_lstType] ON [dbo].[lstType] REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 98, DATA_COMPRESSION = PAGE)
Please let me know if any one knows how to fix this issue.
Thanks in Advance.

Sorry for the confusion.
Here is what is happening.
The query is failing while trying to rebuild index [Pk_lsttype] on table [lstAssign], both these objects belong to database
admin.
I have verified the old instance there is table databaselog within the database
dba_admin, but in new SQL instance within the database dba_admin the table is not present.
Even I'm not sure of what this table databaselog has to do with rebuilding indexes on table
lstAssign within the admin database.
I have manually tried to execute the alter index command within the database
admin and it is failing with the below error.
ALTER_TABLE - dbo.Query_pnb_sms
Msg 208, Level 16, State 1, Procedure ddlDatabaseTriggerLog, Line 39
Invalid object name 'dba_admin.dbo.databaselog'.

REBUILD INDEX vs DROP/CREATE INDEX

Hi there,
Does anyone has already got some performance degradation after REBUILD INDEXes ? Would it be better to perform DROP/CREATE INDEX instead ?
Thank you very much for anu reply.
Best regards,
Helena

Hi,
>>so is it then better to DROP/CREATE them ?
Well, In fact I learned that when you rebuild an index, Oracle creates a new index from the old index and does not perform sorting while building the new index, which results in performance enhancement. In this case, depending of the size of your data it's necessary sufficient space on a tablespace for storing the old as well as the new index (while creating the new index). Other advantage, is that Oracle can use the old index for answering queries while it builds the new index too using [alter index <index_name> rebuild online].
Cheers

"analyze index" vs "rebuild index"

Hi,
I don't undestand the difference between "analyze index" and "rebuild index".
I have a table where I do a lot of "insert" and "update" and "query", What is the best thing to do ??
thanks
Giordano

When you use dbms_stats.gather_schema_stats package with cascade=>true option, you are also collecting stats for the indexes, no need to collects stats separately using dbms_stats.gather_index_stats.Of course, but I refered to the rebuild index question. Therefore I only mentioned the GATHER_INDEX_STATS.
Auto_sample_size has many problems/bugs in 9iOk didn't know that - I'm using 10gR2.
But this discussion made me curious. So I tried something (10gR2):
CREATE TABLE BIG NOLOGGING AS
WITH GEN AS (
SELECT ROWNUM ID FROM ALL_OBJECTS WHERE ROWNUM <=10000)
SELECT V1.ID,RPAD('A',10) C FROM GEN V1,GEN V2
WHERE ROWNUM <=10000000;
SELECT COUNT(*) FROM BIG;
COUNT(*)
10000000
So I had a Table containing 10 Million rows. Now I indexed ID:
CREATE INDEX BIG_IDX ON BIG(ID)
I tested two different methods:
1.) GATHER_TABLE_STATS with estimate 10%
EXEC DBMS_STATS.GATHER_TABLE_STATS(TABNAME=>'BIG',OWNNAME=>'DIMITRI',CASCADE=>TRUE,ESTIMATE_PERCENT=>10);
It took about 6 seconds (I only set timing on in sqlplus, no 10046 trace) Now I checked the estimated values:
SELECT NUM_ROWS,SAMPLE_SIZE,ABS(10000000-NUM_ROWS)/100000 VARIANCE,'TABLE' OBJECT FROM USER_TABLES WHERE TABLE_NAME='BIG'
UNION ALL
SELECT NUM_ROWS,SAMPLE_SIZE,ABS(10000000-NUM_ROWS)/100000 VARIANCE,'INDEX' OBJECT FROM USER_INDEXES WHERE INDEX_NAME='BIG_IDX';
NUM_ROWS SAMPLE_SIZE VARIANCE OBJEC
9985220 998522 ,1478 TABLE
9996210 999621 ,0379 INDEX
2.) GATHER_TABLE_STATS with DBMS_STATS.AUTO_SAMPLE_SIZE
EXEC DBMS_STATS.DELETE_TABLE_STATS(OWNNAME=>'DIMITRI',TABNAME=>'BIG');
EXEC DBMS_STATS.GATHER_TABLE_STATS(TABNAME=>'BIG',OWNNAME=>'DIMITRI',CASCADE=>TRUE,ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE);
It took about 1,5 seconds. Now the results:
NUM_ROWS SAMPLE_SIZE VARIANCE OBJEC
9826851 4715 1,73149 TABLE
10262432 561326 2,62432 INDEX
The estimate 10% was more exact - also a 1,7 and 2,6 percent variance is still ok. It's also very interesting, that using AUTO_SAMPLE_SIZE
causes oracle to execute a estimate 5% for the index and a estimate 0.5 for the table.
I tried again with a table containing only 1 Million records and oracle did an estimate with 100% for the index.
So for me I will continue using AUTO_SAMPLE_SIZE. Its very flexible, fast and accurate.
Dim
PS: Is there a way to format code like one can do in HTML using <code> or <pre>?

Rebuild index vs Analyze index

Hi All,
I am realy confused about rebuilding index versus Analyzing index.
Could anyone plz help me out what is the diffrence between them.
How to Perform analyze of indexes and Rebuld of Indexes for both Oracle 9i and 10g databases.
Thanks a lot

CKPT wrote:
You can see the posts of experts by jonathan
I am realy confused about rebuilding index versus Analyzing index. tell us you are getting confused why we need to ananlyze before reubild index? if so
if index analyzed the whole statistics of index will be gathered.... then you can check what is the hieght of the index.. according to the height of the index you need to take step is index need to be really rebuild or not...
lets see furhter posts from experts if not clear..Thanks OK, so you determine the height of an index is (say) 4. What then ? If you decide to rebuild the index and the index remains at a height of 4, what now ? Was it really worth doing and do you rebuild it again as the index height is still 4 and still within your index rebuild criteria ? At what point do you decide that rebuilding the index just because it has a height of 4 is a total waste of time in this case ?
OK, so you determine the index only has a height of (say) 3, does that mean you don't rebuild the index ? But what if by rebuilding the index, the index now reduces to a height of just 1 ? Perhaps not rebuilding the index even though it has just a height of 3 and doesn't currently meet your index rebuild criteria is totally the wrong thing to do and a rebuild would result in a significantly leaner and more efficient index structure ?
So what if it's pointless rebuilding an index with a height of 4 but another index with a height of 3 is a perfect candidate to be rebuilt ?
Perhaps knowing just the height of an index leaves one totally clueless after all as to whether the index might benefit from an index rebuild ...
Cheers
Richard Foote
http://richardfoote.wordpress.com/

SCCM database Modified date doesn't change / rebuild indexes

Hi all,
I have 2 questions
1)
We have a month ago upgraded our SCCM environment from SCCM 2012 RTM -> SCCM 2012 SP1 (no CU), and we have upgraded SQL 2008 R2 (CU6) to SQL 2008 R2 SP2.
We have a SCCM 2012 primary site and an SCCM 2012 CAS site from both these sites its database file has not changed its modified date since the data of upgrade (SQL is installed on the same server so the database is local). However the WSUS database and the
reporting DB that exist on the same server updates its modified date.
SCCM is running and all status messages are OK. All component status's are updating and have correct dates based on when e.g. the last backup ran (that is at 6 pm every night) with no errors. To make a long story short, everything works
as it should. Deployments and advertisements and OSD arrive, collections get updated, no errors appear in the log files or in the component or site status, but the database on these servers (CAS and Primary) does not modify its date. SCCM backup of these servers
is running and the database file in that backup also contains the same modified date.
Anyone knows why this happens , or do we have an issue ?
2)
Maintenance task rebuild indexes
Is there a best practice according to the maintenance task rebuild indexes?
In our environment we have not enabled this maintenance task, both sites run for over one year.
Can we enable this task without disturbing or is it a better idea to enable this task in the weekend when there is less workload , and afterwards schedule this task once a week
regards and thx in advance
Johan

As stated “The time stamp will also change if the database files size are expanded as well when the database grow”
does that mean that after our upgrade a month ago the database has not grown with new data??
It depends. Data might have been added to the database (which it was fur sure with ConfigMgr), but the timestamp will only change if the file size was increased too. That has something to do with the initial and max file size settings in SQL and the autogrowth
settings.
Torsten Meringer | http://www.mssccmfaq.de

SSIS 2008 Rebuild Index Task increasing Log Size

I am testing SSIS 2008 Rebuild Index Task on a single database (db1). I shrank the
db1's log file to initial size. I also checked the box Sort results in tempdb on the SSIS package.
However, when I run the package, db1's log file size increased about 55 times the original size.
When I run a rebuild of all the index on db1
with (sort_in_tempdb=ON) ; there was only a slight increase in the log file size ( did not even double the initial size).
Is this a SSIS bug? The check box is not actually sorting in tempdb?

I am testing SSIS 2008 Rebuild Index Task on a single database (db1). I shrank the
db1's log file to initial size. I also checked the box Sort results in tempdb on the SSIS package.
However, when I run the package, db1's log file size increased about 55 times the original size.
When I run a rebuild of all the index on db1
with (sort_in_tempdb=ON) ; there was only a slight increase in the log file size ( did not even double the initial size).
Is this a SSIS bug? The check box is not actually sorting in tempdb?
Arthur can you please move this thread in Database engine forum. IMO its what changed from 2008 .Index rebuild is fully logged from 2008 onwards it was previously (in 2005) minimally logged .Refer below link for information regarding same
http://support.microsoft.com/kb/2407439/en-gb
Now about when sort intempdb is used.The intermediate sort results that are used to build the index are stored in tempdb .When you rebuild without sort_in_tempdb ( i guess your data and log file are on same drive) index will utilize disk space on which it
resides so it might seem to you log has increased.Is it so ,am i correct.
What query you used to measure log file size,are you absolutely sure it was log file that increased
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

Recommeded way to rebuild Indexes in EBS 11.5.10.2

What is the recommended way to rebuild all the possible indexes for better performance in EBS 11.5.10.2?
Is there any seeded script / concurrent program, that which could be made use of?

I have been using bde_rebuild.sql (available from Metalink) with pretty good success. It seems to work better doing it schema by schema rather than supplying % for schema name (gets hung up and never completes).
bde_rebuild.sql - Validates and rebuilds indexes occupying more space than needed
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=182699.1
How to Rebuild All Indexes in a Database
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=300327.1

Index array problems with tcp open function

Hello,
I am using the TCP open function to check if an IP or hostname is online. I do this with an input array specifying the IP/hostname as well as the port. This doesn't seem to work as expected. After using highlight execution I noticed that the port on index 1 gets to the tcp open function after the IP/hostway on index 0 so the tcp open function seems to execute without a port and returns an error. If I set the port as a constant it works fine. Anyone have any ideas how I could fix this? Thank you in advance.
Attachments:
iface-detect_online.vi ‏12 KB

After some more testing I think I am wrong on the assumption that the values are getting there at different times. I think the problem is that the port is a text string and needs to be numeric instead. Is there a way to make index 1 on the array numeric while leaving the hostname a string?
On edit: after figuring out why this wasn't working I was able to fix this problem by using the decimal string to number function. Thanks to anyone that reviewed this.
Message Edited by Pawel Kowalski on 09-22-2008 11:12 AM

Rebuild indexes?

I am working with a large scale database with approximately 100 tables where some tables grow with 100-500 million rows per year. The performance in of the system is fairly good but I was wondering if anyone has any input regarding how often indexes should be rebuilt?
Kind regards,
Sumpen

martinmorono wrote:
Inside my company, We are using this self-made rules to consider an index as candidate to be rebuild:
Index is considered as candidate for rebuild when :
- when deleted entries represent 20% or more of the current entries
- when the index depth is more then 4 levels.(height starts counting from 1 so > 5)
- Index is (possible) candidate for a bitmap index when :
- distinctiveness is more than 99%
That'll come from the old metalink guidance. It doesn't exist now. Oracle reviewed it and pulled it. You might want to think about a 1 billion row table (2 years of the OP's highest growth rate). Would an index on a randomly distributed varchar column on that table of a height of 5 be especially inefficient?
I don't understand 'distinctiveness'
Niall Litchfield
http://www.orawin.info/

Online Rebuild Index Vs Shrinking With Compact Segment with Release space

Similar Messages

Maybe you are looking for