Locks and Blocks: back

Showing posts with label back. Show all posts

Friday, March 30, 2012

Log on Problem.

OK. I have a little problem that i need help diagnosing. I have a Webpage
for internal program that connects back to SQL Server. When I rebooted the
server last night, in the morning users complainted that they can't log on
into it. As soon as I walked up to the server and simply logged in,
everything started to work. My question is why. All my services are set to
system accounts and to Automatic starts so everything should be started when
the server starts. How can I diagnose this?
Thank You!These are possibly programs that are in your Startup routine after you
login.
If you're running Windows 2003 click the Start button > Run > Msconfig.exe.
Check the Startup tab for programs that are loading at startup from the
Startup group, Win.ini load= and run=, and the registry.
For Windows 2000, use regedit & check the following entries:
HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \Run
HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \RunOnce
HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Run
HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Runonce
"Kory" <koryg@.community.nospam> wrote in message
news:uIxvwLd8FHA.3416@.TK2MSFTNGP15.phx.gbl...
> OK. I have a little problem that i need help diagnosing. I have a
Webpage
> for internal program that connects back to SQL Server. When I rebooted
the
> server last night, in the morning users complainted that they can't log on
> into it. As soon as I walked up to the server and simply logged in,
> everything started to work. My question is why. All my services are set
to
> system accounts and to Automatic starts so everything should be started
when
> the server starts. How can I diagnose this?
> Thank You!
>|||I'm running windows 2003. So basically I should remove these files from
Startup and move them to WIN.INI'
"Isaac Steinfeld" <isteinfeld@.hotmail.com> wrote in message
news:%23tM6PYd8FHA.1292@.tk2msftngp13.phx.gbl...
> These are possibly programs that are in your Startup routine after you
> login.
> If you're running Windows 2003 click the Start button > Run >
> Msconfig.exe.
> Check the Startup tab for programs that are loading at startup from the
> Startup group, Win.ini load= and run=, and the registry.
> For Windows 2000, use regedit & check the following entries:
> HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \Run
> HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \RunOnce
> HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Run
> HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Runonce
> "Kory" <koryg@.community.nospam> wrote in message
> news:uIxvwLd8FHA.3416@.TK2MSFTNGP15.phx.gbl...
>> OK. I have a little problem that i need help diagnosing. I have a
> Webpage
>> for internal program that connects back to SQL Server. When I rebooted
> the
>> server last night, in the morning users complainted that they can't log
>> on
>> into it. As soon as I walked up to the server and simply logged in,
>> everything started to work. My question is why. All my services are set
> to
>> system accounts and to Automatic starts so everything should be started
> when
>> the server starts. How can I diagnose this?
>> Thank You!
>>
>|||No.
You have a few options to have programs run without requiring a login.
One is to have these programs run as User-defined service.
See the following link for instructions:
http://support.microsoft.com/support/kb/articles/q137/8/90.asp
Another is to have it run as a Computer Script. (Either as a local policy or
as a group policy depending on your environment)
Run gpedit.msc and create a startup scripts at Computer Configuration
>Windows Settings>Scripts>Startup.
See the following link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;322241
Another option might be to do an Autologon. See
http://www.petri.co.il/configuring_autologon.htm
"Kory" <koryg@.community.nospam> wrote in message
news:%23s5Qahd8FHA.444@.TK2MSFTNGP11.phx.gbl...
> I'm running windows 2003. So basically I should remove these files from
> Startup and move them to WIN.INI'
>
> "Isaac Steinfeld" <isteinfeld@.hotmail.com> wrote in message
> news:%23tM6PYd8FHA.1292@.tk2msftngp13.phx.gbl...
> > These are possibly programs that are in your Startup routine after you
> > login.
> > If you're running Windows 2003 click the Start button > Run >
> > Msconfig.exe.
> > Check the Startup tab for programs that are loading at startup from the
> > Startup group, Win.ini load= and run=, and the registry.
> > For Windows 2000, use regedit & check the following entries:
> > HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \Run
> > HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion
\RunOnce
> > HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Run
> > HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Runonce
> >
> > "Kory" <koryg@.community.nospam> wrote in message
> > news:uIxvwLd8FHA.3416@.TK2MSFTNGP15.phx.gbl...
> >> OK. I have a little problem that i need help diagnosing. I have a
> > Webpage
> >> for internal program that connects back to SQL Server. When I
rebooted
> > the
> >> server last night, in the morning users complainted that they can't log
> >> on
> >> into it. As soon as I walked up to the server and simply logged in,
> >> everything started to work. My question is why. All my services are
set
> > to
> >> system accounts and to Automatic starts so everything should be started
> > when
> >> the server starts. How can I diagnose this?
> >>
> >> Thank You!
> >>
> >>
> >
> >
>

Log on Problem.

Wednesday, March 28, 2012

Log Full

I am having a problem with one of my databases since the log is getting
rather large dispite regular back up. I have heard that there a extended
stored proceedure that will recycle the log. Anyone have an idea..?
I really appreciate this.
"Recycle The Log" is a term used when talking about the SQL Server Errorlog.
The command in question is sp_cycle_errorlog. To view it use
sp_readerrorlog.
However, neither of these are any good to you as the log you are refering to
is the TransAction Log. There are numerous articles on the subject, here are
a few :-
http://www.support.microsoft.com/?id=256650 INF: How to Shrink the SQL
Server 7.0 Tran Log
http://www.support.microsoft.com/?id=317375 Log File Grows too big
http://www.support.microsoft.com/?id=110139 Log file filling up
http://www.mssqlserver.com/faq/logs-shrinklog.asp Shrink File
http://www.support.microsoft.com/?id=315512 Considerations for Autogrow
and AutoShrink
http://www.support.microsoft.com/?id=272318 INF: Shrinking Log in SQL
Server 2000 with DBCC SHRINKFILE
http://www.support.microsoft.com/?id=317375 Log File Grows too big
http://www.support.microsoft.com/?id=110139 Log file filling up
http://www.mssqlserver.com/faq/logs-shrinklog.asp Shrink File
http://www.support.microsoft.com/?id=315512 Considerations for Autogrow
and AutoShrink
HTH. Ryan
"bluefish" <bluefish@.discussions.microsoft.com> wrote in message
news:32533A4B-FC3A-4536-BD99-BD9BEFEAA1C9@.microsoft.com...
>I am having a problem with one of my databases since the log is getting
> rather large dispite regular back up. I have heard that there a extended
> stored proceedure that will recycle the log. Anyone have an idea..?
> I really appreciate this.
>

