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

Monday, March 19, 2012

back log dbname with no_log

Hi,

I'm issuing the following statements to reduce the size of transaction log, My database is in simple recovery mode:

CHECKPOINT

GO

backup log TMDATABASE with truncate_only

go

dbcc shrinkfile (TMDATABASE_Log,2)

GO

The log file size still remains the same. Even though there are no active or open transactions...

Any insight greatly appreciated....

Thanks,

Razi

Perhaps the Log file is at either its defined size, or there is no free space.

These are useful sources:

FileSize -How to stop the log file from growing
http://www.support.microsoft.com/?id=873235

FileSize -Log file filling up
http://www.support.microsoft.com/?id=110139

FileSize -Log File Grows too big
http://www.support.microsoft.com/?id=317375

FileSize -Log File issues
http://www.nigelrivett.net/TransactionLogFileGrows_1.html

Also refer to Books Online, Topic: 'DBCC ShrinkFile'.

The File Does Not Shrink

If the shrink operation runs without error, but the file does not appear to have changed in size, verify that the file has adequate free space to remove by performing one of the following operations:

Run the following query.

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB FROM sys.database_files;

Run the DBCC SQLPERF command to return the space used in the transaction log.

|||

Hi,

Thanks for the reply but my log is still not shrinking. I tried using

"DBCC SQLPERF(logspace)" which shows Logsize = 499.875 and Log used = 0.04083052 0

This database in under compatibilty mode 80.

Also tried altering database file sizes using the GUI and ALTER DATABASE command but that didnt work since the initial size was larger.

There are no current connections to the database. Any insight?

Regards,

Razi

Wednesday, March 7, 2012

AWE and set working set size

Hello everybody!
System description:
OS: Windows Server 2003 Enterprise Edition SP1
RAM: 16 Gb
SQL: SQL Server 2000 Enterprise Edition SP3
SQL Server has "awe enabled"=1 and "set working set size"=1 at the same time.
"Max server memory" is limited by 12 Gb. SQLServer:MemoryManager:Total
Server Memory counter shows that SQL Server consumes all of the 12 Gb memory.
Allmost every day the client receives ODBC error 1222 (lock timeout) even if
only one user is connected to the database.
BOL says that if "awe enabled"=1 memory is not swapped out by default.
www.microsoft.com says that if you change "set working set size" from its
default value it may involve 844 and 845 errors (page latch timeout).
So the questions are:
1. Can two simulaneously enabled options ("awe enabled" and "set working set
size") result in such conflict?
2. Can enabling set working set size result in ODBC error 1222?
Thank you
I don't know if that configuration will cause that error but I doubt it.
There is no reason to have SET Working Set Size set to 1 when you have AWE
since AWE in 2000 is not dynamic to begin with. AWE also allocates all the
memory up to the Max memory setting on startup. I would turn it off and see
if the errors go away and I see no need to have in on anyway.
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:CFCDD61D-ACE4-4C25-ABF1-50395C763B8E@.microsoft.com...
> Hello everybody!
> System description:
> OS: Windows Server 2003 Enterprise Edition SP1
> RAM: 16 Gb
> SQL: SQL Server 2000 Enterprise Edition SP3
> SQL Server has "awe enabled"=1 and "set working set size"=1 at the same
> time.
> "Max server memory" is limited by 12 Gb. SQLServer:MemoryManager:Total
> Server Memory counter shows that SQL Server consumes all of the 12 Gb
> memory.
> Allmost every day the client receives ODBC error 1222 (lock timeout) even
> if
> only one user is connected to the database.
> BOL says that if "awe enabled"=1 memory is not swapped out by default.
> www.microsoft.com says that if you change "set working set size" from its
> default value it may involve 844 and 845 errors (page latch timeout).
> So the questions are:
> 1. Can two simulaneously enabled options ("awe enabled" and "set working
> set
> size") result in such conflict?
> 2. Can enabling set working set size result in ODBC error 1222?
> Thank you
>
|||Thank you, Mr.Kelly. Before I read you answer I had decided to act by trial
and error and I advice to turn "working set size" off. My client informed me
that the error did not disappear but it got less frequent.
|||The Lock Timeout setting is infinite by default in SQL Server. IF they are
getting this message that means someone somewhere changed the setting. I
would look for any code that has SET LOCK_TIMEOUT in it and find out why and
what value they set it to.
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
> Thank you, Mr.Kelly. Before I read you answer I had decided to act by
> trial
> and error and I advice to turn "working set size" off. My client informed
> me
> that the error did not disappear but it got less frequent.
|||Yes, I see, but can only one user working with the server lock himself? I
mean there are situations when only one user works with the database but the
error occurs all the same.
"Andrew J. Kelly" wrote:

> The Lock Timeout setting is infinite by default in SQL Server. IF they are
> getting this message that means someone somewhere changed the setting. I
> would look for any code that has SET LOCK_TIMEOUT in it and find out why and
> what value they set it to.
> --
> Andrew J. Kelly SQL MVP
>
> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
> news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
>
>
|||Sure. If the user is trying to get an exclusive table lock there are lots of
things that can prevent him from getting one. I think you need to see the
code and why they are setting this and under what conditions it is
happening.
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:057E64D8-ED9F-4442-9623-FECE3BDB865E@.microsoft.com...[vbcol=seagreen]
> Yes, I see, but can only one user working with the server lock himself? I
> mean there are situations when only one user works with the database but
> the
> error occurs all the same.
> "Andrew J. Kelly" wrote:
|||There is a general interface setting which allow users to set time-out (via
the setting the code receives time interval for SET LOCK_TIMEOUT statement).
The only thing I'm going to recommend is to increase the value. Thank you,
Mr.Kelly, you have been very helpful.
"Andrew J. Kelly" wrote:

> Sure. If the user is trying to get an exclusive table lock there are lots of
> things that can prevent him from getting one. I think you need to see the
> code and why they are setting this and under what conditions it is
> happening.
> --
> Andrew J. Kelly SQL MVP
>
> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
> news:057E64D8-ED9F-4442-9623-FECE3BDB865E@.microsoft.com...
>
>

AWE and set working set size

Hello everybody!
System description:
OS: Windows Server 2003 Enterprise Edition SP1
RAM: 16 Gb
SQL: SQL Server 2000 Enterprise Edition SP3
SQL Server has "awe enabled"=1 and "set working set size"=1 at the same time.
"Max server memory" is limited by 12 Gb. SQLServer:MemoryManager:Total
Server Memory counter shows that SQL Server consumes all of the 12 Gb memory.
Allmost every day the client receives ODBC error 1222 (lock timeout) even if
only one user is connected to the database.
BOL says that if "awe enabled"=1 memory is not swapped out by default.
www.microsoft.com says that if you change "set working set size" from its
default value it may involve 844 and 845 errors (page latch timeout).
So the questions are:
1. Can two simulaneously enabled options ("awe enabled" and "set working set
size") result in such conflict?
2. Can enabling set working set size result in ODBC error 1222?
Thank youI don't know if that configuration will cause that error but I doubt it.
There is no reason to have SET Working Set Size set to 1 when you have AWE
since AWE in 2000 is not dynamic to begin with. AWE also allocates all the
memory up to the Max memory setting on startup. I would turn it off and see
if the errors go away and I see no need to have in on anyway.
--
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:CFCDD61D-ACE4-4C25-ABF1-50395C763B8E@.microsoft.com...
> Hello everybody!
> System description:
> OS: Windows Server 2003 Enterprise Edition SP1
> RAM: 16 Gb
> SQL: SQL Server 2000 Enterprise Edition SP3
> SQL Server has "awe enabled"=1 and "set working set size"=1 at the same
> time.
> "Max server memory" is limited by 12 Gb. SQLServer:MemoryManager:Total
> Server Memory counter shows that SQL Server consumes all of the 12 Gb
> memory.
> Allmost every day the client receives ODBC error 1222 (lock timeout) even
> if
> only one user is connected to the database.
> BOL says that if "awe enabled"=1 memory is not swapped out by default.
> www.microsoft.com says that if you change "set working set size" from its
> default value it may involve 844 and 845 errors (page latch timeout).
> So the questions are:
> 1. Can two simulaneously enabled options ("awe enabled" and "set working
> set
> size") result in such conflict?
> 2. Can enabling set working set size result in ODBC error 1222?
> Thank you
>|||Thank you, Mr.Kelly. Before I read you answer I had decided to act by trial
and error and I advice to turn "working set size" off. My client informed me
that the error did not disappear but it got less frequent.|||The Lock Timeout setting is infinite by default in SQL Server. IF they are
getting this message that means someone somewhere changed the setting. I
would look for any code that has SET LOCK_TIMEOUT in it and find out why and
what value they set it to.
--
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
> Thank you, Mr.Kelly. Before I read you answer I had decided to act by
> trial
> and error and I advice to turn "working set size" off. My client informed
> me
> that the error did not disappear but it got less frequent.|||Yes, I see, but can only one user working with the server lock himself? I
mean there are situations when only one user works with the database but the
error occurs all the same.
"Andrew J. Kelly" wrote:
> The Lock Timeout setting is infinite by default in SQL Server. IF they are
> getting this message that means someone somewhere changed the setting. I
> would look for any code that has SET LOCK_TIMEOUT in it and find out why and
> what value they set it to.
> --
> Andrew J. Kelly SQL MVP
>
> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
> news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
> > Thank you, Mr.Kelly. Before I read you answer I had decided to act by
> > trial
> > and error and I advice to turn "working set size" off. My client informed
> > me
> > that the error did not disappear but it got less frequent.
>
>|||Sure. If the user is trying to get an exclusive table lock there are lots of
things that can prevent him from getting one. I think you need to see the
code and why they are setting this and under what conditions it is
happening.
--
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:057E64D8-ED9F-4442-9623-FECE3BDB865E@.microsoft.com...
> Yes, I see, but can only one user working with the server lock himself? I
> mean there are situations when only one user works with the database but
> the
> error occurs all the same.
> "Andrew J. Kelly" wrote:
>> The Lock Timeout setting is infinite by default in SQL Server. IF they
>> are
>> getting this message that means someone somewhere changed the setting. I
>> would look for any code that has SET LOCK_TIMEOUT in it and find out why
>> and
>> what value they set it to.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
>> news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
>> > Thank you, Mr.Kelly. Before I read you answer I had decided to act by
>> > trial
>> > and error and I advice to turn "working set size" off. My client
>> > informed
>> > me
>> > that the error did not disappear but it got less frequent.
>>|||There is a general interface setting which allow users to set time-out (via
the setting the code receives time interval for SET LOCK_TIMEOUT statement).
The only thing I'm going to recommend is to increase the value. Thank you,
Mr.Kelly, you have been very helpful.
"Andrew J. Kelly" wrote:
> Sure. If the user is trying to get an exclusive table lock there are lots of
> things that can prevent him from getting one. I think you need to see the
> code and why they are setting this and under what conditions it is
> happening.
> --
> Andrew J. Kelly SQL MVP
>
> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
> news:057E64D8-ED9F-4442-9623-FECE3BDB865E@.microsoft.com...
> > Yes, I see, but can only one user working with the server lock himself? I
> > mean there are situations when only one user works with the database but
> > the
> > error occurs all the same.
> >
> > "Andrew J. Kelly" wrote:
> >
> >> The Lock Timeout setting is infinite by default in SQL Server. IF they
> >> are
> >> getting this message that means someone somewhere changed the setting. I
> >> would look for any code that has SET LOCK_TIMEOUT in it and find out why
> >> and
> >> what value they set it to.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
> >> news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
> >> > Thank you, Mr.Kelly. Before I read you answer I had decided to act by
> >> > trial
> >> > and error and I advice to turn "working set size" off. My client
> >> > informed
> >> > me
> >> > that the error did not disappear but it got less frequent.
> >>
> >>
> >>
>
>

AWE and set working set size

Hello everybody!
System description:
OS: Windows Server 2003 Enterprise Edition SP1
RAM: 16 Gb
SQL: SQL Server 2000 Enterprise Edition SP3
SQL Server has "awe enabled"=1 and "set working set size"=1 at the same time
.
"Max server memory" is limited by 12 Gb. SQLServer:MemoryManager:Total
Server Memory counter shows that SQL Server consumes all of the 12 Gb memory
.
Allmost every day the client receives ODBC error 1222 (lock timeout) even if
only one user is connected to the database.
BOL says that if "awe enabled"=1 memory is not swapped out by default.
www.microsoft.com says that if you change "set working set size" from its
default value it may involve 844 and 845 errors (page latch timeout).
So the questions are:
1. Can two simulaneously enabled options ("awe enabled" and "set working set
size") result in such conflict?
2. Can enabling set working set size result in ODBC error 1222?
Thank youI don't know if that configuration will cause that error but I doubt it.
There is no reason to have SET Working Set Size set to 1 when you have AWE
since AWE in 2000 is not dynamic to begin with. AWE also allocates all the
memory up to the Max memory setting on startup. I would turn it off and see
if the errors go away and I see no need to have in on anyway.
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:CFCDD61D-ACE4-4C25-ABF1-50395C763B8E@.microsoft.com...
> Hello everybody!
> System description:
> OS: Windows Server 2003 Enterprise Edition SP1
> RAM: 16 Gb
> SQL: SQL Server 2000 Enterprise Edition SP3
> SQL Server has "awe enabled"=1 and "set working set size"=1 at the same
> time.
> "Max server memory" is limited by 12 Gb. SQLServer:MemoryManager:Total
> Server Memory counter shows that SQL Server consumes all of the 12 Gb
> memory.
> Allmost every day the client receives ODBC error 1222 (lock timeout) even
> if
> only one user is connected to the database.
> BOL says that if "awe enabled"=1 memory is not swapped out by default.
> www.microsoft.com says that if you change "set working set size" from its
> default value it may involve 844 and 845 errors (page latch timeout).
> So the questions are:
> 1. Can two simulaneously enabled options ("awe enabled" and "set working
> set
> size") result in such conflict?
> 2. Can enabling set working set size result in ODBC error 1222?
> Thank you
>|||Thank you, Mr.Kelly. Before I read you answer I had decided to act by trial
and error and I advice to turn "working set size" off. My client informed me
that the error did not disappear but it got less frequent.|||The Lock Timeout setting is infinite by default in SQL Server. IF they are
getting this message that means someone somewhere changed the setting. I
would look for any code that has SET LOCK_TIMEOUT in it and find out why and
what value they set it to.
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
> Thank you, Mr.Kelly. Before I read you answer I had decided to act by
> trial
> and error and I advice to turn "working set size" off. My client informed
> me
> that the error did not disappear but it got less frequent.|||Yes, I see, but can only one user working with the server lock himself? I
mean there are situations when only one user works with the database but the
error occurs all the same.
"Andrew J. Kelly" wrote:

> The Lock Timeout setting is infinite by default in SQL Server. IF they are
> getting this message that means someone somewhere changed the setting. I
> would look for any code that has SET LOCK_TIMEOUT in it and find out why a
nd
> what value they set it to.
> --
> Andrew J. Kelly SQL MVP
>
> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
> news:69717477-0287-4FB8-9F65-96168F25F2BB@.microsoft.com...
>
>|||Sure. If the user is trying to get an exclusive table lock there are lots of
things that can prevent him from getting one. I think you need to see the
code and why they are setting this and under what conditions it is
happening.
Andrew J. Kelly SQL MVP
"RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
news:057E64D8-ED9F-4442-9623-FECE3BDB865E@.microsoft.com...[vbcol=seagreen]
> Yes, I see, but can only one user working with the server lock himself? I
> mean there are situations when only one user works with the database but
> the
> error occurs all the same.
> "Andrew J. Kelly" wrote:
>|||There is a general interface setting which allow users to set time-out (via
the setting the code receives time interval for SET LOCK_TIMEOUT statement).
The only thing I'm going to recommend is to increase the value. Thank you,
Mr.Kelly, you have been very helpful.
"Andrew J. Kelly" wrote:

> Sure. If the user is trying to get an exclusive table lock there are lots
of
> things that can prevent him from getting one. I think you need to see the
> code and why they are setting this and under what conditions it is
> happening.
> --
> Andrew J. Kelly SQL MVP
>
> "RDBSAdmin" <RDBSAdmin@.discussions.microsoft.com> wrote in message
> news:057E64D8-ED9F-4442-9623-FECE3BDB865E@.microsoft.com...
>
>

Sunday, February 12, 2012

Autoshrink Log

Hello: I have a Database with a file log of 75 Mb which I have increased to 150 MB, but when i execute a "backup log with no_log" the size is returned to the initial size, I must mention that autoshrink is disabled.
:confused:with no_log or truncate_only they will only remove the checkpointed transactions in the log, it will not reduce the footprint (file size). If you need to shrink the file use dbcc shrinkfile. But be careful in this as if your log regularly has to grow, you are hurting your performance by constantly shrinking it.

HTH|||Hi :

I know that, but my problem is that i dont want to "shrink" the file but when i execute "Backup log" the file log is "shrinked".|||What syntax did you use to increase it?|||I'm executing "Backup Log NAME with no_log".

Results : Truncate the log and my file log that i increased to 150 Mb is decresed to the initial size of 75 Mb.

:confused:|||What syntax did you use to increase the transaction log?|||I'm using Enterprise Manager.|||I ran this multiple times and with simple and full recovery mode and can not duplicate what you are experiencing. If you can do what you are trying to do in SQL, plese post it, if you do not, run profiler while you make your changes in EM. See if this helps at all:

create database testing
use testing
dbcc sqlperf('logspace')

alter database testing
modify file
(NAME = testing_log,
SIZE = 20MB)

dbcc sqlperf ('logspace')

backup log testing with no_log

dbcc sqlperf ('logspace')|||I know that you can't duplicate my experience, that's why is a problem. but thats happen sometimes in SQL 7.0.

AutoShrink

Hi!
I have a question about the log file of my db, it
increases day by day of a lot of MB!!
To reduce its size I make the back up of transaction log
and then the Shink db tasks by Enterprise Manager.
I wonder if I check to true the option Auto Shrink on the
tab Option of the my db's properties, I get the same
result.
the Help sais that if this check is valued true, the
server periodically make the shrink...but "periodically"
means WHAT? and the resize would be the same I obtain with
the statements?
Thanks!If your log is legitimately growing, don't use auto-shrink, it will just
hurt your performance in your most active times of the day. If you do not
require point in time recovery, use simple mode.
HTH
--
Ray Higdon MCSE, MCDBA, CCNA
--
"milena" <anonymous@.discussions.microsoft.com> wrote in message
news:955b01c3eb00$94202d90$a301280a@.phx.gbl...
> Hi!
> I have a question about the log file of my db, it
> increases day by day of a lot of MB!!
> To reduce its size I make the back up of transaction log
> and then the Shink db tasks by Enterprise Manager.
> I wonder if I check to true the option Auto Shrink on the
> tab Option of the my db's properties, I get the same
> result.
> the Help sais that if this check is valued true, the
> server periodically make the shrink...but "periodically"
> means WHAT? and the resize would be the same I obtain with
> the statements?
> Thanks!
>|||The tran log will be truncated "periodically" when the database is in
simple recovery mode... The process that does this is the checkpoint
process. You may adjust the frequency of checkpoints ( and the log
truncation ) using sp_configure "recovery interval". The default setting
causes this to occur every minute.
"milena" <anonymous@.discussions.microsoft.com> wrote in message
news:955b01c3eb00$94202d90$a301280a@.phx.gbl...
> Hi!
> I have a question about the log file of my db, it
> increases day by day of a lot of MB!!
> To reduce its size I make the back up of transaction log
> and then the Shink db tasks by Enterprise Manager.
> I wonder if I check to true the option Auto Shrink on the
> tab Option of the my db's properties, I get the same
> result.
> the Help sais that if this check is valued true, the
> server periodically make the shrink...but "periodically"
> means WHAT? and the resize would be the same I obtain with
> the statements?
> Thanks!
>|||Hi
SQL Server execute Shrink Method for remove unused pages. All depend of how You have the RECOVERY MODEL of the SQL Server, dependding on this its grow your log file
FULL: Save all information about transaction
SIMPLE: Only Save the neeseraly importan
SQL Server only can Shrink the Space Free, this depends on the Checkpoints the SQL Server, and this goes associated to BACKUP Process
The AutoShrink is not very good. It is better than executing for Transact-SQL with a Work, and thus your you can determine when this task is executed.
The AutoShrink is not very good. It is better than executing for Transact-SQL with a Job, and thus your you can determine when this task is executed
Look -> Books Online -> Index [Shrinking a Database
Look -> Books Online -> Index [Selecting a Recovery Model
Hermilson Tinoco

AutoShrink

Hi!
I have a question about the log file of my db, it
increases day by day of a lot of MB!!
To reduce its size I make the back up of transaction log
and then the Shink db tasks by Enterprise Manager.
I wonder if I check to true the option Auto Shrink on the
tab Option of the my db's properties, I get the same
result.
the Help sais that if this check is valued true, the
server periodically make the shrink...but "periodically"
means WHAT? and the resize would be the same I obtain with
the statements?
Thanks!If your log is legitimately growing, don't use auto-shrink, it will just
hurt your performance in your most active times of the day. If you do not
require point in time recovery, use simple mode.
HTH
Ray Higdon MCSE, MCDBA, CCNA
--
"milena" <anonymous@.discussions.microsoft.com> wrote in message
news:955b01c3eb00$94202d90$a301280a@.phx.gbl...
quote:

> Hi!
> I have a question about the log file of my db, it
> increases day by day of a lot of MB!!
> To reduce its size I make the back up of transaction log
> and then the Shink db tasks by Enterprise Manager.
> I wonder if I check to true the option Auto Shrink on the
> tab Option of the my db's properties, I get the same
> result.
> the Help sais that if this check is valued true, the
> server periodically make the shrink...but "periodically"
> means WHAT? and the resize would be the same I obtain with
> the statements?
> Thanks!
>
|||The tran log will be truncated "periodically" when the database is in
simple recovery mode... The process that does this is the checkpoint
process. You may adjust the frequency of checkpoints ( and the log
truncation ) using sp_configure "recovery interval". The default setting
causes this to occur every minute.
"milena" <anonymous@.discussions.microsoft.com> wrote in message
news:955b01c3eb00$94202d90$a301280a@.phx.gbl...
quote:

> Hi!
> I have a question about the log file of my db, it
> increases day by day of a lot of MB!!
> To reduce its size I make the back up of transaction log
> and then the Shink db tasks by Enterprise Manager.
> I wonder if I check to true the option Auto Shrink on the
> tab Option of the my db's properties, I get the same
> result.
> the Help sais that if this check is valued true, the
> server periodically make the shrink...but "periodically"
> means WHAT? and the resize would be the same I obtain with
> the statements?
> Thanks!
>
|||Hi.
SQL Server execute Shrink Method for remove unused pages. All depend of how
You have the RECOVERY MODEL of the SQL Server, dependding on this its grow y
our log file.
FULL: Save all information about transactions
SIMPLE: Only Save the neeseraly important
SQL Server only can Shrink the Space Free, this depends on the Checkpoints t
he SQL Server, and this goes associated to BACKUP Process.
The AutoShrink is not very good. It is better than executing for Transact-S
QL with a Work, and thus your you can determine when this task is executed.
The AutoShrink is not very good. It is better than executing for Transact-SQ
L with a Job, and thus your you can determine when this task is executed.
Look -> Books Online -> Index [Shrinking a Database ]
Look -> Books Online -> Index [Selecting a Recovery Model]
Hermilson Tinoco