Dlaczego DBCC SHRINKFILE działa niekonsekwentnie w pracy bazy danych?

głosy
1

DBCC SHRINKFILE zawsze działa, gdy uruchomić go ręcznie w pliku dziennika, nawet gdy pojawia się następujący komunikat:

'Cannot shrink log file 2 (Claim_Log) because all logical log files are in use.'

Kiedy uruchamiam go z pracy, jednak tylko kurczy dziennik o jedną trzecią czasu. Inne czasy, to po prostu pozostaje duża (około 150GB). Nigdy nie ma żadnego błędu inny niż wymieniony powyżej. Jest to stwierdzenie, że używam:

DBCC SHRINKFILE (N'Claim_log' , 0, TRUNCATEONLY)

Mam „Dołącz wyjście krok w historii” włączona na etapie pracy. Czy coś jeszcze mogę zrobić, aby uzyskać więcej informacji o tym, dlaczego to nie działa?

Edycja: Oto pełna wiadomość z dziennika:

'Executed as user: *. Cannot shrink log file 2 (Claim_Log) because all logical
log files are in use. [SQLSTATE 01000] (Message 9008)  DBCC execution completed. 
If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000]
(Message 2528).  The step succeeded.'

Próbowałem już kopać użytkowników z db i ustawienie go w trybie pojedynczego użytkownika.

Utwórz 09/12/2008 o 17:27
źródło użytkownik
W innych językach...                            


3 odpowiedzi

głosy
2

Niedawno rozwiązać podobny problem, stwierdziliśmy, że w sys.databases, log_reuse_wait_desc był równy „replikacja”. Widocznie to oznacza coś do skutku SQL Server czeka na zadanie replikacji, aby zakończyć, zanim będzie można go ponownie wykorzystać przestrzeń dziennika.

Jednak replikacja nigdy nie zostały wykorzystane na naszej DB ani na naszym serwerze. Powinieneś być w stanie wyczyścić stan uruchamiając „sp_removedbreplication”; jednak dla mnie „sp_removedbreplication” nie rozwiąże problemu. Zamiast SQL właśnie wrócił mówiąc, że baza danych nie była częścią replikacji ...

Znalazłem moją odpowiedź tutaj:

Zasadniczo musiałem stworzyć replikację, wyzerować wszystkie wskaźniki replikacji do zera; następnie usunąć replikację ja właśnie wykonany. to znaczy

Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO
Odpowiedział 06/07/2011 o 05:10
źródło użytkownik

głosy
2

próby wystawienia Checkpoint pierwsze polecenie, a następnie kurczy się dzienniki

pochodzi z BOL ( http://msdn.microsoft.com/en-us/library/aa226036(SQL.80).aspx )

Siły wszystkich brudnych stron dla bieżącej bazy danych mają być zapisane na dysku. Brudne strony są dane lub strony dziennika zmodyfikowane po wejściu w buforze pamięci podręcznej, ale modyfikacje, które nie zostały jeszcze zapisane na dysku. Aby uzyskać więcej informacji na temat dziennika obcinania, zobacz Obcinanie dziennika transakcji.

Odpowiedział 09/12/2008 o 18:01
źródło użytkownik

głosy
0

Oznacza Obecnie plik dziennika jest w użyciu i punkt kontrolny, gdzie kwestia Sprawdź punkt będzie zapisuje datfile że nie został napisany do pliku danych z pliku dziennika transakcji (brudnych stron). Sprawdź czy jest jakiś prąd Aktywny się dzieje, czy nie,

Sprawdzić za pomocą Active transakcją w 2005 select * from sys.dm_tran_session_transactions

2000 DBCC LOGINFO

zrobić dobry plan => 1.Create Plan czynności konserwacyjnych do tworzenia kopii zapasowych dziennika (Made plan).

Odpowiedział 29/08/2009 o 06:18
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more