jump to navigation

SQL server db marked as SUSPECT 20 Φεβρουαρίου 2006

Posted by Νικόλας in SQL.
Tags: , ,
trackback

Πριν από μερικές εβδομάδες, με πήρε τηλέφωνο ένας πελάτης για να μου αναφέρει ένα πρόβλημα που παρουσιάστηκε στην εφαρμογή του. Μια εφαρμογή γραμμένη σε DELPHI, με MSSQL ως data repository, η οποία δεν είχε εμφανίσει ποτέ προβλήματα στο παρελθόν. Αυτή τη φορά η αναφορά του πελάτη ήταν ότι απλά δεν μπορεί να μπει στην εφαρμογή και ότι του ζητά ξανά τα στοιχεία σύνδεση με τον SQL server.
Συνήθως οι πελάτες, δεν είναι ιδιαίτερα κατατοπιστικοί στην αναφορά βλαβών είτε των εφαρμογών τους, ή των Η/Υ και από τα λεγόμενά του κατάλαβα ότι θα είχα να αντιμετωπίσω μια σχετικά απλή περίπτωση.
Όταν έφτασα στο πελάτη, άνοιξα κατευθείαν το DbaMgr2K – ένα πολύ καλό replacement του Enterprise Manager, το οποίο είναι FREE – και διαπίστωσα, ότι η βάση δεδομένων της εφαρμογής, εμφανιζόταν με status SUSPECT.
Πρώτη κίνηση λοιπόν, backup της βάσης δεδομένων.
Δεύτερη κίνηση έλεγχος στο SQL LOG για να διαπιστώσω από πού προέκυψε το πρόβλημα. Δυστυχώς από το LOG δεν κατάφερα να διαπιστώσω κάτι το ιδιαίτερο. Συνήθως όταν η βάση εμφανίζεται ως SUSPECT το πρόβλημα μπορεί να είναι είτε στο MDF, ή στο LDF. Ευτυχώς το MDF δεν είχε πρόβλημα, εφόσον είχα τη δυνατότητα να δώ τα δεδομένα μέσα από το DbaMgr2K.
Μια πολύ καλή λειτουργία η οποία ωστόσο δεν αναφέρετε στο επίσημο documentation της SQL είναι η δυνατότητα να αλλάξετε το status της βάσης σε EMERGENCY. Για να γίνει αυτό θα πρέπει από τις ρυθμίσεις της SQL να επιλέξετε το “Allow modifications to be made directly to the system catalogs”, το οποίο ωστόσο θα πρέπει να απενεργοποιήσετε στο τέλος. Στη συνέχεια εκτελείτε την εντολή UPDATE master..sysdatabases SET status=-32768 WHERE name=’<όνομα βάσης>’.
Εννοείται ότι η βάση θα πρέπει να είναι είτε detached, ή έστω offline και μετά την εκτέλεση της εντολής θα πρέπει να κάνετε restart τον SQL server (αφού πρώτα κάνετε attach ή online τη βάση).
Θέτοντας τη βάση σε Emergency Mode έχετε τη δυνατότητα να μεταφέρετε όλα τα δεδομένα της βάσης σε κάποια άλλη βάση με τη χρήση του Import and Export Data.
Εφόσον, λοιπόν το MDF δεν είχε πρόβλημα, τότε το πρόβλημα ήταν στο LDF.
Η λύση λοιπόν που ακολούθησα ήταν η εξής:

  1. Λήψη backup της βάσης με το πρόβλημα (για ασφάλεια).
  2. STOP SQL Server.
  3. Αντιγραφή του αρχείου MDF.
  4. START SQL Server.
  5. Διαγραφή της βάσης από τον SQL.
  6. Δημιουργία νέας βάσης με το ίδιο όνομα, έτσι ώστε να δημιουργηθεί νέο αρχείο LDF, χωρίς πρόβλημα (ΠΡΟΣΟΧΗ: Θα πρέπει και τα ονόματα των αρχείων να είναι ίδια με τα προηγούμενα!)
  7. Εκτέλεση της εντολής

EXEC sp_attach_single_file_db @dbname = ‘<όνομα βάσης>’, @physname = ‘<SQL path\mdf_αρχείο_βασης.mdf>’, π.χ. EXEC sp_attach_single_file_db @dbname = ‘mydb’, @physname = ‘C:\Program Files\Microsoft SQL Server\Data\mydb.mdf’ (έτσι γίνεται attach μόνο το MDF αρχείο της βάσης και αναδημιουργείται το LDF αρχείο).

  1. Restart SQL Server.
  2. DONE!!!

Προκειμένου, να λύσω το συγκεκριμένο πρόβλημα, βρήκα αρκετά χρήσιμα τα παρακάτω articles:

  1. http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=14047
  2. http://www.spaceprogram.com/knowledge/2002/06/recovering-from-deleted-log-file-on_12.html
  3. http://support.microsoft.com/kb/180500/en-us
  4. http://support.microsoft.com/kb/165918/en-us
  5. http://www.sqlservercentral.com/columnists/bknight/unmarksuspect.asp
Advertisements

Σχόλια»

No comments yet — be the first.

Σχολιάστε

Εισάγετε τα παρακάτω στοιχεία ή επιλέξτε ένα εικονίδιο για να συνδεθείτε:

Λογότυπο WordPress.com

Σχολιάζετε χρησιμοποιώντας τον λογαριασμό WordPress.com. Αποσύνδεση / Αλλαγή )

Φωτογραφία Twitter

Σχολιάζετε χρησιμοποιώντας τον λογαριασμό Twitter. Αποσύνδεση / Αλλαγή )

Φωτογραφία Facebook

Σχολιάζετε χρησιμοποιώντας τον λογαριασμό Facebook. Αποσύνδεση / Αλλαγή )

Φωτογραφία Google+

Σχολιάζετε χρησιμοποιώντας τον λογαριασμό Google+. Αποσύνδεση / Αλλαγή )

Σύνδεση με %s

Αρέσει σε %d bloggers: