(2006)
Arrivare in ufficio dopo il weekend lungo di Pasqua è già difficile a causa del dopo picnic, e del dopo colomba, uova di cioccolato, uova sode e quant'altro. T rovare il server di sviluppo spento e all'accensione accorgersi che il gruppo di continuità non ha provveduto automaticamente allo shutdown non migliora le cose. Un messaggio di errore da parte del servizio di SQL Server 2005 che indica che non può partire perché il database Master è danneggiato non è che la conferma che Murphy è sempre in agguato.
Dopo questa premessa, vediamo come fare a sopravvivere:
- Aprire i Books online, digitare sulla casella di ricerca le parole "master database damaged" e selezionare tra le risposte Rebuilding the master Database
- Da qui seguire il link How to: Install SQL Server 2005 from the Command Prompt .
- Leggere attentamente quanto scritto nella pagina che raggiungerete ed in particolare il paragrafo: HOW To rebuild system databases for a default instance of SQL Server 2005 from the command prompt
- In questo paragrafo, è indicato di aprire un command prompt (console) inserire il disco di setup di SQL Server e digitare il seguente comando:
start /wait setup.exe /qn INSTANCENAME= REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=
dove INSTANCENAME = MSSQLSERVER per l'instanza di default e SAPWD=MiapasswordMoltoLungaPerSa
Provando a eseguire in modo letterale però si verificano 2 problemi, il primo ovvio, il secondo un po' meno. Nelle istruzioni è stato omesso il fatto che setup.exe può essere lanciato solo se ci troviamo sulla cartella corretta nel suo CD o DVD e infatti, andando sulla documentazione di MSDN Online c'è un update del 14/04/2006 (lo stesso giorno in cui il mio server si è schiantato) in cui prima di setup.exe è stato aggiunto di mettere il path del disco di setup, aggiungo che oltre al disco è necessario mettere anche la cartella completa quindi il comando diviene:
start /wait "d:\SQL Server x86\Servers\setup.exe"
/qn INSTANCENAME=MSSQLSERVER REINSTALL=SQL_Engine
REBUILDDATABASE=1 SAPWD=SAPASSWORD
Ovviamente con una password un po' meno ovvia.
Lanciando questo comando, il database Master dovrebbe essere rigenerato e poi, avendo un Backup dell'originale si può provvedere a restorarlo, oppure, come nel mio caso non avendo il backup, è necessario riattaccare tutti i database e ripristinare tutta la configurazione della sicurezza.
Peccato però che questo comando funzioni solo se la cartella dati di SQL Server si trova nella posizione di default, ovvero C:\Programmi\Microsoft SQL Server\MSSQL.1\MSSQL\Data.
Per principio, io non installo mai i miei database sul disco che contiene il sistema operativo, e ancor meno li installo sulla cartella programmi, perciò il mio DB master non veniva rigenerato, però, scendendo più in basso sulla pagina dell'help, e osservando la procedura di ripristino per i SQL Server in Cluster, ho notato che esiste un parametro, che è richiesto solo nel caso di SQL Server in Cluster, e si chiama INSTALLSQLDATADIR, visto che provare non costava nulla, ho modificato il comando nel seguente modo:
start /wait "d:\SQL Server x86\Servers\setup.exe" /qn INSTANCENAME=MSSQLSERVER
REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=SAPASSWORD
INSTALLSQLDATADIR=D:\SQL.DIR\DATA
Indicando quindi al setup dove cercare la cartella dati di SQL Server, lanciandolo in questo modo, la ricostruzione è andata a buon fine, il servizio è partito e se pure vuoto, il server è pronto a lavorare.
- Se avessi avuto un Backup del DB Master, a questo punto avrei seguito le istruzioni che si trovano sulla pagina How to: Restore the master Database (Transact-SQL) e avrei ripristinato la situazione relativa all'ultimo backup.
- Io non ero provvista di Backup, (Ok merito una bacchettata per questo) ma la scusante è che essendo il server di sviluppo , difficilmente vi sono salvati dati importanti, però, al termine di questo report, predisporrò il piano di backup di tutto quello che si trova sul server , parola di scout.
Pertanto, visto che non ho il backup, per prima cosa provvedo a effettuare un Attach di tutti i database precedentemente esistenti.
- Se, ci assiste la fortuna e tutti i database si Attachano correttamente, la sola cosa che manca è andare sulla cartella SECURITY e provvedere a rigenerare i Login che prima erano presenti sul server, senza ridare loro i permessi sui database in quanto tali permessi rimangono quindi il server darebbe errore. Ripristinate solo i login, fate un F5 e verificate che siano riapparsi i diritti di accesso ai database.
- Se, come nel mio caso, Murphy non è andato in vacanza e accade che uno dei database da un errore durante l'attach, non c'è un backup dello stesso (sempre perché non erano db importanti) cosa possiamo fare?
Come ripristinare un database bacato e sopravvivere:
Scenario: la procedura di Attach vi da errore e vi consiglia gentilmente di fare un DBCC CHECKDB , non avete una copia di backup oppure ne avete una obsoleta, sapete bene che per fare DBCC CHECKDB è necessario che il Database sia stato attaccato al server, cosa fate?
- Primo, prendete una camomilla , meglio se assieme a 20 gocce di valeriana .
- Stabilite che un metodo per girare attorno all'errore c'è.
- Spostate i files del database rotto su una cartella diversa da quella ove si trovano.
- Generate un nuovo database con lo stesso nome, gli stessi nomi di file e la stessa dimensione.
- Fermate il servizio di SQL Server.
- Copiate il database rotto su quello sano ma vuoto.
- Riavviate il servizio di SQL Server sghignazzando perché lo avete fregato.
- Aprite il SQL Server Management studio pensando di potervela cavare con il lancio del DBCC CHECKDB.
- Vi accorgerete che lui è più furbo di voi, infatti il database è marcato come SUSPECT.
- Provando a metterlo in modalità Single User e lanciando DBCC CHECKDB la risposta sarà un messaggio di errore.
- Fatevi una nuova camomilla e 40 gocce di valeriana.
- Ricercate SUSPECT nei Books online, e con un po' di fortuna, scoprite che esiste una stored procedure che si chiama: sp_resetstatus , a cui passare il nome del DB sospetto affinché venga reso nuovamente innocente.
Eseguite quindi: sp_resetstatus 'NomeDelDbSospetto'
- Traete un sospiro di sollievo, rimettete il database in multiutenza, e lanciate il DBCC CHECKDB .
- Se questo per caso vi dicesse che ci sono degli errori, non disperate, invece usate una delle opzioni di checkdb , ALLOW_DATA_LOSS , che ha un nome pericoloso, ma in casi estremi non è purtroppo possibile evitare i rimedi estremi.
Eseguite: DBCC CHECKDB ('NomeDelDatabaseRotto', ALLOW_DATA_LOSS)
- E se come me siete molto fortunati, a dispetto di Murphy, ritroverete il database integro e pronto all'uso.
Siete già andati a predisporre il piano di backup di tutti i vostri database?
NON ANCORA????
MUOVETEVI!!!!!!!! ;););)
Tags: SQL, Errori, SqlServer