how to tell empty space in a bd?

[david spaisman]

Hello:

Today, I transferred (via transfer manager)the data from production to a
development database to refresh it with current data. The counts of the
rows in each table of production and development are exactly the same. In
looking at the total space allocated and the space remaining, it appears
that the production database consumes 1100mb while development ate up
800mb+.

The largest table(with a clustered index) takes up 60% of the disk space.
The production database(part of the conversion from an older app) has much
data deleted(too old) and development was rebuild last week.

I ran dbcc showcontig on both and both have scan densities of 99%+ so there
should be no fragmentation or wasted space.

I am almost certain that the large table was created with the same
fillfactor(default).

So, now I am perplexed as to why there is a large difference?

1) When MSSQL reclaim disk sapce from rows deleted?

2) How can I tell exactly exactly hwee the wasted storage is?

3) Do I have to drop and recreated whatever objects have wasted space(large
table?)?

4) Are there any other suggestions as why this large discrepancy occurred?

Thanks.

David Spaisman

[Greg]

did u use 'dbcc updateusage'?

On 3/4/99 8:46:52 PM, david spaisman wrote:
> Hello:

Today, I transferred (via transfer manager)the
> data from production to a
development database to
> refresh it with current data. The counts of the
rows in
> each table of production and development are exactly the same. In

> looking at the total space allocated and the space remaining, it
> appears
that the production database consumes 1100mb
> while development ate up
800mb+.


> The largest table(with a clustered index) takes up 60% of the disk space.
>
The production database(part of the conversion from an
> older app) has much
data deleted(too old) and
> development was rebuild last week.

I ran dbcc
> showcontig on both and both have scan densities of 99%+ so there

> should be no fragmentation or wasted space.

I
> am almost certain that the large table was created with the same

> fillfactor(default).

So, now I am perplexed
> as to why there is a large difference?

1) When MSSQL
> reclaim disk sapce from rows deleted?

2) How can I
> tell exactly exactly hwee the wasted storage is?

3) Do
> I have to drop and recreated whatever objects have wasted space(large

> table?)?

4) Are there any other
> suggestions as why this large discrepancy occurred?


> Thanks.

David Spaisman

[Ray Miao]

On 3/4/99 8:46:52 PM, david spaisman wrote:
> Hello:

Today, I transferred (via transfer manager)the
> data from production to a
development database to
> refresh it with current data. The counts of the
rows in
> each table of production and development are exactly the same. In

> looking at the total space allocated and the space remaining, it
> appears
that the production database consumes 1100mb
> while development ate up
800mb+.


> The largest table(with a clustered index) takes up 60% of the disk space.
>
The production database(part of the conversion from an
> older app) has much
data deleted(too old) and
> development was rebuild last week.

I ran dbcc
> showcontig on both and both have scan densities of 99%+ so there

> should be no fragmentation or wasted space.

I
> am almost certain that the large table was created with the same

> fillfactor(default).

So, now I am perplexed
> as to why there is a large difference?

1) When MSSQL
> reclaim disk sapce from rows deleted?

2) How can I
> tell exactly exactly hwee the wasted storage is?

3) Do
> I have to drop and recreated whatever objects have wasted space(large

> table?)?

4) Are there any other
> suggestions as why this large discrepancy occurred?


> Thanks.

David Spaisman

Try dbcc checkdb and dbcc dbreindex.