Author |
Topic |
dcarva
Posting Yak Master
140 Posts |
Posted - 2007-03-06 : 14:12:12
|
Hello,My database grew pretty large over the weekend. I inspected the table sizes and I found that I have a table that has 650,000 rows and shows up as 18GB in the Taskpad. Each row has 5 columns. All columns are ints and don't contain very much data. Index size is 24 MB. How can a table of that size be 18GB? Any ideas? I have databases with many larger tables (and more columns) and the entire database is less than 18GB.ThanksDanny |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
|
dcarva
Posting Yak Master
140 Posts |
Posted - 2007-03-06 : 14:48:49
|
Cool script. I'll try it out. Thanks |
 |
|
milkman
Starting Member
5 Posts |
Posted - 2007-03-07 : 12:25:30
|
I work with Dcarva. Here is a clip from the results that were returned against the DB in question:TABLE_ROWS928734USED_MB40664.7109USED_GB39.7116Strange. If anyone has anything on this, or needs more info from this dump, please let me know.Thanks!!Milkman |
 |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2007-03-07 : 14:34:30
|
Well, the table is using 45,912 bytes/row.Too bad you didn't post the rest of the output, especially since the numbers are completely different from the original post.CODO ERGO SUM |
 |
|
milkman
Starting Member
5 Posts |
Posted - 2007-03-07 : 14:41:36
|
I just didn't want to take up a ton of room in the thread. Posting the top 5 rows in size, with extended data. Unfortunately, I don't know how to get it in a legible format. I'd attach a text file if I could...Thanks...TABLE_ROWS RESERVED DATA INDEX_SIZE UNUSED USED_MB USED_GB AVERAGE_BYTES_PER_ROW AVERAGE_DATA_BYTES_PER_ROW AVERAGE_INDEX_BYTES_PER_ROW AVERAGE_UNUSED_BYTES_PER_ROW----------- ----------- ----------- ----------- ----------- -------------------- -------------------- --------------------- -------------------------- --------------------------- ----------------------------928734 41640664 5187432 85064 36368168 40664.7109 39.7116 45912.00488 5719.53904 93.78954 40098.6763625545 17924296 2236344 24184 15663768 17504.1953 17.0939 29341.58071 3660.83376 39.58854 25641.1584421042 14212120 1775792 23320 12413008 13879.0234 13.5537 34564.7486 4318.83519 56.71567 30189.19773316100 11805832 1473488 11128 10321216 11529.1328 11.2589 38244.77054 4773.33664 36.04895 33435.38495198134 6930480 866360 6472 6057648 6768.0469 6.6094 35818.2418 4477.53864 33.44872 31307.25444 |
 |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2007-03-07 : 14:52:35
|
The average unused bytes per row is huge, over 40098 on the first table.Did you just reindex the tables with some extremely low fill factor, like 1%, or perform some other major maintenance operation?You should investigate by running DBCC SHOWCONTIG on these tables.CODO ERGO SUM |
 |
|
milkman
Starting Member
5 Posts |
Posted - 2007-03-08 : 15:15:17
|
Here are the results from the SHOWCONTIG for the largest table:DBCC SHOWCONTIG scanning 'UserUsage' table...Table: 'UserUsage' (1646628909); index ID: 0, database ID: 38TABLE level scan performed.- Pages Scanned................................: 648429- Extents Scanned..............................: 648176- Extent Switches..............................: 648175- Avg. Pages per Extent........................: 1.0- Scan Density [Best Count:Actual Count].......: 12.50% [81054:648176]- Extent Scan Fragmentation ...................: 45.32%- Avg. Bytes Free per Page.....................: 7997.2- Avg. Page Density (full).....................: 1.20%DBCC SHOWCONTIG scanning 'UserUsage' table...Table: 'UserUsage' (1646628909); index ID: 2, database ID: 38LEAF level scan performed.- Pages Scanned................................: 4313- Extents Scanned..............................: 972- Extent Switches..............................: 1383- Avg. Pages per Extent........................: 4.4- Scan Density [Best Count:Actual Count].......: 39.02% [540:1384]- Logical Scan Fragmentation ..................: 11.36%- Extent Scan Fragmentation ...................: 50.51%- Avg. Bytes Free per Page.....................: 1635.8- Avg. Page Density (full).....................: 79.79%DBCC SHOWCONTIG scanning 'UserUsage' table...Table: 'UserUsage' (1646628909); index ID: 3, database ID: 38LEAF level scan performed.- Pages Scanned................................: 3831- Extents Scanned..............................: 927- Extent Switches..............................: 1291- Avg. Pages per Extent........................: 4.1- Scan Density [Best Count:Actual Count].......: 37.07% [479:1292]- Logical Scan Fragmentation ..................: 12.42%- Extent Scan Fragmentation ...................: 55.12%- Avg. Bytes Free per Page.....................: 1792.8- Avg. Page Density (full).....................: 77.85%DBCC SHOWCONTIG scanning 'UserUsage' table...Table: 'UserUsage' (1646628909); index ID: 4, database ID: 38LEAF level scan performed.- Pages Scanned................................: 2342- Extents Scanned..............................: 551- Extent Switches..............................: 697- Avg. Pages per Extent........................: 4.3- Scan Density [Best Count:Actual Count].......: 41.98% [293:698]- Logical Scan Fragmentation ..................: 9.99%- Extent Scan Fragmentation ...................: 53.72%- Avg. Bytes Free per Page.....................: 1750.9- Avg. Page Density (full).....................: 78.37%DBCC execution completed. If DBCC printed error messages, contact your system administrator.Is that Avg. Page Density for that first index low? 1.20%?Forgive me, but I'm new to this stuff.Oh, just adding that these bigger tables are 'heap' tables. Don't know if that has anything to do with it, but we do know that nothing has changed, and anytime this DB is created on different machines, we've never seen this. |
 |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2007-03-08 : 21:54:41
|
The page density of 1.20% is extremely low. With a more reasonable page density, like 80%, the table would only be about 0.5 Gb in size instead of 40 GB.If you had a clustered index on the table, you could just run DBCC DBREINDEX to reindex the table to recover most of the space.Since you don't have a clustered index, you would have to reload the table to increase the page density to a reasonable level. Just one reason why it is almost always better to have a clustered index on a table.CODO ERGO SUM |
 |
|
Kristen
Test
22859 Posts |
Posted - 2007-03-09 : 04:49:25
|
"you would have to reload the table to increase the page density"Blimey, I never knew that - is there no way to defrag such a table then? (other than "reload")... mind you, not sure why I'm worrying, we always have a clustered index ... but I suppose I ought to add a Query to me "Make a Release Version" process to list any table that does NOT have a C.I. ...Kristen |
 |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2007-03-09 : 08:32:38
|
quote: Originally posted by Kristen "you would have to reload the table to increase the page density"Blimey, I never knew that - is there no way to defrag such a table then? (other than "reload")... mind you, not sure why I'm worrying, we always have a clustered index ... but I suppose I ought to add a Query to me "Make a Release Version" process to list any table that does NOT have a C.I. ...Kristen
This script shows what happens. Notice that the DBCC SHOWCONTIG is unchanged after DBCC DBREINDEX.Of course, you could increase the page density without reloading by creating a clustered index on the table.print ''print '-- Create a heap table'print ''create table NUM ( NUMBER int not null ) print ''print '-- Insert data'print ''insert into NUM (NUMBER)select top 100 percent NUMBERfrom F_TABLE_NUMBER_RANGE(1,100000)order by NUMBERprint ''print '-- showcontig before delete'print ''dbcc showcontig ( NUM )print ''print '-- Delete 99% of the rows'print ''delete from NUMwhere NUMBER%100 <> 0print ''print '-- showcontig before dbreindex'print ''dbcc showcontig ( NUM )print ''print '-- Run dbreindex'print ''dbcc dbreindex ( NUM ,'',90)print ''print '-- showcontig after dbreindex'print ''dbcc showcontig ( NUM )drop table NUM Results: -- Create a heap table -- Insert data (100000 row(s) affected) -- showcontig before delete DBCC SHOWCONTIG scanning 'NUM' table...Table: 'NUM' (546817010); index ID: 0, database ID: 10TABLE level scan performed.- Pages Scanned................................: 179- Extents Scanned..............................: 24- Extent Switches..............................: 23- Avg. Pages per Extent........................: 7.5- Scan Density [Best Count:Actual Count].......: 95.83% [23:24]- Extent Scan Fragmentation ...................: 8.33%- Avg. Bytes Free per Page.....................: 833.4- Avg. Page Density (full).....................: 89.70%DBCC execution completed. If DBCC printed error messages, contact your system administrator. -- Delete 99% of the rows (99000 row(s) affected) -- showcontig before dbreindex DBCC SHOWCONTIG scanning 'NUM' table...Table: 'NUM' (546817010); index ID: 0, database ID: 10TABLE level scan performed.- Pages Scanned................................: 173- Extents Scanned..............................: 24- Extent Switches..............................: 23- Avg. Pages per Extent........................: 7.2- Scan Density [Best Count:Actual Count].......: 91.67% [22:24]- Extent Scan Fragmentation ...................: 8.33%- Avg. Bytes Free per Page.....................: 7069.2- Avg. Page Density (full).....................: 12.66%DBCC execution completed. If DBCC printed error messages, contact your system administrator. -- Run dbreindex DBCC execution completed. If DBCC printed error messages, contact your system administrator. -- showcontig after dbreindex DBCC SHOWCONTIG scanning 'NUM' table...Table: 'NUM' (546817010); index ID: 0, database ID: 10TABLE level scan performed.- Pages Scanned................................: 173- Extents Scanned..............................: 24- Extent Switches..............................: 23- Avg. Pages per Extent........................: 7.2- Scan Density [Best Count:Actual Count].......: 91.67% [22:24]- Extent Scan Fragmentation ...................: 8.33%- Avg. Bytes Free per Page.....................: 7069.2- Avg. Page Density (full).....................: 12.66%DBCC execution completed. If DBCC printed error messages, contact your system administrator. CODO ERGO SUM |
 |
|
Kristen
Test
22859 Posts |
Posted - 2007-03-09 : 09:55:38
|
Scary!Thanks for that. |
 |
|
|