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

Similar Messages

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

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'.

Run Rebuild Index Task daily on database but about 77 tables still highly fragmented over 80% !!!

Hello everyone
On our particular database server, we run the Rebuild Index Task (Using classic Maintenance Plan Designer) every night. Running the script below, I saw that about 77 tables had an avg_fragmentation_in_percentage between 80% and 99% !!
SELECT OBJECT_NAME(ind.OBJECT_ID) AS TableName,
ind.name AS IndexName, indexstats.index_type_desc AS IndexType,
indexstats.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats
INNER JOIN sys.indexes ind
ON ind.object_id = indexstats.object_id
AND ind.index_id = indexstats.index_id
WHERE indexstats.avg_fragmentation_in_percent > 30--You can specify the percent as you want
ORDER BY indexstats.avg_fragmentation_in_percent DESC
I dont understand why these tables are highly fragmented after a daily index rebuild! Unless the users are doing heavy inserts/updates/deletes during the day.
Anyone has an idea of the possible causes of these results??
Thank you all in advance

Hallo Efyuzegeekgurl,
this is a normal behaviour when your table is only a small one. The reason for that behaviour is the following:
The dmv sys.dm_db_index_physical_stats counts each page which is not located at the very next one of the same table as a "fragment". If the first data page is 1700 and the second one is located on 1705 SQL server will count it as a fragment.
The basic allocation algorithm of Microsoft SQL Server is that new data pages will be created in "mixed extents". An extent is a contigious line of 8 consecutive data pages. This is for historical reasons when storage was expensive and data should
use as much as possible of allocated storage.
If a new table will be created the very first 8 pages are not located one after the other but "could" be located on different extents. If your table has only 9 data pages than 8 pages will count as "fragmented" because of their non consecutive
allocation. After 8 pages have been allocated Microsoft SQL Server will ALWAYS use a full extent for the next 8 pages (and so on!).
To understand this behaviour use the following example which creates a table with a record length of 8K. The next command will create 10 records (which means 10 data pages).
CREATE TABLE dbo.foo
Id INT NOT NULL IDENTITY (1, 1),
c1 CHAR(8000) NOT NULL DEFAULT ('filler')
GO
SET NOCOUNT ON;
GO
INSERT INTO dbo.foo DEFAULT VALUES
GO 10
When you check the page allocation you'll find the first 8 data pages not in a consecutive row but "scrambled" into different pages:
SELECT database_id,
index_id,
partition_id,
allocation_unit_type_desc,
extent_page_id,
allocated_page_page_id,
is_mixed_page_allocation,
page_type_desc
FROM sys.dm_db_database_page_allocations
DB_ID(),
OBJECT_ID('dbo.foo', 'U'),
0,
NULL,
'DETAILED'
) AS DDDPA
WHERE
DDDPA.is_allocated = 1
ORDER BY
DDDPA.is_iam_page DESC,
DDDPA.page_level DESC;
GO
You will see that the first 8 pages are located in a MIXED extent. Although the pages are in a consecutive order in the extent 221112 it is not guaranteed!
You can see from the very first three records that they are not in a consecutive row stored.
Now the fragmentation of the data seems to be quite high because we have 4 breaks in the rows. If we compare this value to the "fragmentation in sys.dm_db_index_physical_stats we will see at least the same result:
SELECT index_type_desc,
alloc_unit_type_desc,
DDIPS.avg_fragmentation_in_percent,
DDIPS.fragment_count,
DDIPS.page_count,
avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats
DB_ID(),
OBJECT_ID('dbo.foo', 'U'),
NULL,
NULL,
'DETAILED'
) AS DDIPS;
So - just from my point of view - don't count only to the fragmentation in percent because if the table is to small it will ALWAYS be over 30%. Take more into account the density of the pages and - as all others have mentioned - the number of pages of the
index.
I would consider indexes with more or equal to 1.000 pages.
Another tip: Forget about the f... maintenance plans. These "plans" are not worth the time and money because you cannot control it in a more precise way. Have a look to the solution of Ola Hallengren and implement his solution - a great master
piece of index maintenance:
http://ola.hallengren.com
All the best to the community :)
MCM - SQL Server 2008
MCSE - SQL Server 2012
db Berater GmbH
SQL Server Blog (german only)

Rebuilding indexes after importing...

My coworker and I are discussing whether it is necessary, or advised, to rebuild indexes after an import of the schema.
My thinking is that the index data is put into fresh blocks thereby creating a very flat index tree without any fragmentation.
But my coworker suspects that perhaps the blocks are built exactly as they existed in the source database.
I could understand, perhaps, if the refresh were done by using RMAN which copies block by block, but even then I'm not sure.
Can you help us understand this please?
Thanks.
Ed