Log Full

I am having a problem with one of my databases since the log is getting
rather large dispite regular back up. I have heard that there a extended
stored proceedure that will recycle the log. Anyone have an idea..?
I really appreciate this."Recycle The Log" is a term used when talking about the SQL Server Errorlog.
The command in question is sp_cycle_errorlog. To view it use
sp_readerrorlog.
However, neither of these are any good to you as the log you are refering to
is the TransAction Log. There are numerous articles on the subject, here are
a few :-
http://www.support.microsoft.com/?id=256650 INF: How to Shrink the SQL
Server 7.0 Tran Log
http://www.support.microsoft.com/?id=317375 Log File Grows too big
http://www.support.microsoft.com/?id=110139 Log file filling up
http://www.mssqlserver.com/faq/logs-shrinklog.asp Shrink File
http://www.support.microsoft.com/?id=315512 Considerations for Autogrow
and AutoShrink
http://www.support.microsoft.com/?id=272318 INF: Shrinking Log in SQL
Server 2000 with DBCC SHRINKFILE
http://www.support.microsoft.com/?id=317375 Log File Grows too big
http://www.support.microsoft.com/?id=110139 Log file filling up
http://www.mssqlserver.com/faq/logs-shrinklog.asp Shrink File
http://www.support.microsoft.com/?id=315512 Considerations for Autogrow
and AutoShrink
--
HTH. Ryan
"bluefish" <bluefish@.discussions.microsoft.com> wrote in message
news:32533A4B-FC3A-4536-BD99-BD9BEFEAA1C9@.microsoft.com...
>I am having a problem with one of my databases since the log is getting
> rather large dispite regular back up. I have heard that there a extended
> stored proceedure that will recycle the log. Anyone have an idea..?
> I really appreciate this.
>

Log Full

I am having a problem with one of my databases since the log is getting
rather large dispite regular back up. I have heard that there a extended
stored proceedure that will recycle the log. Anyone have an idea..?
I really appreciate this."Recycle The Log" is a term used when talking about the SQL Server Errorlog.
The command in question is sp_cycle_errorlog. To view it use
sp_readerrorlog.
However, neither of these are any good to you as the log you are refering to
is the TransAction Log. There are numerous articles on the subject, here are
a few :-
http://www.support.microsoft.com/?id=256650 INF: How to Shrink the SQL
Server 7.0 Tran Log
http://www.support.microsoft.com/?id=317375 Log File Grows too big
http://www.support.microsoft.com/?id=110139 Log file filling up
http://www.mssqlserver.com/faq/logs-shrinklog.asp Shrink File
http://www.support.microsoft.com/?id=315512 Considerations for Autogrow
and AutoShrink
http://www.support.microsoft.com/?id=272318 INF: Shrinking Log in SQL
Server 2000 with DBCC SHRINKFILE
http://www.support.microsoft.com/?id=317375 Log File Grows too big
http://www.support.microsoft.com/?id=110139 Log file filling up
http://www.mssqlserver.com/faq/logs-shrinklog.asp Shrink File
http://www.support.microsoft.com/?id=315512 Considerations for Autogrow
and AutoShrink
HTH. Ryan
"bluefish" <bluefish@.discussions.microsoft.com> wrote in message
news:32533A4B-FC3A-4536-BD99-BD9BEFEAA1C9@.microsoft.com...
>I am having a problem with one of my databases since the log is getting
> rather large dispite regular back up. I have heard that there a extended
> stored proceedure that will recycle the log. Anyone have an idea..?
> I really appreciate this.
>sql

Log for tempdb is full

I keep getting the following error in my SQL 2K SP3a server logs:
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space..
But using the EM I cannot backup the transaction logs - the options are
grayed out. If I try to backup the tempdb through EM, I get an error that
Backup and Restore are not allowed on tempdb. I have the options set to
allow unlimited growth. There are many GB's of space on the drive. What is
the problem/solution?
TIA!
http://www.aspfaq.com/2446
http://www.aspfaq.com/
(Reverse address to reply.)
"Ron Hinds" <__NoSpam__ron@.__ramac__.com> wrote in message
news:u95Znp3wEHA.2624@.TK2MSFTNGP11.phx.gbl...
> I keep getting the following error in my SQL 2K SP3a server logs:
> The log file for database 'tempdb' is full. Back up the transaction log
for
> the database to free up some log space..
> But using the EM I cannot backup the transaction logs - the options are
> grayed out. If I try to backup the tempdb through EM, I get an error that
> Backup and Restore are not allowed on tempdb. I have the options set to
> allow unlimited growth. There are many GB's of space on the drive. What is
> the problem/solution?
> TIA!
>
|||Perhaps there's code in some application that has an open transaction that
has run amok?
"Ron Hinds" <__NoSpam__ron@.__ramac__.com> wrote in message
news:u95Znp3wEHA.2624@.TK2MSFTNGP11.phx.gbl...
> I keep getting the following error in my SQL 2K SP3a server logs:
> The log file for database 'tempdb' is full. Back up the transaction log
for
> the database to free up some log space..
> But using the EM I cannot backup the transaction logs - the options are
> grayed out. If I try to backup the tempdb through EM, I get an error that
> Backup and Restore are not allowed on tempdb. I have the options set to
> allow unlimited growth. There are many GB's of space on the drive. What is
> the problem/solution?
> TIA!
>

Log for tempdb is full

