User profile for colby

Yes 73GB log file is to large. Please provide an example on how I would use redgate to run DBCC shrinkfile "command once, back up the transaction log, and run it again to successfully shrink the file" without losing transaction. Using 'with truncate_only' is not an option. Thanks for your help. Colby petey wrote: The option 'Remove inactive entries from transaction log' just allows SQL Server to truncate the transaction log, but does not physically shrink the file. This is actually the default behaviour when you back up the transaction log. If you uncheck the option, SQL Backup will back up the transaction log using the NO_TRUNCATE option. With regards to your transaction log file, you'll need to determine if 73 GB is 'normal'. E.g. you could be reindexing the entire database periodically, which would potentially grow the transaction log to that size. In that case, 73 GB is normal, and shrinking it is useless as it'll just grow again during the next reindexing process. If however you think 73 GB is an abnormal size, you could use the DBCC SHRINKFILE command to physically reduce the size. You may need to run that command once, back up the transaction log, and run it again to successfully shrink the file. See here for details. / comments

Yes 73GB log file is to large. Please provide an example on how I would use redgate to run DBCC shrinkfile "command once, back up the transaction log, and run it again to successfully shrink the fi...

0 votes

To the details: I have a database that is 23 GB with a log that is 73GB and we do backups with transactional logging on the hour, differentinals 6 daya a week and fulls 1 day a week. I did the DBCC LOGINFO('staging') and found some 474 rows of the below. How do I remove these when I have "Remove inactive entries from transaction log" checked. Is there another option to remove the below rows. FileId FileSize StartOffset FSeqNo Status Parity CreateLSN 2 253952 8192 15508 0 128 0 2 253952 262144 15509 0 128 0 2 253952 516096 15510 0 128 0 2 278528 770048 15511 0 128 0 2 262144 1048576 15864 0 128 18000000013600180 2 262144 1310720 15865 0 128 18000000022300388 2 262144 1572864 15738 0 64 19000000001600453 2 262144 1835008 15739 0 64 19000000015200406 2 262144 2097152 15744 0 64 19000000031600456 2 262144 2359296 15745 0 64 20000000006600262 2 262144 2621440 15746 0 64 20000000017100339 2 327680 2883584 15747 0 64 20000000030200442 2 327680 3211264 15748 0 64 21000000013600131 2 393216 3538944 15749 0 64 21000000030900396 2 393216 3932160 15750 0 64 22000000013600300 2 458752 4325376 15530 0 128 22000000038900356 2 253952 4784128 15531 0 128 23000000028100342 2 270336 5038080 15532 0 128 23000000028100342 2 253952 5308416 15533 0 128 24000000013600440 petey wrote: So assuming you have hourly transactional log backups the size of the log continues to grow with more and more unused space. Could you please clarify what you mean by that? When you back up the transaction log, SQL Server will mark the space occupied by the backed up transactions as reusable, as long as the transactions are not part of the active portion of the log, and the transactions have been replicated in a transaction replication setup. Thus, it is not likely that the transaction log will grow indefinitely. Reducing the physical size of the transaction log files to an unrealistic size is not a recommended option. This is because the growth may be due to normal database activity, which will eventually grow the transaction log to that size again, causing the file to fragment in the process. The exception is when you had a one-off event e.g. mass-loading data from an external source. In this case, shrinking the transaction log to a reasonable size is appropriate. See here for more details. / comments

To the details: I have a database that is 23 GB with a log that is 73GB and we do backups with transactional logging on the hour, differentinals 6 daya a week and fulls 1 day a week. I did the DBC...

0 votes

For your review, the attached is a PDF of version 1.1 of the PCI document. Start with section 3.4 and see if anything applies. https://www.pcisecuritystandards.org/pd ... s_v1-1.pdf Thanks Colby / comments

For your review, the attached is a PDF of version 1.1 of the PCI document. Start with section 3.4 and see if anything applies.https://www.pcisecuritystandards.org/pd ... s_v1-1.pdf Thanks Colby

0 votes

Brian This SqlBackupC.exe is a Redgate tool not a Microsoft SQL tool. So when I run the Redgate SQL backup monitoring tool for a new server in a disater recovery mode , do I then install this Redgate server components and then get on the box and run your command line version? Thoughts? Colby Brian Donahue wrote: Hi Colby, SqlBackupC.exe is part of the server components installation, so you should find it in the SQL Backup program folder on the SQL Server already. / comments

Brian This SqlBackupC.exe is a Redgate tool not a Microsoft SQL tool. So when I run the Redgate SQL backup monitoring tool for a new server in a disater recovery mode , do I then install this Red...

0 votes

Brian I need to create a complete disaster recovery plan using Redgate software. The product really does a great job in backup up all databases. Now I need to plan for a complete restore of the server in a disaster recovery mode. I need to understand all aspects of the disaster recovery and need to know what steps to make sure all users and there passwords are also restored. Sometimes if they are not done correctly, you get orphaned userid and lost passwords. I now know about restoring Master, MSdb and model databases backuped with Redgate based on the articles in this thread. Thanks Colby Brian Donahue wrote: Hi Chris, Thanks for your post. If you are in a Disaster Recovery scenario where you have to restore a SQL Server's configuration and all of its' databases, then it should suffice to restore master. Provided the master database backup is current, it will list all of the databases on the system, although some may be in 'suspect' mode, but should be able to restore over. There are some particular things to pay attention to when restoring the master database using SQL Backup. These are covered in the help file and in a bit more detail here. This describes how to bring the server up in single-user mode and restore the master database using SQL Backup. / comments

Brian I need to create a complete disaster recovery plan using Redgate software. The product really does a great job in backup up all databases. Now I need to plan for a complete restore of the se...

0 votes

Brian Where do we get a copy of SQLbackupc? Need to download from Redgate or should we keep a copy it laying around? Thanks Colby Brian Donahue wrote: Hi Chris, Thanks for your post. If you are in a Disaster Recovery scenario where you have to restore a SQL Server's configuration and all of its' databases, then it should suffice to restore master. Provided the master database backup is current, it will list all of the databases on the system, although some may be in 'suspect' mode, but should be able to restore over. There are some particular things to pay attention to when restoring the master database using SQL Backup. These are covered in the help file and in a bit more detail here. This describes how to bring the server up in single-user mode and restore the master database using SQL Backup. / comments

Brian Where do we get a copy of SQLbackupc? Need to download from Redgate or should we keep a copy it laying around? Thanks Colby Brian Donahue wrote: Hi Chris, Thanks for your post. If you are i...

0 votes

How can we help you today?

colby

Comments