Fellow MSSQL DBA's, I am stuck. I am getting a Msg 2511 on a production database. The message reads - Table Corrupt: Keys in leaf page should be in ascending order. I have dropped the offending index and rebuilt both through the application and through ISQL. Neither method fixed the problem. DBCC CHECKDB shows no errors as long as the index does not exist. I have checked out the data and see no problems. Any ideas?
Thanks very much.
After rebuilding an index, it still shows as the same amount offragmentation. ANy ideas what's wrong?I'm determining which indexes to rebuild using the following query:SELECTOBJECT_NAME(i.object_id) AS TableName,i.name AS IndexName,ips.avg_fragmentation_in_percentFROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL,'DETAILED') ipsJOIN sys.indexes i ONi.object_id = ips.object_idAND i.index_id = ips.index_idWHERE ips.avg_fragmentation_in_percent > 10(I know 10% is not enough where a full rebuild is called for, justwanted to see my fragmentation)Then I rebuild w/:ALTER INDEX IX_CustomerName ON Customers REBUILDWhen I rerun the 1st query the same amount of fragmentation is shownas before the rebuild. I'd appreciate any help.
My SSIS package is running very slow taking so much time to execute, One task is taking 2hr for inserting 100k records, i have disabled unused index still it is taking time.I am rebuilding/Refreshing indexes and stats once in month if i try to execute on daily basis will it improve my SSIS Package performance?Â
Rebuild Index job for user db's is failing, one user db is a huge size 120 GB. The job scheduled to run every sunday 1 AM
I found the below error in log report
Rebuild Index Task (server name) Rebuild index on Local server connection Databases: All user databases Object: Tables and views Original amount of free space Task start: 01/13/2008 1:26 AM. Task end: 01/13/2008 2:38 AM. Failed-1073548784) Executing the query "ALTER INDEX [Idx_CISCO_WLC_EVENTID] ON [dbo].[CISCO_WLC_200711262137] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, ONLINE = OFF ) " failed with the following error: "Cannot find the object "dbo.CISCO_WLC_200711262137" because it does not exist or you do not have permissions.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I have a table with over 60 million rows (approx 20GB) which has an indexed column. I have tried using DBC DBReindex to rebuild the index, but after kicking it off on a friday, it is still running the following wednesday. Since managers and other finicky types access this database, that's not acceptable (it slows down their reporting).
Is there a way to speed up the reindexing process? Perhaps by adding space to the tempdb (it's 500MB) or putting it in RAM temporarily? I haven't seen any articles that specifically state that TEMPDB is used during an index rebuild, but it seems logical that it would be.
Any suggestions to speed up the process would be most appreciated!
I would like to completely understand the difference between index rebuild Maintenace plan and the customized script.Maintenance Plan rebuilds every single index.It will take the long time as it checks every index.If we use a custom script as a job, it will rebuild the index which has fragmentation >30%.So that, the job will not take much time.
In SQL Server 2005 EE I created a maintenance plan to rebuild indexes for a few large tables. I have selected five specific tables, and I'm using both "sort results in tempdb" as well as "keep index online while reindexing".
If I execute this plan for all these tables, are the indexes guaranteed to remain online? There are all different types of indexes on these tables. For example, the table "Contacts" has 8 indexes: 1 Clustered, 1 PK Unique Non-Clustered, 2 Unique Non-Clustered, and 4 Non-Unique Non-Clustered. I've heard that only certain types of indexes can remain online during a reindex (Clustered and Non-Unique Non-Clustered??).
Will SQL Server rebuild an index that isn't compatible with the online reindex mode, or will it choose to ignore it?
SQL Server 2005 version: 2153 I created a maintplan for system and user databases includes rebuild index, maint cleanup tasks.
Job is failing for user databases It includes rebuild index task( online index enabled) and maintenance cleanup task, scheduled at every sunday 1 AM.
I receive following errors:
In eventvwr log
sql server scheduled job 'DBMP_RebuildIndex_User' status: failed-Invoked on 2007-12-02 -1:00 Message: The job failed. The job was invoked by schedule 8 ('DBMP_RebuildIndex_User-Schedule).The last step to run was step1 ('DBMP_RebuildIndex_User')[/red]
In log report:
Failed:(-1073548784) Excuting the query "ALTER INDEX [XPKact_log] ON [dbo].[act log] REBUILD WITH (PAD_INDEX=OFF, STATISTICS_NORECOMPUTE=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON,SORT_IN_TEMPDB=OFF,ONLINE=ON) "failed with the following error "Online index operation cannot be performed for index 'XPKact_log' because the index contains column 'action_desc' of data type text, ntext.image.varchar(max),varbinary(max) or xml. For non clusterd index the column could be an include column of the index. for clusterd index it could be any column of the table .Incase of drop_existing the cloumn could be part of new or old index. The operation must be performed offline". Possible failure reasons : Problems with the querey .'" Resultset" property not set correctly, parameters not set correctly, or connection not established correctly.
Please anyone help me on this? I really appriciate
Hi Folks,SQL Server 2000 SP3 on Windows 2000. I have a database on which I ranthe command :dbcc dbreindex ('tablename')gofor all tables in the database. Then I compared the dbcc showcontigwith all_index output from before and after the reindex and on thelargest table in the database I found this. First output is prior toreindex:Table: 'PlannedTransferArchive' (1975014117); index ID: 1, database ID:7TABLE level scan performed.- Pages Scanned................................: 184867- Extents Scanned..............................: 23203- Extent Switches..............................: 23324- Avg. Pages per Extent........................: 8.0- Scan Density [Best Count:Actual Count].......: 99.07% [23109:23325]- Logical Scan Fragmentation ..................: 11.13%- Extent Scan Fragmentation ...................: 35.46%- Avg. Bytes Free per Page.....................: 60.0- Avg. Page Density (full).....................: 99.26%Second output is from after the reindex:DBCC SHOWCONTIG scanning 'PlannedTransferArchive' table...Table: 'PlannedTransferArchive' (1975014117); index ID: 1, database ID:8TABLE level scan performed.- Pages Scanned................................: 303177- Extents Scanned..............................: 37964- Extent Switches..............................: 42579- Avg. Pages per Extent........................: 8.0- Scan Density [Best Count:Actual Count].......: 89.00% [37898:42580]- Logical Scan Fragmentation ..................: 43.19%- Extent Scan Fragmentation ...................: 24.78%- Avg. Bytes Free per Page.....................: 75.1- Avg. Page Density (full).....................: 99.07%Following are my concerns:The following numbers are all higher after reindex than before reindex:pages scanned, extent switches, logical scan fragmentation, avg bytesfree per page, avg page density.scan density is lower after reindex than before reindexSeems to me that the numbers that are higher after reindex should belower and numbers that are lower after reindex should be higher? Ididn't specify the fill factor in the dbcc reindex command so it shouldhave used the default fill factor. The fill factor has never beenchanged on this machine.Am I missing something?Thanks,Raziq.*** Sent via Developersdex http://www.developersdex.com ***
Rebuild index maintenance plan is failed, since we don't have space in the C:Drive we have left the option as it is to sort the results in user databases respectively. These user databases are in E: with sufficient space to rebuild index.
Check the below details.
SQL Server 2005: Microsoft SQL Server 2005 - 9.00.5000.00 (X64)  Dec 10 2010 10:38:40  Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)Â
Online reindexing supports in SQL Server 2005 Standard Edition? Job is failing because these options (sort results in tempdb & keep index online while reindexing) is not checked (enabled)?
I have read through BOL but am still confused by the above sql. I think it rebuilds all indexes on a table. Am I correct? (If so, if would seem to be a good thing to run it nightly on all tables in all databases. Or maybe that is too extreme)
Is it neccessary to schedule a update statistics on index in sql server 2005 on daily basis Is it neccessary to schedule a rebuild index on index in sql server 2005 on daily basis
I have been testing methods to maintain indexes in a SQL Server 2005 database which has been migrated from SQL Server 2000. The compatibility level is still set to 80. I used the query below to inspect the degree of fragmentation amongst other things.
SELECT a.index_id
, name
, database_id
, avg_fragmentation_in_percent
,index_type_desc
,fragment_count
,page_count
FROM sys.dm_db_index_physical_stats (NULL, NULL, NULL, NULL, 'DETAILED') AS a
JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id
Some of the indexes in the database had a high degree of fragmentation based on the avg_fragmentation_in_percent value. I tried drop+create, rebuild and reorganise commands on those indexes. Predictably, drop + create was the most effective, but even that did not always reduce fragmentation much. Sometimes the fragmentation was the same no matter what method I used. Other times drop+create helped, rebuild made it worse.
The rebuild index task in a maintenance plan allows you to choose system databases. I noticed that some of the system database tables do have indexes. Should you run this task on system databases within the maintenance plan. Is it necessary and will it do anything. Also will it cause any issue with these databases. What about reorganize index task or update statistics will this cause any issues and should it be run. Lastly can you shrink a system database. For instance should you run the shrink database task. Any help would be greatly appreciated thank you.
I'm running SQL Server 2008 R2 with latest patch. I'm performing all index maintenance online. How long the final phase of the index operation takes? Does the size of the index matter and if any blocking occurs, does the duration increase because the size of indexes is larger? I've been told by management, we can not have any downtime, its my understanding even with online index there's a chance blocking can occur in the final phase of the index operation. My database and index size is over 1.5 tb and the number of transaction per second are in the 100's.
I try to create script which Rebuild one table index after transaction log backup.
In my script first i check or backup is complete in 10 minutes if i find record i do it index rebuild if i don't find i need go back and check again.
The problem is that query finish if don't find a backup record, How i can loop that script that he checking until find the record and then start rebuild index.
Use DB GO DECLARE @database_name NVARCHAR(50) SELECT @database_name='DB'`
START: WHILE EXISTS (SELECT msdb.dbo.backupset.database_name,
Table A 5.6GB 80 million rows Initial Page Space Used = 85.7% (sys.dm_db_index_physical_stats - avg_page_space_used_in_percent)
Index and data size are almost unchanged after an ONLINE rebuild of the clustered index. Page count actually goes up by 800. No fill factor or pad index settings. Page space used = 99.2%
During an OFFLINE rebuild the page count drops by ~20%. Page space used = 99.8%.
How can the pages be 99.2% used yet the number of pages hasn't gone done from the ONLINE rebuild?
I'm getting the feeling a shortcut was taken somewhere. Does an ONLINE rebuild only reorganize leaf level index pages but not any of the upper levels? Essentially it puts the pages in order but doesn't do any structure consolidation like OFFLINE?
It would seem that you're missing out on some of the benefits of defragmenting if your data is still spread across more pages and you don't get as many rows per read or it takes more reads to go down your tree to get to your data.
I do a lot of index maintenance and started testing rebuilding my indexes with the ONLINE option, but noticed an increase in record size by 14 bytes. The issue I have is that for each index you build the ONLINE option, you add 14 bytes for row. After the index rebuild is done, normal transaction updates drop the additional 14 bytes.
The act of adding and dropping 14 bytes would cause fragmentation and uncompressed data. Is this correct or do I have something wrong?
I have a very large table with approximately 400 million records in it. Every 10 seconds approximately 150 insert are done on the table. I am attempting to rebuild one of the indexes (non-unique, non-clustered). But when I run a script to rebuild the index online (i have enterprise edition) the VB.NET service that is attempting to insert generates SQL timeout errors (timeout set to 30 seconds). From an article on msdn they state that long term table locks are not held for the duration of the index operation. So what am I missing because I am not close to being a DBA. I know SQL Server is not a SCADA but it is not my choice.
Here is the script for one of the rebuilds USE [DATABASENAME] GO ALTER INDEX [IX_REALLY_BIG_TABLE_DT] ON [dbo].[REALLY_BIG_TABLE] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = OFF, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, ONLINE = ON ) GO
Here is the article http://msdn.microsoft.com/en-us/library/ms188388.aspx
I am using sys.dm_db_index_physical_stats to identify indexes that need to be rebuilt based on a fragmentation limit. Once identified, I execute and ALTER INDEX... REBUILD on the index. If the index is clustered, only that index gets rebuilt for the table. After all the indexes are complete, I receive a report on the indexes that were rebuilt in the databases and what level of fragmentation the index was at before rebuilt. After checking these indexes, I still see that all the Primary Key indexes are still at the same fragmentation level. I run the process again and it does not change. I updated table usage and also ran update statistics after running the rebuild again, but the fragmentation does not change. Why can€™t these PK Clustered indexes be rebuilt as expected? Do I need to drop and recreate the PK before this fragmentation changes?
