Używamy wysyłania dzienników i RESTORE WITH STANDBYna serwerze SQL Server 2012 w celu przywrócenia bazy danych w trybie tylko do odczytu do celów raportowania. Jednak konfiguracja wysyłania dziennika nadal się psuje po zakończeniu przywracania jednej lub dwóch kopii zapasowych dziennika. Przesyłanie kłód psuje się tylko wtedy, gdy jest uruchomione jako RESTORE WITH STANDBY; RESTORE WITH NORECOVERYnie powoduje żadnych problemów.
Mam tylko intuicję, że podstawowa baza danych nie jest tak dynamiczna. Dlatego, gdy nie ma transakcji, może to powodować problemy z RESTOREprocesem?
Jakieś pomysły, znane poprawki?
Pracowałem przez kilka dni, wykonując regularne zadanie, które wymaga intensywnej aktualizacji na dwóch stołach. Gdy zadanie szybko przestało działać, konfiguracja wysyłania dziennika szybko zakończyła się niepowodzeniem, nie można przetworzyć pliku .trn. Zresetowałem wysyłanie dziennika i starałem się sprawdzić, czy nadal będzie działał, wykonując małą aktualizację, zmieniając wartość jednej kolumny jednego rekordu w tabeli, niezależnie od tego, czy nadal się nie udaje.
Dziękuję za wszystkie odpowiedzi.
PS: Fragment naszego dziennika
02/25/2013 13: 00: 00, LSRestore_DBDB01-A_BulldogDB, W toku, 1, DBREPORTS, LSRestore_DBDB01-A_BulldogDB, Krok dziennika przywracania dziennika zadania zadania., 2013-02-25 13: 00: 12.31 *** Błąd: Nie można zastosować pliku kopii zapasowej dziennika „\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn” do dodatkowej bazy danych „BulldogDB”. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.31 *** Błąd: Wystąpił błąd podczas przetwarzania dziennika dla bazy danych „BulldogDB”. Jeśli to możliwe, przywróć z kopii zapasowej. Jeśli kopia zapasowa nie jest dostępna, może być konieczne przebudowanie dziennika. Wystąpił błąd podczas odzyskiwania uniemożliwiający ponowne uruchomienie bazy danych „BulldogDB” (8: 0). Zdiagnozuj błędy odzyskiwania i napraw je lub przywróć ze znanej dobrej kopii zapasowej. Jeśli błędy nie zostaną poprawione lub nie są spodziewane, skontaktuj się z pomocą techniczną. PRZYWRACANIE DZIENNIKA kończy się nienormalnie. Przetwarzano 0 stron dla pliku bazy danych „BulldogDB” „BulldogDB” w pliku 1. Przetwarzano 1 strony dla pliku bazy danych „BulldogDB” „BulldogDB_log” w pliku 1. (. Net SqlClient Data Provider) *** 2013-02-25 13: 00: 12.32 *** Błąd: Nie można zarejestrować historii / komunikatu o błędzie. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.32 *** Błąd: ExecuteNonQuery wymaga otwartego i dostępnego połączenia. Obecny stan połączenia jest zamknięty. (System.Data) *** 2013-02-25 13: 00: 12.32 Pomijanie pliku kopii zapasowej dziennika „\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn” dla dodatkowej bazy danych „BulldogDB”, ponieważ nie można zweryfikować pliku. 2013-02-25 13: 00: 12.32 *** Błąd: Nie można zarejestrować historii / komunikatu o błędzie. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.32 *** Błąd: ExecuteNonQuery wymaga otwartego i dostępnego połączenia. Obecny stan połączenia jest zamknięty. (System.Data) *** 2013-02-25 13: 00: 12.33 *** Błąd: Wystąpił błąd podczas przywracania trybu dostępu do bazy danych. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.33 *** Błąd: ExecuteScalar wymaga otwartego i dostępnego połączenia. Obecny stan połączenia jest zamknięty. (System.Data) *** 2013-02-25 13: 00: 12.33 *** Błąd: Nie można zarejestrować historii / komunikatu o błędzie. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.33 *** Błąd: ExecuteNonQuery wymaga otwartego i dostępnego połączenia. Obecny stan połączenia jest zamknięty. (System.Data) *** 2013-02-25 13: 00: 12.33 *** Błąd: Wystąpił błąd podczas przywracania trybu dostępu do bazy danych. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.33 *** Błąd: ExecuteScalar wymaga otwartego i dostępnego połączenia. Obecny stan połączenia jest zamknięty. (System.Data) *** 2013-02-25 13: 00: 12.33 *** Błąd: Nie można zarejestrować historii / komunikatu o błędzie. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.33 *** Błąd: ExecuteNonQuery wymaga otwartego i dostępnego połączenia. Obecny stan połączenia jest zamknięty. (System.Data) *** 2013-02-25 13: 00: 12.33 Usuwanie starych plików kopii zapasowej dziennika. Podstawowa baza danych: „BulldogDB” 2013-02-25 13: 00: 12.33 *** Błąd: Nie można zarejestrować historii / komunikatu o błędzie. (Microsoft.SqlServer.Management.LogShipping) *** 2013-02-25 13: 00: 12.33 *** Błąd: ExecuteNonQuery wymaga otwartego i dostępnego połączenia. Aktualny stan połączenia jest zamknięty. (System.Data) ***, 00: 00: 12,0,0 ,,,, 0
Odpowiedzi:
Jeśli kopie zapasowe dziennika można przywrócić, gdy dodatkowa baza danych jest w stanie NORECOVERY i zawiedzie tylko wtedy, gdy jest w trybie TYLKO DO CZYTANIA / W GOTOWOŚCI, to zakładam, że same kopie zapasowe dziennika są prawidłowe i nie są uszkodzone.
Możliwe, że komponent raportujący ma otwarte połączenie z bazą danych, dlatego podczas przywracania pliku dziennika nie można uzyskać wyłącznego połączenia z bazą danych z powodu otwartych połączeń. Podczas konfigurowania wysyłania dziennika istniałaby opcja rozłączenia jakichkolwiek połączeń, aby umożliwić mu przywrócenie kopii zapasowej dziennika.
źródło
W trybie gotowości Wtórne przywracanie rozłącza użytkowników tylko podczas uruchamiania zadania, po uruchomieniu użytkownicy mogą się połączyć ... a to zatrzyma proces przywracania z błędem dotyczącym „wyłącznego dostępu”. Mam usługę, która próbowała połączyć się z rezerwową bazą danych podczas przywracania. To spowodowało przerwanie procesu przywracania po 1-10 / 100 przywróconych plikach.
źródło