New answers tagged

0

For SQL Server 2016 SP2 and later, the following code significantly simplifies obtaining a list of databases suffering from a large number of Virtual Log Files. The code uses the system dynamic management function, sys.dm_db_log_info which contains a single row for each VLF in the specified database. The function is officially supported, and documentation ...


1

The Log files are used like if it was only one file. Both files have VLF so let's say the first log file have VLF1 to VLF10 and the second one have VLF11 to VLF15. It will write down stuff in the VLF1 and once that one is full, will continue in VLF2, etc... once it reach VLF15, it will then go back to VLF1 (not before) so it's 100% normal that both files ...


1

Have you measured the performance penalty for not defragmenting your indexes? It is a pretty big chance that you do all this work with little gain. See for instance http://sqlblog.karaszi.com/fragmentation-the-final-installment/. And don't confuse defrag with getting new statistics. If you see performance gains from a defrag job, it might just be because a ...


1

My understanding is that full backups do not truncate transaction logs - only transaction log backups do (e.g., the full backup is fairly independent of the transaction logs). However, my guess is that the re-organise all indexes does a lot of data processing - it is likely that these go into the transaction logs and are causing your issues. You could test ...


0

The reason you are seeing this behaviour is due to the fact that you have SUSPENDED the data synchronization (see @AMtwo's comment). From BOL, a secondary replica must be able to communicate with the primary replica and must be SYNCHRONIZED or SYNCHRONIZING. so if you unsuspend the data synchronization, then the log can be reused since you took the log ...


Top 50 recent answers are included