I keep getting the following error in my SQL 2K SP3a server logs:
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space..
But using the EM I cannot backup the transaction logs - the options are
grayed out. If I try to backup the tempdb through EM, I get an error that
Backup and Restore are not allowed on tempdb. I have the options set to
allow unlimited growth. There are many GB's of space on the drive. What is
the problem/solution?
TIA!http://www.aspfaq.com/2446
--
http://www.aspfaq.com/
(Reverse address to reply.)
"Ron Hinds" <__NoSpam__ron@.__ramac__.com> wrote in message
news:u95Znp3wEHA.2624@.TK2MSFTNGP11.phx.gbl...
> I keep getting the following error in my SQL 2K SP3a server logs:
> The log file for database 'tempdb' is full. Back up the transaction log
for
> the database to free up some log space..
> But using the EM I cannot backup the transaction logs - the options are
> grayed out. If I try to backup the tempdb through EM, I get an error that
> Backup and Restore are not allowed on tempdb. I have the options set to
> allow unlimited growth. There are many GB's of space on the drive. What is
> the problem/solution?
> TIA!
>|||Perhaps there's code in some application that has an open transaction that
has run amok?
"Ron Hinds" <__NoSpam__ron@.__ramac__.com> wrote in message
news:u95Znp3wEHA.2624@.TK2MSFTNGP11.phx.gbl...
> I keep getting the following error in my SQL 2K SP3a server logs:
> The log file for database 'tempdb' is full. Back up the transaction log
for
> the database to free up some log space..
> But using the EM I cannot backup the transaction logs - the options are
> grayed out. If I try to backup the tempdb through EM, I get an error that
> Backup and Restore are not allowed on tempdb. I have the options set to
> allow unlimited growth. There are many GB's of space on the drive. What is
> the problem/solution?
> TIA!
>

Log for tempdb is full

I keep getting the following error in my SQL 2K SP3a server logs:
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space..
But using the EM I cannot backup the transaction logs - the options are
grayed out. If I try to backup the tempdb through EM, I get an error that
Backup and Restore are not allowed on tempdb. I have the options set to
allow unlimited growth. There are many GB's of space on the drive. What is
the problem/solution?
TIA!http://www.aspfaq.com/2446
http://www.aspfaq.com/
(Reverse address to reply.)
"Ron Hinds" <__NoSpam__ron@.__ramac__.com> wrote in message
news:u95Znp3wEHA.2624@.TK2MSFTNGP11.phx.gbl...
> I keep getting the following error in my SQL 2K SP3a server logs:
> The log file for database 'tempdb' is full. Back up the transaction log
for
> the database to free up some log space..
> But using the EM I cannot backup the transaction logs - the options are
> grayed out. If I try to backup the tempdb through EM, I get an error that
> Backup and Restore are not allowed on tempdb. I have the options set to
> allow unlimited growth. There are many GB's of space on the drive. What is
> the problem/solution?
> TIA!
>|||Perhaps there's code in some application that has an open transaction that
has run amok?
"Ron Hinds" <__NoSpam__ron@.__ramac__.com> wrote in message
news:u95Znp3wEHA.2624@.TK2MSFTNGP11.phx.gbl...
> I keep getting the following error in my SQL 2K SP3a server logs:
> The log file for database 'tempdb' is full. Back up the transaction log
for
> the database to free up some log space..
> But using the EM I cannot backup the transaction logs - the options are
> grayed out. If I try to backup the tempdb through EM, I get an error that
> Backup and Restore are not allowed on tempdb. I have the options set to
> allow unlimited growth. There are many GB's of space on the drive. What is
> the problem/solution?
> TIA!
>

Log files WAY too big

I know this seems to be a common issue. My dbs transaction logs are
absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
an effort to shink these bloated transaction logs, I'm trying to follow this
article: http://support.microsoft.com/default...b;EN-US;272318
...but what does step 1 really mean? "Run this code"? How? Where? What
do you mean 'run this code'? As a stored procedure? As a query? Any
advice would be appreciated.
TIA
Open Query Analyzer. Switch the database context to the offending database
with a USE statement or using the dropdown up top. Paste the code. Hit
F5.
http://www.aspfaq.com/
(Reverse address to reply.)
"D. Shane Fowlkes" <shanefowlkes@.h-o-t-m-a-i-l.com> wrote in message
news:#fdZHNRiEHA.3664@.TK2MSFTNGP11.phx.gbl...
> I know this seems to be a common issue. My dbs transaction logs are
> absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
> an effort to shink these bloated transaction logs, I'm trying to follow
this
> article: http://support.microsoft.com/default...b;EN-US;272318
> ...but what does step 1 really mean? "Run this code"? How? Where? What
> do you mean 'run this code'? As a stored procedure? As a query? Any
> advice would be appreciated.
> TIA
>
|||Hi
1.. You must run a BACKUP LOG statement to free up space by removing the
inactive portion of the log.
2.. You must run DBCC SHRINKFILE again with the desired target size until
the log file shrinks to the target size
Run BACKUP LOG ....(see a syntax in the BOL) in QA within your database.
Run DBCC SHRINKFILE in QA within your database as well.
"D. Shane Fowlkes" <shanefowlkes@.h-o-t-m-a-i-l.com> wrote in message
news:%23fdZHNRiEHA.3664@.TK2MSFTNGP11.phx.gbl...
> I know this seems to be a common issue. My dbs transaction logs are
> absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
> an effort to shink these bloated transaction logs, I'm trying to follow
this
> article: http://support.microsoft.com/default...b;EN-US;272318
> ...but what does step 1 really mean? "Run this code"? How? Where? What
> do you mean 'run this code'? As a stored procedure? As a query? Any
> advice would be appreciated.
> TIA
>
sql

Log files WAY too big

