Showing posts with label mdf. Show all posts
Showing posts with label mdf. Show all posts

Wednesday, March 28, 2012

Log files must be named *_log.ldf?

Hello,

I've been having problems with SQL Express when my database files are named basename.mdf and basename.ldf (e.g. on using the Access upsizing wizard).

At points that I haven't fully identified yet (I'm using VB Express clients), a second log file named basename_log.mdf gets created and SQL Express gets confused and compalins the files are corrupted.

Can anyone explain what is happening?

TIA,

Bill

SQL Server files do not really need to have a specific extension, so it might be possible that this file, although having a ldf extension is not a ldf file. Which files did the wizard create for you ?

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

Hello Jens.

My problem is not with the ldf extension but with a second transaction log file getting created.

As an example:

1) Create a new Access database namedmyDatabase.mdb (containing a single table.)

2) Use the Upsizing wizard to create a new SQL database from the Access database accepting the defaults as much as possible. This creates files named myDatabaseSQL.mdf and myDatabaseSQL.ldf in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data

3) The database myDatabaseSql is already visible when you next open up MSS MSE, from where you can see the data in the one table.

4) So far everything is ok.

5) Now exit MSS MSE and start VB 2k5 Express. Without opening up any project or solution, simply open the Database Explorer and create a new connection to myDatabaseSQL. Hit the Test Connection button and once told it’s ok, immediately exit VB.

6) At this point there are now three files in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data :

myDatabaseSQL.mdf

myDatabaseSQL.ldf

myDataBaseSQL_log.ldf (this one seems to be created by VB's Database Explorer)

7) Now open up MSS MSE again and try to get to table within myDatabaseSQL from the object explorer. On clicking on myDatabaseSQL you get the following error message

One or more files do not match the primary file of the database….. If this is an existing database the file may be corrupted and should be restored from a backup. (Microsoft SQL Server, Error 5173)

This behaviour is repeated on all my databases including Adventure Works and NorthWind.

I got the problem on the ‘smaller ‘ SQL Server Express + MSS MSE down loads on one machine and also get the problem with the ‘larger’ SSE with Advanced Services + Toolkit downloads on a second machine.

Both machines are running XP Pro + Office 2003 + 2005 Express versions of SS + VB.

Hope this lot help.

TIA

Bill

sql

Monday, March 26, 2012

LOG files

I moved all my data files from mssql2000 to mssql2005.
problem is that my log files are GB's bigger than the MDF file.
Can I delete the LOG files? IF not, can I reduced the size?
How?
Thanks,
Raul Rego
NJPIESDo you mean transaction log files (typically .ldf) or something else? If you mean transaction log
files, then do not delete them (unless you are prepared to restore the databases from backups). You
can shrink the file size using DBCC SHRINKFILE.
Bu the fact that these are so large is an indication that you or your dba haven't thought out a
suitable backup plan for your database and set the recovery model accordingly.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Raul" <rrego@.njpies.org> wrote in message
news:26041173-37E9-44E0-AA79-CFDFC093EC5B@.microsoft.com...
>I moved all my data files from mssql2000 to mssql2005.
> problem is that my log files are GB's bigger than the MDF file.
> Can I delete the LOG files? IF not, can I reduced the size?
> How?
> Thanks,
> Raul Rego
> NJPIES

LOG files

I moved all my data files from mssql2000 to mssql2005.
problem is that my log files are GB's bigger than the MDF file.
Can I delete the LOG files? IF not, can I reduced the size?
How?
Thanks,
Raul Rego
NJPIES
Do you mean transaction log files (typically .ldf) or something else? If you mean transaction log
files, then do not delete them (unless you are prepared to restore the databases from backups). You
can shrink the file size using DBCC SHRINKFILE.
Bu the fact that these are so large is an indication that you or your dba haven't thought out a
suitable backup plan for your database and set the recovery model accordingly.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Raul" <rrego@.njpies.org> wrote in message
news:26041173-37E9-44E0-AA79-CFDFC093EC5B@.microsoft.com...
>I moved all my data files from mssql2000 to mssql2005.
> problem is that my log files are GB's bigger than the MDF file.
> Can I delete the LOG files? IF not, can I reduced the size?
> How?
> Thanks,
> Raul Rego
> NJPIES
sql

Friday, March 23, 2012

Log File too big

The size of the .MDF is 175,000 Kb while that of the .LDF is 2,377,000 Kb. What should I do to truncate the Log File? Pls advise.before executing this code read BOL, dbcc shrinkfile

