Using sql server 2000...
We are having issues with growing transaction log files...
Is the following a safe practice ?
Assume you create a "full" backup job using the Database Maintenance plan
wizard... This will create Step 1 in an SQL Job.
Would it be safe to add the following code as a step that was executed "on
success" of the first...
Use DatabaseName
BACKUP LOG DatabaseNameWITH NO_LOG
DBCC SHRINKFILE(DatabaseName_Log,10)
GORob
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"Rob" <robc1@.yahoo.com> wrote in message
news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.co
mcast.com...
> Using sql server 2000...
> We are having issues with growing transaction log files...
> Is the following a safe practice ?
> Assume you create a "full" backup job using the Database Maintenance plan
> wizard... This will create Step 1 in an SQL Job.
> Would it be safe to add the following code as a step that was executed
> "on success" of the first...
> Use DatabaseName
> BACKUP LOG DatabaseNameWITH NO_LOG
> DBCC SHRINKFILE(DatabaseName_Log,10)
> GO
>|||Thanks Uri,
But I still need an interpreter...
Left unchecked, the Log file appears to grow and fill up space on the
server. My assumption, is that IF a good full backup has been successful,
then it should be OK to use SHRINKFILE to lose the transaction file. At
that point, there would be no need to restore a transaction log file...
BTW - I never use shrinkdatabase
Rob
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
> Rob
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.co
mcast.com...
>|||Rob
If you have database is set up withj FULL RECOVERY mode then in order to
control a physical size of the LOG file , you need to BACKUP LOG ...
command, otherwise set up the database with SIMPLE recovery mode and the SQL
Server will take care for it.
If you implement BACKUP LOG file you probably won't lose the data if the
database get corrupted , please make sure what is your/or your boss
requirements.
"Rob" <robc1@.yahoo.com> wrote in message
news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.co
mcast.com...
> Thanks Uri,
> But I still need an interpreter...
> Left unchecked, the Log file appears to grow and fill up space on the
> server. My assumption, is that IF a good full backup has been successful,
> then it should be OK to use SHRINKFILE to lose the transaction file. At
> that point, there would be no need to restore a transaction log file...
> BTW - I never use shrinkdatabase
> Rob
>
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
>|||Hello,
To add on to Uri, perform the transaction log backup in regular intervals
(say 15 minutes), this will make sure that your
log (LDF) file will not grow. Shrinking the LDF life after the log backup is
not a good approch, this will shrino the
LDF file and after each DML operation file will autogrow and this will take
consifderable amount of I/O resources.
One more thing is you can archive all your transaction log backup files
which was taken before the
last full database backup.
Thanks
Hari
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:eMZ9F$5bHHA.4012@.TK2MSFTNGP03.phx.gbl...
> Rob
> If you have database is set up withj FULL RECOVERY mode then in order to
> control a physical size of the LOG file , you need to BACKUP LOG ...
> command, otherwise set up the database with SIMPLE recovery mode and the
> SQL Server will take care for it.
>
> If you implement BACKUP LOG file you probably won't lose the data if the
> database get corrupted , please make sure what is your/or your boss
> requirements.
>
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.co
mcast.com...
>
Showing posts with label growing. Show all posts
Showing posts with label growing. Show all posts
Monday, March 19, 2012
Backup question
Using sql server 2000...
We are having issues with growing transaction log files...
Is the following a safe practice ?
Assume you create a "full" backup job using the Database Maintenance plan
wizard... This will create Step 1 in an SQL Job.
Would it be safe to add the following code as a step that was executed "on
success" of the first...
Use DatabaseName
BACKUP LOG DatabaseNameWITH NO_LOG
DBCC SHRINKFILE(DatabaseName_Log,10)
GO
Rob
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"Rob" <robc1@.yahoo.com> wrote in message
news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com. ..
> Using sql server 2000...
> We are having issues with growing transaction log files...
> Is the following a safe practice ?
> Assume you create a "full" backup job using the Database Maintenance plan
> wizard... This will create Step 1 in an SQL Job.
> Would it be safe to add the following code as a step that was executed
> "on success" of the first...
> Use DatabaseName
> BACKUP LOG DatabaseNameWITH NO_LOG
> DBCC SHRINKFILE(DatabaseName_Log,10)
> GO
>
|||Thanks Uri,
But I still need an interpreter...
Left unchecked, the Log file appears to grow and fill up space on the
server. My assumption, is that IF a good full backup has been successful,
then it should be OK to use SHRINKFILE to lose the transaction file. At
that point, there would be no need to restore a transaction log file...
BTW - I never use shrinkdatabase
Rob
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
> Rob
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com. ..
>
|||Rob
If you have database is set up withj FULL RECOVERY mode then in order to
control a physical size of the LOG file , you need to BACKUP LOG ...
command, otherwise set up the database with SIMPLE recovery mode and the SQL
Server will take care for it.
If you implement BACKUP LOG file you probably won't lose the data if the
database get corrupted , please make sure what is your/or your boss
requirements.
"Rob" <robc1@.yahoo.com> wrote in message
news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com. ..
> Thanks Uri,
> But I still need an interpreter...
> Left unchecked, the Log file appears to grow and fill up space on the
> server. My assumption, is that IF a good full backup has been successful,
> then it should be OK to use SHRINKFILE to lose the transaction file. At
> that point, there would be no need to restore a transaction log file...
> BTW - I never use shrinkdatabase
> Rob
>
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
>
|||Hello,
To add on to Uri, perform the transaction log backup in regular intervals
(say 15 minutes), this will make sure that your
log (LDF) file will not grow. Shrinking the LDF life after the log backup is
not a good approch, this will shrino the
LDF file and after each DML operation file will autogrow and this will take
consifderable amount of I/O resources.
One more thing is you can archive all your transaction log backup files
which was taken before the
last full database backup.
Thanks
Hari
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:eMZ9F$5bHHA.4012@.TK2MSFTNGP03.phx.gbl...
> Rob
> If you have database is set up withj FULL RECOVERY mode then in order to
> control a physical size of the LOG file , you need to BACKUP LOG ...
> command, otherwise set up the database with SIMPLE recovery mode and the
> SQL Server will take care for it.
>
> If you implement BACKUP LOG file you probably won't lose the data if the
> database get corrupted , please make sure what is your/or your boss
> requirements.
>
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com. ..
>
|||i need to creat a log.ldf file . i am only having the Data.Mdf file with me. I does'nt want to attach the database but i want to only create the log.ldf file how can i creat it.
EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com
We are having issues with growing transaction log files...
Is the following a safe practice ?
Assume you create a "full" backup job using the Database Maintenance plan
wizard... This will create Step 1 in an SQL Job.
Would it be safe to add the following code as a step that was executed "on
success" of the first...
Use DatabaseName
BACKUP LOG DatabaseNameWITH NO_LOG
DBCC SHRINKFILE(DatabaseName_Log,10)
GO
Rob
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"Rob" <robc1@.yahoo.com> wrote in message
news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com. ..
> Using sql server 2000...
> We are having issues with growing transaction log files...
> Is the following a safe practice ?
> Assume you create a "full" backup job using the Database Maintenance plan
> wizard... This will create Step 1 in an SQL Job.
> Would it be safe to add the following code as a step that was executed
> "on success" of the first...
> Use DatabaseName
> BACKUP LOG DatabaseNameWITH NO_LOG
> DBCC SHRINKFILE(DatabaseName_Log,10)
> GO
>
|||Thanks Uri,
But I still need an interpreter...
Left unchecked, the Log file appears to grow and fill up space on the
server. My assumption, is that IF a good full backup has been successful,
then it should be OK to use SHRINKFILE to lose the transaction file. At
that point, there would be no need to restore a transaction log file...
BTW - I never use shrinkdatabase
Rob
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
> Rob
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com. ..
>
|||Rob
If you have database is set up withj FULL RECOVERY mode then in order to
control a physical size of the LOG file , you need to BACKUP LOG ...
command, otherwise set up the database with SIMPLE recovery mode and the SQL
Server will take care for it.
If you implement BACKUP LOG file you probably won't lose the data if the
database get corrupted , please make sure what is your/or your boss
requirements.
"Rob" <robc1@.yahoo.com> wrote in message
news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com. ..
> Thanks Uri,
> But I still need an interpreter...
> Left unchecked, the Log file appears to grow and fill up space on the
> server. My assumption, is that IF a good full backup has been successful,
> then it should be OK to use SHRINKFILE to lose the transaction file. At
> that point, there would be no need to restore a transaction log file...
> BTW - I never use shrinkdatabase
> Rob
>
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
>
|||Hello,
To add on to Uri, perform the transaction log backup in regular intervals
(say 15 minutes), this will make sure that your
log (LDF) file will not grow. Shrinking the LDF life after the log backup is
not a good approch, this will shrino the
LDF file and after each DML operation file will autogrow and this will take
consifderable amount of I/O resources.
One more thing is you can archive all your transaction log backup files
which was taken before the
last full database backup.
Thanks
Hari
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:eMZ9F$5bHHA.4012@.TK2MSFTNGP03.phx.gbl...
> Rob
> If you have database is set up withj FULL RECOVERY mode then in order to
> control a physical size of the LOG file , you need to BACKUP LOG ...
> command, otherwise set up the database with SIMPLE recovery mode and the
> SQL Server will take care for it.
>
> If you implement BACKUP LOG file you probably won't lose the data if the
> database get corrupted , please make sure what is your/or your boss
> requirements.
>
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com. ..
>
|||i need to creat a log.ldf file . i am only having the Data.Mdf file with me. I does'nt want to attach the database but i want to only create the log.ldf file how can i creat it.
EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com
Backup question
Using sql server 2000...
We are having issues with growing transaction log files...
Is the following a safe practice ?
Assume you create a "full" backup job using the Database Maintenance plan
wizard... This will create Step 1 in an SQL Job.
Would it be safe to add the following code as a step that was executed "on
success" of the first...
Use DatabaseName
BACKUP LOG DatabaseNameWITH NO_LOG
DBCC SHRINKFILE(DatabaseName_Log,10)
GORob
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"Rob" <robc1@.yahoo.com> wrote in message
news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
> Using sql server 2000...
> We are having issues with growing transaction log files...
> Is the following a safe practice ?
> Assume you create a "full" backup job using the Database Maintenance plan
> wizard... This will create Step 1 in an SQL Job.
> Would it be safe to add the following code as a step that was executed
> "on success" of the first...
> Use DatabaseName
> BACKUP LOG DatabaseNameWITH NO_LOG
> DBCC SHRINKFILE(DatabaseName_Log,10)
> GO
>|||Thanks Uri,
But I still need an interpreter...
Left unchecked, the Log file appears to grow and fill up space on the
server. My assumption, is that IF a good full backup has been successful,
then it should be OK to use SHRINKFILE to lose the transaction file. At
that point, there would be no need to restore a transaction log file...
BTW - I never use shrinkdatabase
Rob
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
> Rob
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
>> Using sql server 2000...
>> We are having issues with growing transaction log files...
>> Is the following a safe practice ?
>> Assume you create a "full" backup job using the Database Maintenance plan
>> wizard... This will create Step 1 in an SQL Job.
>> Would it be safe to add the following code as a step that was executed
>> "on success" of the first...
>> Use DatabaseName
>> BACKUP LOG DatabaseNameWITH NO_LOG
>> DBCC SHRINKFILE(DatabaseName_Log,10)
>> GO
>|||Rob
If you have database is set up withj FULL RECOVERY mode then in order to
control a physical size of the LOG file , you need to BACKUP LOG ...
command, otherwise set up the database with SIMPLE recovery mode and the SQL
Server will take care for it.
If you implement BACKUP LOG file you probably won't lose the data if the
database get corrupted , please make sure what is your/or your boss
requirements.
"Rob" <robc1@.yahoo.com> wrote in message
news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com...
> Thanks Uri,
> But I still need an interpreter...
> Left unchecked, the Log file appears to grow and fill up space on the
> server. My assumption, is that IF a good full backup has been successful,
> then it should be OK to use SHRINKFILE to lose the transaction file. At
> that point, there would be no need to restore a transaction log file...
> BTW - I never use shrinkdatabase
> Rob
>
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
>> Rob
>> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>>
>>
>> "Rob" <robc1@.yahoo.com> wrote in message
>> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
>> Using sql server 2000...
>> We are having issues with growing transaction log files...
>> Is the following a safe practice ?
>> Assume you create a "full" backup job using the Database Maintenance
>> plan wizard... This will create Step 1 in an SQL Job.
>> Would it be safe to add the following code as a step that was executed
>> "on success" of the first...
>> Use DatabaseName
>> BACKUP LOG DatabaseNameWITH NO_LOG
>> DBCC SHRINKFILE(DatabaseName_Log,10)
>> GO
>>
>|||Hello,
To add on to Uri, perform the transaction log backup in regular intervals
(say 15 minutes), this will make sure that your
log (LDF) file will not grow. Shrinking the LDF life after the log backup is
not a good approch, this will shrino the
LDF file and after each DML operation file will autogrow and this will take
consifderable amount of I/O resources.
One more thing is you can archive all your transaction log backup files
which was taken before the
last full database backup.
Thanks
Hari
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:eMZ9F$5bHHA.4012@.TK2MSFTNGP03.phx.gbl...
> Rob
> If you have database is set up withj FULL RECOVERY mode then in order to
> control a physical size of the LOG file , you need to BACKUP LOG ...
> command, otherwise set up the database with SIMPLE recovery mode and the
> SQL Server will take care for it.
>
> If you implement BACKUP LOG file you probably won't lose the data if the
> database get corrupted , please make sure what is your/or your boss
> requirements.
>
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com...
>> Thanks Uri,
>> But I still need an interpreter...
>> Left unchecked, the Log file appears to grow and fill up space on the
>> server. My assumption, is that IF a good full backup has been
>> successful, then it should be OK to use SHRINKFILE to lose the
>> transaction file. At that point, there would be no need to restore a
>> transaction log file...
>> BTW - I never use shrinkdatabase
>> Rob
>>
>> "Uri Dimant" <urid@.iscar.co.il> wrote in message
>> news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
>> Rob
>> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>>
>>
>> "Rob" <robc1@.yahoo.com> wrote in message
>> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
>> Using sql server 2000...
>> We are having issues with growing transaction log files...
>> Is the following a safe practice ?
>> Assume you create a "full" backup job using the Database Maintenance
>> plan wizard... This will create Step 1 in an SQL Job.
>> Would it be safe to add the following code as a step that was executed
>> "on success" of the first...
>> Use DatabaseName
>> BACKUP LOG DatabaseNameWITH NO_LOG
>> DBCC SHRINKFILE(DatabaseName_Log,10)
>> GO
>>
>>
>|||i need to creat a log.ldf file . i am only having the Data.Mdf file with me. I does'nt want to attach the database but i want to only create the log.ldf file how can i creat it.
EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com
We are having issues with growing transaction log files...
Is the following a safe practice ?
Assume you create a "full" backup job using the Database Maintenance plan
wizard... This will create Step 1 in an SQL Job.
Would it be safe to add the following code as a step that was executed "on
success" of the first...
Use DatabaseName
BACKUP LOG DatabaseNameWITH NO_LOG
DBCC SHRINKFILE(DatabaseName_Log,10)
GORob
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"Rob" <robc1@.yahoo.com> wrote in message
news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
> Using sql server 2000...
> We are having issues with growing transaction log files...
> Is the following a safe practice ?
> Assume you create a "full" backup job using the Database Maintenance plan
> wizard... This will create Step 1 in an SQL Job.
> Would it be safe to add the following code as a step that was executed
> "on success" of the first...
> Use DatabaseName
> BACKUP LOG DatabaseNameWITH NO_LOG
> DBCC SHRINKFILE(DatabaseName_Log,10)
> GO
>|||Thanks Uri,
But I still need an interpreter...
Left unchecked, the Log file appears to grow and fill up space on the
server. My assumption, is that IF a good full backup has been successful,
then it should be OK to use SHRINKFILE to lose the transaction file. At
that point, there would be no need to restore a transaction log file...
BTW - I never use shrinkdatabase
Rob
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
> Rob
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
>> Using sql server 2000...
>> We are having issues with growing transaction log files...
>> Is the following a safe practice ?
>> Assume you create a "full" backup job using the Database Maintenance plan
>> wizard... This will create Step 1 in an SQL Job.
>> Would it be safe to add the following code as a step that was executed
>> "on success" of the first...
>> Use DatabaseName
>> BACKUP LOG DatabaseNameWITH NO_LOG
>> DBCC SHRINKFILE(DatabaseName_Log,10)
>> GO
>|||Rob
If you have database is set up withj FULL RECOVERY mode then in order to
control a physical size of the LOG file , you need to BACKUP LOG ...
command, otherwise set up the database with SIMPLE recovery mode and the SQL
Server will take care for it.
If you implement BACKUP LOG file you probably won't lose the data if the
database get corrupted , please make sure what is your/or your boss
requirements.
"Rob" <robc1@.yahoo.com> wrote in message
news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com...
> Thanks Uri,
> But I still need an interpreter...
> Left unchecked, the Log file appears to grow and fill up space on the
> server. My assumption, is that IF a good full backup has been successful,
> then it should be OK to use SHRINKFILE to lose the transaction file. At
> that point, there would be no need to restore a transaction log file...
> BTW - I never use shrinkdatabase
> Rob
>
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
>> Rob
>> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>>
>>
>> "Rob" <robc1@.yahoo.com> wrote in message
>> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
>> Using sql server 2000...
>> We are having issues with growing transaction log files...
>> Is the following a safe practice ?
>> Assume you create a "full" backup job using the Database Maintenance
>> plan wizard... This will create Step 1 in an SQL Job.
>> Would it be safe to add the following code as a step that was executed
>> "on success" of the first...
>> Use DatabaseName
>> BACKUP LOG DatabaseNameWITH NO_LOG
>> DBCC SHRINKFILE(DatabaseName_Log,10)
>> GO
>>
>|||Hello,
To add on to Uri, perform the transaction log backup in regular intervals
(say 15 minutes), this will make sure that your
log (LDF) file will not grow. Shrinking the LDF life after the log backup is
not a good approch, this will shrino the
LDF file and after each DML operation file will autogrow and this will take
consifderable amount of I/O resources.
One more thing is you can archive all your transaction log backup files
which was taken before the
last full database backup.
Thanks
Hari
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:eMZ9F$5bHHA.4012@.TK2MSFTNGP03.phx.gbl...
> Rob
> If you have database is set up withj FULL RECOVERY mode then in order to
> control a physical size of the LOG file , you need to BACKUP LOG ...
> command, otherwise set up the database with SIMPLE recovery mode and the
> SQL Server will take care for it.
>
> If you implement BACKUP LOG file you probably won't lose the data if the
> database get corrupted , please make sure what is your/or your boss
> requirements.
>
>
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:bPidnfI0R4aaK5rbnZ2dnUVZ_hmtnZ2d@.comcast.com...
>> Thanks Uri,
>> But I still need an interpreter...
>> Left unchecked, the Log file appears to grow and fill up space on the
>> server. My assumption, is that IF a good full backup has been
>> successful, then it should be OK to use SHRINKFILE to lose the
>> transaction file. At that point, there would be no need to restore a
>> transaction log file...
>> BTW - I never use shrinkdatabase
>> Rob
>>
>> "Uri Dimant" <urid@.iscar.co.il> wrote in message
>> news:uyC4Ho5bHHA.4716@.TK2MSFTNGP02.phx.gbl...
>> Rob
>> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>>
>>
>> "Rob" <robc1@.yahoo.com> wrote in message
>> news:ANudneEo7LraMJrbnZ2dnUVZ_segnZ2d@.comcast.com...
>> Using sql server 2000...
>> We are having issues with growing transaction log files...
>> Is the following a safe practice ?
>> Assume you create a "full" backup job using the Database Maintenance
>> plan wizard... This will create Step 1 in an SQL Job.
>> Would it be safe to add the following code as a step that was executed
>> "on success" of the first...
>> Use DatabaseName
>> BACKUP LOG DatabaseNameWITH NO_LOG
>> DBCC SHRINKFILE(DatabaseName_Log,10)
>> GO
>>
>>
>|||i need to creat a log.ldf file . i am only having the Data.Mdf file with me. I does'nt want to attach the database but i want to only create the log.ldf file how can i creat it.
EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com
Friday, February 10, 2012
backup file to big
I have a database who's SQL Server backup file has been hovering around 33MB
and has been growing only a few hundred kilobytes week for a couple years.
I have since added a catalog and indexed a couple of tables and now this
database and another one on the server--that should be unrelated--have
backup files that are 140 and 170MB each. The indexes are really not that
big. The catalog is only about 20MB.
First, why would a 20MB catalog increase the size of this database so much.
Second, why would a catalog in one database affect one in another (if that's
what's really happening)
Third, how can I do a tally of the database elements that should comprise
the total so I can find out the true cause of the increase. Counting the
tables size in K + the indexes does not give me this huge file size.
_____
DC G
DC G,
Assuming that you're using SQL Sever 7.0 or SQL Server 2000 and no other
logged activity has occurred in the same database that you created the FT
Catalog and ran a Full Population, as the affect of only doing this type of
"read only" process should not of contributed to the growth in the size of
your database backup. Indeed, this has been one of the long outstanding
issues, i.e.. to include the FT Catalog with the database backup, that is
not included in either SQL 7.0 or 2000, but is only available as a new
feature in SQL Server 2005 (Yukon).
Q. why would a 20MB catalog increase the size of this database so much?
A. It should not. Did you make any other database &/or table changes? For
example alter a table and add a timestamp or other new column?
Q. why would a catalog in one database affect one in another?
A. It should not. Did you make any database changes &/or table schema
changes to either database?
Q. how can I do a tally of the database elements that should comprise the
total so I can find out the true cause of the increase?
A. You can use sp_spaceused or as well as the Enterprise Manager and the
Profiler.
FYI, for a KB article on how to Backup Full-Text Catalog Folders and Files,
see 240867 (Q240867) "INF: How to Move, Copy, and Backup Full-Text Catalog
Folders and Files" at
http://support.microsoft.com/default...b;EN-US;240867
Regards,
John
"DC Gringo" <dcgringo@.visiontechnology.net> wrote in message
news:ur3L#n92EHA.3596@.TK2MSFTNGP12.phx.gbl...
> I have a database who's SQL Server backup file has been hovering around
33MB
> and has been growing only a few hundred kilobytes week for a couple years.
> I have since added a catalog and indexed a couple of tables and now this
> database and another one on the server--that should be unrelated--have
> backup files that are 140 and 170MB each. The indexes are really not that
> big. The catalog is only about 20MB.
> First, why would a 20MB catalog increase the size of this database so
much.
> Second, why would a catalog in one database affect one in another (if
that's
> what's really happening)
> Third, how can I do a tally of the database elements that should comprise
> the total so I can find out the true cause of the increase. Counting the
> tables size in K + the indexes does not give me this huge file size.
>
> --
> _____
> DC G
>
and has been growing only a few hundred kilobytes week for a couple years.
I have since added a catalog and indexed a couple of tables and now this
database and another one on the server--that should be unrelated--have
backup files that are 140 and 170MB each. The indexes are really not that
big. The catalog is only about 20MB.
First, why would a 20MB catalog increase the size of this database so much.
Second, why would a catalog in one database affect one in another (if that's
what's really happening)
Third, how can I do a tally of the database elements that should comprise
the total so I can find out the true cause of the increase. Counting the
tables size in K + the indexes does not give me this huge file size.
_____
DC G
DC G,
Assuming that you're using SQL Sever 7.0 or SQL Server 2000 and no other
logged activity has occurred in the same database that you created the FT
Catalog and ran a Full Population, as the affect of only doing this type of
"read only" process should not of contributed to the growth in the size of
your database backup. Indeed, this has been one of the long outstanding
issues, i.e.. to include the FT Catalog with the database backup, that is
not included in either SQL 7.0 or 2000, but is only available as a new
feature in SQL Server 2005 (Yukon).
Q. why would a 20MB catalog increase the size of this database so much?
A. It should not. Did you make any other database &/or table changes? For
example alter a table and add a timestamp or other new column?
Q. why would a catalog in one database affect one in another?
A. It should not. Did you make any database changes &/or table schema
changes to either database?
Q. how can I do a tally of the database elements that should comprise the
total so I can find out the true cause of the increase?
A. You can use sp_spaceused or as well as the Enterprise Manager and the
Profiler.
FYI, for a KB article on how to Backup Full-Text Catalog Folders and Files,
see 240867 (Q240867) "INF: How to Move, Copy, and Backup Full-Text Catalog
Folders and Files" at
http://support.microsoft.com/default...b;EN-US;240867
Regards,
John
"DC Gringo" <dcgringo@.visiontechnology.net> wrote in message
news:ur3L#n92EHA.3596@.TK2MSFTNGP12.phx.gbl...
> I have a database who's SQL Server backup file has been hovering around
33MB
> and has been growing only a few hundred kilobytes week for a couple years.
> I have since added a catalog and indexed a couple of tables and now this
> database and another one on the server--that should be unrelated--have
> backup files that are 140 and 170MB each. The indexes are really not that
> big. The catalog is only about 20MB.
> First, why would a 20MB catalog increase the size of this database so
much.
> Second, why would a catalog in one database affect one in another (if
that's
> what's really happening)
> Third, how can I do a tally of the database elements that should comprise
> the total so I can find out the true cause of the increase. Counting the
> tables size in K + the indexes does not give me this huge file size.
>
> --
> _____
> DC G
>
Subscribe to:
Posts (Atom)