I know this seems to be a common issue. My dbs transaction logs are
absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
an effort to shink these bloated transaction logs, I'm trying to follow this
article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;272318
...but what does step 1 really mean? "Run this code"? How? Where? What
do you mean 'run this code'? As a stored procedure? As a query? Any
advice would be appreciated.
TIAOpen Query Analyzer. Switch the database context to the offending database
with a USE statement or using the dropdown up top. Paste the code. Hit
F5.
--
http://www.aspfaq.com/
(Reverse address to reply.)
"D. Shane Fowlkes" <shanefowlkes@.h-o-t-m-a-i-l.com> wrote in message
news:#fdZHNRiEHA.3664@.TK2MSFTNGP11.phx.gbl...
> I know this seems to be a common issue. My dbs transaction logs are
> absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
> an effort to shink these bloated transaction logs, I'm trying to follow
this
> article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;272318
> ...but what does step 1 really mean? "Run this code"? How? Where? What
> do you mean 'run this code'? As a stored procedure? As a query? Any
> advice would be appreciated.
> TIA
>|||Hi
1.. You must run a BACKUP LOG statement to free up space by removing the
inactive portion of the log.
2.. You must run DBCC SHRINKFILE again with the desired target size until
the log file shrinks to the target size
Run BACKUP LOG ....(see a syntax in the BOL) in QA within your database.
Run DBCC SHRINKFILE in QA within your database as well.
"D. Shane Fowlkes" <shanefowlkes@.h-o-t-m-a-i-l.com> wrote in message
news:%23fdZHNRiEHA.3664@.TK2MSFTNGP11.phx.gbl...
> I know this seems to be a common issue. My dbs transaction logs are
> absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
> an effort to shink these bloated transaction logs, I'm trying to follow
this
> article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;272318
> ...but what does step 1 really mean? "Run this code"? How? Where? What
> do you mean 'run this code'? As a stored procedure? As a query? Any
> advice would be appreciated.
> TIA
>

Log files WAY too big

I know this seems to be a common issue. My dbs transaction logs are
absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
an effort to shink these bloated transaction logs, I'm trying to follow this
article: http://support.microsoft.com/defaul...kb;EN-US;272318
...but what does step 1 really mean? "Run this code"? How? Where? What
do you mean 'run this code'? As a stored procedure? As a query? Any
advice would be appreciated.
TIAOpen Query Analyzer. Switch the database context to the offending database
with a USE statement or using the dropdown up top. Paste the code. Hit
F5.
http://www.aspfaq.com/
(Reverse address to reply.)
"D. Shane Fowlkes" <shanefowlkes@.h-o-t-m-a-i-l.com> wrote in message
news:#fdZHNRiEHA.3664@.TK2MSFTNGP11.phx.gbl...
> I know this seems to be a common issue. My dbs transaction logs are
> absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
> an effort to shink these bloated transaction logs, I'm trying to follow
this
> article: http://support.microsoft.com/defaul...kb;EN-US;272318
> ...but what does step 1 really mean? "Run this code"? How? Where? What
> do you mean 'run this code'? As a stored procedure? As a query? Any
> advice would be appreciated.
> TIA
>|||Hi
1.. You must run a BACKUP LOG statement to free up space by removing the
inactive portion of the log.
2.. You must run DBCC SHRINKFILE again with the desired target size until
the log file shrinks to the target size
Run BACKUP LOG ....(see a syntax in the BOL) in QA within your database.
Run DBCC SHRINKFILE in QA within your database as well.
"D. Shane Fowlkes" <shanefowlkes@.h-o-t-m-a-i-l.com> wrote in message
news:%23fdZHNRiEHA.3664@.TK2MSFTNGP11.phx.gbl...
> I know this seems to be a common issue. My dbs transaction logs are
> absurdly too big. Therefore, I switched the back mode to SIMPLE. Now, in
> an effort to shink these bloated transaction logs, I'm trying to follow
this
> article: http://support.microsoft.com/defaul...kb;EN-US;272318
> ...but what does step 1 really mean? "Run this code"? How? Where? What
> do you mean 'run this code'? As a stored procedure? As a query? Any
> advice would be appreciated.
> TIA
>

Wednesday, March 21, 2012

Log file of test database bloating

A test database that we used in one of our implementation pilots was
abandoned around 4 months back. The database when abandoned had a log
file size of less than 500MB. The log file has been steadily bloating
(just came to my attention) and has reached 8.5GB. The database has
not been used since abandoned 4 months back at 500MB. Considering the
fact that our live DB has a combined (data + log) file size of less
than 2GB I do not want to delete the database before exploring the
cause.

Any ideas? Thanks and appreciate your help

SQL Server 2000"Sanjay Asrani" <sasrani@.boathouse.com> wrote in message
news:26ae5f82.0410060618.352c931e@.posting.google.c om...
>A test database that we used in one of our implementation pilots was
> abandoned around 4 months back. The database when abandoned had a log
> file size of less than 500MB. The log file has been steadily bloating
> (just came to my attention) and has reached 8.5GB. The database has
> not been used since abandoned 4 months back at 500MB. Considering the
> fact that our live DB has a combined (data + log) file size of less
> than 2GB I do not want to delete the database before exploring the
> cause.
> Any ideas? Thanks and appreciate your help
> SQL Server 2000

This might be useful:

http://support.microsoft.com/defaul...kb;EN-US;317375

If you believe the database should not be in use, you might want to run a
Profiler trace filtered on that particular database to see what's happening.

Simon

Monday, March 19, 2012

Log file is Full: How to prevent it happening?

"The log file for database 'DW_BackRoom_RT' is full. Back up the
transaction log for the database to free up some log space."
Now I only know this way to deal with that manually,
Step1. in option , chance Recovery model from FULL to Simple.
Step2: go to task to manually shrink the log file
Step3: Change recovery model back from simple to FULL.
But by this way, I could get same problem again, the log file is fill,
and need free up.
Could you give an idea how to prevent this from happening? what and
how should I do?
Thanks a lot in advance for your help.
If you are periodically wiping the transaction log, then it sounds like it
is of no importance to you so I'd recommend leaving in simple recovery mode.
If you decide that the log is needed for DR, set up a backup plan which
includes full database backups and regular log backups.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Hello,
If the data is this database is not critical/non production you can set the
recovery model to SIMPLE. THis will make sure that after
each checkpoint data will be writtent o disk and clear the transaction log
file. Incase if the data is critical keep the Recovery model
to FULL and make sure that you schedule a transction log backup (BACKUP
LOG). SO after each transction log backup the
LDF file will be cleared. THis will help you to restrict the growth of LDF
file and log backups will help you to recover the
database if needed as welll as you can perform Point_IN_Time recovery if
needed.
Take a look into Recovery models in Books online.
Thanks
Hari
<danceli@.gmail.com> wrote in message
news:1171053424.553101.106320@.s48g2000cws.googlegr oups.com...
> "The log file for database 'DW_BackRoom_RT' is full. Back up the
> transaction log for the database to free up some log space."
> Now I only know this way to deal with that manually,
> Step1. in option , chance Recovery model from FULL to Simple.
> Step2: go to task to manually shrink the log file
> Step3: Change recovery model back from simple to FULL.
> But by this way, I could get same problem again, the log file is fill,
> and need free up.
> Could you give an idea how to prevent this from happening? what and
> how should I do?
> Thanks a lot in advance for your help.
>