backup DATABASE yourdatabasename to disk='c:\yourdatabasename .bak'
go
dbcc shrinkfile (yourdatabase_log,size,truncateonly)
go
--to get log file name--
select * from sysfiles|||1.Please change the db options to Simple recovery Model.
2.Use the DBCC Shrinkfile ('FileNAme','SizeinMB) e.g DBCC Shrinkfile ('Myfile',100)

Thankssql

log file to be reduced

Hi All
I have a mdf file of around 4gb but log file increased to
20gb. how to reduce size of log file.
Any help would be highly appreciated.
Rgds
TriveniHave a look at these articles
INF: How to Shrink the SQL Server 7.0 Transaction Lo
http://support.microsoft.com/default.aspx?scid=kb;en-us;25665
INF: Shrinking the Transaction Log in SQL Server 2000 with DBCC SHRINKFIL
http://support.microsoft.com/default.aspx?scid=kb;en-us;27231
http://www.mssqlserver.com/faq/logs-shrinklog.as
Hope this help
John

log file to be reduced

Hi All
I have a mdf file of around 4gb but log file increased to
20gb. how to reduce size of log file.
Any help would be highly appreciated.
Rgds
TriveniHave a look at these articles.
INF: How to Shrink the SQL Server 7.0 Transaction Log
http://support.microsoft.com/defaul...kb;en-us;256650
INF: Shrinking the Transaction Log in SQL Server 2000 with DBCC SHRINKFILE
http://support.microsoft.com/defaul...kb;en-us;272318
http://www.mssqlserver.com/faq/logs-shrinklog.asp
Hope this helps
John

Log File Size vs. Data Size ?

I am creating maintenance plans in SQL Server 2005 to manage the backups of
a
database. The Databasename_Data.MDF file is approx. 234 MB in size. The
Databasename_Log.LDF is approx. 3.5 GB. Does this ratio of log size to data
size
sound "normal" ? If not, any thoughts or advice ?
If I want to try shrinking the log file, do I need to use a combination of
'BACKUP LOG' and 'DBCC SHRINKFILE' commands ? Or is there a more
automated way using maintenance plans?
Thanks in advance!
TomTom Glasser wrote:
> I am creating maintenance plans in SQL Server 2005 to manage the backups o
f a
> database. The Databasename_Data.MDF file is approx. 234 MB in size. The
> Databasename_Log.LDF is approx. 3.5 GB. Does this ratio of log size to da
ta
> size
> sound "normal" ? If not, any thoughts or advice ?
> If I want to try shrinking the log file, do I need to use a combination of
> 'BACKUP LOG' and 'DBCC SHRINKFILE' commands ? Or is there a more
> automated way using maintenance plans?
> Thanks in advance!
> Tom
Hi Tom
It sounds like your logfile is much bigger than it needs to be, but it
could also be right. If you are running in FULL recovery mode and you're
not backing up your logfile, it will just grow and grow and grow. When
you backup the logfile, the backup commands will truncate you log which
means that old transactions can be overwritten. In this way the space
will be re-used so the file doesn't need to grow.
If you find out that you have to shrink the logfile, you'll have to run
DBCC SHRINKFILE.
Be carefull about shrinking the log though. A logfile should only be
shrunk in cases where there has been extraordinary activity in the
database which has made the logfile grow. This could e.g. be if you have
imported or deleted a lot of data as a "one time" operation. You
shouldn't shrink a logfile on a regular basis - that will only lead to
poor performance because it will have to grow again, and the file will
most likely be fragmented as well.
Try to have a look at -
http://www.karaszi.com/SQLServer/info_dont_shrink.asp.
Regards
Steen Schlüter Persson
Database Administrator / System Administratorsql

Log File Size vs. Data Size ?

I am creating maintenance plans in SQL Server 2005 to manage the backups of a
database. The Databasename_Data.MDF file is approx. 234 MB in size. The
Databasename_Log.LDF is approx. 3.5 GB. Does this ratio of log size to data
size
sound "normal" ? If not, any thoughts or advice ?
If I want to try shrinking the log file, do I need to use a combination of
'BACKUP LOG' and 'DBCC SHRINKFILE' commands ? Or is there a more
automated way using maintenance plans?
Thanks in advance!
TomTom Glasser wrote:
> I am creating maintenance plans in SQL Server 2005 to manage the backups of a
> database. The Databasename_Data.MDF file is approx. 234 MB in size. The
> Databasename_Log.LDF is approx. 3.5 GB. Does this ratio of log size to data
> size
> sound "normal" ? If not, any thoughts or advice ?
> If I want to try shrinking the log file, do I need to use a combination of
> 'BACKUP LOG' and 'DBCC SHRINKFILE' commands ? Or is there a more
> automated way using maintenance plans?
> Thanks in advance!
> Tom
Hi Tom
It sounds like your logfile is much bigger than it needs to be, but it
could also be right. If you are running in FULL recovery mode and you're
not backing up your logfile, it will just grow and grow and grow. When
you backup the logfile, the backup commands will truncate you log which
means that old transactions can be overwritten. In this way the space
will be re-used so the file doesn't need to grow.
If you find out that you have to shrink the logfile, you'll have to run
DBCC SHRINKFILE.
Be carefull about shrinking the log though. A logfile should only be
shrunk in cases where there has been extraordinary activity in the
database which has made the logfile grow. This could e.g. be if you have
imported or deleted a lot of data as a "one time" operation. You
shouldn't shrink a logfile on a regular basis - that will only lead to
poor performance because it will have to grow again, and the file will
most likely be fragmented as well.
Try to have a look at -
http://www.karaszi.com/SQLServer/info_dont_shrink.asp.
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator

Log File Size - Sudden Growth

I have a relatively small database that I use for development purposes (this
isn't the production database).
The .mdf is about 10 MB. The log file size - for over 1 year - has been
about 7MB in size. During the past couple of ws the log file has grown to
over 15 MB in size. The amount of db-related development activity has
remained roughly constant over the past year. So I'm curious as to what
could be causing the log file to suddenly grow this large (small as it is in
the relative scheme of things).
Thanks!Felipe,
A couple of guesses: 1. Importing data 2. index creation or maintanence 3.
log backup didn't occur
HTH
Jerry
"Felipe" <aye@.bee.calm> wrote in message
news:OAgDoxGxFHA.3892@.TK2MSFTNGP12.phx.gbl...
>I have a relatively small database that I use for development purposes
>(this isn't the production database).
> The .mdf is about 10 MB. The log file size - for over 1 year - has been
> about 7MB in size. During the past couple of ws the log file has grown
> to over 15 MB in size. The amount of db-related development activity has
> remained roughly constant over the past year. So I'm curious as to what
> could be causing the log file to suddenly grow this large (small as it is
> in the relative scheme of things).
> Thanks!
>sql

Log file size

Hi,
Can anyone help on this, how to reduce the size of the log file ?
I have a database (SQL7.0) the mdf file is 1.6 Gbytes, but the ldf file is
17Gbytes. The database has been in operation for more than 2 years and why
has the log file grown to such a size ? It was set to auto growth at 10%. Can
I reduce it size and how? I need to claim back some disk space.
Thank you for your time
KC ThongKCThong wrote:
> Hi,
> Can anyone help on this, how to reduce the size of the log file ?
> I have a database (SQL7.0) the mdf file is 1.6 Gbytes, but the ldf
> file is 17Gbytes. The database has been in operation for more than 2
> years and why has the log file grown to such a size ? It was set to
> auto growth at 10%. Can I reduce it size and how? I need to claim
> back some disk space.
> Thank you for your time
> KC Thong
See DBCC SHRINKFILE in BOL.
--
David Gugick
Imceda Software
www.imceda.com|||Here are a few things to keep in mind:
â?¢ Always perform system database and user database backups before and after
you make changes that affect the system. DBCC SHRINKFILE and DBCC
SHRINKDATABASE are not logged operations, and running them invalidates
further transaction log backups. You must make a full database backup after
you run either the DBCC SHRINKFILE or the DBCC SHRINKDATABASE commands.
â?¢ Make sure that there are no backups scheduled to occur during the time the
shrink is supposed to occur.
â?¢ Make sure that there are no old, long-running, or unreplicated
transactions. To do so, use code similar to:DBCC OPENTRAN (database_name)
â?¢ Run the DBCC SHRINKFILE or DBCC SHRINKDATABASE command to mark a
shrinkpoint. DBCC SHRINKFILE and DBCC SHRINKDATABASE permissions default to
members of the sysadmin fixed server role or the db_owner fixed database
role, and are not transferable. For information about the differences between
these commands, refer to the following topics in SQL Books Online (note the
different parameters):
DBCC SHRINKFILE (file_name, target_size)
DBCC SHRINKDATABASE (database_name, target_percent)
â?¢ Create some dummy transactions to make the log wrap around and then issue
a BACKUP command to truncate the log. The BACKUP statement is what actually
attempts to shrink the log to the marked target size.
Here is a sample of how to create a dummy transactions that wraps the log
for a single logical log file and causes it to truncate, allowing for
shrinkage. Modify the sample as needed for your environment. SET NOCOUNT ON
DECLARE @.LogicalFileName sysname,
@.MaxMinutes INT,
@.NewSize INT
-- *** MAKE SURE TO CHANGE THE NEXT 4 LINES WITH YOUR CRITERIA. ***
USE [Test DB] -- This is the name of the database
-- for which the log will be shrunk.
SELECT @.LogicalFileName = 'Test DB Log', -- Use sp_helpfile to
-- identify the logical file
-- name that you want to shrink.
@.MaxMinutes = 10, -- Limit on time allowed to wrap log.
@.NewSize = 10 -- in MB
-- Setup / initialize
DECLARE @.OriginalSize int
SELECT @.OriginalSize = size -- in 8K pages
FROM sysfiles
WHERE name = @.LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),@.OriginalSize) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(@.OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @.LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)
-- Wrap log and truncate it.
DECLARE @.Counter INT,
@.StartTime DATETIME,
@.TruncLog VARCHAR(255)
SELECT @.StartTime = GETDATE(),
@.TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'
-- Try an initial shrink.
DBCC SHRINKFILE (@.LogicalFileName, @.NewSize)
EXEC (@.TruncLog)
-- Wrap the log if necessary.
WHILE @.MaxMinutes > DATEDIFF (mi, @.StartTime, GETDATE()) -- time has
not expired
AND @.OriginalSize = (SELECT size FROM sysfiles WHERE name =@.LogicalFileName) -- the log has not shrunk
AND (@.OriginalSize * 8 /1024) > @.NewSize -- The value passed in
for new size is smaller than the current size.
BEGIN -- Outer loop.
SELECT @.Counter = 0
WHILE ((@.Counter < @.OriginalSize / 16) AND (@.Counter < 50000))
BEGIN -- update
INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char
field it inserts 8000 bytes.
DELETE DummyTrans
SELECT @.Counter = @.Counter + 1
END -- update
EXEC (@.TruncLog) -- See if a trunc of the log shrinks it.
END -- outer loop
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @.LogicalFileName
DROP TABLE DummyTrans
PRINT '*** Perform a full database backup ***'
SET NOCOUNT OFF
Check to see if the log has shrunk from its original size.Repeat the
preceding steps if necessary. If the log is not shrinking, re-check the
summary at the top of the article to see if you are encountering any of the
common issues with shrinking the log.
After the log shrinks:
1. Perform a full database backup of the master database.
2. Perform a full database backup of the user database. This is necessary
because the SHRINK command is not logged and invalidates future transaction
log backups unless a full database backup is completed.
To determine why the log is growing so big in the first place, you can check
for open transactions, long running transactions, unreplicated transactions,
or transactions that touch a lot of data.
"KCThong" wrote:
> Hi,
> Can anyone help on this, how to reduce the size of the log file ?
> I have a database (SQL7.0) the mdf file is 1.6 Gbytes, but the ldf file is
> 17Gbytes. The database has been in operation for more than 2 years and why
> has the log file grown to such a size ? It was set to auto growth at 10%. Can
> I reduce it size and how? I need to claim back some disk space.
> Thank you for your time
> KC Thong
>
>|||At this stage, if I set " trunc. log on chkpt" in the database option to
TRUE, does it help to clear the log or shrink ?
Pls advise.
"surajits" wrote:
> Here are a few things to keep in mind:
> â?¢ Always perform system database and user database backups before and after
> you make changes that affect the system. DBCC SHRINKFILE and DBCC
> SHRINKDATABASE are not logged operations, and running them invalidates
> further transaction log backups. You must make a full database backup after
> you run either the DBCC SHRINKFILE or the DBCC SHRINKDATABASE commands.
> â?¢ Make sure that there are no backups scheduled to occur during the time the
> shrink is supposed to occur.
> â?¢ Make sure that there are no old, long-running, or unreplicated
> transactions. To do so, use code similar to:DBCC OPENTRAN (database_name)
> â?¢ Run the DBCC SHRINKFILE or DBCC SHRINKDATABASE command to mark a
> shrinkpoint. DBCC SHRINKFILE and DBCC SHRINKDATABASE permissions default to
> members of the sysadmin fixed server role or the db_owner fixed database
> role, and are not transferable. For information about the differences between
> these commands, refer to the following topics in SQL Books Online (note the
> different parameters):
> DBCC SHRINKFILE (file_name, target_size)
> DBCC SHRINKDATABASE (database_name, target_percent)
> â?¢ Create some dummy transactions to make the log wrap around and then issue
> a BACKUP command to truncate the log. The BACKUP statement is what actually
> attempts to shrink the log to the marked target size.
> Here is a sample of how to create a dummy transactions that wraps the log
> for a single logical log file and causes it to truncate, allowing for
> shrinkage. Modify the sample as needed for your environment. SET NOCOUNT ON
> DECLARE @.LogicalFileName sysname,
> @.MaxMinutes INT,
> @.NewSize INT
> -- *** MAKE SURE TO CHANGE THE NEXT 4 LINES WITH YOUR CRITERIA. ***
> USE [Test DB] -- This is the name of the database
> -- for which the log will be shrunk.
> SELECT @.LogicalFileName = 'Test DB Log', -- Use sp_helpfile to
> -- identify the logical file
> -- name that you want to shrink.
> @.MaxMinutes = 10, -- Limit on time allowed to wrap log.
> @.NewSize = 10 -- in MB
> -- Setup / initialize
> DECLARE @.OriginalSize int
> SELECT @.OriginalSize = size -- in 8K pages
> FROM sysfiles
> WHERE name = @.LogicalFileName
> SELECT 'Original Size of ' + db_name() + ' LOG is ' +
> CONVERT(VARCHAR(30),@.OriginalSize) + ' 8K pages or ' +
> CONVERT(VARCHAR(30),(@.OriginalSize*8/1024)) + 'MB'
> FROM sysfiles
> WHERE name = @.LogicalFileName
> CREATE TABLE DummyTrans
> (DummyColumn char (8000) not null)
> -- Wrap log and truncate it.
> DECLARE @.Counter INT,
> @.StartTime DATETIME,
> @.TruncLog VARCHAR(255)
> SELECT @.StartTime = GETDATE(),
> @.TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'
> -- Try an initial shrink.
> DBCC SHRINKFILE (@.LogicalFileName, @.NewSize)
> EXEC (@.TruncLog)
> -- Wrap the log if necessary.
> WHILE @.MaxMinutes > DATEDIFF (mi, @.StartTime, GETDATE()) -- time has
> not expired
> AND @.OriginalSize = (SELECT size FROM sysfiles WHERE name => @.LogicalFileName) -- the log has not shrunk
> AND (@.OriginalSize * 8 /1024) > @.NewSize -- The value passed in
> for new size is smaller than the current size.
> BEGIN -- Outer loop.
> SELECT @.Counter = 0
> WHILE ((@.Counter < @.OriginalSize / 16) AND (@.Counter < 50000))
> BEGIN -- update
> INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char
> field it inserts 8000 bytes.
> DELETE DummyTrans
> SELECT @.Counter = @.Counter + 1
> END -- update
> EXEC (@.TruncLog) -- See if a trunc of the log shrinks it.
> END -- outer loop
> SELECT 'Final Size of ' + db_name() + ' LOG is ' +
> CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
> CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
> FROM sysfiles
> WHERE name = @.LogicalFileName
> DROP TABLE DummyTrans
> PRINT '*** Perform a full database backup ***'
> SET NOCOUNT OFF
> Check to see if the log has shrunk from its original size.Repeat the
> preceding steps if necessary. If the log is not shrinking, re-check the
> summary at the top of the article to see if you are encountering any of the
> common issues with shrinking the log.
> After the log shrinks:
> 1. Perform a full database backup of the master database.
> 2. Perform a full database backup of the user database. This is necessary
> because the SHRINK command is not logged and invalidates future transaction
> log backups unless a full database backup is completed.
> To determine why the log is growing so big in the first place, you can check
> for open transactions, long running transactions, unreplicated transactions,
> or transactions that touch a lot of data.
> "KCThong" wrote:
> > Hi,
> > Can anyone help on this, how to reduce the size of the log file ?
> > I have a database (SQL7.0) the mdf file is 1.6 Gbytes, but the ldf file is
> > 17Gbytes. The database has been in operation for more than 2 years and why
> > has the log file grown to such a size ? It was set to auto growth at 10%. Can
> > I reduce it size and how? I need to claim back some disk space.
> >
> > Thank you for your time
> > KC Thong
> >
> >
> >
> >sql

log file size

Dear Sir
I found that my database file (*.mdf) size is about
600 mb, but my log file (*.ldf) size is about 16 GB. My
harddisk has not enough space to place this file, if the
log continues to increase. I want to ask does any method
too reduced the size of the log file, becuase the log file
is not important for us'
Thank youIf you don't backup your transaction log regularly as part of your
recovery plan, you can have SQL Server automatically remove committed
data from the log by setting the recovery model to SIMPLE (SQL 2000) or
turn on the 'trunc. log on chkpt.' database option (SQL 7). Note that
your only recovery option in the SIMPLE recovery model is to restore
from full and differential backup.
For example:
SQL 2000:
ALTER DATABASE MyDatabase
SET RECOVERY SIMPLE
SQL 7:
EXEC sp_dboption 'MyDatabase', 'trunc. log on chkpt.', true
To reduce the size of your log, use DBCC SHRINKFILE. The example below
will shrink the log file to 200MB:
USE MyDatabase
DBCC SHRINKFILE('MyDatabase_Log', 200)
See the Books Online for details.
--
Hope this helps.
Dan Guzman
SQL Server MVP
--
SQL FAQ links (courtesy Neil Pike):
http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--
"back1" <back1@.mail.hongkong.com> wrote in message
news:033f01c36aad$9ede6f90$a401280a@.phx.gbl...
> Dear Sir
> I found that my database file (*.mdf) size is about
> 600 mb, but my log file (*.ldf) size is about 16 GB. My
> harddisk has not enough space to place this file, if the
> log continues to increase. I want to ask does any method
> too reduced the size of the log file, becuase the log file
> is not important for us'
> Thank you|||Dear Sir
Thank you for your quickly reply!
I already use this statement "DBCC SHRINKFILE
('MyDatabase_Log', 200)" to shrink the log file, but it
has not any effect. What can i do now '
Thank you
>--Original Message--
>If you don't backup your transaction log regularly as
part of your
>recovery plan, you can have SQL Server automatically
remove committed
>data from the log by setting the recovery model to SIMPLE
(SQL 2000) or
>turn on the 'trunc. log on chkpt.' database option (SQL
7). Note that
>your only recovery option in the SIMPLE recovery model is
to restore
>from full and differential backup.
>For example:
>SQL 2000:
> ALTER DATABASE MyDatabase
> SET RECOVERY SIMPLE
>SQL 7:
> EXEC sp_dboption 'MyDatabase', 'trunc. log on
chkpt.', true
>To reduce the size of your log, use DBCC SHRINKFILE. The
example below
>will shrink the log file to 200MB:
> USE MyDatabase
> DBCC SHRINKFILE('MyDatabase_Log', 200)
>See the Books Online for details.
>--
>Hope this helps.
>Dan Guzman
>SQL Server MVP
>--
>SQL FAQ links (courtesy Neil Pike):
>http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
>http://www.sqlserverfaq.com
>http://www.mssqlserver.com/faq
>--
>"back1" <back1@.mail.hongkong.com> wrote in message
>news:033f01c36aad$9ede6f90$a401280a@.phx.gbl...
>> Dear Sir
>> I found that my database file (*.mdf) size is about
>> 600 mb, but my log file (*.ldf) size is about 16 GB. My
>> harddisk has not enough space to place this file, if the
>> log continues to increase. I want to ask does any method
>> too reduced the size of the log file, becuase the log
file
>> is not important for us'
>> Thank you
>
>.
>

Log file size

Hi,
Can anyone help on this, how to reduce the size of the log file ?
I have a database (SQL7.0) the mdf file is 1.6 Gbytes, but the ldf file is
17Gbytes. The database has been in operation for more than 2 years and why
has the log file grown to such a size ? It was set to auto growth at 10%. Can
I reduce it size and how? I need to claim back some disk space.
Thank you for your time
KC Thong
KCThong wrote:
> Hi,
> Can anyone help on this, how to reduce the size of the log file ?
> I have a database (SQL7.0) the mdf file is 1.6 Gbytes, but the ldf
> file is 17Gbytes. The database has been in operation for more than 2
> years and why has the log file grown to such a size ? It was set to
> auto growth at 10%. Can I reduce it size and how? I need to claim
> back some disk space.
> Thank you for your time
> KC Thong
See DBCC SHRINKFILE in BOL.
David Gugick
Imceda Software
www.imceda.com
|||Here are a few things to keep in mind:
? Always perform system database and user database backups before and after
you make changes that affect the system. DBCC SHRINKFILE and DBCC
SHRINKDATABASE are not logged operations, and running them invalidates
further transaction log backups. You must make a full database backup after
you run either the DBCC SHRINKFILE or the DBCC SHRINKDATABASE commands.
? Make sure that there are no backups scheduled to occur during the time the
shrink is supposed to occur.
? Make sure that there are no old, long-running, or unreplicated
transactions. To do so, use code similar to:DBCC OPENTRAN (database_name)
? Run the DBCC SHRINKFILE or DBCC SHRINKDATABASE command to mark a
shrinkpoint. DBCC SHRINKFILE and DBCC SHRINKDATABASE permissions default to
members of the sysadmin fixed server role or the db_owner fixed database
role, and are not transferable. For information about the differences between
these commands, refer to the following topics in SQL Books Online (note the
different parameters):
DBCC SHRINKFILE (file_name, target_size)
DBCC SHRINKDATABASE (database_name, target_percent)
? Create some dummy transactions to make the log wrap around and then issue
a BACKUP command to truncate the log. The BACKUP statement is what actually
attempts to shrink the log to the marked target size.
Here is a sample of how to create a dummy transactions that wraps the log
for a single logical log file and causes it to truncate, allowing for
shrinkage. Modify the sample as needed for your environment. SET NOCOUNT ON
DECLARE @.LogicalFileName sysname,
@.MaxMinutes INT,
@.NewSize INT
-- *** MAKE SURE TO CHANGE THE NEXT 4 LINES WITH YOUR CRITERIA. ***
USE [Test DB] -- This is the name of the database
-- for which the log will be shrunk.
SELECT @.LogicalFileName = 'Test DB Log', -- Use sp_helpfile to
-- identify the logical file
-- name that you want to shrink.
@.MaxMinutes = 10, -- Limit on time allowed to wrap log.
@.NewSize = 10 -- in MB
-- Setup / initialize
DECLARE @.OriginalSize int
SELECT @.OriginalSize = size -- in 8K pages
FROM sysfiles
WHERE name = @.LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),@.OriginalSize) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(@.OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @.LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)
-- Wrap log and truncate it.
DECLARE @.Counter INT,
@.StartTime DATETIME,
@.TruncLog VARCHAR(255)
SELECT @.StartTime = GETDATE(),
@.TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'
-- Try an initial shrink.
DBCC SHRINKFILE (@.LogicalFileName, @.NewSize)
EXEC (@.TruncLog)
-- Wrap the log if necessary.
WHILE @.MaxMinutes > DATEDIFF (mi, @.StartTime, GETDATE()) -- time has
not expired
AND @.OriginalSize = (SELECT size FROM sysfiles WHERE name =
@.LogicalFileName) -- the log has not shrunk
AND (@.OriginalSize * 8 /1024) > @.NewSize -- The value passed in
for new size is smaller than the current size.
BEGIN -- Outer loop.
SELECT @.Counter = 0
WHILE ((@.Counter < @.OriginalSize / 16) AND (@.Counter < 50000))
BEGIN -- update
INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char
field it inserts 8000 bytes.
DELETE DummyTrans
SELECT @.Counter = @.Counter + 1
END -- update
EXEC (@.TruncLog) -- See if a trunc of the log shrinks it.
END -- outer loop
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @.LogicalFileName
DROP TABLE DummyTrans
PRINT '*** Perform a full database backup ***'
SET NOCOUNT OFF
Check to see if the log has shrunk from its original size.Repeat the
preceding steps if necessary. If the log is not shrinking, re-check the
summary at the top of the article to see if you are encountering any of the
common issues with shrinking the log.
After the log shrinks:
1. Perform a full database backup of the master database.
2. Perform a full database backup of the user database. This is necessary
because the SHRINK command is not logged and invalidates future transaction
log backups unless a full database backup is completed.
To determine why the log is growing so big in the first place, you can check
for open transactions, long running transactions, unreplicated transactions,
or transactions that touch a lot of data.
"KCThong" wrote:

