Showing posts with label size. Show all posts
Showing posts with label size. Show all posts

Tuesday, March 20, 2012

Rebuild Index grew database .mdf files

Hello,

Overnight, I had a Rebuild Index job run and it grew the size of the database.mdf file approximately 4 times. 300MB to 1.2GB. It also changed the initial size of the database to 1.2GB. Is there any way to recover this space or to shrink the database?

I tried to shrink it with DBCC SHRINKDATABASE to no avail (only recovered 40MB).

Do I have any options to reclaim the space?

Any ideas?

Thanks.It turns out that the cause of the increase in size of database files was due to the fact that I had the Rebuild Index job set with a fill factor of 10%. I tested a bit and found that if I set it to reorganize pages with the default amount of free space that it didn't triple/quadruple/etc the size of the files.

Case Closed!

Friday, March 9, 2012

Reasonable size of rdl file?

I'm working with a report that will produce 5 printed pages with key data
for a company. Each page will contain from 3 to 12 diagrams, there will be
39 diagrams totally in the rdl file. Plus some text boxes etc.
Each diagram has a dataset, plus some support datasets. Totally about 45
datasets (all using stored procedures).
I currently have 15 diagrams, and the rdl file is 140kB.
Am I stretching it? Experiences?
More detailed information:
The reason for keeping it in one rdl file is that a scheduled data driven
subscription will produce one PDF file per department (about 100
departments). The PDF file will be send to a printing shop which then will
mail the papers to each department. Each PDF file has 5 A3 pages with the
diagrams.
Keeping it in one RDL file allow for me to have one subscription.
Also, I have text boxes with values for colors for diagram bars etc (I pick
the values for the diagrams from the text boxes using an expression). When
people will start fiddling with changing colors, I can do it in one place,
instead of setting it in all 39 diagrams.
(I want to keep the work in Report Designer as much as possible. Even if I
can edit the RDL file, I don't want that the customer need to do this then
the project is rolled out and I'm out of here... :-). )
TIA
Tibor Karaszi
SQL Server MVPUndo/Redo in Report Designer is somewhat memory intensive. You may find that
you need to restart Report Designer if you use this feature extensively
during a single editing session. Another aspect is that very large RDLs,
especially those that contain a large number of images, can impact the
Report Designer's editing experience. In general, Report Designer should be
able handle this report.
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eDPik7ymEHA.3944@.TK2MSFTNGP10.phx.gbl...
> I'm working with a report that will produce 5 printed pages with key data
> for a company. Each page will contain from 3 to 12 diagrams, there will be
> 39 diagrams totally in the rdl file. Plus some text boxes etc.
> Each diagram has a dataset, plus some support datasets. Totally about 45
> datasets (all using stored procedures).
> I currently have 15 diagrams, and the rdl file is 140kB.
> Am I stretching it? Experiences?
>
> More detailed information:
> The reason for keeping it in one rdl file is that a scheduled data driven
> subscription will produce one PDF file per department (about 100
> departments). The PDF file will be send to a printing shop which then will
> mail the papers to each department. Each PDF file has 5 A3 pages with the
> diagrams.
> Keeping it in one RDL file allow for me to have one subscription.
> Also, I have text boxes with values for colors for diagram bars etc (I
pick
> the values for the diagrams from the text boxes using an expression). When
> people will start fiddling with changing colors, I can do it in one place,
> instead of setting it in all 39 diagrams.
> (I want to keep the work in Report Designer as much as possible. Even if I
> can edit the RDL file, I don't want that the customer need to do this then
> the project is rolled out and I'm out of here... :-). )
> TIA
> Tibor Karaszi
> SQL Server MVP
>|||OK, sounds good. Good tips. I don't use much UNDO/REDO in the first place, at least not at this
stage. :-)
One thing I do is to copy a whole measurement (three diagrams plus a few text boxes) and then start
work on the new sets of diagrams. This has worked fine so far, and I understand if RD becomes a bit
sluggish. So far I haven't noticed any problems.
I'd just hate to be on the last sets of diagram and I'm going beyond some boundary and RD or RS
comes crashing on me. Even with frequent backups it will take a little while to recover from such,
and if necessary I would then prefer doing it right from the beginning.
Thanks Bruce!
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bruce Johnson [MSFT]" <brucejoh@.online.microsoft.com> wrote in message
news:eCj97r0mEHA.596@.TK2MSFTNGP11.phx.gbl...
> Undo/Redo in Report Designer is somewhat memory intensive. You may find that
> you need to restart Report Designer if you use this feature extensively
> during a single editing session. Another aspect is that very large RDLs,
> especially those that contain a large number of images, can impact the
> Report Designer's editing experience. In general, Report Designer should be
> able handle this report.
> --
> Bruce Johnson [MSFT]
> Microsoft SQL Server Reporting Services
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:eDPik7ymEHA.3944@.TK2MSFTNGP10.phx.gbl...
>> I'm working with a report that will produce 5 printed pages with key data
>> for a company. Each page will contain from 3 to 12 diagrams, there will be
>> 39 diagrams totally in the rdl file. Plus some text boxes etc.
>> Each diagram has a dataset, plus some support datasets. Totally about 45
>> datasets (all using stored procedures).
>> I currently have 15 diagrams, and the rdl file is 140kB.
>> Am I stretching it? Experiences?
>>
>> More detailed information:
>> The reason for keeping it in one rdl file is that a scheduled data driven
>> subscription will produce one PDF file per department (about 100
>> departments). The PDF file will be send to a printing shop which then will
>> mail the papers to each department. Each PDF file has 5 A3 pages with the
>> diagrams.
>> Keeping it in one RDL file allow for me to have one subscription.
>> Also, I have text boxes with values for colors for diagram bars etc (I
> pick
>> the values for the diagrams from the text boxes using an expression). When
>> people will start fiddling with changing colors, I can do it in one place,
>> instead of setting it in all 39 diagrams.
>> (I want to keep the work in Report Designer as much as possible. Even if I
>> can edit the RDL file, I don't want that the customer need to do this then
>> the project is rolled out and I'm out of here... :-). )
>> TIA
>> Tibor Karaszi
>> SQL Server MVP
>>
>|||140 KB is certainly reasonable.
BTW: IIS 6.0 has a security restriction of a default 4 MB file
upload/download limit. This is due to a buffering restriction implemented in
IIS 6.0 (AspMaxRequestEntityAllowed setting in MetaBase.xml). Therefore, if
RDL files get larger than 4 MB, you might run into an issue when uploading
them on the report server.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eDPik7ymEHA.3944@.TK2MSFTNGP10.phx.gbl...
> I'm working with a report that will produce 5 printed pages with key data
> for a company. Each page will contain from 3 to 12 diagrams, there will be
> 39 diagrams totally in the rdl file. Plus some text boxes etc.
> Each diagram has a dataset, plus some support datasets. Totally about 45
> datasets (all using stored procedures).
> I currently have 15 diagrams, and the rdl file is 140kB.
> Am I stretching it? Experiences?
>
> More detailed information:
> The reason for keeping it in one rdl file is that a scheduled data driven
> subscription will produce one PDF file per department (about 100
> departments). The PDF file will be send to a printing shop which then will
> mail the papers to each department. Each PDF file has 5 A3 pages with the
> diagrams.
> Keeping it in one RDL file allow for me to have one subscription.
> Also, I have text boxes with values for colors for diagram bars etc (I
pick
> the values for the diagrams from the text boxes using an expression). When
> people will start fiddling with changing colors, I can do it in one place,
> instead of setting it in all 39 diagrams.
> (I want to keep the work in Report Designer as much as possible. Even if I
> can edit the RDL file, I don't want that the customer need to do this then
> the project is rolled out and I'm out of here... :-). )
> TIA
> Tibor Karaszi
> SQL Server MVP
>|||Assuming the size of the file is roughly proportional to what I have now, I will probably end up
with a 0.5 MB file after adding the rest of the diagrams and some fluff. Even with lots of fluff, I
will most probably not go over 0.6-0.7 MB. Seems I have some margin, then.
And thanks for the tip about IIS size restriction, good to know if I happen to run into this at some
point. Not something I'd find easily myself. :-)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Robert Bruckner [MSFT]" <robruc@.online.microsoft.com> wrote in message
news:u8LLCp1mEHA.2076@.TK2MSFTNGP15.phx.gbl...
> 140 KB is certainly reasonable.
> BTW: IIS 6.0 has a security restriction of a default 4 MB file
> upload/download limit. This is due to a buffering restriction implemented in
> IIS 6.0 (AspMaxRequestEntityAllowed setting in MetaBase.xml). Therefore, if
> RDL files get larger than 4 MB, you might run into an issue when uploading
> them on the report server.
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:eDPik7ymEHA.3944@.TK2MSFTNGP10.phx.gbl...
>> I'm working with a report that will produce 5 printed pages with key data
>> for a company. Each page will contain from 3 to 12 diagrams, there will be
>> 39 diagrams totally in the rdl file. Plus some text boxes etc.
>> Each diagram has a dataset, plus some support datasets. Totally about 45
>> datasets (all using stored procedures).
>> I currently have 15 diagrams, and the rdl file is 140kB.
>> Am I stretching it? Experiences?
>>
>> More detailed information:
>> The reason for keeping it in one rdl file is that a scheduled data driven
>> subscription will produce one PDF file per department (about 100
>> departments). The PDF file will be send to a printing shop which then will
>> mail the papers to each department. Each PDF file has 5 A3 pages with the
>> diagrams.
>> Keeping it in one RDL file allow for me to have one subscription.
>> Also, I have text boxes with values for colors for diagram bars etc (I
> pick
>> the values for the diagrams from the text boxes using an expression). When
>> people will start fiddling with changing colors, I can do it in one place,
>> instead of setting it in all 39 diagrams.
>> (I want to keep the work in Report Designer as much as possible. Even if I
>> can edit the RDL file, I don't want that the customer need to do this then
>> the project is rolled out and I'm out of here... :-). )
>> TIA
>> Tibor Karaszi
>> SQL Server MVP
>>
>|||Just as an FYI:
The rdl file ended up in size 330kB. RD was sluggish but worked. Howeverm
the data-driven subscription did not work. I don't have exact error message
here, but the service logged error messages about memory allocation. The
service terminated. I suspect this was in the PDF rendering (which worked
OK, but was slow both in VS and RM).
So I splitted the report up in 5 files (one per printed page) and it work
fine now. The job finished (for 37 PDF files) in about 5-7 minutes. So, I
now have 5 such jobs, one for each printed file.
Tibor
"Robert Bruckner [MSFT]" <robruc@.online.microsoft.com> wrote in message
news:u8LLCp1mEHA.2076@.TK2MSFTNGP15.phx.gbl...
> 140 KB is certainly reasonable.
> BTW: IIS 6.0 has a security restriction of a default 4 MB file
> upload/download limit. This is due to a buffering restriction implemented
in
> IIS 6.0 (AspMaxRequestEntityAllowed setting in MetaBase.xml). Therefore,
if
> RDL files get larger than 4 MB, you might run into an issue when uploading
> them on the report server.
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> message news:eDPik7ymEHA.3944@.TK2MSFTNGP10.phx.gbl...
> > I'm working with a report that will produce 5 printed pages with key
data
> > for a company. Each page will contain from 3 to 12 diagrams, there will
be
> > 39 diagrams totally in the rdl file. Plus some text boxes etc.
> > Each diagram has a dataset, plus some support datasets. Totally about 45
> > datasets (all using stored procedures).
> >
> > I currently have 15 diagrams, and the rdl file is 140kB.
> >
> > Am I stretching it? Experiences?
> >
> >
> > More detailed information:
> > The reason for keeping it in one rdl file is that a scheduled data
driven
> > subscription will produce one PDF file per department (about 100
> > departments). The PDF file will be send to a printing shop which then
will
> > mail the papers to each department. Each PDF file has 5 A3 pages with
the
> > diagrams.
> >
> > Keeping it in one RDL file allow for me to have one subscription.
> >
> > Also, I have text boxes with values for colors for diagram bars etc (I
> pick
> > the values for the diagrams from the text boxes using an expression).
When
> > people will start fiddling with changing colors, I can do it in one
place,
> > instead of setting it in all 39 diagrams.
> >
> > (I want to keep the work in Report Designer as much as possible. Even if
I
> > can edit the RDL file, I don't want that the customer need to do this
then
> > the project is rolled out and I'm out of here... :-). )
> >
> > TIA
> > Tibor Karaszi
> > SQL Server MVP
> >
> >
>

Reason for using Filegroup

Vendor has produced a Read Only system for us in SQL
Server 2000.
The database size is around 10GB and there are around 2000
tables in it.
I find that they have configured the database to use 5
files in the primary filegroup with size of 2GB each. All
of them are located in a RAID 1 disk. The autogrow is not
enabled for that database as it is READ ONLY.
I would like to know what is the benefit of placing them
in 5 files in a filegroup instead of 1 single physical
file ? Is it due to performance issue ?
Thanks
If they're all on the same spindle then there is no benefit. They may
as well have had them in a single file.
The main reason for multiple files in a filegroup is improving
performance by putting the files on different spindles (and also when
you get low on disk space on one logical volume you can seamlessly
"extend" the filegroup by adding another file to it that resides on a
different logical volume (presumedly with more disk space)).
Perhaps the vendor meant to actually locate the 5 physical files on 5
separate RAID arrays but...forgot?
*mike hodgson*
/ mallesons stephen jaques/
blog: http://sqlnerd.blogspot.com
Stephen wrote:

>Vendor has produced a Read Only system for us in SQL
>Server 2000.
>The database size is around 10GB and there are around 2000
>tables in it.
>I find that they have configured the database to use 5
>files in the primary filegroup with size of 2GB each. All
>of them are located in a RAID 1 disk. The autogrow is not
>enabled for that database as it is READ ONLY.
>I would like to know what is the benefit of placing them
>in 5 files in a filegroup instead of 1 single physical
>file ? Is it due to performance issue ?
>Thanks
>

Reason for using Filegroup

Vendor has produced a Read Only system for us in SQL
Server 2000.
The database size is around 10GB and there are around 2000
tables in it.
I find that they have configured the database to use 5
files in the primary filegroup with size of 2GB each. All
of them are located in a RAID 1 disk. The autogrow is not
enabled for that database as it is READ ONLY.
I would like to know what is the benefit of placing them
in 5 files in a filegroup instead of 1 single physical
file ? Is it due to performance issue ?
ThanksIf they're all on the same spindle then there is no benefit. They may
as well have had them in a single file.
The main reason for multiple files in a filegroup is improving
performance by putting the files on different spindles (and also when
you get low on disk space on one logical volume you can seamlessly
"extend" the filegroup by adding another file to it that resides on a
different logical volume (presumedly with more disk space)).
Perhaps the vendor meant to actually locate the 5 physical files on 5
separate RAID arrays but...forgot?
*mike hodgson*
/ mallesons stephen jaques/
blog: http://sqlnerd.blogspot.com
Stephen wrote:

>Vendor has produced a Read Only system for us in SQL
>Server 2000.
>The database size is around 10GB and there are around 2000
>tables in it.
>I find that they have configured the database to use 5
>files in the primary filegroup with size of 2GB each. All
>of them are located in a RAID 1 disk. The autogrow is not
>enabled for that database as it is READ ONLY.
>I would like to know what is the benefit of placing them
>in 5 files in a filegroup instead of 1 single physical
>file ? Is it due to performance issue ?
>Thanks
>

Reason for using Filegroup

Vendor has produced a Read Only system for us in SQL
Server 2000.
The database size is around 10GB and there are around 2000
tables in it.
I find that they have configured the database to use 5
files in the primary filegroup with size of 2GB each. All
of them are located in a RAID 1 disk. The autogrow is not
enabled for that database as it is READ ONLY.
I would like to know what is the benefit of placing them
in 5 files in a filegroup instead of 1 single physical
file ? Is it due to performance issue ?
ThanksThis is a multi-part message in MIME format.
--020103050106080203040701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
If they're all on the same spindle then there is no benefit. They may
as well have had them in a single file.
The main reason for multiple files in a filegroup is improving
performance by putting the files on different spindles (and also when
you get low on disk space on one logical volume you can seamlessly
"extend" the filegroup by adding another file to it that resides on a
different logical volume (presumedly with more disk space)).
Perhaps the vendor meant to actually locate the 5 physical files on 5
separate RAID arrays but...forgot?
--
*mike hodgson*
/ mallesons stephen jaques/
blog: http://sqlnerd.blogspot.com
Stephen wrote:
>Vendor has produced a Read Only system for us in SQL
>Server 2000.
>The database size is around 10GB and there are around 2000
>tables in it.
>I find that they have configured the database to use 5
>files in the primary filegroup with size of 2GB each. All
>of them are located in a RAID 1 disk. The autogrow is not
>enabled for that database as it is READ ONLY.
>I would like to know what is the benefit of placing them
>in 5 files in a filegroup instead of 1 single physical
>file ? Is it due to performance issue ?
>Thanks
>
--020103050106080203040701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>If they're all on the same spindle then there is no benefit. They
may as well have had them in a single file.<br>
<br>
The main reason for multiple files in a filegroup is improving
performance by putting the files on different spindles (and also when
you get low on disk space on one logical volume you can seamlessly
"extend" the filegroup by adding another file to it that resides on a
different logical volume (presumedly with more disk space)).<br>
<br>
Perhaps the vendor meant to actually locate the 5 physical files on 5
separate RAID arrays but...forgot?<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font> </span><b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<em><font face="Tahoma" size="2"> mallesons</font><font face="Tahoma"> </font><font
face="Tahoma" size="2">stephen</font><font face="Tahoma"> </font><font
face="Tahoma" size="2"> jaques</font></em><font face="Tahoma"><br>
</font><font face="Tahoma" size="2">blog:</font><font face="Tahoma"
size="2"> <a href="http://links.10026.com/?link=/">http://sqlnerd.blogspot.com">
http://sqlnerd.blogspot.com</a></font></span> </p>
</div>
<br>
<br>
Stephen wrote:
<blockquote cite="mid033901c57851$56fa1040$a501280a@.phx.gbl" type="cite">
<pre wrap="">Vendor has produced a Read Only system for us in SQL
Server 2000.
The database size is around 10GB and there are around 2000
tables in it.
I find that they have configured the database to use 5
files in the primary filegroup with size of 2GB each. All
of them are located in a RAID 1 disk. The autogrow is not
enabled for that database as it is READ ONLY.
I would like to know what is the benefit of placing them
in 5 files in a filegroup instead of 1 single physical
file ? Is it due to performance issue ?
Thanks
</pre>
</blockquote>
</body>
</html>
--020103050106080203040701--

Monday, February 20, 2012

Real size of database

I have a database which I do not think is really big, but when it was created the initial file sizes where set to very large amounts.

How do I get the actual size of the data?

When I do shrink database, SQL say there is no space to reclaim but when I back it up the backup is extreamly small, does this mean that shrink database will not shrink past the original size?

How do I resize the database to only the actual size needed?

Here is the result of sp_spaceused:

database_name database_size unallocated space

--

CCCca 99863.81 MB 96318.27 MB

reserved data index_size unused

5680 KB 3000 KB 2232 KB 448 KB

One thing about shrinking database files is that you cannot shink below the true size of your data. Imagine your database as a box filled with paper. If the box was half-filled, you can only shrink it to that size and no more than that. You cannot shirink it to 1/3 of the size of the box as you have 1/2 as data. Your database size includes not just data and metadata but indexes as well. From the data you posted here, you cannot shrink the database to below approx 3GB|||

u can use,

backup log databasename with truncate_only and then shrink the files and database.

|||

After I shrink the database still getting a database size of 134534.56 MB not 3GB. I ran the following:

backup log CCCca with truncate_only

DBCC SHRINKFILE (CCCca_Primary, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_Log, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_Analysis, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_AnalysisIdx3, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_AnalysisIdx, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_AnalysisIdx2, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_PrimeIdx, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_Word, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_WordIdx, TRUNCATEONLY);

DBCC SHRINKDATABASE (CCCca, TRUNCATEONLY);

but all I get is : "

DBCC SHRINKDATABASE: File ID 1 of database ID 5 was skipped because the file does not have enough free space to reclaim."

is this data base really 134534.56 MB or is it 3GB?

|||Truncating the log does not necessarily mean shrinking the database. It simply means you are freeing up space on your transaction log and committing the transactions in your database. Microsoft did not include the shrinking as part of the truncate option for the transaction log as this will incurr overhead when transactions starts occurring after the truncate command. You have to do them individually to shrink your database.|||I have same problem, I can't shrink the data and index files.... even there are unused space|||

Have you tried DBCC SHRINKFILE with the 'target_size' option specified

Real size of database

I have a database which I do not think is really big, but when it was created the initial file sizes where set to very large amounts.

How do I get the actual size of the data?

When I do shrink database, SQL say there is no space to reclaim but when I back it up the backup is extreamly small, does this mean that shrink database will not shrink past the original size?

How do I resize the database to only the actual size needed?

Here is the result of sp_spaceused:

database_name database_size unallocated space

--

CCCca 99863.81 MB 96318.27 MB

reserved data index_size unused

5680 KB 3000 KB 2232 KB 448 KB

One thing about shrinking database files is that you cannot shink below the true size of your data. Imagine your database as a box filled with paper. If the box was half-filled, you can only shrink it to that size and no more than that. You cannot shirink it to 1/3 of the size of the box as you have 1/2 as data. Your database size includes not just data and metadata but indexes as well. From the data you posted here, you cannot shrink the database to below approx 3GB|||

u can use,

backup log databasename with truncate_only and then shrink the files and database.

|||

After I shrink the database still getting a database size of 134534.56 MB not 3GB. I ran the following:

backup log CCCca with truncate_only

DBCC SHRINKFILE (CCCca_Primary, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_Log, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_Analysis, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_AnalysisIdx3, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_AnalysisIdx, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_AnalysisIdx2, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_PrimeIdx, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_Word, TRUNCATEONLY);

DBCC SHRINKFILE (CCCca_WordIdx, TRUNCATEONLY);

DBCC SHRINKDATABASE (CCCca, TRUNCATEONLY);

but all I get is : "

DBCC SHRINKDATABASE: File ID 1 of database ID 5 was skipped because the file does not have enough free space to reclaim."

is this data base really 134534.56 MB or is it 3GB?

|||Truncating the log does not necessarily mean shrinking the database. It simply means you are freeing up space on your transaction log and committing the transactions in your database. Microsoft did not include the shrinking as part of the truncate option for the transaction log as this will incurr overhead when transactions starts occurring after the truncate command. You have to do them individually to shrink your database.|||I have same problem, I can't shrink the data and index files.... even there are unused space|||

Have you tried DBCC SHRINKFILE with the 'target_size' option specified