Log file is Full: How to prevent it happening?

"The log file for database 'DW_BackRoom_RT' is full. Back up the
transaction log for the database to free up some log space."
Now I only know this way to deal with that manually,
Step1. in option , chance Recovery model from FULL to Simple.
Step2: go to task to manually shrink the log file
Step3: Change recovery model back from simple to FULL.
But by this way, I could get same problem again, the log file is fill,
and need free up.
Could you give an idea how to prevent this from happening? what and
how should I do?
Thanks a lot in advance for your help.If you are periodically wiping the transaction log, then it sounds like it
is of no importance to you so I'd recommend leaving in simple recovery mode.
If you decide that the log is needed for DR, set up a backup plan which
includes full database backups and regular log backups.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com|||Hello,
If the data is this database is not critical/non production you can set the
recovery model to SIMPLE. THis will make sure that after
each checkpoint data will be writtent o disk and clear the transaction log
file. Incase if the data is critical keep the Recovery model
to FULL and make sure that you schedule a transction log backup (BACKUP
LOG). SO after each transction log backup the
LDF file will be cleared. THis will help you to restrict the growth of LDF
file and log backups will help you to recover the
database if needed as welll as you can perform Point_IN_Time recovery if
needed.
Take a look into Recovery models in Books online.
Thanks
Hari
<danceli@.gmail.com> wrote in message
news:1171053424.553101.106320@.s48g2000cws.googlegroups.com...
> "The log file for database 'DW_BackRoom_RT' is full. Back up the
> transaction log for the database to free up some log space."
> Now I only know this way to deal with that manually,
> Step1. in option , chance Recovery model from FULL to Simple.
> Step2: go to task to manually shrink the log file
> Step3: Change recovery model back from simple to FULL.
> But by this way, I could get same problem again, the log file is fill,
> and need free up.
> Could you give an idea how to prevent this from happening? what and
> how should I do?
> Thanks a lot in advance for your help.
>

Log file is Full: How to prevent it happening?

"The log file for database 'DW_BackRoom_RT' is full. Back up the
transaction log for the database to free up some log space."
Now I only know this way to deal with that manually,
Step1. in option , chance Recovery model from FULL to Simple.
Step2: go to task to manually shrink the log file
Step3: Change recovery model back from simple to FULL.
But by this way, I could get same problem again, the log file is fill,
and need free up.
Could you give an idea how to prevent this from happening? what and
how should I do?
Thanks a lot in advance for your help.If you are periodically wiping the transaction log, then it sounds like it
is of no importance to you so I'd recommend leaving in simple recovery mode.
If you decide that the log is needed for DR, set up a backup plan which
includes full database backups and regular log backups.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com|||Hello,
If the data is this database is not critical/non production you can set the
recovery model to SIMPLE. THis will make sure that after
each checkpoint data will be writtent o disk and clear the transaction log
file. Incase if the data is critical keep the Recovery model
to FULL and make sure that you schedule a transction log backup (BACKUP
LOG). SO after each transction log backup the
LDF file will be cleared. THis will help you to restrict the growth of LDF
file and log backups will help you to recover the
database if needed as welll as you can perform Point_IN_Time recovery if
needed.
Take a look into Recovery models in Books online.
Thanks
Hari
<danceli@.gmail.com> wrote in message
news:1171053424.553101.106320@.s48g2000cws.googlegroups.com...
> "The log file for database 'DW_BackRoom_RT' is full. Back up the
> transaction log for the database to free up some log space."
> Now I only know this way to deal with that manually,
> Step1. in option , chance Recovery model from FULL to Simple.
> Step2: go to task to manually shrink the log file
> Step3: Change recovery model back from simple to FULL.
> But by this way, I could get same problem again, the log file is fill,
> and need free up.
> Could you give an idea how to prevent this from happening? what and
> how should I do?
> Thanks a lot in advance for your help.
>

Log File is Full error: How to prevent this happening?

"The log file for database is full. Back up the transaction log for
the database to free up some log space."

Now I only know this way to deal with that manually,

Step1. in option , chance Recovery model from FULL to Simple.
Step2: go to task to manually shrink the log file
Step3: Change recovery model back from simple to FULL.

But by this way, I could get same problem again, the log file is fill,
and need free up.

Could you give an idea how to prevent this from happening? what and
how should I do?

Thanks a lot in advance for your help.(danceli@.gmail.com) writes:

Quote:

Originally Posted by

"The log file for database is full. Back up the transaction log for
the database to free up some log space."
>
Now I only know this way to deal with that manually,
>
Step1. in option , chance Recovery model from FULL to Simple.
Step2: go to task to manually shrink the log file
Step3: Change recovery model back from simple to FULL.
>
But by this way, I could get same problem again, the log file is fill,
and need free up.
>
Could you give an idea how to prevent this from happening? what and
how should I do?

First: decide what recovery mechanism do you need. Second: implement it.

Do you need up-to-the-point recovery? That is, if the database goes
belly-up, or somewhat makes a fatal mistake, are you content with
restoring the latest backup? Or do you want recovery as close to
the accident as possible. If you are content with the latest backup,
go for simple, and all you need to make sure is that you back up the
database regularly.