> Hi,
> Can anyone help on this, how to reduce the size of the log file ?
> I have a database (SQL7.0) the mdf file is 1.6 Gbytes, but the ldf file is
> 17Gbytes. The database has been in operation for more than 2 years and why
> has the log file grown to such a size ? It was set to auto growth at 10%. Can
> I reduce it size and how? I need to claim back some disk space.
> Thank you for your time
> KC Thong
>
>
|||At this stage, if I set " trunc. log on chkpt" in the database option to
TRUE, does it help to clear the log or shrink ?
Pls advise.
"surajits" wrote:
[vbcol=seagreen]
> Here are a few things to keep in mind:
> ? Always perform system database and user database backups before and after
> you make changes that affect the system. DBCC SHRINKFILE and DBCC
> SHRINKDATABASE are not logged operations, and running them invalidates
> further transaction log backups. You must make a full database backup after
> you run either the DBCC SHRINKFILE or the DBCC SHRINKDATABASE commands.
> ? Make sure that there are no backups scheduled to occur during the time the
> shrink is supposed to occur.
> ? Make sure that there are no old, long-running, or unreplicated
> transactions. To do so, use code similar to:DBCC OPENTRAN (database_name)
> ? Run the DBCC SHRINKFILE or DBCC SHRINKDATABASE command to mark a
> shrinkpoint. DBCC SHRINKFILE and DBCC SHRINKDATABASE permissions default to
> members of the sysadmin fixed server role or the db_owner fixed database
> role, and are not transferable. For information about the differences between
> these commands, refer to the following topics in SQL Books Online (note the
> different parameters):
> DBCC SHRINKFILE (file_name, target_size)
> DBCC SHRINKDATABASE (database_name, target_percent)
> ? Create some dummy transactions to make the log wrap around and then issue
> a BACKUP command to truncate the log. The BACKUP statement is what actually
> attempts to shrink the log to the marked target size.
> Here is a sample of how to create a dummy transactions that wraps the log
> for a single logical log file and causes it to truncate, allowing for
> shrinkage. Modify the sample as needed for your environment. SET NOCOUNT ON
> DECLARE @.LogicalFileName sysname,
> @.MaxMinutes INT,
> @.NewSize INT
> -- *** MAKE SURE TO CHANGE THE NEXT 4 LINES WITH YOUR CRITERIA. ***
> USE [Test DB] -- This is the name of the database
> -- for which the log will be shrunk.
> SELECT @.LogicalFileName = 'Test DB Log', -- Use sp_helpfile to
> -- identify the logical file
> -- name that you want to shrink.
> @.MaxMinutes = 10, -- Limit on time allowed to wrap log.
> @.NewSize = 10 -- in MB
> -- Setup / initialize
> DECLARE @.OriginalSize int
> SELECT @.OriginalSize = size -- in 8K pages
> FROM sysfiles
> WHERE name = @.LogicalFileName
> SELECT 'Original Size of ' + db_name() + ' LOG is ' +
> CONVERT(VARCHAR(30),@.OriginalSize) + ' 8K pages or ' +
> CONVERT(VARCHAR(30),(@.OriginalSize*8/1024)) + 'MB'
> FROM sysfiles
> WHERE name = @.LogicalFileName
> CREATE TABLE DummyTrans
> (DummyColumn char (8000) not null)
> -- Wrap log and truncate it.
> DECLARE @.Counter INT,
> @.StartTime DATETIME,
> @.TruncLog VARCHAR(255)
> SELECT @.StartTime = GETDATE(),
> @.TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'
> -- Try an initial shrink.
> DBCC SHRINKFILE (@.LogicalFileName, @.NewSize)
> EXEC (@.TruncLog)
> -- Wrap the log if necessary.
> WHILE @.MaxMinutes > DATEDIFF (mi, @.StartTime, GETDATE()) -- time has
> not expired
> AND @.OriginalSize = (SELECT size FROM sysfiles WHERE name =
> @.LogicalFileName) -- the log has not shrunk
> AND (@.OriginalSize * 8 /1024) > @.NewSize -- The value passed in
> for new size is smaller than the current size.
> BEGIN -- Outer loop.
> SELECT @.Counter = 0
> WHILE ((@.Counter < @.OriginalSize / 16) AND (@.Counter < 50000))
> BEGIN -- update
> INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char
> field it inserts 8000 bytes.
> DELETE DummyTrans
> SELECT @.Counter = @.Counter + 1
> END -- update
> EXEC (@.TruncLog) -- See if a trunc of the log shrinks it.
> END -- outer loop
> SELECT 'Final Size of ' + db_name() + ' LOG is ' +
> CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
> CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
> FROM sysfiles
> WHERE name = @.LogicalFileName
> DROP TABLE DummyTrans
> PRINT '*** Perform a full database backup ***'
> SET NOCOUNT OFF
> Check to see if the log has shrunk from its original size.Repeat the
> preceding steps if necessary. If the log is not shrinking, re-check the
> summary at the top of the article to see if you are encountering any of the
> common issues with shrinking the log.
> After the log shrinks:
> 1. Perform a full database backup of the master database.
> 2. Perform a full database backup of the user database. This is necessary
> because the SHRINK command is not logged and invalidates future transaction
> log backups unless a full database backup is completed.
> To determine why the log is growing so big in the first place, you can check
> for open transactions, long running transactions, unreplicated transactions,
> or transactions that touch a lot of data.
> "KCThong" wrote: