New answers tagged

4

You have to start over and restore full and diffs with no recovery and then the tlogs with stand by option. This will allow you to restore tlogs later as well. You can configure logshipping with option of stand by, so you can read from the secondary database. There will be a .tuf (transaction undo file) file created when you restore tlogs with standby ...


0

Yes, if you want to apply additional transaction logs you will need to start back at your full backup. To quote MSDN, The database cannot be recovered until after the final transaction log has been applied. If you recover the database after restoring one of the intermediate transaction log backups, that before the end of the log chain, you cannot ...


0

It really depends on what's best for your situation as long as you follow some guidelines. We keep the disks for transaction logs separate because often RAID 6 doesn't give us the IOPS we want during peak usage, but many times it does. It depends on your peak IOPS requirements, future growth, and file management. Note that these best practices were created ...


3

What is the cardinality of (this) entity relationship between Employee and Department? Yes, this relationship ("managed-by") is an example of a one-to-one relationship. This doesn't forbid the two entities form having other relationships, (ie. "works-in") that are of different cardinality, one-to-many or many-to-many. Suppose after a year another ...


2

I have run the Shrink job at about 1 AM manually, after that the scheduled Transaction Log Backup got failed with following error I am sure you are running shrink job by changing database recovery model to simple and then changing it back to full and then shrinking it. This would break log chain and you would need full backup again to start the log chain. ...


3

Your maintenance plan should not contain any shrink tasks anyway. These cause fragmentation by moving pages around the file and likely the database will just need to grow back to its original size shortly anyway. But this isn't causing your error. BACKUP LOG cannot be performed because there is no current database backup. The transaction logs would ...


0

Also needed: log_output = 'FILE' Meanwhile, you have possibly thrown lots of stuff into the table mysql.general_log. Do SELECT * FROM mysql.general_log LIMIT 11;


-1

Yes, Ian is correct here. I am sure your issue is resolve now. Also, archive logs can still exist in Active log path if we set LOGARCHMETH1 to LOGRETAIN correctly . Details at Information Center can give better overview .Hope it helps !


0

The COMMIT and ROLLBACK logs entries are mostly from different connections. Even when there is a ROLLBACK after a COMMIT on the same connection, it cannot roll back the already committed change. AFAIR, a ROLLBACK was also logged when a connection was closed.


5

Only overnight SSIS is making writes, daytime is all reads - I only need daily recovery. You should choose your recovery model based on your business needs : How much data business can loose and at the same time survive ? Based on the above answer, you should carefully choose your database recovery model. In simple terms (not discussing bulk logged ...


0

I faced the similar issue some days ago, few suggestions. Check the output of the following command: show variables like '%general%'; If the output listing general log file and still it is not logging queries, modify the following parameters. general_log = ON general_log_file = /var/log/mysql/mysql.log Still if it is not working, check ...


1

Everything is written to the transaction log, it is literally a log of every transaction that has taken place in your database, To remove something from the transaction log the transaction must be: Complete Written to Disk If in Full recovery mode, backed up If the transaction is not complete, then the transaction cannot be written to disk, and every ...


4

but I still don't understand why the log is so big, especially in Simple recovery mode - this operation should be minimally logged... No, in simple recovery mode, leaving Operations That Can be minimally Logged, all other operations are fully logged. In simple recovery model what is different is when the checkpoints are going to happen. Checkpoints are ...



Top 50 recent answers are included