If you want up-to-the-point-recovery, the you need FULL recovery mode.
You also need to backup your transaction log regularly. How often
depends on the transaction rate in your database. If you never backup
the transaction log, it will outgrow the disk eventually. Note also that
by switching to simple recovery, you break the log chain, and the
ability to up-to-the-point recovery.

Also with full recovery, you need to backup your database regularly.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||danc...
This can also be an application issue, I often encounter situations
where delevelopers do not batch their transactions, and thus do not
give the log a chance to truncate, if this is an inhouse app; updates
and deletes should be done in batches. The size of the batch should be
set by the ideal size of your transaction log, the size of the db
etc.. Also, be sure to dump the log periodically, typically I dump the
log every 15 minutes (when the db is in full recovery mode). This will
also assist in controlling the size of the log.
Cheers,
G|||GZ (gerald.zimmerman@.gmail.com) writes:

Quote:

Originally Posted by

This can also be an application issue, I often encounter situations
where delevelopers do not batch their transactions, and thus do not
give the log a chance to truncate, if this is an inhouse app; updates
and deletes should be done in batches. The size of the batch should be
set by the ideal size of your transaction log, the size of the db
etc.. Also, be sure to dump the log periodically, typically I dump the
log every 15 minutes (when the db is in full recovery mode). This will
also assist in controlling the size of the log.

I assume that you are thinking of is the case where you update, insert
or delete millions of rows in one go, and that in such case it may be
better to break up the operation in batches of say 500000 rows. Yes,
this can be a good idea. But it has to implemented in such a way that
if the operation fails half-way, the database is still consistent.

Log File Full -> Back up Transaction Log

Hi.
I get the following error message occassionally,
"The log file for database 'TSBASE' is full. Back up the transaction log for
the database to free up some log space."
I'll backup the transaction log, and the database immediately. But after a
while (a few weeks), the error comes out again.
Why is there such an error? It seems like no matter how large I assign the
size of the transaction log to be, I'll still get this error one day. How
occassionally do I need to backup the transaction log? Is backing up the
transaction log the only solution? Will it come to a day whereby the log file
gets really so full that even backing up won't solve the problem?
Thank you in advance.This is a multi-part message in MIME format.
--000300010805090603020106
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
You need to do a bit of reading on basic database technology & concepts.
A transaction log is a record of all change to a database. So, every
time you change a database in any way (changing, adding, deleting data,
building indexes, dropping tables, adding new users, etc., etc.) the
transaction log will grow. The transaction log is a *very *important
part of a production database server.
Typically DBAs backup their production logs very regularly. If you
don't and you have some kind of failure on your database server
necessitating recovery from a backup, then you're going to lose vast
amounts of data. For example, I backup the transaction logs for all my
production databases every 15 minutes (with a full backup nightly) so,
in theory, I lose at most 15 minutes worth of data in the case of a disk
failure or database corruption of some sort. That's a very common thing
to do and 15 minutes, while it suits my situation but may not be right
for others, is also quite a common log backup interval. Some backup
their logs more often (every 5 minutes or less). Others backup their
logs less frequently (once an hour, once a day, etc.)
Timing all depends on your overall backup strategy. You must have one
of these - this is important.
If you're not interested in keeping incremental changes to a database
and you simply want to do full backups periodically then you can
automatically truncate the transaction log on every checkpoint
(typically every 30-120 seconds). This will keep the log from growing
very large (only a couple minutes transactions will be recorded before
getting truncated). You do this in SQL Server by changing the *recovery
model* of the database to SIMPLE with the ALTER DATABASE statement as
follows:
ALTER DATABASE TSBASE set RECOVERY SIMPLE
However, this will invalidate the transaction log and you will not be
able to backup the transaction log while in SIMPLE recovery mode.
(Actually you can backup the transaction log while in this mode but the
backups will be useless for recovery purposes because the log on those
backups will be invalid.)
For more information on transaction logs you could start with SQL Books
Online:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_02_6xwz.asp
--
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
wrytat wrote:
>Hi.
>I get the following error message occassionally,
>"The log file for database 'TSBASE' is full. Back up the transaction log for
>the database to free up some log space."
>I'll backup the transaction log, and the database immediately. But after a
>while (a few weeks), the error comes out again.
>Why is there such an error? It seems like no matter how large I assign the
>size of the transaction log to be, I'll still get this error one day. How
>occassionally do I need to backup the transaction log? Is backing up the
>transaction log the only solution? Will it come to a day whereby the log file
>gets really so full that even backing up won't solve the problem?
>Thank you in advance.
>
--000300010805090603020106
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>You need to do a bit of reading on basic database technology &
concepts. 
 
A transaction log is a record of all change to a database.Â So, every
time you change a database in any way (changing, adding, deleting data,
building indexes, dropping tables, adding new users, etc., etc.) the
transaction log will grow.Â The transaction log is a very important
part of a production database server. 
 
Typically DBAs backup their production logs very regularly.Â If you
don't and you have some kind of failure on your database server
necessitating recovery from a backup, then you're going to lose vast
amounts of data.Â For example, I backup the transaction logs for all my
production databases every 15 minutes (with a full backup nightly) so,
in theory, I lose at most 15 minutes worth of data in the case of a
disk failure or database corruption of some sort.Â That's a very common
thing to do and 15 minutes, while it suits my situation but may not be
right for others, is also quite a common log backup interval.Â Some
backup their logs more often (every 5 minutes or less).Â Others backup
their logs less frequently (once an hour, once a day, etc.) 
 
Timing all depends on your overall backup strategy.Â You must have one
of these - this is important. 
 
If you're not interested in keeping incremental changes to a database
and you simply want to do full backups periodically then you can
automatically truncate the transaction log on every checkpoint
(typically every 30-120 seconds).Â This will keep the log from growing
very large (only a couple minutes transactions will be recorded before
getting truncated).Â You do this in SQL Server by changing the recovery
model of the database to SIMPLE with the ALTER DATABASE statement
as follows: 
</tt>
<blockquote><tt>ALTER DATABASE TSBASE set RECOVERY SIMPLE 
</tt></blockquote>
<tt>However, this will invalidate the transaction log and you will not
be able to backup the transaction log while in SIMPLE recovery mode.Â
(Actually you can backup the transaction log while in this mode but the
backups will be useless for recovery purposes because the log on those
backups will be invalid.) 
 
