Rebuilding indexes on a replicated database

Hello there,
I am planning to rebuild the highly-fragmented indexes on my db which has both transaction and merge replications on many of its tables in addition to a number of indexed views. Fragmentation percent is almost the same on both servers, so my question is:
can I rebuild the indexes on both the publisher and subscriber manually without the need to recreate all these replications taking into account that almost all the indexes are on the primary keys of the replicated tables. My first thought was to rebuild the
indexes on either server, take a copy of the database and recreate all the replications. This is a long process and will take almost 18 hours.
Any ideas?
Thanks in advance
Ghada M.Ahmad

This is the MDT Forum, seems like you are looking for help on SQL - post here -
http://social.technet.microsoft.com/Forums/sqlserver/en-US/home
Regards, Vik Singh "If this thread answered your question, please click on "Mark as Answer"

Similar Messages

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)

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

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

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/

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

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/

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

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

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.

Rebuilding indexes on a replicated database

Similar Messages

Maybe you are looking for