Tag Info

New answers tagged

-4

My work around for the Replication that is blocking shrinking log file is: Set DB Recovery Model to Simple Take DB offline Create backup of log file (just in case) Delete log file Bring DB online In my case it worked. After bringing DB online log was created automatically and it's size was 512kb instead of 70GB. But this is only a workaround. The root ...


2

This is no error. It is just a log file which was too small and has auto growth enabled. It means that while there are transactions running the sql server process has to expand the log file. Expanding the log file is a single threaded process and every transaction which has to write something in the transaction log has to wait. And no: no IFI - you have to ...


2

This is telling you that a or several transaction logs are growing repeatedly, which means it is set to FULL or BULK LOGGED recovery mode with no or insufficient transaction log backups, or someone has written a really bad or long query that is keeping the transaction log active. You should look for all FULL recovery model databases on that server and when ...


6

In addition to the additional space marked "in-use" by SQLPERF you might have space in your transaction log that is not being freed for other reasons. You should probably take a look at the log_reuse_wait_desc column of sys.databases. If it says NOTHING or LOG_BACKUP then what you are seeing is probably the space taken up by the current VLF. If however if ...


5

It could be that a transaction running in another database has a hold on some objects in foo database. Using dbcc opentran(foo) only reports on transactions in foo, not in some other database. Also, it might help you to read this description (from 2001(!)) on How DBCC SQLPERF (Logspace) Reports Percentage Used at: ...


1

Please refer following link to get answer to your question : To get the size of each open transactions refer following link https://www.mssqltips.com/sqlservertip/1225/how-to-determine-sql-server-database-transaction-log-usage/ If you want to know the transaction log of any historical date then you can take the backup of database or just a transaction log ...


1

As indicated above, after running more tests, I arrived at an calculated conclusions. I summarized all of them into a blog post here, but I'll copy some content over to this post for posterity. Conjecture (based on some tests) As of now, I do not have a clear explanation as to why this is. But following are my estimations based on the artifacts gathered ...


0

I tried the following experiment and got similar results. In both cases, fn_dblog() shows rollback occurring and it seems to happen quicker in Scenario 2 than in Scenario 1. By the way, I placed both the MDF and LDF on the same single external (USB 2.0) disk. My initial conclusion is that there is no difference in the operation of rollback in this case, ...


1

When this DML be written to iblog files ? -- "as needed" during the hour When the DML be written to binary log files ? -- Never. Information for the binlog is gathered, but not written until COMMIT. Will the related data pages on disc be modified during 10:00 AM to 11:00 AM -- There may be modifications to the pages. They will be invisible to the user. ...



Top 50 recent answers are included