For more information on transaction logs you could start with SQL Books
Online: 
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_02_6xwz.asp</a> ">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_02_6xwz.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_02_6xwz.asp</a> 
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
-- 
 mike
hodgson | database administrator
| mallesons stephen jaques 
T +61 (2) 9296 3668 | F +61
(2) 9296 3885 | M +61
(408) 675 907 
E
<a href="http://links.10026.com/?link=mailto:mike.hodgson@.mallesons.nospam.com">
mailto:mike.hodgson@.mallesons.nospam.com</a> | W <a href="http://links.10026.com/?link=/">http://www.mallesons.com">
http://www.mallesons.com</a> 
</div>
 
 
wrytat wrote:
<blockquote cite="mid2629587A-6C8D-4A63-AB5E-ECAC182CDEAC@.microsoft.com"
type="cite">
<pre wrap="">Hi.
I get the following error message occassionally,
"The log file for database 'TSBASE' is full. Back up the transaction log for
the database to free up some log space."
I'll backup the transaction log, and the database immediately. But after a
while (a few weeks), the error comes out again.
Why is there such an error? It seems like no matter how large I assign the
size of the transaction log to be, I'll still get this error one day. How
occassionally do I need to backup the transaction log? Is backing up the
transaction log the only solution? Will it come to a day whereby the log file
gets really so full that even backing up won't solve the problem?
Thank you in advance.
</pre>
</blockquote>
</body>
</html>
--000300010805090603020106--|||Thank you for the explanation. Does backing up the transaction log reduce the
size of the log file then?
"Mike Hodgson" wrote:
> You need to do a bit of reading on basic database technology & concepts.
> A transaction log is a record of all change to a database. So, every
> time you change a database in any way (changing, adding, deleting data,
> building indexes, dropping tables, adding new users, etc., etc.) the
> transaction log will grow. The transaction log is a *very *important
> part of a production database server.
> Typically DBAs backup their production logs very regularly. If you
> don't and you have some kind of failure on your database server
> necessitating recovery from a backup, then you're going to lose vast
> amounts of data. For example, I backup the transaction logs for all my
> production databases every 15 minutes (with a full backup nightly) so,
> in theory, I lose at most 15 minutes worth of data in the case of a disk
> failure or database corruption of some sort. That's a very common thing
> to do and 15 minutes, while it suits my situation but may not be right
> for others, is also quite a common log backup interval. Some backup
> their logs more often (every 5 minutes or less). Others backup their
> logs less frequently (once an hour, once a day, etc.)
> Timing all depends on your overall backup strategy. You must have one
> of these - this is important.
> If you're not interested in keeping incremental changes to a database
> and you simply want to do full backups periodically then you can
> automatically truncate the transaction log on every checkpoint
> (typically every 30-120 seconds). This will keep the log from growing
> very large (only a couple minutes transactions will be recorded before
> getting truncated). You do this in SQL Server by changing the *recovery
> model* of the database to SIMPLE with the ALTER DATABASE statement as
> follows:
> ALTER DATABASE TSBASE set RECOVERY SIMPLE
> However, this will invalidate the transaction log and you will not be
> able to backup the transaction log while in SIMPLE recovery mode.
> (Actually you can backup the transaction log while in this mode but the
> backups will be useless for recovery purposes because the log on those
> backups will be invalid.)
> For more information on transaction logs you could start with SQL Books
> Online:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_02_6xwz.asp
> --
> *mike hodgson* |/ database administrator/ | mallesons stephen jaques
> *T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
> *E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
>
> wrytat wrote:
> >Hi.
> >
> >I get the following error message occassionally,
> >"The log file for database 'TSBASE' is full. Back up the transaction log for
> >the database to free up some log space."
> >
> >I'll backup the transaction log, and the database immediately. But after a
> >while (a few weeks), the error comes out again.
> >
> >Why is there such an error? It seems like no matter how large I assign the
> >size of the transaction log to be, I'll still get this error one day. How
> >occassionally do I need to backup the transaction log? Is backing up the
> >transaction log the only solution? Will it come to a day whereby the log file
> >gets really so full that even backing up won't solve the problem?
> >
> >Thank you in advance.
> >
> >
>|||No. It just means the space can be re-used. It's not a good idea to
keep shrinking the transaction log because shrinking per se won't
reduce the storage requirement and auto-growing it again is a very
expensive operation. The way to control log file usage is to perform
regular transaction log backups and allocate a fixed, sustainable size
to the log.
--
David Portas
SQL Server MVP
--|||Yes Sir, Its not advisable to use
dbcc shrinkfile
or
backup log 'dbname' with truncate_only -- Will truncate Log File
but as if problem is running out of space then at this moment it need to
shrink the file ?!! M i right ?
"David Portas" wrote:
> No. It just means the space can be re-used. It's not a good idea to
> keep shrinking the transaction log because shrinking per se won't
> reduce the storage requirement and auto-growing it again is a very
> expensive operation. The way to control log file usage is to perform
> regular transaction log backups and allocate a fixed, sustainable size
> to the log.
> --
> David Portas
> SQL Server MVP
> --
>|||This is a multi-part message in MIME format.
--000303070709010108040507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
It's only running out of disk space because the original poster never
backs up the transaction log. If he just sets up a backup scheduled (or
sets the recovery mode to simple) then he shouldn't have any worries.
--
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
Hemant Goswami wrote:
>Yes Sir, Its not advisable to use
>dbcc shrinkfile
>or
>backup log 'dbname' with truncate_only -- Will truncate Log File
>but as if problem is running out of space then at this moment it need to
>shrink the file ?!! M i right ?
>"David Portas" wrote:
>
>>No. It just means the space can be re-used. It's not a good idea to
>>keep shrinking the transaction log because shrinking per se won't
>>reduce the storage requirement and auto-growing it again is a very
>>expensive operation. The way to control log file usage is to perform
>>regular transaction log backups and allocate a fixed, sustainable size
>>to the log.
>>--
>>David Portas
>>SQL Server MVP
>>--
>>
>>
--000303070709010108040507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>It's only running out of disk space because the original poster
never backs up the transaction log.Â If he just sets up a backup
scheduled (or sets the recovery mode to simple) then he shouldn't have
any worries.</tt> 
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
-- 
 mike
