Qui ci sono alcune strade che vorrei indagare. Non fare tutte queste (alcune sono tecniche diverse per raggiungere lo stesso scopo), ma vale la pena considerare:
1. Esaminare direttamente il registro errori SQL
Passare direttamente alla cartella contenente i log degli errori SQL e caricare il più recente ERRORLOGnel blocco note per ottenere maggiori dettagli sul motivo per cui l'istanza SQL non verrà avviata. Forse scoprirai che il problema non riguarda affatto il database principale.
2. Provare ad avviare l'istanza in modalità utente singolo
Ecco un elenco completo delle opzioni di avvio per il server SQL , tra cui -m(modalità utente singolo) e -f(modalità di configurazione minima). Altre opzioni consentono di specificare il percorso per il database principale, se questo è il problema.
Se sei in grado di avviare l'istanza, segui i passaggi nell'articolo MSDN che hai collegato per ripristinare il database principale o questa procedura dettagliata dettagliata di Thomas LaRock .
Se un'altra applicazione prende sempre la connessione del singolo utente prima che tu possa farlo, disabilita prima SQL Agent in modo che non si avvii. In secondo luogo, vedere le idee su questa domanda per l'utilizzo del -m"Application Name"parametro per specificare il nome dell'applicazione.
3. Ripristinare masterin un'altra istanza e copiarne i file
Ho trovato solo un'altra menzione di questa tecnica non documentata, ma l'ho usata con successo lo scorso fine settimana, quindi potrebbe valere la pena provarla.
Se non riesci ad avviare l'istanza in modalità utente singolo, ma hai un'altra istanza SQL che esegue esattamente la stessa versione e build , prova a ripristinare l'ultimo backup noto del database master valido dall'altro server:
- Ripristina come nome diverso, ovviamente (
master_please_god_let_this_work), in WITH MOVEmodo da non sovrascrivere mastersul tuo buon server
- Restore
WITH NORECOVERY. Non sono sicuro che ciò sia necessario, ma mi ha fatto sentire meglio sapendo che l'altro server non avrebbe modificato nulla nel master ripristinato
- Impostalo su offline:
ALTER DATABASE [master_please_god_let_this_work] SET OFFLINE
- Copia i file MDF e LDF ripristinati dal server valido al server guasto
- Rinominare i file
master.mdfe mastlog.ldfcome necessario per sostituire i file master danneggiati con le versioni ripristinate
- Incrocia le dita e avvia l'istanza
- Opzionale: eseguire un nuovo ripristino del master sul server ripristinato. Non sono sicuro che ciò sia necessario, poiché siamo stati abbastanza attenti a non cambiare
master.
4. Ricostruire i database di sistema
Se non si dispone di un'altra istanza che esegue la stessa versione o se non si ha familiarità con l'utilizzo della procedura non documentata elencata al punto 3 o se non si dispone di backup di master( perché non si dispone di backup ?? ), è possibile ricostruire i database del sistema SQL dal disco di installazione originale :
Setup.exe /ACTION=REBUILDDATABASE /...
Al termine, è possibile seguire i passaggi precedentemente collegati per ripristinare masterdall'ultimo backup valido. Sarà inoltre necessario ripristinare un backup recente di msdbper mantenere tutti i lavori, la pianificazione dei lavori e la cronologia dei lavori.
5. Ripristinare tutti i database USER in una nuova (o esistente) istanza SQL
Se hai già un'altra istanza esistente (versione SQL corretta, spazio su disco sufficiente), probabilmente inizierei i ripristini del database dai backup più recenti mentre sto lavorando agli altri passaggi di risoluzione dei problemi sopra, nel caso in cui ne avessi bisogno.
Se la tua nuova (o reinstallata) istanza ha accesso allo stesso disco, è molto più veloce collegarli semplicemente come nuovi database:
CREATE DATABASE foo
ON (FILENAME = 'D:\data\foo.mdf'),
(FILENAME = 'D:\data\foo_log.ldf')
FOR ATTACH;
6. Eseguire nuovamente le modifiche a master
Una volta ripristinato correttamente master(tramite una delle tecniche sopra), è necessario esaminare eventuali modifiche che potrebbero essere state perse, se sono state apportate dopo il backup appena ripristinato:
- Cambiamenti di sicurezza
- Nuovi database (i file saranno ancora su disco, basta collegarli)
- Impostazioni a livello di server
Non esiste un modo magico per trovarli, dovrai tornare alla documentazione della tua azienda per questo tipo di modifiche, se ne hai uno.