Hi,
Normally, the indexes are build and statistics upfated after the import automatically. You do not ned to generate the statistics after the import until unless you are running very old version of database.
Regards
[sfa-dev1:oracle:10.2.0] $ imp help=Y
Import: Release 10.2.0.4.0 - Production on Fri Nov 13 11:49:56 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
You can let Import prompt you for parameters by entering the IMP
command followed by your username/password:
Example: IMP SCOTT/TIGER
Or, you can control how Import runs by entering the IMP command followed
by various arguments. To specify parameters, you use keywords:
Format: IMP KEYWORD=value or KEYWORD=(value1,value2,...,valueN)
Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N
or TABLES=(T1:P1,T1:P2), if T1 is partitioned table
USERID must be the first parameter on the command line.
Keyword Description (Default) Keyword Description (Default)
USERID username/password FULL import entire file (N)
BUFFER size of data buffer FROMUSER list of owner usernames
FILE input files (EXPDAT.DMP) TOUSER list of usernames
SHOW just list file contents (N) TABLES list of table names
IGNORE ignore create errors (N) RECORDLENGTH length of IO record
GRANTS import grants (Y) INCTYPE incremental import type
INDEXES import indexes (Y) COMMIT commit array insert (N)
ROWS import data rows (Y) PARFILE parameter filename
LOG log file of screen output CONSTRAINTS import constraints (Y)
DESTROY overwrite tablespace data file (N)
INDEXFILE write table/index info to specified file
SKIP_UNUSABLE_INDEXES skip maintenance of unusable indexes (N)
FEEDBACK display progress every x rows(0)
TOID_NOVALIDATE skip validation of specified type ids
FILESIZE maximum size of each dump file
STATISTICS import precomputed statistics (always) On 10gR2
Edited by: skvaish1 on Nov 13, 2009 11:50 AM

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/

Compression for oracle database and index compression during import of data

Hi All,
I have a query , in order to import into oracle database and also have compression and index compression , do we have some kind of load args for r3load and also do we have to change the tpl file ?

Hello guy,
I did this kind of compression within migration project before.
I performed index compress first and then export -> import with table compress.
One thing you should take care, delete nocompress flag from TARGET.SQL (created by program SMIGR_CREATE_DDL, program SMIGR_CREATE_DDL created pure non-compression objects for these considered non-standard tables). For table columns > 255, we should not delete this flag.
Regarding to the index compress in source system, please check the following notes:
Note 1464156 - Support for index compression in BRSPACE 7.20
Note 1109743 - Use of Index Key Compression for Oracle Databases
Note 682926 - Composite SAP note: Problems with "create/rebuild index"
Best Regards,
Ning Tong

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

DATABASE.FULLTEXT indexer stuck on Delete

I've run into an issue with our Database Fulltext Indexer on UCM 10g. The Automatic Update Cycle seems to be 'stuck' on Deleting metadata for a piece of content that is no longer in the system. The indexer State is "Clean Up" and the Status is Active. The message says "Deleting metadata (0 of 1)". I've run IdcAnalyze on the collection looking for possible errors but it did not report any problems.
Is there some place I can clear this Indexer state and start processing new content items that are backing up? I'd like to be able to avoid a collection rebuild if at all possible.

Srinath - the two things that stick out in my mind are these two items, one from the Server Logs and the other from Output after turning on indexer and system database..
Looks like this query reached max time out and canceled.
------from Server Logs---------
Unable to do clean up. csDbUnableToExecuteBatch() error occurred during batching: ORA-01013: user requested cancel of current operation
java.sql.BatchUpdateException: error occurred during batching: ORA-01013: user requested cancel of current operation [ Details ]
An error has occurred. The stack trace below shows more information.
!csIndexerAbortedMsg!csIndexerUnableToCleanup!csDbUnableToExecuteBatch,!$error occurred during batching: ORA-01013: user requested cancel of current operation<br>!syExceptionType2,java.sql.BatchUpdateException,error occurred during batching: ORA-01013: user requested cancel of current operation<br>
intradoc.common.ServiceException: !csIndexerUnableToCleanup
     at intradoc.indexer.Indexer.doCleanUp(Indexer.java:825)
     at intradoc.indexer.Indexer.doWork(Indexer.java:278)
     at intradoc.indexer.Indexer.doIndexing(Indexer.java:439)
     at intradoc.indexer.Indexer.buildIndex(Indexer.java:348)
     at intradoc.server.IndexerMonitor.doIndexing(IndexerMonitor.java:1012)
     at intradoc.server.IndexerMonitor$4.run(IndexerMonitor.java:832)
Caused by: intradoc.data.DataException: !csDbUnableToExecuteBatch,!$error occurred during batching: ORA-01013: user requested cancel of current operation
     at intradoc.jdbc.JdbcWorkspace.handleSQLException(JdbcWorkspace.java:2371)
     at intradoc.jdbc.JdbcWorkspace.executeBatch(JdbcWorkspace.java:525)
     at intradoc.indexer.IndexerWorkObject.executeDependentQueriesAllowBatch(IndexerWorkObject.java:417)
     at intradoc.indexer.IndexerWorkObject.executeDependentQueriesEx(IndexerWorkObject.java:344)
     at intradoc.indexer.IndexerWorkObject.executeDependentQueries(IndexerWorkObject.java:338)
     at intradoc.indexer.Indexer.cleanUpQueries(Indexer.java:557)
     at intradoc.indexer.Indexer.doCleanUp(Indexer.java:821)
     ... 5 more
Caused by: java.sql.BatchUpdateException: error occurred during batching: ORA-01013: user requested cancel of current operation
     at oracle.jdbc.driver.OracleStatement.executeBatch(OracleStatement.java:4534)
     at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:213)
     at intradoc.jdbc.JdbcWorkspace.executeBatch(JdbcWorkspace.java:519)
     ... 10 more
From server output .. the Indexer now says it's in Clean Up mode deleting metadata (0 of 3) and I'm assuming it's these three;
systemdatabase     01.24 05:48:15.810     index update work     9.40 ms. SELECT/*+ INDEX (Revisions dIndexerState dStatus)*/ dID FROM Revisions
          WHERE dStatus='DELETED' AND dIndexerState = 'A'[Executed. Returned row(s): true]
systemdatabase     01.24 05:48:15.811     index update work     Batched query added at index 0: DELETE/*+ INDEX (DocMeta PK_DocMeta)*/ FROM DocMeta
          WHERE DocMeta.dID = 485759
systemdatabase     01.24 05:48:15.813     index update work     Batched query added at index 1: DELETE/*+ INDEX (DocMeta PK_DocMeta)*/ FROM DocMeta
          WHERE DocMeta.dID = 485760
systemdatabase     01.24 05:48:15.813     index update work     Batched query added at index 2: DELETE/*+ INDEX (DocMeta PK_DocMeta)*/ FROM DocMeta
          WHERE DocMeta.dID = 503528

Recommended frequency for running Rebuild Indexes Maintenance task on CAS

How frequently shall we run "Rebuild Index" maintenance task on CAS?

You should also consider using an actual SQL index rebuild script instead of the built-in maintenance task as described at http://stevethompsonmvp.wordpress.com/2013/05/07/optimizing-configmgr-databases/
Jason | http://blog.configmgrftw.com

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/

What is database re indexing

hi
what is database re indexing
what is the concept of it,
adil

One can REBUILD or REORGANIZE an existing index.
BOL: "This topic describes how to reorganize or rebuild a fragmented index in SQL Server 2012 by using SQL Server Management Studio or Transact-SQL. The SQL Server Database Engine automatically maintains indexes whenever insert, update, or delete operations
are made to the underlying data. Over time these modifications can cause the information in the index to become scattered in the database (fragmented). Fragmentation exists when indexes have pages in which the logical ordering, based on the key value, does
not match the physical ordering inside the data file. Heavily fragmented indexes can degrade query performance and cause your application to respond slowly.
You can remedy index fragmentation by reorganizing or rebuilding an index. For partitioned indexes built on a partition scheme, you can use either of these methods on a complete index or a single partition of an index. Rebuilding an index drops and re-creates
the index. This removes fragmentation, reclaims disk space by compacting the pages based on the specified or existing fill factor setting, and reorders the index rows in contiguous pages. When ALL is specified, all indexes on the table are dropped and rebuilt
in a single transaction. Reorganizing an index uses minimal system resources. It defragments the leaf level of clustered and nonclustered indexes on tables and views by physically reordering the leaf-level pages to match the logical, left to right, order of
the leaf nodes. Reorganizing also compacts the index pages. Compaction is based on the existing fill factor value."
LINK: http://technet.microsoft.com/en-us/library/ms189858.aspx
The following blog demonstrates how to REBUILD all the indexes in a database:
http://www.sqlusa.com/bestpractices2008/rebuild-all-indexes/
Kalman Toth Database & OLAP Architect
SELECT Video Tutorials 4 Hours
New Book / Kindle: Exam 70-461 Bootcamp: Querying Microsoft SQL Server 2012

Rebuild Indexes required everyday

We are running Core Banking Application on Oracle 11g R1 on AIX. Recently while we do banking day end activity, we have to rebuild the indexes to improve the performance. if we perform end of day activity without rebuilding the indexes it takes around 4 hours. After rebuilding indexes it takes around 2 hours. We need to know why we have perform rebuild everyday. Everyday approximately 5000 records are inserted.

This is the forum for the SQL Developer Data Modeler product. I suggest you ask your question on the General Database Discussions forum: General Database Discussions
or on the forum for your Banking application.

What is the difference between the drop and create the index and rebuild index ?

Hi All,
what is the difference between drop and create index & rebuild index ? i think both are same...Please clarify if both are same or any difference...
Thanks in Advance,
rup

Both are same. Rebuilding an index drops and re-creates the index.
Ref:
SSMS - https://technet.microsoft.com/en-us/library/ms187874(v=sql.105).aspx
TSQL - https://msdn.microsoft.com/en-us/library/ms188388.aspx
I would suggest you to also refer one of the best index maintenance script as below:
https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

Shrink Database (Rebuild Indexes)

Similar Messages

Maybe you are looking for