hodgson | database administrator
| mallesons stephen jaques 
T +61 (2) 9296 3668 | F +61
(2) 9296 3885 | M +61
(408) 675 907 
E
<a href="http://links.10026.com/?link=mailto:mike.hodgson@.mallesons.nospam.com">
mailto:mike.hodgson@.mallesons.nospam.com</a> | W <a href="http://links.10026.com/?link=/">http://www.mallesons.com">
http://www.mallesons.com</a> 
</div>
 
 
Hemant Goswami wrote:
<blockquote cite="mid70310EFD-8DFC-4212-A588-EF601607BD2E@.microsoft.com"
type="cite">
<pre wrap="">Yes Sir, Its not advisable to use
dbcc shrinkfile
or
backup log 'dbname' with truncate_only -- Will truncate Log File
but as if problem is running out of space then at this moment it need to
shrink the file ?!! M i right ?
"David Portas" wrote:
</pre>
<blockquote type="cite">
<pre wrap="">No. It just means the space can be re-used. It's not a good idea to
keep shrinking the transaction log because shrinking per se won't
reduce the storage requirement and auto-growing it again is a very
expensive operation. The way to control log file usage is to perform
regular transaction log backups and allocate a fixed, sustainable size
to the log.
--
David Portas
SQL Server MVP
--
</pre>
</blockquote>
</blockquote>
</body>
</html>
--000303070709010108040507--|||This is a multi-part message in MIME format.
--=_NextPart_000_0101_01C571B2.66267180
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
I agree with Mike, that if you have a proper backup strategy, the =problem should never occour. Ther are cases though where I feel it's ok =to truncate the log file, and that's if there has been some unususal =activity in the database. If you e.g. has merged 2 databases, that might =have made the logfile grow, but since this might be a "once in a =lifetime" thing that most likely won't happen again, it might be ok to =tshrink the logfile back to a decent size.
Regards
Steen
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> skrev i en =meddelelse news:eBnOiOZcFHA.3712@.TK2MSFTNGP12.phx.gbl...
It's only running out of disk space because the original poster never =backs up the transaction log. If he just sets up a backup scheduled (or =sets the recovery mode to simple) then he shouldn't have any worries.
--
mike hodgson | database administrator | mallesons stephen jaques
T +61 (2) 9296 3668 | F +61 (2) 9296 3885 | M +61 (408) 675 907
E mailto:mike.hodgson@.mallesons.nospam.com | W =http://www.mallesons.com=20
Hemant Goswami wrote: Yes Sir, Its not advisable to use
dbcc shrinkfile or
backup log 'dbname' with truncate_only -- Will truncate Log File
but as if problem is running out of space then at this moment it need to =
shrink the file ?!! M i right ?
"David Portas" wrote:
No. It just means the space can be re-used. It's not a good idea to
keep shrinking the transaction log because shrinking per se won't
reduce the storage requirement and auto-growing it again is a very
expensive operation. The way to control log file usage is to perform
regular transaction log backups and allocate a fixed, sustainable size
to the log.
-- David Portas SQL Server MVP --
--=_NextPart_000_0101_01C571B2.66267180
Content-Type: text/html;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

I agree with Mike, that if you have a =proper backup strategy, the problem should never occour. Ther are cases though where I =feel it's ok to truncate the log file, and that's if there has been some =unususal activity in the database. If you e.g. has merged 2 databases, that might =have made the logfile grow, but since this might be a "once in a lifetime" =thing that most likely won't happen again, it might be ok to tshrink the logfile =back to a decent size.
Regards
Steen
"Mike Hodgson" skrev i en meddelelse news:eBnOiOZcFHA.3712=@.TK2MSFTNGP12.phx.gbl...It's only running out of disk space because the original poster never backs =up the transaction log. If he just sets up a backup scheduled (or sets =the recovery mode to simple) then he shouldn't have any worries.
--mike =hodgson | database =administrator | mallesons =stephen jaquesT +61 (2) 9296 3668 | F +61 (2) 9296 3885 | M +61 (408) 675 907E mailto:mike.hodgson@.mal=lesons.nospam.com | W http://www.mallesons.com Hemant Goswami wrote: Yes Sir, Its not advisable to use
dbcc shrinkfile or
backup log 'dbname' with truncate_only -- Will truncate Log File
but as if problem is running out of space then at this moment it need to =shrink the file ?!! M i right ?
"David Portas" wrote:
No. It just means the space =can be re-used. It's not a good idea to
keep shrinking the transaction log because shrinking per se won't
reduce the storage requirement and auto-growing it again is a very
expensive operation. The way to control log file usage is to perform
regular transaction log backups and allocate a fixed, sustainable size
to the log.
-- David Portas SQL Server MVP --

--=_NextPart_000_0101_01C571B2.66267180--

Friday, March 30, 2012

Log on Problem.

Log on Problem.

Log on Problem.

Wednesday, March 28, 2012

Log Full

Log Full

Log Full

Log for tempdb is full

Log for tempdb is full

Log for tempdb is full

Log files WAY too big

Log files WAY too big

Log files WAY too big

Wednesday, March 21, 2012

Log file of test database bloating

Monday, March 19, 2012

Log file is Full: How to prevent it happening?

Log file is Full: How to prevent it happening?

Log file is Full: How to prevent it happening?

Log File is Full error: How to prevent this happening?

Log File Full -> Back up Transaction Log

Log File Full -> Back up Transaction Log

Log File Full -> Back up Transaction Log

Locks and Blocks

Blog Archive

About Me