Search Results

Search found 194 results on 8 pages for 'dbcc'.

Page 1/8 | 1 2 3 4 5 6 7 8  | Next Page >

  • SQL SERVER – Monitoring SQL Server Database Transaction Log Space Growth – DBCC SQLPERF(logspace) – Puzzle for You

    - by pinaldave
    First of all – if you are going to say this is very old subject, I agree this is very (very) old subject. I believe in earlier time we used to have this only option to monitor Log Space. As new version of SQL Server released we all equipped with DMV, Performance Counters, Extended Events and much more new enhancements. However, during all this year, I have always used DBCC SQLPERF(logspace) to get the details of the logs. It may be because when I started my career I remember this command and it did what I wanted all the time. Recently I have received interesting question and I thought, I should request your help. However, before I request your help, let us see traditional usage of DBCC SQLPERF(logspace). Every time I have to get the details of the log I ran following script. Additionally, I liked to store the details of the when the log file snapshot was taken as well so I can go back and know the status log file growth. This gives me a fair estimation when the log file was growing. CREATE TABLE dbo.logSpaceUsage ( id INT IDENTITY (1,1), logDate DATETIME DEFAULT GETDATE(), databaseName SYSNAME, logSize DECIMAL(18,5), logSpaceUsed DECIMAL(18,5), [status] INT ) GO INSERT INTO dbo.logSpaceUsage (databaseName, logSize, logSpaceUsed, [status]) EXEC ('DBCC SQLPERF(logspace)') GO SELECT * FROM dbo.logSpaceUsage GO I used to record the details of log file growth every hour of the day and then we used to plot charts using reporting services (and excel in much earlier times). Well, if you look at the script above it is very simple script. Now here is the puzzle for you. Puzzle 1: Write a script based on a table which gives you the time period when there was highest growth based on the data stored in the table. Puzzle 2: Write a script based on a table which gives you the amount of the log file growth from the beginning of the table to the latest recording of the data. You may have to run above script at some interval to get the various data samples of the log file to answer above puzzles. To make things simple, I am giving you sample script with expected answers listed below for both of the puzzle. Here is the sample query for puzzle: -- This is sample query for puzzle CREATE TABLE dbo.logSpaceUsage ( id INT IDENTITY (1,1), logDate DATETIME DEFAULT GETDATE(), databaseName SYSNAME, logSize DECIMAL(18,5), logSpaceUsed DECIMAL(18,5), [status] INT ) GO INSERT INTO dbo.logSpaceUsage (databaseName, logDate, logSize, logSpaceUsed, [status]) SELECT 'SampleDB1', '2012-07-01 7:00:00.000', 5, 10, 0 UNION ALL SELECT 'SampleDB1', '2012-07-01 9:00:00.000', 16, 10, 0 UNION ALL SELECT 'SampleDB1', '2012-07-01 11:00:00.000', 9, 10, 0 UNION ALL SELECT 'SampleDB1', '2012-07-01 14:00:00.000', 18, 10, 0 UNION ALL SELECT 'SampleDB3', '2012-06-01 7:00:00.000', 5, 10, 0 UNION ALL SELECT 'SampleDB3', '2012-06-04 7:00:00.000', 15, 10, 0 UNION ALL SELECT 'SampleDB3', '2012-06-09 7:00:00.000', 25, 10, 0 GO Expected Result of Puzzle 1 You will notice that there are two entries for database SampleDB3 as there were two instances of the log file grows with the same value. Expected Result of Puzzle 2 Well, please a comment with valid answer and I will post valid answers with due credit next week. Not to mention that winners will get a surprise gift from me. Reference: Pinal Dave (http://blog.sqlauthority.com) Filed under: PostADay, SQL, SQL Authority, SQL Query, SQL Server, SQL Tips and Tricks, T SQL, Technology Tagged: DBCC

    Read the article

  • in MSSQL Server 2005 Dev Edition, I faced index corruption

    - by tranhuyhung
    Hi all, When running stored procedures in MSSQL Server, I found it failed and the DBMS (MSSQL Server 2005 Dev Edition) notified that some indexes are corrupted. Please advice me, here below is DBCC logs: DBCC results for 'itopup_dev'. Service Broker Msg 9675, State 1: Message Types analyzed: 14. Service Broker Msg 9676, State 1: Service Contracts analyzed: 6. Service Broker Msg 9667, State 1: Services analyzed: 3. Service Broker Msg 9668, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0. DBCC results for 'sys.sysrowsetcolumns'. There are 1148 rows in 14 pages for object "sys.sysrowsetcolumns". DBCC results for 'sys.sysrowsets'. There are 187 rows in 2 pages for object "sys.sysrowsets". DBCC results for 'sysallocunits'. There are 209 rows in 3 pages for object "sysallocunits". DBCC results for 'sys.sysfiles1'. There are 2 rows in 1 pages for object "sys.sysfiles1". DBCC results for 'sys.syshobtcolumns'. There are 1148 rows in 14 pages for object "sys.syshobtcolumns". DBCC results for 'sys.syshobts'. There are 187 rows in 2 pages for object "sys.syshobts". DBCC results for 'sys.sysftinds'. There are 0 rows in 0 pages for object "sys.sysftinds". DBCC results for 'sys.sysserefs'. There are 209 rows in 1 pages for object "sys.sysserefs". DBCC results for 'sys.sysowners'. There are 15 rows in 1 pages for object "sys.sysowners". DBCC results for 'sys.sysprivs'. There are 135 rows in 1 pages for object "sys.sysprivs". DBCC results for 'sys.sysschobjs'. There are 817 rows in 21 pages for object "sys.sysschobjs". DBCC results for 'sys.syscolpars'. There are 2536 rows in 71 pages for object "sys.syscolpars". DBCC results for 'sys.sysnsobjs'. There are 1 rows in 1 pages for object "sys.sysnsobjs". DBCC results for 'sys.syscerts'. There are 0 rows in 0 pages for object "sys.syscerts". DBCC results for 'sys.sysxprops'. There are 12 rows in 4 pages for object "sys.sysxprops". DBCC results for 'sys.sysscalartypes'. There are 27 rows in 1 pages for object "sys.sysscalartypes". DBCC results for 'sys.systypedsubobjs'. There are 0 rows in 0 pages for object "sys.systypedsubobjs". DBCC results for 'sys.sysidxstats'. There are 466 rows in 15 pages for object "sys.sysidxstats". DBCC results for 'sys.sysiscols'. There are 616 rows in 6 pages for object "sys.sysiscols". DBCC results for 'sys.sysbinobjs'. There are 23 rows in 1 pages for object "sys.sysbinobjs". DBCC results for 'sys.sysobjvalues'. There are 1001 rows in 376 pages for object "sys.sysobjvalues". DBCC results for 'sys.sysclsobjs'. There are 14 rows in 1 pages for object "sys.sysclsobjs". DBCC results for 'sys.sysrowsetrefs'. There are 0 rows in 0 pages for object "sys.sysrowsetrefs". DBCC results for 'sys.sysremsvcbinds'. There are 0 rows in 0 pages for object "sys.sysremsvcbinds". DBCC results for 'sys.sysxmitqueue'. There are 0 rows in 0 pages for object "sys.sysxmitqueue". DBCC results for 'sys.sysrts'. There are 1 rows in 1 pages for object "sys.sysrts". DBCC results for 'sys.sysconvgroup'. There are 0 rows in 0 pages for object "sys.sysconvgroup". DBCC results for 'sys.sysdesend'. There are 0 rows in 0 pages for object "sys.sysdesend". DBCC results for 'sys.sysdercv'. There are 0 rows in 0 pages for object "sys.sysdercv". DBCC results for 'sys.syssingleobjrefs'. There are 317 rows in 2 pages for object "sys.syssingleobjrefs". DBCC results for 'sys.sysmultiobjrefs'. There are 3607 rows in 37 pages for object "sys.sysmultiobjrefs". DBCC results for 'sys.sysdbfiles'. There are 2 rows in 1 pages for object "sys.sysdbfiles". DBCC results for 'sys.sysguidrefs'. There are 0 rows in 0 pages for object "sys.sysguidrefs". DBCC results for 'sys.sysqnames'. There are 91 rows in 1 pages for object "sys.sysqnames". DBCC results for 'sys.sysxmlcomponent'. There are 93 rows in 1 pages for object "sys.sysxmlcomponent". DBCC results for 'sys.sysxmlfacet'. There are 97 rows in 1 pages for object "sys.sysxmlfacet". DBCC results for 'sys.sysxmlplacement'. There are 17 rows in 1 pages for object "sys.sysxmlplacement". DBCC results for 'sys.sysobjkeycrypts'. There are 0 rows in 0 pages for object "sys.sysobjkeycrypts". DBCC results for 'sys.sysasymkeys'. There are 0 rows in 0 pages for object "sys.sysasymkeys". DBCC results for 'sys.syssqlguides'. There are 0 rows in 0 pages for object "sys.syssqlguides". DBCC results for 'sys.sysbinsubobjs'. There are 0 rows in 0 pages for object "sys.sysbinsubobjs". DBCC results for 'TBL_BONUS_TEMPLATES'. There are 0 rows in 0 pages for object "TBL_BONUS_TEMPLATES". DBCC results for 'TBL_ROLE_PAGE_GROUP'. There are 18 rows in 1 pages for object "TBL_ROLE_PAGE_GROUP". DBCC results for 'TBL_BONUS_LEVELS'. There are 0 rows in 0 pages for object "TBL_BONUS_LEVELS". DBCC results for 'TBL_SUPERADMIN'. There are 1 rows in 1 pages for object "TBL_SUPERADMIN". DBCC results for 'TBL_ADMIN_ROLES'. There are 11 rows in 1 pages for object "TBL_ADMIN_ROLES". DBCC results for 'TBL_ADMIN_USER_ROLE'. There are 42 rows in 1 pages for object "TBL_ADMIN_USER_ROLE". DBCC results for 'TBL_BONUS_CALCULATION_HISTORIES'. There are 0 rows in 0 pages for object "TBL_BONUS_CALCULATION_HISTORIES". DBCC results for 'TBL_MERCHANT_MOBILES'. There are 0 rows in 0 pages for object "TBL_MERCHANT_MOBILES". DBCC results for 'TBL_ARCHIVE_EXPORTED_SOFTPINS'. There are 16030918 rows in 35344 pages for object "TBL_ARCHIVE_EXPORTED_SOFTPINS". DBCC results for 'TBL_ARCHIVE_LOGS'. There are 280 rows in 2 pages for object "TBL_ARCHIVE_LOGS". DBCC results for 'TBL_ADMIN_USERS'. There are 29 rows in 1 pages for object "TBL_ADMIN_USERS". DBCC results for 'TBL_SYSTEM_ALERT_GROUPS'. There are 4 rows in 1 pages for object "TBL_SYSTEM_ALERT_GROUPS". DBCC results for 'TBL_EXPORTED_TRANSACTIONS'. There are 7848 rows in 89 pages for object "TBL_EXPORTED_TRANSACTIONS". DBCC results for 'TBL_SYSTEM_ALERTS'. There are 968 rows in 9 pages for object "TBL_SYSTEM_ALERTS". DBCC results for 'TBL_SYSTEM_ALERT_GROUP_MEMBERS'. There are 1 rows in 1 pages for object "TBL_SYSTEM_ALERT_GROUP_MEMBERS". DBCC results for 'TBL_ESTIMATED_TIME'. There are 11 rows in 1 pages for object "TBL_ESTIMATED_TIME". DBCC results for 'TBL_SYSTEM_ALERT_MEMBERS'. There are 0 rows in 1 pages for object "TBL_SYSTEM_ALERT_MEMBERS". DBCC results for 'TBL_COMMISSIONS'. There are 10031 rows in 106 pages for object "TBL_COMMISSIONS". DBCC results for 'TBL_CATEGORIES'. There are 3 rows in 1 pages for object "TBL_CATEGORIES". DBCC results for 'TBL_SERVICE_PROVIDERS'. There are 11 rows in 1 pages for object "TBL_SERVICE_PROVIDERS". DBCC results for 'TBL_CATEGORY_SERVICE_PROVIDER'. There are 11 rows in 1 pages for object "TBL_CATEGORY_SERVICE_PROVIDER". DBCC results for 'TBL_PRODUCTS'. There are 73 rows in 6 pages for object "TBL_PRODUCTS". DBCC results for 'TBL_MERCHANT_KEYS'. There are 291 rows in 30 pages for object "TBL_MERCHANT_KEYS". DBCC results for 'TBL_POS_UNLOCK_KEYS'. There are 0 rows in 0 pages for object "TBL_POS_UNLOCK_KEYS". DBCC results for 'TBL_POS'. There are 0 rows in 0 pages for object "TBL_POS". DBCC results for 'TBL_IMPORT_BATCHES'. There are 3285 rows in 84 pages for object "TBL_IMPORT_BATCHES". DBCC results for 'TBL_IMPORT_KEYS'. There are 2 rows in 1 pages for object "TBL_IMPORT_KEYS". DBCC results for 'TBL_PRODUCT_COMMISSION_TEMPLATES'. There are 634 rows in 4 pages for object "TBL_PRODUCT_COMMISSION_TEMPLATES". DBCC results for 'TBL_POS_SETTLE_TRANSACTIONS'. There are 0 rows in 0 pages for object "TBL_POS_SETTLE_TRANSACTIONS". DBCC results for 'TBL_CHANGE_KEY_SOFTPINS'. There are 0 rows in 1 pages for object "TBL_CHANGE_KEY_SOFTPINS". DBCC results for 'TBL_POS_RETURN_TRANSACTIONS'. There are 0 rows in 0 pages for object "TBL_POS_RETURN_TRANSACTIONS". DBCC results for 'TBL_POS_SOFTPINS'. There are 0 rows in 0 pages for object "TBL_POS_SOFTPINS". DBCC results for 'TBL_POS_MENUS'. There are 0 rows in 0 pages for object "TBL_POS_MENUS". DBCC results for 'TBL_COMMISSION_TEMPLATES'. There are 23 rows in 1 pages for object "TBL_COMMISSION_TEMPLATES". DBCC results for 'TBL_DOWNLOAD_TRANSACTIONS'. There are 170820 rows in 1789 pages for object "TBL_DOWNLOAD_TRANSACTIONS". DBCC results for 'TBL_IMPORT_TEMP_SOFTPINS'. There are 0 rows in 1 pages for object "TBL_IMPORT_TEMP_SOFTPINS". DBCC results for 'TBL_REGIONS'. There are 2 rows in 1 pages for object "TBL_REGIONS". DBCC results for 'TBL_SOFTPINS'. There are 9723677 rows in 126611 pages for object "TBL_SOFTPINS". DBCC results for 'sysdiagrams'. There are 0 rows in 0 pages for object "sysdiagrams". DBCC results for 'TBL_SYNCHRONIZE_TRANSACTIONS'. There are 9302 rows in 53 pages for object "TBL_SYNCHRONIZE_TRANSACTIONS". DBCC results for 'TBL_SALEMEN'. There are 32 rows in 1 pages for object "TBL_SALEMEN". DBCC results for 'TBL_RESERVATION_SOFTPINS'. There are 131431 rows in 1629 pages for object "TBL_RESERVATION_SOFTPINS". DBCC results for 'TBL_SYNCHRONIZE_TRANSACTION_ITEMS'. There are 5345 rows in 16 pages for object "TBL_SYNCHRONIZE_TRANSACTION_ITEMS". DBCC results for 'TBL_ACCOUNTS'. There are 1 rows in 1 pages for object "TBL_ACCOUNTS". DBCC results for 'TBL_SYNCHRONIZE_TRANSACTION_SOFTPIN'. There are 821988 rows in 2744 pages for object "TBL_SYNCHRONIZE_TRANSACTION_SOFTPIN". *DBCC results for 'TBL_EXPORTED_SOFTPINS'. Msg 8928, Level 16, State 1, Line 1 Object ID 1716917188, index ID 1, partition ID 72057594046119936, alloc unit ID 72057594050838528 (type In-row data): Page (1:677314) could not be processed. See other errors for details. Msg 8939, Level 16, State 7, Line 1 Table error: Object ID 1716917188, index ID 1, partition ID 72057594046119936, alloc unit ID 72057594050838528 (type In-row data), page (1:677314). Test (m_freeData = PAGEHEADSIZE && m_freeData <= (UINT)PAGESIZE - m_slotCnt * sizeof (Slot)) failed. Values are 15428 and 7240. There are 2267937 rows in 6133 pages for object "TBL_EXPORTED_SOFTPINS". CHECKDB found 0 allocation errors and 2 consistency errors in table 'TBL_EXPORTED_SOFTPINS' (object ID 1716917188).* DBCC results for 'TBL_DOWNLOAD_SOFTPINS'. There are 7029404 rows in 17999 pages for object "TBL_DOWNLOAD_SOFTPINS". DBCC results for 'TBL_MERCHANT_BALANCE_CREDIT_PAID'. There are 0 rows in 0 pages for object "TBL_MERCHANT_BALANCE_CREDIT_PAID". DBCC results for 'TBL_ARCHIVE_SOFTPINS'. There are 44015040 rows in 683692 pages for object "TBL_ARCHIVE_SOFTPINS". DBCC results for 'TBL_ACCOUNT_BALANCE_LOGS'. There are 0 rows in 0 pages for object "TBL_ACCOUNT_BALANCE_LOGS". DBCC results for 'TBL_BLOCK_BATCHES'. There are 23 rows in 1 pages for object "TBL_BLOCK_BATCHES". DBCC results for 'TBL_BLOCK_BATCH_SOFTPIN'. There are 396 rows in 1 pages for object "TBL_BLOCK_BATCH_SOFTPIN". DBCC results for 'TBL_MERCHANTS'. There are 290 rows in 22 pages for object "TBL_MERCHANTS". DBCC results for 'TBL_DOWNLOAD_TRANSACTION_ITEMS'. There are 189296 rows in 1241 pages for object "TBL_DOWNLOAD_TRANSACTION_ITEMS". DBCC results for 'TBL_BLOCK_BATCH_CONDITIONS'. There are 23 rows in 1 pages for object "TBL_BLOCK_BATCH_CONDITIONS". DBCC results for 'TBL_SP_ADVERTISEMENTS'. There are 6 rows in 1 pages for object "TBL_SP_ADVERTISEMENTS". DBCC results for 'TBL_SERVER_KEYS'. There are 1 rows in 1 pages for object "TBL_SERVER_KEYS". DBCC results for 'TBL_ARCHIVE_DOWNLOAD_SOFTPINS'. There are 27984122 rows in 60773 pages for object "TBL_ARCHIVE_DOWNLOAD_SOFTPINS". DBCC results for 'TBL_ACCOUNT_BALANCE_REQUESTS'. There are 0 rows in 0 pages for object "TBL_ACCOUNT_BALANCE_REQUESTS". DBCC results for 'TBL_MERCHANT_TERMINALS'. There are 633 rows in 4 pages for object "TBL_MERCHANT_TERMINALS". DBCC results for 'TBL_SP_PREFIXES'. There are 6 rows in 1 pages for object "TBL_SP_PREFIXES". DBCC results for 'TBL_DIRECT_TOPUP_TRANSACTIONS'. There are 43 rows in 1 pages for object "TBL_DIRECT_TOPUP_TRANSACTIONS". DBCC results for 'TBL_MERCHANT_BALANCE_REQUESTS'. There are 19367 rows in 171 pages for object "TBL_MERCHANT_BALANCE_REQUESTS". DBCC results for 'TBL_ACTION_LOGS'. There are 133714 rows in 1569 pages for object "TBL_ACTION_LOGS". DBCC results for 'sys.queue_messages_1977058079'. There are 0 rows in 0 pages for object "sys.queue_messages_1977058079". DBCC results for 'sys.queue_messages_2009058193'. There are 0 rows in 0 pages for object "sys.queue_messages_2009058193". DBCC results for 'TBL_CODES'. There are 98 rows in 1 pages for object "TBL_CODES". DBCC results for 'TBL_MERCHANT_BALANCE_LOGS'. There are 183498 rows in 3178 pages for object "TBL_MERCHANT_BALANCE_LOGS". DBCC results for 'TBL_MERCHANT_CHANNEL_TEMPLATE'. There are 397 rows in 2 pages for object "TBL_MERCHANT_CHANNEL_TEMPLATE". DBCC results for 'sys.queue_messages_2041058307'. There are 0 rows in 0 pages for object "sys.queue_messages_2041058307". DBCC results for 'TBL_VNPTEPAY'. There are 0 rows in 0 pages for object "TBL_VNPTEPAY". DBCC results for 'TBL_PAGE_GROUPS'. There are 10 rows in 1 pages for object "TBL_PAGE_GROUPS". DBCC results for 'TBL_PAGE_GROUP_PAGE'. There are 513 rows in 2 pages for object "TBL_PAGE_GROUP_PAGE". DBCC results for 'TBL_ACCOUNT_CHANNEL_TEMPLATE'. There are 0 rows in 0 pages for object "TBL_ACCOUNT_CHANNEL_TEMPLATE". DBCC results for 'TBL_PAGES'. There are 148 rows in 3 pages for object "TBL_PAGES". CHECKDB found 0 allocation errors and 2 consistency errors in database 'itopup_dev'. repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (itopup_dev). DBCC execution completed. If DBCC printed error messages, contact your system administrator.

    Read the article

  • DBCC CHECKDB WITH DATA_PURITY gives out of range error

    - by Mark Allison
    Hi there, I have restore a SQL Server 2000 database onto SQL Server 2005 and then run DBCC CHECKDB WITH DATA_PURITY and I get this error: Msg 2570, Level 16, State 3, Line 2 Page (1:19558), slot 13 in object ID 181575685, index ID 1, partition ID 293374720802816, alloc unit ID 11899744092160 (type "In-row data"). Column "NumberOfShares" value is out of range for data type "numeric". Update column to a legal value. The column NumberOfShares is a numeric (19,6) data type. If I run the following select max (NumberOfShares) from AUDIT_Table select min (NumberOfShares) from AUDIT_Table I get: 22678647.839110 -1845953000.000000 These values are inside the bounds of a numeric (19,6) so I'm not sure why the DBCC check fails. Any ideas to find out why it fails? Do I need to use DBCC PAGE? How would you troubleshoot this? Thanks, Mark.

    Read the article

  • DBCC CHECKDB fails and quits job, ambiguous error message.

    - by ddono25
    I received a notice that one of our servers' DBCC CHECKDB for all databases has been failing the past four times it has been run. We don't have any data prior to that, but it doesn't look like it has been succeeding for awhile. There are no errors in the log file only: DBCC results for 'sys.sysxmlfacet'. [SQLSTATE 01000] Msg 0, Sev 0, State 1: Unspecified error occurred on SQL Server. Connection may have been terminated by the server. [SQLSTATE HY000] There are 112 rows in 1 pages for object "sys.sysxmlfacet". [SQLSTATE 01000] I ran a DBCC CHECKDB using sp_MSForEachDB to get more accurate results and had the same error on the same DB but at a separate point: DBCC results for 'NameValuePair_Greek_CI_AS'. [SQLSTATE 01000] Msg 0, Sev 0, State 1: Unspecified error occurred on SQL Server. Connection may have been terminated by the server. [SQLSTATE HY000] There are 0 rows in 0 pages for object "NameValuePair_Greek_CI_AS". [SQLSTATE 01000] Also, the error-log states that the DBCC completed without errors for this database. I can't figure out how to track down this ambiguous issue that only happens on this database out of the dozens on this server. Any help is appreciated!

    Read the article

  • DBCC SQL Server 2000 sysindexkeys

    - by Debasish Pramanik
    I have a SQL Server 2000 database. When I run the following command select * from sysindexkeys This display the appropriate records. I then do a DBCC command for the sysindexkeys. It doesn't display anything. Strange there is no page having the sysindexkeys records. Then how the query display the list of records.

    Read the article

  • SQL SERVER – Check the Isolation Level with DBCC useroptions

    - by pinaldave
    In recent consultancy project coordinator asked me – “can you tell me what is the isolation level for this database?” I have worked with different isolation levels but have not ever queried database for the same. I quickly looked up bookonline and found out the DBCC command which can give me the same details. You can run the DBCC UserOptions command on any database to get few details about dateformat, datefirst as well isolation level. DBCC useroptions Set Option                  Value --------------------------- -------------- textsize                    2147483647 language                    us_english dateformat                  mdy datefirst                   7 lock_timeout                -1 quoted_identifier           SET arithabort                  SET ansi_null_dflt_on           SET ansi_warnings               SET ansi_padding                SET ansi_nulls                  SET concat_null_yields_null     SET isolation level             read committed I thought this was very handy script, which I have not used earlier. Thanks Gary for asking right question. Reference: Pinal Dave (http://blog.sqlauthority.com) Filed under: Pinal Dave, SQL, SQL Authority, SQL Query, SQL Scripts, SQL Server, SQL System Table, SQL Tips and Tricks, T SQL, Technology Tagged: Transaction Isolation

    Read the article

  • Why are so many DBCC commands undocumented?

    - by DBA
    Paul Randal of SQLskills.com does a great job of answering the question of why there are so many undocumented DBCC commands in his post Why are so many DBCC commands undocumented? I would like to go on to say that not only does this apply to the DBCC commands but is some respect to all parts of SQL, other Servers, IDE's, Operating Systems, just about everywhere. There is always something that just does not make it into the official documentation. And as Paul points out probably never will make it. That could be why there are so many "Tips & Tricks" types of books, blog post, etc. everywhere you look. And I also agree with Janos's comments on Paul's post, which was "I'm fine with them undocumented. All of us who need to use these commands know where to find "documentation" and whom to ask ". Till later,

    Read the article

  • DBCC CHECKDB on VVLDB and latches (Or: My Pain is Your Gain)

    - by Argenis
      Does your CHECKDB hurt, Argenis? There is a classic blog series by Paul Randal [blog|twitter] called “CHECKDB From Every Angle” which is pretty much mandatory reading for anybody who’s even remotely considering going for the MCM certification, or its replacement (the Microsoft Certified Solutions Master: Data Platform – makes my fingers hurt just from typing it). Of particular interest is the post “Consistency Options for a VLDB” – on it, Paul provides solid, timeless advice (I use the word “timeless” because it was written in 2007, and it all applies today!) on how to perform checks on very large databases. Well, here I was trying to figure out how to make CHECKDB run faster on a restored copy of one of our databases, which happens to exceed 7TB in size. The whole thing was taking several days on multiple systems, regardless of the storage used – SAS, SATA or even SSD…and I actually didn’t pay much attention to how long it was taking, or even bothered to look at the reasons why - as long as it was finishing okay and found no consistency errors. Yes – I know. That was a huge mistake, as corruption found in a database several days after taking place could only allow for further spread of the corruption – and potentially large data loss. In the last two weeks I increased my attention towards this problem, as we noticed that CHECKDB was taking EVEN LONGER on brand new all-flash storage in the SAN! I couldn’t really explain it, and were almost ready to blame the storage vendor. The vendor told us that they could initially see the server driving decent I/O – around 450Mb/sec, and then it would settle at a very slow rate of 10Mb/sec or so. “Hum”, I thought – “CHECKDB is just not pushing the I/O subsystem hard enough”. Perfmon confirmed the vendor’s observations. Dreaded @BlobEater What was CHECKDB doing all the time while doing so little I/O? Eating Blobs. It turns out that CHECKDB was taking an extremely long time on one of our frankentables, which happens to be have 35 billion rows (yup, with a b) and sucks up several terabytes of space in the database. We do have a project ongoing to purge/split/partition this table, so it’s just a matter of time before we deal with it. But the reality today is that CHECKDB is coming to a screeching halt in performance when dealing with this particular table. Checking sys.dm_os_waiting_tasks and sys.dm_os_latch_stats showed that LATCH_EX (DBCC_OBJECT_METADATA) was by far the top wait type. I remembered hearing recently about that wait from another post that Paul Randal made, but that was related to computed-column indexes, and in fact, Paul himself reminded me of his article via twitter. But alas, our pathologic table had no non-clustered indexes on computed columns. I knew that latches are used by the database engine to do internal synchronization – but how could I help speed this up? After all, this is stuff that doesn’t have a lot of knobs to tweak. (There’s a fantastic level 500 talk by Bob Ward from Microsoft CSS [blog|twitter] called “Inside SQL Server Latches” given at PASS 2010 – and you can check it out here. DISCLAIMER: I assume no responsibility for any brain melting that might ensue from watching Bob’s talk!) Failed Hypotheses Earlier on this week I flew down to Palo Alto, CA, to visit our Headquarters – and after having a great time with my Monkey peers, I was relaxing on the plane back to Seattle watching a great talk by SQL Server MVP and fellow MCM Maciej Pilecki [twitter] called “Masterclass: A Day in the Life of a Database Transaction” where he discusses many different topics related to transaction management inside SQL Server. Very good stuff, and when I got home it was a little late – that slow DBCC CHECKDB that I had been dealing with was way in the back of my head. As I was looking at the problem at hand earlier on this week, I thought “How about I set the database to read-only?” I remembered one of the things Maciej had (jokingly) said in his talk: “if you don’t want locking and blocking, set the database to read-only” (or something to that effect, pardon my loose memory). I immediately killed the CHECKDB which had been running painfully for days, and set the database to read-only mode. Then I ran DBCC CHECKDB against it. It started going really fast (even a bit faster than before), and then throttled down again to around 10Mb/sec. All sorts of expletives went through my head at the time. Sure enough, the same latching scenario was present. Oh well. I even spent some time trying to figure out if NUMA was hurting performance. Folks on Twitter made suggestions in this regard (thanks, Lonny! [twitter]) …Eureka? This past Friday I was still scratching my head about the whole thing; I was ready to start profiling with XPERF to see if I could figure out which part of the engine was to blame and then get Microsoft to look at the evidence. After getting a bunch of good news I’ll blog about separately, I sat down for a figurative smack down with CHECKDB before the weekend. And then the light bulb went on. A sparse column. I thought that I couldn’t possibly be experiencing the same scenario that Paul blogged about back in March showing extreme latching with non-clustered indexes on computed columns. Did I even have a non-clustered index on my sparse column? As it turns out, I did. I had one filtered non-clustered index – with the sparse column as the index key (and only column). To prove that this was the problem, I went and setup a test. Yup, that'll do it The repro is very simple for this issue: I tested it on the latest public builds of SQL Server 2008 R2 SP2 (CU6) and SQL Server 2012 SP1 (CU4). First, create a test database and a test table, which only needs to contain a sparse column: CREATE DATABASE SparseColTest; GO USE SparseColTest; GO CREATE TABLE testTable (testCol smalldatetime SPARSE NULL); GO INSERT INTO testTable (testCol) VALUES (NULL); GO 1000000 That’s 1 million rows, and even though you’re inserting NULLs, that’s going to take a while. In my laptop, it took 3 minutes and 31 seconds. Next, we run DBCC CHECKDB against the database: DBCC CHECKDB('SparseColTest') WITH NO_INFOMSGS, ALL_ERRORMSGS; This runs extremely fast, as least on my test rig – 198 milliseconds. Now let’s create a filtered non-clustered index on the sparse column: CREATE NONCLUSTERED INDEX [badBadIndex] ON testTable (testCol) WHERE testCol IS NOT NULL; With the index in place now, let’s run DBCC CHECKDB one more time: DBCC CHECKDB('SparseColTest') WITH NO_INFOMSGS, ALL_ERRORMSGS; In my test system this statement completed in 11433 milliseconds. 11.43 full seconds. Quite the jump from 198 milliseconds. I went ahead and dropped the filtered non-clustered indexes on the restored copy of our production database, and ran CHECKDB against that. We went down from 7+ days to 19 hours and 20 minutes. Cue the “Argenis is not impressed” meme, please, Mr. LaRock. My pain is your gain, folks. Go check to see if you have any of such indexes – they’re likely causing your consistency checks to run very, very slow. Happy CHECKDBing, -Argenis ps: I plan to file a Connect item for this issue – I consider it a pretty serious bug in the engine. After all, filtered indexes were invented BECAUSE of the sparse column feature – and it makes a lot of sense to use them together. Watch this space and my twitter timeline for a link.

    Read the article

  • DBCC MEMUSAGE in 2005/8 ?

    - by steveh99999
    I used to like using undocumented command DBCC MEMUSAGE in SQL 2000 to see which tables were using space in SQL data cache. In SQL 2005, this command is not longer present. Instead a DMV – sys.dm_os_buffer_descriptors – can be used to display data cache contents,  but this doesn’t quite give you the same output as DBCC MEMUSAGE. I’m also aware that you can use Quest’s spotlight tool to view a summary of data cache contents. Using  this post by Umachandar Jayachandran  of Microsoft, I was able to create the following equivalent for SQL 2005/8. I’ve wrapped Umachandar’s original query in a CTE to produce summary information :- ;WITH memusage_CTE AS (SELECT bd.database_id, bd.file_id, bd.page_id, bd.page_type , COALESCE(p1.object_id, p2.object_id) AS object_id , COALESCE(p1.index_id, p2.index_id) AS index_id , bd.row_count, bd.free_space_in_bytes, CONVERT(TINYINT,bd.is_modified) AS 'DirtyPage' FROM sys.dm_os_buffer_descriptors AS bd JOIN sys.allocation_units AS au ON au.allocation_unit_id = bd.allocation_unit_id OUTER APPLY ( SELECT TOP(1) p.object_id, p.index_id FROM sys.partitions AS p WHERE p.hobt_id = au.container_id AND au.type IN (1, 3) ) AS p1 OUTER APPLY ( SELECT TOP(1) p.object_id, p.index_id FROM sys.partitions AS p WHERE p.partition_id = au.container_id AND au.type = 2 ) AS p2 WHERE  bd.database_id = DB_ID() AND bd.page_type IN ('DATA_PAGE', 'INDEX_PAGE') ) SELECT TOP 20 DB_NAME(database_id) AS 'Database',OBJECT_NAME(object_id,database_id) AS 'Table Name', index_id,COUNT(*) AS 'Pages in Cache', SUM(dirtyPage) AS 'Dirty Pages' FROM memusage_CTE GROUP BY database_id, object_id, index_id ORDER BY COUNT(*) DESC I’m not 100% happy with the results of the above query however… I’ve noticed that on a busy BizTalk messageBox database  it will return information on pages that contain GHOST rows – . ie where data has already been deleted but has yet to be cleaned-up by a background process – I’m need to investigate further why cache on this server apparently contains so much GHOST data… For more information on the background ghost cleanup process, see this article by Paul Randall. However, I think the results of this query should still be of interest to a DBA. I have another post to come shortly regarding an example I encountered where this information proved useful to me… I notice in SQL 2008, sys.dm_os_buffer_descriptors gained an extra column – numa_mode – I’m interested to see how this is populated and how useful this column can be on a NUMA-enabled system. I’m assuming in theory you could use this column to help analyse how your tables are spread across Numa-enabled data-cache ?

    Read the article

  • SQL SERVER – 2000 – DBCC SQLPERF(waitstats) – Wait Type – Day 24 of 28

    - by pinaldave
    I have received many comments, email, suggestions and motivations for my current series of wait types and wait statistics. One of the questions which I keep on receiving almost every other day is whether all of the discussions I have presented so far are also applicable to SQL Server 2000. Additionally, I receive another question asking me if wait statistics matters in SQL Server 2000. If it is, then the asker wants to know how to measure wait types for SQL Server 2000. In SQL Server, you can run the following command to get a list of all the wait types: DBCC SQLPERF(waitstats) The query above will work in SQL Server 2005/2008/R2  because of backup compatibility. As you might have noticed, I have been discussing everything keeping SQL Server 2005+ in mind, but I have given little consideration on SQL Server 2000. However, I am pretty sure that most of the suggestions I have provided are applicable to SQL Server 2000. The wait types I have been discussing mostly exist in SQL Server 2000 as well. But the difference of the 2000 version is that it gets late recent releases, but it is worth it. Wait types are very essential to measure performance bottleneck. Because of this, I do not have to state that I am big fan of them just so I could identify performance bottleneck. Please read all the post in the Wait Types and Queue series. Note: The information presented here is from my experience and there is no way that I claim it to be accurate. I suggest reading Book OnLine for further clarification. All the discussion of Wait Stats in this blog is generic and varies from system to system. It is recommended that you test this on a development server before implementing it to a production server. Reference: Pinal Dave (http://blog.SQLAuthority.com) Filed under: Pinal Dave, PostADay, SQL, SQL Authority, SQL Query, SQL Scripts, SQL Server, SQL Tips and Tricks, SQL Wait Stats, SQL Wait Types, T SQL, Technology

    Read the article

  • DBCC CHECKDB Fails Displaying 8914 Error

    MS SQL Server database user might encounter database corruption issues due to improper system shutdown, metadata structure damage, human mistake, and virus infection. In most situations of database c... [Author: Mark Willium - Computers and Internet - May 14, 2010]

    Read the article

  • HD Crash SQL server -> DBCC - consistency errors in table 'sysindexes'

    - by Julian de Wit
    Hello A client of mine has had an HD crash an a SQL DB got corrupt : They did not make backups so they have a big problem. When I tried (an ultimate measure) to DBCC-repair I got the following message. Can anybody help me with this ? Server: Msg 8966, Level 16, State 1, Line 1 Could not read and latch page (1:872) with latch type SH. sysindexes failed. Server: Msg 8944, Level 16, State 1, Line 1 Table error: Object ID 2, index ID 0, page (1:872), row 11. Test (columnOffsets->IsComplex (varColumnNumber) && (ColumnId == COLID_HYDRA_TEXTPTR || ColumnId == COLID_INROW_ROOT || ColumnId == COLID_BACKPTR)) failed. Values are 2 and 5. The repair level on the DBCC statement caused this repair to be bypassed. CHECKTABLE found 0 allocation errors and 1 consistency errors in table 'sysindexes' (object ID 2). DBCC execution completed. If DBCC printed error messages, contact your system administrator.

    Read the article

  • Syntax for DBCC CHECKTABLE on all indexes?

    - by GuinnessFan
    Just want to check the syntax to make sure this is for one table and all indexes (default?). --must be single user ALTER DATABASE database_name SET SINGLE_USER; DBCC CHECKTABLE ( "table_name" , REPAIR_ALLOW_DATA_LOSS ) WITH ALL_ERRORMSGS; -- TURN BACK MULTI USER ALTER DATABASE database_name SET MULTI_USER; Also, should I be in the database containing the table to repair or should I be in master?

    Read the article

  • is there a GOTCHA - DBCC CHECKDB ('DBNAME', NOINDEX)?

    - by Deb Anderson
    I am turning on DBCC CHECKDB in our OLTP environment (SQL 2005,2008). System overhead is a very visible thing on our serversso I want them to be as efficient as it makes sense for them to be. HENCE - I want to turn on the NOINDEX option, an option I've never used before. My thoughts are these: if there is a problem with an index that is detected outside the integrity check, that I can just rebuild the index. Also the duration of the integrity checks will be drastically reduced, and the nastier corruption will be detected. What is the flaw in my plan? Thanks, Deb

    Read the article

  • Repairing inconsistent pages in database

    - by Raj
    We have a SQL 2000 DB. The server crashed due to Raid array failure. Now when we run DBCC CHECKDB, we get an error that there are 27 consistency errors in 9 pages. When we run DBCC PAGE on these pages, we get this: Msg 8939, Level 16, State 106, Line 1 Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19. Msg 8939, Level 16, State 108, Line 1 Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0. Since the indicated index is non-clustered and is created by a unique constarint that includes 2 columns, we tried dropping and recreating the index. This resulted in the following error: CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '3280'. The statement has been terminated. However running Select var_id,result_on from tests group by var_id,result_on having count(*)>1 returns 0 rows. Here is what we are planning to do: Restore a pre-server crash copy of the DB and run DBCC CHECKDB If that returns clean, then restore again with no recovery Apply all subequent TLOG backups Stop production app, take a tail log backup and apply that too Drop prod DB and rename the freshly restored DB to make it prod Start prod app Could someone please punch holes in this approach? Maybe, suggest a different approach? What we need is minimum downtime. SQL 2000 DB Size 94 GB The table that has corrupt pages has 460 Million+ rows of data Thanks for the help. Raj

    Read the article

  • Why do I bother with RAID 10 ?

    - by GrumpyOldDBA
    Before I post anything I just want to clarify what I mean by RAID 10 , this is sets of mirrored pairs that have been striped as against a RAID 0 which has been mirrored. I've just had a disk failure in the data array for one of my dev servers, it's an eight disk raid 8, no real worries, replace disk and off we go - but no - the HP engineers told me from the diagnostics ( done to ensure I got the right replacement under warranty ) that not only had a disk failed but I'd lost all the data...(read more)

    Read the article

  • DBCC CHECKDB (BatmanDb, REPAIR_ALLOW_DATA_LOSS) &ndash; Are you Feeling Lucky?

    - by David Totzke
    I’m currently working for a client on a PowerBuilder to WPF migration.  It’s one of those “I could tell you, but I’d have to kill you” kind of clients and the quick-lime pits are currently occupied by the EMC tech…but I’ve said too much already. At approximately 3 or 4 pm that day users of the Batman[1] application here in Gotham[1] started to experience problems accessing the application.  Batman[2] is a document management system here that also integrates with the ERP system.  Very little goes on here that doesn’t involve Batman in some way.  The errors being received seemed to point to network issues (TCP protocol error, connection forcibly closed by the remote host etc…) but the real issue was much more insidious. Connecting to the database via SSMS and performing selects on certain tables underlying the application areas that were having problems started to reveal the issue.  You couldn’t do a SELECT * FROM MyTable without it bombing and giving the same error noted above.  A run of DBCC CHECKDB revealed 14 tables with corruption.  One of the tables with issues was the Document table.  Pretty central to a “document management” system.  Information was obtained from IT that a single drive in the SAN went bad in the night.  A new drive was in place and was working fine.  The partition that held the Batman database is configured for RAID Level 5 so a single drive failure shouldn’t have caused any trouble and yet, the database is corrupted.  They do hourly incremental backups here so the first thing done was to try a restore.  A restore of the most recent backup failed so they worked backwards until they hit a good point.  This successful restore was for a backup at 3AM – a full day behind.  This time also roughly corresponds with the time the SAN started to report the drive failure.  The plot thickens… I got my hands on the output from DBCC CHECKDB and noticed a pattern.  What’s sad is that nobody that should have noticed the pattern in the DBCC output did notice.  There was a rush to do things to try and recover the data before anybody really understood what was wrong with it in the first place.  Cooler heads must prevail in these circumstances and some investigation should be done and a plan of action laid out or you could end up making things worse[3].  DBCC CHECKDB also told us that: repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB Yikes.  That means that the database is so messed up that you’re definitely going to lose some stuff when you repair it to get it back to a consistent state.  All the more reason to do a little more investigation into the problem.  Rescuing this database is preferable to having to export all of the data possible from this database into a new one.  This is a fifteen year old application with about seven hundred tables.  There are TRIGGERS everywhere not to mention the referential integrity constraints to deal with.  Only fourteen of the tables have an issue.  We have a good backup that is missing the last 24 hours of business which means we could have a “do-over” of yesterday but that’s not a very palatable option either. All of the affected tables had TEXT columns and all of the errors were about LOB data types and orphaned off-row data which basically means TEXT, IMAGE or NTEXT columns.  If we did a SELECT on an affected table and excluded those columns, we got all of the rows.  We exported that data into a separate database.  Things are looking up.  Working on a copy of the production database we then ran DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS and that “fixed” everything up.   The allow data loss option will delete the bad rows.  This isn’t too horrible as we have all of those rows minus the text fields from out earlier export.  Now I could LEFT JOIN to the exported data to find the missing rows and INSERT them minus the TEXT column data. We had the restored data from the good 3AM backup that we could now JOIN to and, with fingers crossed, recover the missing TEXT column information.  We got lucky in that all of the affected rows were old and in the end we didn’t lose anything.  :O  All of the row counts along the way worked out and it looks like we dodged a major bullet here. We’ve heard back from EMC and it turns out the SAN firmware that they were running here is apparently buggy.  This thing is only a couple of months old.  Grrr…. They dispatched a technician that night to come and update it .  That explains why RAID didn’t save us. All-in-all this could have been a lot worse.  Given the root cause here, they basically won the lottery in not losing anything. Here are a few links to some helpful posts on the SQL Server Engine blog.  I love the title of the first one: Which part of 'REPAIR_ALLOW_DATA_LOSS' isn't clear? CHECKDB (Part 8): Can repair fix everything? (in fact, read the whole series) Ta da! Emergency mode repair (we didn’t have to resort to this one thank goodness)   Dave Just because I can…   [1] Names have been changed to protect the guilty. [2] I'm Batman. [3] And if I'm the coolest head in the room, you've got even bigger problems...

    Read the article

  • How to analyze 'dbcc memorystatus' result in SQL Server 2008

    - by envykok
    Currently i am facing a sql memory pressure issue. i have run 'dbcc memorystatus', here is part of my result: Memory Manager KB VM Reserved 23617160 VM Committed 14818444 Locked Pages Allocated 0 Reserved Memory 1024 Reserved Memory In Use 0 Memory node Id = 0 KB VM Reserved 23613512 VM Committed 14814908 Locked Pages Allocated 0 MultiPage Allocator 387400 SinglePage Allocator 3265000 MEMORYCLERK_SQLBUFFERPOOL (node 0) KB VM Reserved 16809984 VM Committed 14184208 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 0 MultiPage Allocator 408 MEMORYCLERK_SQLCLR (node 0) KB VM Reserved 6311612 VM Committed 141616 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 1456 MultiPage Allocator 20144 CACHESTORE_SQLCP (node 0) KB VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 3101784 MultiPage Allocator 300328 Buffer Pool Value Committed 1742946 Target 1742946 Database 1333883 Dirty 940 In IO 1 Latched 18 Free 89 Stolen 408974 Reserved 2080 Visible 1742946 Stolen Potential 1579938 Limiting Factor 13 Last OOM Factor 0 Page Life Expectancy 5463 Process/System Counts Value Available Physical Memory 258572288 Available Virtual Memory 8771398631424 Available Paging File 16030617600 Working Set 15225597952 Percent of Committed Memory in WS 100 Page Faults 305556823 System physical memory high 1 System physical memory low 0 Process physical memory low 0 Process virtual memory low 0 Procedure Cache Value TotalProcs 11382 TotalPages 430160 InUsePages 28 Can you lead me to analyze this result ? Is it a lot execute plan have been cached causing the memory issue or other reasons?

    Read the article

  • Should I be regularly shrinking my DB or at least my log file?

    - by Tom
    My question is, should I be running one or both of the shrink command regularly, DBCC SHRINKDATABASE OR DBCC SHRINKFILE ============================= background Sql Server: Database is 200 gigs, logs are 150 gigs. running this command SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int) / 128.0 AS AvailableSpaceInMB FROM sys.database_files;` produces this output.. MyDB: 159.812500 MB free MyDB_Log: 149476.390625 MB free So it seems there is some free space. We backup transaction logs every hour, diff backup 5 nights a week, full backup the other 2 nights of the week.

    Read the article

  • SQL Server 2005 - Understanding ouput of DBCC SHOWCONTIG

    - by user169743
    I'm seeing some slow performance on a SQL Server 2005 database. I've been doing some research regarding SQL Server performance but I'm having difficulty fully understanding the output of SHOWCONTIG and would be very grateful if someone could have a look and offer some suggestions to improve performance. TABLE level scan performed. Pages Scanned................................: 19348 Extents Scanned..............................: 2427 Extent Switches..............................: 3829 Avg. Pages per Extent........................: 8.0 Scan Density [Best Count:Actual Count].......: 63.16% [2419:3830] Logical Scan Fragmentation ..................: 8.40% Extent Scan Fragmentation ...................: 35.15% Avg. Bytes Free per Page.....................: 938.1 Avg. Page Density (full).....................: 88.41%

    Read the article

  • MS SQL 2005 - Understanding ouput of DBCC SHOWCONTIG

    - by user169743
    I'm seeing some slow performance on a MS SQL 2005 database. I've been doing some research regarding MS SQL performance but I'm having difficulty fully understanding the output of SHOWCONTIG and would be very grateful if someone could have a look and offer some suggestions to improve performance. TABLE level scan performed. Pages Scanned................................: 19348 Extents Scanned..............................: 2427 Extent Switches..............................: 3829 Avg. Pages per Extent........................: 8.0 Scan Density [Best Count:Actual Count].......: 63.16% [2419:3830] Logical Scan Fragmentation ..................: 8.40% Extent Scan Fragmentation ...................: 35.15% Avg. Bytes Free per Page.....................: 938.1 Avg. Page Density (full).....................: 88.41%

    Read the article

1 2 3 4 5 6 7 8  | Next Page >