Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 Table size

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.

Thanks
Danny

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2007-03-06 : 14:21:04
You should run the script on this link to verify that the information from Taskpad is correct:

Script to analyze table space usage
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=61762



CODO ERGO SUM
Go to Top of Page

dcarva
Posting Yak Master

140 Posts

Posted - 2007-03-06 : 14:48:49
Cool script. I'll try it out. Thanks
Go to Top of Page

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_ROWS
928734

USED_MB
40664.7109

USED_GB
39.7116


Strange. If anyone has anything on this, or needs more info from this dump, please let me know.

Thanks!!

Milkman
Go to Top of Page

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
Go to Top of Page

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.6763
625545 17924296 2236344 24184 15663768 17504.1953 17.0939 29341.58071 3660.83376 39.58854 25641.1584
421042 14212120 1775792 23320 12413008 13879.0234 13.5537 34564.7486 4318.83519 56.71567 30189.19773
316100 11805832 1473488 11128 10321216 11529.1328 11.2589 38244.77054 4773.33664 36.04895 33435.38495
198134 6930480 866360 6472 6057648 6768.0469 6.6094 35818.2418 4477.53864 33.44872 31307.25444
Go to Top of Page

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
Go to Top of Page

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: 38
TABLE 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: 38
LEAF 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: 38
LEAF 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: 38
LEAF 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.
Go to Top of Page

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
Go to Top of Page

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
Go to Top of Page

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
NUMBER
from
F_TABLE_NUMBER_RANGE(1,100000)
order by
NUMBER

print ''
print '-- showcontig before delete'
print ''
dbcc showcontig ( NUM )

print ''
print '-- Delete 99% of the rows'
print ''
delete from NUM
where
NUMBER%100 <> 0

print ''
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: 10
TABLE 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: 10
TABLE 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: 10
TABLE 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
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2007-03-09 : 09:55:38
Scary!

Thanks for that.
Go to Top of Page
   

- Advertisement -