How can we help you today? How can we help you today?
colby
Activity overview Badges (0) Posts (12) Comments (6)

Activity overview

Latest activity by colby

SQL Compare 8 -- compare selected tables
  1. Community
  2. SQL Compare 8 beta
Sometimes I just want to compare selected tables in 1 database to selected tables in another database but with different table name. For example, database 1 has table named X and in database 2 has...
1 follower 1 comment 0 votes
Add Checksum option to verify option on the GUI.
  1. Community
  2. SQL Backup Previous Versions
Currently only the command line/SQL versions allows you can add checksum to the backups. Please add checksum to GUI version for SQL 2005 so the backup can be properly verified. Have it greyed out...
1 follower 1 comment 0 votes
Restored database with focus on log size
  1. Community
  2. SQL Backup Previous Versions
Moving a database to another server can be more easily be done with Red Gate than attach detach methods when network is slow because the compression is so large and my copy time to the other server...
1 follower 1 comment 0 votes
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
  1. Community
  2. SQL Backup Previous Versions
  3. shrink transaction log back to default size
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
  1. Community
  2. SQL Backup Previous Versions
  3. shrink transaction log back to default size
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
shrink transaction log back to default size
  1. Community
  2. SQL Backup Previous Versions
When a database is created, the default size of the database is 2MB and log is 1MB. Under the full recovery model, I know that the transactional backing up of the log only removes the unused part...
3 followers 5 comments 0 votes
Use of Log shipping and normal transactional backups
  1. Community
  2. SQL Backup Previous Versions
Need your help. Currently the database has transactional backups every hour, differential daily and fulls weekly. Can I use the normal transactional backups for log shipping? Would this scenario ...
1 follower 1 comment 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
  1. Community
  2. SQL Backup Previous Versions
  3. SQL Backup v5 -- PCI Compliance
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
Scrollable SQLView in Interactive HTML export
  1. Community
  2. SQL Compare Previous Versions
SQL Compare has the ability to export a comparison to an interactive HTML web page. The normal comparison page has a scrollable line which can be moved to seperate the objects from the line by li...
0 followers 0 comments 0 votes
SQL Backup v5 -- PCI Compliance
  1. Community
  2. SQL Backup Previous Versions
Need to know if the Red Gate Backup version 5.x is PCI compliant with version 1.1 of the Payment Card Industry (PCI) Data Security Standard document. We use your backup tool to compress and encrypt...
2 followers 3 comments 0 votes
Total activity
21
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
3