2011-12-20 10 views
7

Użyłem tego skryptu przez przypadek w bazie danych "master" zamiast w tymczasowej bazie danych.Przypadkowo usunięto wszystkie dane z bazy danych "master"

sp_msforeachtable 'delete from ?' 

Czy wyrządził szkodę? Jeśli tak, jak mogę przywrócić dane?

+3

Przywróć najnowszą kopię zapasową głównego DB. Masz jedno, prawda? –

+0

Nie mam. Jest to osobisty DB rozwojowy bez krytycznych danych, więc najgorsze, co może się zdarzyć, to konieczność ponownej instalacji SQL Server. – Stijn

+0

Studio SQL Server, prawda? –

Odpowiedz

10

Nie powinno niczego usunąć (zakładając, że nie masz tabel użytkowników w master).

Testowanie

exec sys.sp_MSforeachtable 'select ''?''' 

nie robi nic dla mnie wrócić. Wydaje się więc wykluczać tabele systemowe, takie jak spt_values.

Edit: Rzeczywiście Patrząc na definicji procedury to nie obejmuje tylko tabele gdzie OBJECTPROPERTY(o.id, N'IsUserTable') = 1

+0

Myślałem inaczej, ale myślę, że Martin może być poprawny. +1. – JonH

+0

Woah! Dzięki! Myślałem, że rozwaliłem moją bazę danych i byłam gotowa na ponowną instalację. Dzieje się tak, gdy nie sprawdzasz, czy wybrana baza danych jest wybrana z menu rozwijanego w Sql Server Studio. Dlaczego Microsoft? Dlaczego nie mógłbyś poprosić kogoś o wybranie konkretnej bazy danych przed otwarciem okna zapytania? Dzięki Bogu wprowadzili warunek IsUserTable. Użyteczność z pewnością nie jest znakiem firmowym Microsoft. –

+0

Twoja odpowiedź jest użyteczna i uspokajająca, ale klauzula "OBJECTPROPERTY" nie jest tym, co uratowało Stijna przed ponowną instalacją. Po popełnieniu tego samego błędu odkryłem kilka interesujących rzeczy na temat wdrażania procedury. Zobacz [moja odpowiedź] (http://stackoverflow.com/a/12530893/111424) na przykład. –

5

Martin Smith ma rację mówiąc, że sp_MSforeachtable nie usuwa tabel systemowych.

Jednakże, choć możemy myśleć o tabelach, takich jak spt_values i MSreplication_options jako tabele systemowe, są to w rzeczywistości tabele użytkowników zgodnie z SQL Server.

Kiedy uruchomić tę kwerendę w mojej bazy danych master:

SELECT name, OBJECTPROPERTY(object_id, N'IsUserTable') AS IsUserTable 
FROM master.sys.tables; 

widzę zestaw następujący wynik:

name     IsUserTable 
--------------------- ----------- 
spt_fallback_db  1 
spt_fallback_dev  1 
spt_fallback_usg  1 
spt_monitor   1 
MSreplication_options 1 

Tak jak zostało zapisane Stijn od reinstalacji?

Jeśli spojrzeć na to, jak sp_MSforeachtable jest realizowany, widać, że robi coś takiego, aby wybrać tabele spadać:

declare @mscat nvarchar(12) 
select @mscat = ltrim(str(convert(int, 0x0002))) 

SELECT * 
from dbo.sysobjects o join sys.all_objects syso on o.id = syso.object_id 
where OBJECTPROPERTY(o.id, N'IsUserTable') = 1 and o.category & @mscat = 0; 

W mojej bazy danych master, to zwraca pusty zestaw wyników.

Klauzula where stosuje maskę bitową do kolumny tabeli tabeli sysobjects w celu wykluczenia tabel, które nie są "mscat".

Tabele w głównej bazie danych są chronione nie dlatego, że są tabelami systemowymi, ale dlatego, że są tabelami "Microsoft".

Takie wykorzystanie kolumny kategorii jest całkowicie nieudokumentowane w Books Online Wszystko to ma to niejasny opis:

używany do publikacji, ograniczeń i tożsamości.

Jednak tabela sysobjects jest przestarzała, więc nie powinieneś jej używać. :)

Równoważny zapytanie za pomocą obsługiwanego widok sys.tables będzie wyglądać następująco:

SELECT * 
FROM sys.tables 
WHERE is_ms_shipped = 0; 

W mojej bazy danych master, to również zwraca pusty zestaw wyników.

+0

+1 Dobra korekta. –

Powiązane problemy