All,
I just want to make sure my understanding is correct:
1) alter table drop column does not release space of varchar columns and
other columns of variable length.
2) dbcc cleantable frees this space
Open questions:
3) What about the space used by fixed size columns? Is it reclaimed
during drop (timing lets me suspect that it's not)? dbcc cleantable "does
not reclaim space after a fixed length column is dropped."
http://msdn.microsoft.com/library/de..._dbcc_4bah.asp
Are rows inserted after a DROP COLUMN smaller?
Thanks a lot!
Kind regards
robert
Robert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/de..._dbcc_4bah.asp
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert
|||Well, its actually two questions.
1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does the
ALTER TABLE ... DROP COLUMN statement. Correct.
2. Are the rows inserted after the ALTER TABLE statement has been issued?
Yes, new rows will only occupy the storage required for the new data
definition contingent on the values of PAD_INDEX and FILLFACTOR for the
Clustered Index.
Now, the next logical question would be: how to I reclaim the space after
issue the ALTER TABLE ... DROP COLUMN statement with a fixed-length column?
Rebuild the Clustered Index.
Sincerely,
Anthony Thomas
"Robert Klemme" <bob.news@.gmx.net> wrote in message
news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
Robert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/de..._dbcc_4bah.asp
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert
|||Anthony Thomas wrote:
> "Robert Klemme" <bob.news@.gmx.net> wrote in message
> news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
> Robert Klemme wrote:
>
http://msdn.microsoft.com/library/de..._dbcc_4bah.asp
> No one wants to answer this one? Come on... I can even offer a
> virtual hug. :-)
> Well, its actually two questions.
> 1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does
> the ALTER TABLE ... DROP COLUMN statement. Correct.
Ok.
> 2. Are the rows inserted after the ALTER TABLE statement has been
> issued? Yes, new rows will only occupy the storage required for the
> new data definition contingent on the values of PAD_INDEX and
> FILLFACTOR for the Clustered Index.
Ok.
> Now, the next logical question would be: how to I reclaim the space
> after issue the ALTER TABLE ... DROP COLUMN statement with a
> fixed-length column?
> Rebuild the Clustered Index.
Ok, so basically the space is not reclaimed until either the complete
table is rebuild or old records are deleted.
Thanks a lot! You get the virtual hug: *hug*
:-)
Kind regards
robert
Showing posts with label release. Show all posts
Showing posts with label release. Show all posts
Tuesday, March 20, 2012
alter table drop column and dbcc cleantable
All,
I just want to make sure my understanding is correct:
1) alter table drop column does not release space of varchar columns and
other columns of variable length.
2) dbcc cleantable frees this space
Open questions:
3) What about the space used by fixed size columns? Is it reclaimed
during drop (timing lets me suspect that it's not)? dbcc cleantable "does
not reclaim space after a fixed length column is dropped."
bah.asp" target="_blank">http://msdn.microsoft.com/library/d...
bah.asp
Are rows inserted after a DROP COLUMN smaller?
Thanks a lot!
Kind regards
robertRobert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/d...s_dbcc_4bah.asp[vb
col=seagreen]
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert[/vbcol]
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Well, its actually two questions.
1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does the
ALTER TABLE ... DROP COLUMN statement. Correct.
2. Are the rows inserted after the ALTER TABLE statement has been issued?
Yes, new rows will only occupy the storage required for the new data
definition contingent on the values of PAD_INDEX and FILLFACTOR for the
Clustered Index.
Now, the next logical question would be: how to I reclaim the space after
issue the ALTER TABLE ... DROP COLUMN statement with a fixed-length column?
Rebuild the Clustered Index.
Sincerely,
Anthony Thomas
"Robert Klemme" <bob.news@.gmx.net> wrote in message
news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
Robert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/d...s_dbcc_4bah.asp[vb
col=seagreen]
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert[/vbcol]
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Anthony Thomas wrote:
> "Robert Klemme" <bob.news@.gmx.net> wrote in message
> news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
> Robert Klemme wrote:
>
http://msdn.microsoft.com/library/d...s_dbcc_4bah.asp[vb
col=seagreen]
> No one wants to answer this one? Come on... I can even offer a
> virtual hug. :-)[/vbcol]
> Well, its actually two questions.
> 1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does
> the ALTER TABLE ... DROP COLUMN statement. Correct.
Ok.
> 2. Are the rows inserted after the ALTER TABLE statement has been
> issued? Yes, new rows will only occupy the storage required for the
> new data definition contingent on the values of PAD_INDEX and
> FILLFACTOR for the Clustered Index.
Ok.
> Now, the next logical question would be: how to I reclaim the space
> after issue the ALTER TABLE ... DROP COLUMN statement with a
> fixed-length column?
> Rebuild the Clustered Index.
Ok, so basically the space is not reclaimed until either the complete
table is rebuild or old records are deleted.
Thanks a lot! You get the virtual hug: *hug*
:-)
Kind regards
robert
I just want to make sure my understanding is correct:
1) alter table drop column does not release space of varchar columns and
other columns of variable length.
2) dbcc cleantable frees this space
Open questions:
3) What about the space used by fixed size columns? Is it reclaimed
during drop (timing lets me suspect that it's not)? dbcc cleantable "does
not reclaim space after a fixed length column is dropped."
bah.asp" target="_blank">http://msdn.microsoft.com/library/d...
bah.asp
Are rows inserted after a DROP COLUMN smaller?
Thanks a lot!
Kind regards
robertRobert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/d...s_dbcc_4bah.asp[vb
col=seagreen]
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert[/vbcol]
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Well, its actually two questions.
1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does the
ALTER TABLE ... DROP COLUMN statement. Correct.
2. Are the rows inserted after the ALTER TABLE statement has been issued?
Yes, new rows will only occupy the storage required for the new data
definition contingent on the values of PAD_INDEX and FILLFACTOR for the
Clustered Index.
Now, the next logical question would be: how to I reclaim the space after
issue the ALTER TABLE ... DROP COLUMN statement with a fixed-length column?
Rebuild the Clustered Index.
Sincerely,
Anthony Thomas
"Robert Klemme" <bob.news@.gmx.net> wrote in message
news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
Robert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/d...s_dbcc_4bah.asp[vb
col=seagreen]
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert[/vbcol]
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Anthony Thomas wrote:
> "Robert Klemme" <bob.news@.gmx.net> wrote in message
> news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
> Robert Klemme wrote:
>
http://msdn.microsoft.com/library/d...s_dbcc_4bah.asp[vb
col=seagreen]
> No one wants to answer this one? Come on... I can even offer a
> virtual hug. :-)[/vbcol]
> Well, its actually two questions.
> 1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does
> the ALTER TABLE ... DROP COLUMN statement. Correct.
Ok.
> 2. Are the rows inserted after the ALTER TABLE statement has been
> issued? Yes, new rows will only occupy the storage required for the
> new data definition contingent on the values of PAD_INDEX and
> FILLFACTOR for the Clustered Index.
Ok.
> Now, the next logical question would be: how to I reclaim the space
> after issue the ALTER TABLE ... DROP COLUMN statement with a
> fixed-length column?
> Rebuild the Clustered Index.
Ok, so basically the space is not reclaimed until either the complete
table is rebuild or old records are deleted.
Thanks a lot! You get the virtual hug: *hug*
:-)
Kind regards
robert
alter table drop column and dbcc cleantable
All,
I just want to make sure my understanding is correct:
1) alter table drop column does not release space of varchar columns and
other columns of variable length.
2) dbcc cleantable frees this space
Open questions:
3) What about the space used by fixed size columns? Is it reclaimed
during drop (timing lets me suspect that it's not)? dbcc cleantable "does
not reclaim space after a fixed length column is dropped."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
Are rows inserted after a DROP COLUMN smaller?
Thanks a lot!
Kind regards
robertRobert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Well, its actually two questions.
1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does the
ALTER TABLE ... DROP COLUMN statement. Correct.
2. Are the rows inserted after the ALTER TABLE statement has been issued?
Yes, new rows will only occupy the storage required for the new data
definition contingent on the values of PAD_INDEX and FILLFACTOR for the
Clustered Index.
Now, the next logical question would be: how to I reclaim the space after
issue the ALTER TABLE ... DROP COLUMN statement with a fixed-length column?
Rebuild the Clustered Index.
Sincerely,
Anthony Thomas
"Robert Klemme" <bob.news@.gmx.net> wrote in message
news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
Robert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Anthony Thomas wrote:
> "Robert Klemme" <bob.news@.gmx.net> wrote in message
> news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
> Robert Klemme wrote:
>> All,
>> I just want to make sure my understanding is correct:
>> 1) alter table drop column does not release space of varchar columns
>> and other columns of variable length.
>> 2) dbcc cleantable frees this space
>> Open questions:
>> 3) What about the space used by fixed size columns? Is it reclaimed
>> during drop (timing lets me suspect that it's not)? dbcc cleantable
>> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
>> Are rows inserted after a DROP COLUMN smaller?
>> Thanks a lot!
>> Kind regards
>> robert
> No one wants to answer this one? Come on... I can even offer a
> virtual hug. :-)
> Well, its actually two questions.
> 1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does
> the ALTER TABLE ... DROP COLUMN statement. Correct.
Ok.
> 2. Are the rows inserted after the ALTER TABLE statement has been
> issued? Yes, new rows will only occupy the storage required for the
> new data definition contingent on the values of PAD_INDEX and
> FILLFACTOR for the Clustered Index.
Ok.
> Now, the next logical question would be: how to I reclaim the space
> after issue the ALTER TABLE ... DROP COLUMN statement with a
> fixed-length column?
> Rebuild the Clustered Index.
Ok, so basically the space is not reclaimed until either the complete
table is rebuild or old records are deleted.
Thanks a lot! You get the virtual hug: *hug*
:-)
Kind regards
robert
I just want to make sure my understanding is correct:
1) alter table drop column does not release space of varchar columns and
other columns of variable length.
2) dbcc cleantable frees this space
Open questions:
3) What about the space used by fixed size columns? Is it reclaimed
during drop (timing lets me suspect that it's not)? dbcc cleantable "does
not reclaim space after a fixed length column is dropped."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
Are rows inserted after a DROP COLUMN smaller?
Thanks a lot!
Kind regards
robertRobert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Well, its actually two questions.
1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does the
ALTER TABLE ... DROP COLUMN statement. Correct.
2. Are the rows inserted after the ALTER TABLE statement has been issued?
Yes, new rows will only occupy the storage required for the new data
definition contingent on the values of PAD_INDEX and FILLFACTOR for the
Clustered Index.
Now, the next logical question would be: how to I reclaim the space after
issue the ALTER TABLE ... DROP COLUMN statement with a fixed-length column?
Rebuild the Clustered Index.
Sincerely,
Anthony Thomas
"Robert Klemme" <bob.news@.gmx.net> wrote in message
news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
Robert Klemme wrote:
> All,
> I just want to make sure my understanding is correct:
> 1) alter table drop column does not release space of varchar columns
> and other columns of variable length.
> 2) dbcc cleantable frees this space
> Open questions:
> 3) What about the space used by fixed size columns? Is it reclaimed
> during drop (timing lets me suspect that it's not)? dbcc cleantable
> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
> Are rows inserted after a DROP COLUMN smaller?
> Thanks a lot!
> Kind regards
> robert
No one wants to answer this one? Come on... I can even offer a virtual
hug. :-)
Thanks!
robert|||Anthony Thomas wrote:
> "Robert Klemme" <bob.news@.gmx.net> wrote in message
> news:%23ypiPd4ZFHA.2212@.TK2MSFTNGP14.phx.gbl...
> Robert Klemme wrote:
>> All,
>> I just want to make sure my understanding is correct:
>> 1) alter table drop column does not release space of varchar columns
>> and other columns of variable length.
>> 2) dbcc cleantable frees this space
>> Open questions:
>> 3) What about the space used by fixed size columns? Is it reclaimed
>> during drop (timing lets me suspect that it's not)? dbcc cleantable
>> "does not reclaim space after a fixed length column is dropped."
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_4bah.asp
>> Are rows inserted after a DROP COLUMN smaller?
>> Thanks a lot!
>> Kind regards
>> robert
> No one wants to answer this one? Come on... I can even offer a
> virtual hug. :-)
> Well, its actually two questions.
> 1. DBCC CLEANTABLE does not reclaim CHAR and NCHAR columns, nor does
> the ALTER TABLE ... DROP COLUMN statement. Correct.
Ok.
> 2. Are the rows inserted after the ALTER TABLE statement has been
> issued? Yes, new rows will only occupy the storage required for the
> new data definition contingent on the values of PAD_INDEX and
> FILLFACTOR for the Clustered Index.
Ok.
> Now, the next logical question would be: how to I reclaim the space
> after issue the ALTER TABLE ... DROP COLUMN statement with a
> fixed-length column?
> Rebuild the Clustered Index.
Ok, so basically the space is not reclaimed until either the complete
table is rebuild or old records are deleted.
Thanks a lot! You get the virtual hug: *hug*
:-)
Kind regards
robert
Monday, February 13, 2012
allocated, unused and free space
Considering the output of sp_spaceused (below) on my SQL Server 2005
database, is it possible to get back (release to the OS) the UNUSED space,
shrinking does not do it.
Basically I need to resize this database, most of its space is not being
used and is filling up my backup storage.
I have plenty of room in my data drive but I keep serveral days worth of
backups and thouse GB start to add up and fill up my backup drive.
Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
database_name: c8audit
database_size: 26960.63 MB
unallocated space: 2033.20 MB
reserved: 25521840 KB
data: 3561528 KB
index_size: 8440 KB
unused: 21951872 KB
Thanks,
Tim
DBCC SHRINKFILE will return the space to the OS as long as it is able to
shrink it in the first place. Can you try running that command and post the
actual command you used with all the parameters along with the output from
it? The backups do not include "free space" and only backup the actual
data. So if you have 4GB of data your backups should be roughly 4GB
regardless of how large your db is overall.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>
|||Hi Tim
There is a difference between allocated and unused space. Unallocated space
could be returned to the OS when you shrink a file, but the unused space is
space that has already been allocated to an object, but just doesn't yet
have any data stored in it.
Without seeing you table definitions and knowing the kind of data you're
storing, it's hard to know why you have so much unused space in your tables.
You might try running sp_spaceused on each table, and see which ones have
the most unused.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>
|||Thanks all for your help.
Using SQL Server 2005's standard report "Disk Usage by Table" I was able to
find out that about 90% of the unused space has been allocated to ONE table.
Among this table's fields there are two VARCHAR that caught my attention
because their lengths are bigger than normal, one is 1024 the other one is
2000.
The table has about 2 million records and both of these fields are only
storing a few characters, even though I have not done any calculations I
believe the free space is in these almost empty fields.
I can't modify the fields' length, but about 90% of the records on this
table can go, so I'm going to delete the records to regain the space.
I did this in TEST after my original post and it worked, the UNUSED space
became AVAILABLE FREE and shrinking released it.
Again THANKS!
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
> Hi Tim
> There is a difference between allocated and unused space. Unallocated
> space could be returned to the OS when you shrink a file, but the unused
> space is space that has already been allocated to an object, but just
> doesn't yet have any data stored in it.
> Without seeing you table definitions and knowing the kind of data you're
> storing, it's hard to know why you have so much unused space in your
> tables. You might try running sp_spaceused on each table, and see which
> ones have the most unused.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://blog.kalendelaney.com
>
> "Tim Bales" <timbales@.bellsouth.net> wrote in message
> news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
>
|||Hi Tim
I'm glad you were able to accomplish your goal.
However, it's a mystery what the cause of all the unused space was. A
varchar column should not reserve more space than it actually uses. So if
there were only a few characters in them, that should not have caused excess
space allocation. It might have been that there was padding with spaces, or
it might have been that the columns were longer originally and then updated.
But if you've deleted the rows, we'll probably never know. ;-)
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:%23SIRI7kbIHA.1376@.TK2MSFTNGP02.phx.gbl...
> Thanks all for your help.
> Using SQL Server 2005's standard report "Disk Usage by Table" I was able
> to find out that about 90% of the unused space has been allocated to ONE
> table.
> Among this table's fields there are two VARCHAR that caught my attention
> because their lengths are bigger than normal, one is 1024 the other one is
> 2000.
> The table has about 2 million records and both of these fields are only
> storing a few characters, even though I have not done any calculations I
> believe the free space is in these almost empty fields.
> I can't modify the fields' length, but about 90% of the records on this
> table can go, so I'm going to delete the records to regain the space.
> I did this in TEST after my original post and it worked, the UNUSED space
> became AVAILABLE FREE and shrinking released it.
> Again THANKS!
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
>
database, is it possible to get back (release to the OS) the UNUSED space,
shrinking does not do it.
Basically I need to resize this database, most of its space is not being
used and is filling up my backup storage.
I have plenty of room in my data drive but I keep serveral days worth of
backups and thouse GB start to add up and fill up my backup drive.
Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
database_name: c8audit
database_size: 26960.63 MB
unallocated space: 2033.20 MB
reserved: 25521840 KB
data: 3561528 KB
index_size: 8440 KB
unused: 21951872 KB
Thanks,
Tim
DBCC SHRINKFILE will return the space to the OS as long as it is able to
shrink it in the first place. Can you try running that command and post the
actual command you used with all the parameters along with the output from
it? The backups do not include "free space" and only backup the actual
data. So if you have 4GB of data your backups should be roughly 4GB
regardless of how large your db is overall.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>
|||Hi Tim
There is a difference between allocated and unused space. Unallocated space
could be returned to the OS when you shrink a file, but the unused space is
space that has already been allocated to an object, but just doesn't yet
have any data stored in it.
Without seeing you table definitions and knowing the kind of data you're
storing, it's hard to know why you have so much unused space in your tables.
You might try running sp_spaceused on each table, and see which ones have
the most unused.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>
|||Thanks all for your help.
Using SQL Server 2005's standard report "Disk Usage by Table" I was able to
find out that about 90% of the unused space has been allocated to ONE table.
Among this table's fields there are two VARCHAR that caught my attention
because their lengths are bigger than normal, one is 1024 the other one is
2000.
The table has about 2 million records and both of these fields are only
storing a few characters, even though I have not done any calculations I
believe the free space is in these almost empty fields.
I can't modify the fields' length, but about 90% of the records on this
table can go, so I'm going to delete the records to regain the space.
I did this in TEST after my original post and it worked, the UNUSED space
became AVAILABLE FREE and shrinking released it.
Again THANKS!
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
> Hi Tim
> There is a difference between allocated and unused space. Unallocated
> space could be returned to the OS when you shrink a file, but the unused
> space is space that has already been allocated to an object, but just
> doesn't yet have any data stored in it.
> Without seeing you table definitions and knowing the kind of data you're
> storing, it's hard to know why you have so much unused space in your
> tables. You might try running sp_spaceused on each table, and see which
> ones have the most unused.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://blog.kalendelaney.com
>
> "Tim Bales" <timbales@.bellsouth.net> wrote in message
> news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
>
|||Hi Tim
I'm glad you were able to accomplish your goal.
However, it's a mystery what the cause of all the unused space was. A
varchar column should not reserve more space than it actually uses. So if
there were only a few characters in them, that should not have caused excess
space allocation. It might have been that there was padding with spaces, or
it might have been that the columns were longer originally and then updated.
But if you've deleted the rows, we'll probably never know. ;-)
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:%23SIRI7kbIHA.1376@.TK2MSFTNGP02.phx.gbl...
> Thanks all for your help.
> Using SQL Server 2005's standard report "Disk Usage by Table" I was able
> to find out that about 90% of the unused space has been allocated to ONE
> table.
> Among this table's fields there are two VARCHAR that caught my attention
> because their lengths are bigger than normal, one is 1024 the other one is
> 2000.
> The table has about 2 million records and both of these fields are only
> storing a few characters, even though I have not done any calculations I
> believe the free space is in these almost empty fields.
> I can't modify the fields' length, but about 90% of the records on this
> table can go, so I'm going to delete the records to regain the space.
> I did this in TEST after my original post and it worked, the UNUSED space
> became AVAILABLE FREE and shrinking released it.
> Again THANKS!
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
>
allocated, unused and free space
Considering the output of sp_spaceused (below) on my SQL Server 2005
database, is it possible to get back (release to the OS) the UNUSED space,
shrinking does not do it.
Basically I need to resize this database, most of its space is not being
used and is filling up my backup storage.
I have plenty of room in my data drive but I keep serveral days worth of
backups and thouse GB start to add up and fill up my backup drive.
Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
database_name: c8audit
database_size: 26960.63 MB
unallocated space: 2033.20 MB
reserved: 25521840 KB
data: 3561528 KB
index_size: 8440 KB
unused: 21951872 KB
Thanks,
TimDBCC SHRINKFILE will return the space to the OS as long as it is able to
shrink it in the first place. Can you try running that command and post the
actual command you used with all the parameters along with the output from
it? The backups do not include "free space" and only backup the actual
data. So if you have 4GB of data your backups should be roughly 4GB
regardless of how large your db is overall.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>|||Hi Tim
There is a difference between allocated and unused space. Unallocated space
could be returned to the OS when you shrink a file, but the unused space is
space that has already been allocated to an object, but just doesn't yet
have any data stored in it.
Without seeing you table definitions and knowing the kind of data you're
storing, it's hard to know why you have so much unused space in your tables.
You might try running sp_spaceused on each table, and see which ones have
the most unused.
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>|||Thanks all for your help.
Using SQL Server 2005's standard report "Disk Usage by Table" I was able to
find out that about 90% of the unused space has been allocated to ONE table.
Among this table's fields there are two VARCHAR that caught my attention
because their lengths are bigger than normal, one is 1024 the other one is
2000.
The table has about 2 million records and both of these fields are only
storing a few characters, even though I have not done any calculations I
believe the free space is in these almost empty fields.
I can't modify the fields' length, but about 90% of the records on this
table can go, so I'm going to delete the records to regain the space.
I did this in TEST after my original post and it worked, the UNUSED space
became AVAILABLE FREE and shrinking released it.
Again THANKS!
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
> Hi Tim
> There is a difference between allocated and unused space. Unallocated
> space could be returned to the OS when you shrink a file, but the unused
> space is space that has already been allocated to an object, but just
> doesn't yet have any data stored in it.
> Without seeing you table definitions and knowing the kind of data you're
> storing, it's hard to know why you have so much unused space in your
> tables. You might try running sp_spaceused on each table, and see which
> ones have the most unused.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://blog.kalendelaney.com
>
> "Tim Bales" <timbales@.bellsouth.net> wrote in message
> news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
>> Considering the output of sp_spaceused (below) on my SQL Server 2005
>> database, is it possible to get back (release to the OS) the UNUSED
>> space, shrinking does not do it.
>> Basically I need to resize this database, most of its space is not being
>> used and is filling up my backup storage.
>> I have plenty of room in my data drive but I keep serveral days worth of
>> backups and thouse GB start to add up and fill up my backup drive.
>> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
>> database_name: c8audit
>> database_size: 26960.63 MB
>> unallocated space: 2033.20 MB
>> reserved: 25521840 KB
>> data: 3561528 KB
>> index_size: 8440 KB
>> unused: 21951872 KB
>> Thanks,
>> Tim
>|||Hi Tim
I'm glad you were able to accomplish your goal.
However, it's a mystery what the cause of all the unused space was. A
varchar column should not reserve more space than it actually uses. So if
there were only a few characters in them, that should not have caused excess
space allocation. It might have been that there was padding with spaces, or
it might have been that the columns were longer originally and then updated.
But if you've deleted the rows, we'll probably never know. ;-)
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:%23SIRI7kbIHA.1376@.TK2MSFTNGP02.phx.gbl...
> Thanks all for your help.
> Using SQL Server 2005's standard report "Disk Usage by Table" I was able
> to find out that about 90% of the unused space has been allocated to ONE
> table.
> Among this table's fields there are two VARCHAR that caught my attention
> because their lengths are bigger than normal, one is 1024 the other one is
> 2000.
> The table has about 2 million records and both of these fields are only
> storing a few characters, even though I have not done any calculations I
> believe the free space is in these almost empty fields.
> I can't modify the fields' length, but about 90% of the records on this
> table can go, so I'm going to delete the records to regain the space.
> I did this in TEST after my original post and it worked, the UNUSED space
> became AVAILABLE FREE and shrinking released it.
> Again THANKS!
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
>> Hi Tim
>> There is a difference between allocated and unused space. Unallocated
>> space could be returned to the OS when you shrink a file, but the unused
>> space is space that has already been allocated to an object, but just
>> doesn't yet have any data stored in it.
>> Without seeing you table definitions and knowing the kind of data you're
>> storing, it's hard to know why you have so much unused space in your
>> tables. You might try running sp_spaceused on each table, and see which
>> ones have the most unused.
>> --
>> HTH
>> Kalen Delaney, SQL Server MVP
>> www.InsideSQLServer.com
>> http://blog.kalendelaney.com
>>
>> "Tim Bales" <timbales@.bellsouth.net> wrote in message
>> news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
>> Considering the output of sp_spaceused (below) on my SQL Server 2005
>> database, is it possible to get back (release to the OS) the UNUSED
>> space, shrinking does not do it.
>> Basically I need to resize this database, most of its space is not being
>> used and is filling up my backup storage.
>> I have plenty of room in my data drive but I keep serveral days worth of
>> backups and thouse GB start to add up and fill up my backup drive.
>> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
>> database_name: c8audit
>> database_size: 26960.63 MB
>> unallocated space: 2033.20 MB
>> reserved: 25521840 KB
>> data: 3561528 KB
>> index_size: 8440 KB
>> unused: 21951872 KB
>> Thanks,
>> Tim
>>
>
database, is it possible to get back (release to the OS) the UNUSED space,
shrinking does not do it.
Basically I need to resize this database, most of its space is not being
used and is filling up my backup storage.
I have plenty of room in my data drive but I keep serveral days worth of
backups and thouse GB start to add up and fill up my backup drive.
Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
database_name: c8audit
database_size: 26960.63 MB
unallocated space: 2033.20 MB
reserved: 25521840 KB
data: 3561528 KB
index_size: 8440 KB
unused: 21951872 KB
Thanks,
TimDBCC SHRINKFILE will return the space to the OS as long as it is able to
shrink it in the first place. Can you try running that command and post the
actual command you used with all the parameters along with the output from
it? The backups do not include "free space" and only backup the actual
data. So if you have 4GB of data your backups should be roughly 4GB
regardless of how large your db is overall.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>|||Hi Tim
There is a difference between allocated and unused space. Unallocated space
could be returned to the OS when you shrink a file, but the unused space is
space that has already been allocated to an object, but just doesn't yet
have any data stored in it.
Without seeing you table definitions and knowing the kind of data you're
storing, it's hard to know why you have so much unused space in your tables.
You might try running sp_spaceused on each table, and see which ones have
the most unused.
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
> Considering the output of sp_spaceused (below) on my SQL Server 2005
> database, is it possible to get back (release to the OS) the UNUSED space,
> shrinking does not do it.
> Basically I need to resize this database, most of its space is not being
> used and is filling up my backup storage.
> I have plenty of room in my data drive but I keep serveral days worth of
> backups and thouse GB start to add up and fill up my backup drive.
> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
> database_name: c8audit
> database_size: 26960.63 MB
> unallocated space: 2033.20 MB
> reserved: 25521840 KB
> data: 3561528 KB
> index_size: 8440 KB
> unused: 21951872 KB
> Thanks,
> Tim
>|||Thanks all for your help.
Using SQL Server 2005's standard report "Disk Usage by Table" I was able to
find out that about 90% of the unused space has been allocated to ONE table.
Among this table's fields there are two VARCHAR that caught my attention
because their lengths are bigger than normal, one is 1024 the other one is
2000.
The table has about 2 million records and both of these fields are only
storing a few characters, even though I have not done any calculations I
believe the free space is in these almost empty fields.
I can't modify the fields' length, but about 90% of the records on this
table can go, so I'm going to delete the records to regain the space.
I did this in TEST after my original post and it worked, the UNUSED space
became AVAILABLE FREE and shrinking released it.
Again THANKS!
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
> Hi Tim
> There is a difference between allocated and unused space. Unallocated
> space could be returned to the OS when you shrink a file, but the unused
> space is space that has already been allocated to an object, but just
> doesn't yet have any data stored in it.
> Without seeing you table definitions and knowing the kind of data you're
> storing, it's hard to know why you have so much unused space in your
> tables. You might try running sp_spaceused on each table, and see which
> ones have the most unused.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://blog.kalendelaney.com
>
> "Tim Bales" <timbales@.bellsouth.net> wrote in message
> news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
>> Considering the output of sp_spaceused (below) on my SQL Server 2005
>> database, is it possible to get back (release to the OS) the UNUSED
>> space, shrinking does not do it.
>> Basically I need to resize this database, most of its space is not being
>> used and is filling up my backup storage.
>> I have plenty of room in my data drive but I keep serveral days worth of
>> backups and thouse GB start to add up and fill up my backup drive.
>> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
>> database_name: c8audit
>> database_size: 26960.63 MB
>> unallocated space: 2033.20 MB
>> reserved: 25521840 KB
>> data: 3561528 KB
>> index_size: 8440 KB
>> unused: 21951872 KB
>> Thanks,
>> Tim
>|||Hi Tim
I'm glad you were able to accomplish your goal.
However, it's a mystery what the cause of all the unused space was. A
varchar column should not reserve more space than it actually uses. So if
there were only a few characters in them, that should not have caused excess
space allocation. It might have been that there was padding with spaces, or
it might have been that the columns were longer originally and then updated.
But if you've deleted the rows, we'll probably never know. ;-)
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Tim Bales" <timbales@.bellsouth.net> wrote in message
news:%23SIRI7kbIHA.1376@.TK2MSFTNGP02.phx.gbl...
> Thanks all for your help.
> Using SQL Server 2005's standard report "Disk Usage by Table" I was able
> to find out that about 90% of the unused space has been allocated to ONE
> table.
> Among this table's fields there are two VARCHAR that caught my attention
> because their lengths are bigger than normal, one is 1024 the other one is
> 2000.
> The table has about 2 million records and both of these fields are only
> storing a few characters, even though I have not done any calculations I
> believe the free space is in these almost empty fields.
> I can't modify the fields' length, but about 90% of the records on this
> table can go, so I'm going to delete the records to regain the space.
> I did this in TEST after my original post and it worked, the UNUSED space
> became AVAILABLE FREE and shrinking released it.
> Again THANKS!
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:eyBNF$ebIHA.4208@.TK2MSFTNGP04.phx.gbl...
>> Hi Tim
>> There is a difference between allocated and unused space. Unallocated
>> space could be returned to the OS when you shrink a file, but the unused
>> space is space that has already been allocated to an object, but just
>> doesn't yet have any data stored in it.
>> Without seeing you table definitions and knowing the kind of data you're
>> storing, it's hard to know why you have so much unused space in your
>> tables. You might try running sp_spaceused on each table, and see which
>> ones have the most unused.
>> --
>> HTH
>> Kalen Delaney, SQL Server MVP
>> www.InsideSQLServer.com
>> http://blog.kalendelaney.com
>>
>> "Tim Bales" <timbales@.bellsouth.net> wrote in message
>> news:OXgzVobbIHA.4880@.TK2MSFTNGP03.phx.gbl...
>> Considering the output of sp_spaceused (below) on my SQL Server 2005
>> database, is it possible to get back (release to the OS) the UNUSED
>> space, shrinking does not do it.
>> Basically I need to resize this database, most of its space is not being
>> used and is filling up my backup storage.
>> I have plenty of room in my data drive but I keep serveral days worth of
>> backups and thouse GB start to add up and fill up my backup drive.
>> Of the 28 GB only about 4 GB are being used, the rest is just RESERVED.
>> database_name: c8audit
>> database_size: 26960.63 MB
>> unallocated space: 2033.20 MB
>> reserved: 25521840 KB
>> data: 3561528 KB
>> index_size: 8440 KB
>> unused: 21951872 KB
>> Thanks,
>> Tim
>>
>
Subscribe to:
Posts (Atom)