• AlwaysON

    AlwaysON database not synchronizing suspect mode

      I got a call the database, not online/available mode, we suspect there was a corruption. One of my AlwaysON secondary database went suspect mode, it’s because of the log file and drive was full. I tried to resume the database. ALTER DATABASE dbname SET HADR RESUME;. It went “in recovery“ phase and fails. Since, it does not have even 1 MB space in the log file and drive to do a recovery phase. The drive has a good capacity for log, even though there was a huge transaction from application and the important one transaction log backup failed for five hours. I have a transaction log backup every five…

  • DBA,  VLDB

    TempDB database is Full and Optimization

    What is TempDB and best practice for TempDB TempDB is the system database and it is per instance. It is a common and shared by all other databases. All the temporary activities are done here and yes, definitely the TempDB will become full and occupy more space depends on the temporary tasks, which we are running. There are many activities can happen in tempDB. Best practice, create a TempDB in separate disk with the estimated initial file size, those are old days and now most of us using disk array. The spindles and HDDS/SSDs are striped through RAID and shared across LUNs and pools, check with your infra team about the…

  • AlwaysON

    How to solve the LSN mismatch in SQL server

      There are many times, we face the LSN mismatch issue in alwaysON and other HA technologies. It is a bit hard to find the missing transaction log backup to apply. Since, there are hundreds of thousands log generated, depends on the transaction log frequency and it can be run in any secondary alwaysON database server. Think about “the VLDB” and “the backup is in different data center” and database are out of sync in DR site because of LSN mismatch. For VLDB 8 TB database, we cannot take a full or differential backup to fix this. Since, it will take more and more time. Backup is in different data center…

  • AlwaysON

    AlwaysON database NOT SYNCHRONIZED and RECOVERY PENDING

    AlwaysON database NOT SYNCHRONIZED and RECOVERY PENDING   I have recently come across an issue that, one of my alwaysON secondary replica databases are went into “NOT SYNCHRONIZED and RECOVERY PENDING” state. It is a geo cluster alwaysON with 4+2 nodes configured in both synchronous and asynchronous mode.  The issue is when the database removed from the primary replica, with the secondary disconnection the higher database IDs on the secondary went into “NOT SYNCHRONIZED and RECOVERY PENDING” state, but the lower database IDs are good and synchronous state only. I just checked with one of the Microsoft MSFT and he said it considers as a bug. “Since, it occurs a…

  • AlwaysON,  DR/HA

    AlwaysON move database without breaking HADR

    Move database without breaking alwaysON   This post is going to show the database movement from one drive to another drive, without breaking the database from alwaysON configuration. An application has created the many databases to both primary and secondary replica servers to the default location of C drive. There are methods like detach/attach, backup/restore & alter database. For alwaysON HADR servers, the best method is Alter database. Since it is in the mirror/sync mode. Detach/attach will not work and backup/ restore, we need to break databases from the HADR. Note: It’s a two node synchronous replica, if you have more replica, you should plan each well. If you have…