Za każdym razem, gdy uruchamiam ponownie system Windows, w przypadku niektórych baz danych pojawia się ten błąd. (Błąd systemu 21 - urządzenie nie jest gotowe)
Wynika to z faktu, że dysk jest w trybie offline lub nie jest online ani w momencie uruchamiania programu SQL Server, ani przechodził w stan po nim.
3. Jeśli zrestartuję SQL Server, błędy znikną
Tak, ponieważ bazy danych zostały ponownie zamontowane w SQL Server. Możesz także offline-> online bazę danych i działałoby, zakładając, że urządzenie dyskowe zostało naprawione.
Można to łatwo odtworzyć w środowisku testowym, umieszczając bazę danych na dysku, wyłączając dysk, uruchamiając zapytanie wyboru (aby uzyskać błąd), przełączając dysk z powrotem w tryb online i zauważając, że wybór nadal kończy się niepowodzeniem z tym samym błędem. Baza danych będzie musiała zostać ponownie zamontowana, aby ponownie działać i nie wyświetlać błędu systemu operacyjnego 21.
Co powinieneś zrobić?
Poproś kogoś, aby wykonał śledzenie systemu Windows, aby dowiedzieć się, dlaczego początkowo nie wchodzi w tryb online lub dlaczego przechodzi w tryb offline (dowolne przejście stanu) lub dlaczego wyświetla się w systemie Windows, ale tak naprawdę nie jest (być może trzeba załadować inne sterowniki dla to).
Dodatkowo sprawdź, czy sterowniki filtrów dysków są aktualne pod kątem takich rzeczy, jak antywirus, ochrona przed włamaniem do hosta itp., Ponieważ mogą one również blokować usługę / uruchomienie / stan.
Miałem podobny problem i dodałem skrypt do ponownego uruchomienia usług SQLServer / SqlLaunchPad po 5 minutach, ale to nie działa. Kiedy później ręcznie zrestartuję, to działa dobrze bez problemów. Ta sama konfiguracja w SQL Server2014 działa bez problemów
Rajesh
Zmień tryb początkowy z Automatycznego na Opóźnienie. Zapewni to, że usługa SQLService zostanie uruchomiona jako ostatnia (po zamontowaniu dysków i wykonaniu ich czynności).
Świetny. To jeden ze sposobów patrzenia na to. Prawdziwą przyczyną jest to, że niektóre usługi SQL nie uruchomiły się do momentu pojawienia się tego błędu SQL. Nie rozpoczęły się z powodu ustawienia „uruchamiania”, zwłaszcza jeśli rzeczywiście używasz „szybkiego uruchamiania” w systemie operacyjnym.
Chagbert,
3
To są moje spostrzeżenia i sposób, w jaki rozwiązałem problem (na korzyść innych, którzy mogą mieć ten sam problem)
Korzystałem z instancji amazon ec2 z serwerem Sql.
Miałem urządzenie EBS Block podłączone do instancji ec2, które zostało zmapowane na dysk D:.
Moje dane i dzienniki znajdowały się na dysku D:.
Kiedy zatrzymuję instancję ec2 i przywołuję ją później, zawsze napotykałem błąd „urządzenie nie jest gotowe” i bazy danych się nie pojawiały.
Próbowałem ustawić usługę MSSQLSERVER za pomocą opcji „Opóźnione uruchomienie”.
Jednak z dzienników serwera SQL odkryłem, że opóźnienie nie było honorowane i MSSQLSERVER uruchomił się wraz z bootowaniem.
Z przeglądarki zdarzeń zaobserwowałem, kiedy dysk D: staje się zdrowy.
Z dzienników serwera SQL zauważyłem czas, w którym SQL Server uruchamia moją bazę danych użytkowników.
Zauważyłem, że napęd D: jest dostępny dopiero po 6 sekundach; i oczywiście pojawia się błąd „Urządzenie nie jest gotowe”.
Zauważyłem również, że „Opóźniony start” nie był honorowany, ponieważ istniała inna usługa o nazwie „SQL SERVER LaunchPad”, która uruchamia „MSSQLSERVER”.
Nie potrzebuję funkcji analitycznej „Launchpad”. Więc wyłączyłem tę usługę.
Teraz „MSSQLSERVER” uruchamia się z opóźnieniem i może znaleźć pliki dysku D:.
Pełny błąd, który wystąpił podczas łączenia się z moją domyślną lokalną instancją MS SQL (2017) za pośrednictwem MSSMS:
System operacyjny zwrócił błąd 21 (urządzenie nie jest gotowe.) Do programu SQL Server podczas odczytu z przesunięciem 0x000000000aeae000 w pliku „D: \ MSSQL \ DATA \ tempdev.mdf”. Dodatkowe komunikaty w dzienniku błędów programu SQL Server i dzienniku błędów systemu operacyjnego mogą zawierać więcej szczegółów. Jest to poważny błąd na poziomie systemu, który zagraża integralności bazy danych i musi zostać natychmiast naprawiony. Wykonaj pełną kontrolę spójności bazy danych (DBCC CHECKDB). Ten błąd może być spowodowany wieloma czynnikami; Aby uzyskać więcej informacji, zobacz SQL Server Books Online. (Microsoft SQL Server, błąd: 823) Aby uzyskać pomoc, kliknij:
http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=823&LinkId=20476
Zacząłem to otrzymywać po przeniesieniu tempdb na nowy dysk D. Wykonanie uruchomienia / zatrzymania usługi SQL usuwa błąd. Nigdy nie dostałem tego błędu, gdy wszystko było włączone C. Oba moje dyski są SSD i są szyfrowane za pomocą Bitlockera, nie jestem pewien, czy to może być problem, być może dysk C jest odblokowywany bardzo wcześnie, ponieważ system operacyjny go potrzebuje, a dysk D zostaje odblokowany później .
W przeciwieństwie do odpowiedzi Venviga ( https://dba.stackexchange.com/a/226115 ) ustawienie usługi „SQL Server” na Typ uruchamiania = „Automatyczny (opóźniony start)” również rozwiązało mój problem (przy ponownym szybkim uruchamianiu systemu Windows włączone).
Wiele razy spotkałem się z tym samym problemem i pomyślałem, że powinienem podzielić się moim rozwiązaniem (niezależnie od już udzielonych odpowiedzi):
Mam więc dwie instancje SQL (SQL 2008 i SQL 2017). Błąd nie pojawia się w mojej instancji SQL08, ale w SQl17. Jest to spowodowane „poświadczeniami konta” podanymi podczas instalacji / konfiguracji każdej instancji SQL:
Można to zobaczyć w Usługach Windows. SQL08 został skonfigurowany do używania „Lokalnego konta systemowego”, podczas gdy SQL17, który uległ awarii, został ustawiony na „KONTO SIECIOWE” podczas instalacji. Po prostu zmień to i zrestartuj tutaj usługę SQL (lub zrestartuj instancję w przeglądarce SQL).
Druga część tego problemu jest unikalna dla programu SQL Server 2017 CTP 2.0 podczas korzystania z programu SQL Server Management Studio V17, w którym to przypadku SMO przełączył się na używanie „ sys.dm_os_enumerate_fixed_drives ” zamiast starych „ xp_fixeddrives ”, aby uzyskać informacje o wolnym miejscu na dysku lokalnym . Aby obejść ten problem, przejdź do DEVICE MANAGER i tymczasowo wyłącz cytowany napęd (w moim przypadku był to napęd „G”, który jest tylko napędem DVD-ROM).
Ten problem mnie również zirytował. Mam 5 dbs podłączonych do mojej instancji SQL Server, z których 3 działają dobrze, ale 2 narzekają
System operacyjny zwrócił błąd 21 (urządzenie nie jest gotowe.) Do programu SQL Server podczas odczytu z przesunięciem 0x00000000204000 w pliku „E: \ xxxxxxxx.mdf”
Oto moje rozwiązanie.
Włącz Services.msc , zlokalizuj usługę o nazwie SQL Server (nazwa instancji) , kliknij prawym przyciskiem myszy i uruchom ją ponownie .
Wróć do ssms, odśwież db i wszystko powinno działać.
Na marginesie, próbowałem wziąć db db offline / online. W moim przypadku nie zadziałało. Brute force ponownie uruchomiła usługę sqlserver. może to stanowić problem dla tych, których stawka za przejście na wszystkie dbs offline jest zbyt wysoka. Jeśli jednak robisz rozwój lokalny taki jak ja, to rozwiązanie powinno być w porządku.
Myślę, że znalazłem przyczynę.
Najprawdopodobniej problem wynika z opcji zasilania „Szybkie uruchamianie” .
Jest to technika systemu Windows, która skraca czas uruchamiania; Fast Startup łączy elementy zimnego wyłączenia i funkcji hibernacji .
Tutaj możesz znaleźć kolejny artykuł o zaletach i wadach
Wyłączyłem go i wydaje się, że problem został rozwiązany.
źródło
To są moje spostrzeżenia i sposób, w jaki rozwiązałem problem (na korzyść innych, którzy mogą mieć ten sam problem)
źródło
Pełny błąd, który wystąpił podczas łączenia się z moją domyślną lokalną instancją MS SQL (2017) za pośrednictwem MSSMS:
Zacząłem to otrzymywać po przeniesieniu tempdb na nowy dysk D. Wykonanie uruchomienia / zatrzymania usługi SQL usuwa błąd. Nigdy nie dostałem tego błędu, gdy wszystko było włączone C. Oba moje dyski są SSD i są szyfrowane za pomocą Bitlockera, nie jestem pewien, czy to może być problem, być może dysk C jest odblokowywany bardzo wcześnie, ponieważ system operacyjny go potrzebuje, a dysk D zostaje odblokowany później .
źródło
Wiele razy spotkałem się z tym samym problemem i pomyślałem, że powinienem podzielić się moim rozwiązaniem (niezależnie od już udzielonych odpowiedzi):
Mam więc dwie instancje SQL (SQL 2008 i SQL 2017). Błąd nie pojawia się w mojej instancji SQL08, ale w SQl17. Jest to spowodowane „poświadczeniami konta” podanymi podczas instalacji / konfiguracji każdej instancji SQL:
Można to zobaczyć w Usługach Windows. SQL08 został skonfigurowany do używania „Lokalnego konta systemowego”, podczas gdy SQL17, który uległ awarii, został ustawiony na „KONTO SIECIOWE” podczas instalacji. Po prostu zmień to i zrestartuj tutaj usługę SQL (lub zrestartuj instancję w przeglądarce SQL).
Druga część tego problemu jest unikalna dla programu SQL Server 2017 CTP 2.0 podczas korzystania z programu SQL Server Management Studio V17, w którym to przypadku SMO przełączył się na używanie „ sys.dm_os_enumerate_fixed_drives ” zamiast starych „ xp_fixeddrives ”, aby uzyskać informacje o wolnym miejscu na dysku lokalnym . Aby obejść ten problem, przejdź do DEVICE MANAGER i tymczasowo wyłącz cytowany napęd (w moim przypadku był to napęd „G”, który jest tylko napędem DVD-ROM).
źródło
Ten problem mnie również zirytował. Mam 5 dbs podłączonych do mojej instancji SQL Server, z których 3 działają dobrze, ale 2 narzekają
System operacyjny zwrócił błąd 21 (urządzenie nie jest gotowe.) Do programu SQL Server podczas odczytu z przesunięciem 0x00000000204000 w pliku „E: \ xxxxxxxx.mdf”
Oto moje rozwiązanie.
Na marginesie, próbowałem wziąć db db offline / online. W moim przypadku nie zadziałało. Brute force ponownie uruchomiła usługę sqlserver. może to stanowić problem dla tych, których stawka za przejście na wszystkie dbs offline jest zbyt wysoka. Jeśli jednak robisz rozwój lokalny taki jak ja, to rozwiązanie powinno być w porządku.
źródło