jump to navigation

Change logical file name of SQL database 27 Ιουνίου 2007

Posted by Νικόλας in SQL.
Tags: ,
add a comment

Σήμερα, έφαγα το εξής «κόλλημα»…

Δημιούργησα ένα αντίγραφο μίας βάσης – ας πούμε το όνομα της οποίας είναι mySQLDB – με την απλή διαδικασία του backup και restore as new.

To logical file name της db ήταν mySQLDB_Data και mySQLDB_Log. Αναπάντεχα όταν έκανα restore δίνοντας νέο όνομα βάσης (για να δημιουργήσει νέα βάση) διατηρήθηκαν τα logical file names της αρχικής βάσης.

Έτσι είχα τη βάση mySQLDB με logical file names mySQLDB_Data/Log και τη νέα βάση myNewSQLDB με logical file names τα ίδια!!!

Κόλλησα, ήθελα να έχω αντιστοιχία ονόματος βάσης, ονόματος mdf/ldf αρχείων και logical file names.

Όχι ότι παίζει κάποιο ουσιαστικό ρόλο στη λειτουργικότητα, απλά γιατί με έπιασε η τελειομανία μου.

Πώς μετονομάζεις λοιπόν τα logical file names μίας βάσης;

Απλό !

(Ισχύει για SQL 2000 και πάνω)

ALTER DATABASE myNewSQLDB

MODIFY FILE (NAME = mySQLDB_Data, NEWNAME = myNewSQLDB_Data)

ALTER DATABASE myNewSQLDB

MODIFY FILE (NAME = mySQLDB_Log, NEWNAME = myNewSQLDB_Log)

Με βοήθησαν τα παρακάτω

LDF file is lost or deleted or corrupted 30 Σεπτεμβρίου 2006

Posted by Νικόλας in SQL.
Tags: ,
1 comment so far

Είχα γράψει κάποτε σχετικά με το τί μπορείς να κάνεις αν για κάποιο λόγο, π.χ. πολύ μεγάλο transaction log ή corrupted transaction log, η βάση εμφανίζεται ως «ύποπτη».

Πρόσφατα αντιμετώπισα το εξής πρόβλημα. Κάποιος έξυπνος είχε τη φαεινή ιδέα, να μεταφέρει την SQL σε άλλο SQL server. Τί έκανε, απλά copy paste. Ότι χειρότερο μπορείται να κάνετε. Η SQL δεν είναι DOS, θέλει προσοχή, αγάπη, φροντίδα και proderm. Για το λόγο αυτό υπάρχουν οι λειτουργίες backup/restore και detach/attach. Όποτε θέλετε να μεταφέρετε μία βάση ΠΟΤΕ μα ΠΟΤΕ ΜΗΝ κάνετε απλά ένα copy. O σωστός τρόπος είναι να την κάνετε ένα backup και στη συνέχεια ένα restore στο νέο server. Και αν αντιμετωπίσετε πρόβλημα εγώ θα κάτσω να με … μουτζώσετε!

Το πρόβλημα λοιπόν που προέκυψε ήταν ότι NO LDF file around! Πού είναι το LDF ΟΕΟΟΟ;!

Στην αρχή σκέφτηκα να κάνω ότι στη περίπτωση που το LDF είναι corrupted, αλλά είπα να «δοκιμάσω τη τύχη μου» και να δοκιμάσω να κάνω κατευθείαν attach τη db, για την ακρίβεια επιχείρησα να κάνω attach single file.

Και Ω! ΝΑΙ! H SQL με ενημέρωσε ευγενικά ότι δεν υπάρχει το αρχείο LDF και ότι θα ήταν μεγάλη της τιμή να δημιουργήσει ένα νέο.

Η αλήθεια είναι ότι δεν έχω καταλάβει γιατί στη μία περίπτωση είναι απαραίτητη όλη αυτή η διαδικασία ενώ σε αυτή τη περίπτωση, αρκεί ένα attach single file.

Όποιος μάστορ(ας) κατέχει περισσότερα για το θέμα, ας δώσει τα φώτα του.

Το θέμα είναι ότι σε περίπτωση που για οποιοδήποτε λόγο βρεθείτε ΜΟΝΟ με ένα ΚΑΛΟ (uncorrupted) MDF αρχείο, τότε απλά εκτελέστε την εντολή: 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 μέσα από τον Enterprise Manager και επιλέξτε Single File.

Transcation log is full 6 Ιουνίου 2006

Posted by Νικόλας in SQL.
Tags: ,
2 Σχόλια

Πρωί πρωί, μόλις έφτασα στο γραφείο, χτυπά το τηλέφωνο:

Πελάτης – Σβήνω, χάνομαι, πήγα να μπώ στο πρόγραμμα και μου έβγαλε ένα μύνημα «Transaction log is full»! Δεν μπορώ να μπω, δεν δουλεύει τίποτα, χάνομαι, σβήνω, τρέχα!

Εγώ – …

Τρέχω λοιπόν στο πελάτη και βρίσκω ένα Transcation Log το οποίο έχε απλώσει σε όλο το δίσκο… 74GB ήταν το αθεόφοβο σε 80άρη δίσκο.

– Βρε καλό μου, βρέ χρυσό μου, κάνε shrink

– Τσού (εκεί, κολλημένο στα 74GB)

– Βρε δεν πάς στην ευχή του Θεού και της Παναγίας, λέω εγώ;

Stop τον SQL Server, Delete το LDF, αντιγραφή του MDF σε άλλο σημείο στο σκληρό και με λίγα λόγια ότι κάνουμε στη περίπτωση που έχουμε SQL database marked as SUSPECT.

Μέγα Λάθος!!! Δεν μου έκατσε με τίποτα (αν και πρέπει να το ψάξω … αύριο τώρα, γιατί πήγε 1.00)

Τέλως πάντων με τα πολλά η λύση βρέθηκε και είναι η εξής:

1. Από Enterprise Manager -> Properties -> Options -> Recovery Model: Simple

2. Εκτελώ το παρακάτω script

USE dbName

GO

DBCC SHRINKFILE(dbName_log, 1)

BACKUP LOG dbName WITH TRUNCATE_ONLY

DBCC SHRINKFILE(dbName_log, 1)

GO

3. Από Enterprise Manager -> Properties -> Options -> Recovery Model: Full (ΜΕΓΑ λάθος! απορώ γιατί το έγραψα. Με Full Recovery Model, μετά από λίγο καιρό έχεις ένα LDF, μεγαλύτερο από όλη τη βάση του ΚΕΠΥΟ!!!)

4. ΕΤΟΙΜΟΣ!

Links που βρήκα χρήσιμα:

Το σωστό encoding 15 Μαΐου 2006

Posted by Νικόλας in .NET, Web Development, Windows.
Tags: , , ,
7 Σχόλια

Αντιμετώπισα πρόσφατα ένα κλασσικό πρόβλημα. Μετέφερα μία βάση δεδομένων και μία web application από έναν server σε κάποιον άλλο. Για την ακρίβεια μετέφερα μία MySQL/PHP εφαρμογή από έναν Linux hosting provider σε έναν windows hosting provider.

Τί έγινε, μόλις τέλειωσα το Upload. Ο χαμός! Εκτός από τα χρώματα, όλα τα άλλα εμφανιζόντουσαν λάθος. Από PHP και MySQL δεν μπορώ να πω ότι κατέχω και ιδιαιτέρως (εντάξει δεν ξέρω, αλλά δεν το μαρτυράω), αλλά δεν άργησα να καταλάβω τί φταίει (και όχι δεν φταίει η αλλαγή από Linux σε Windows). Η νέα MySQL χρησιμοποιεί ως default encoding το latin1_swedish_ci (όπου ci Case Insensitive). Τα δεδομένα όμως μέσα στη βάση δεδομένων είχαν αποθηκευθεί ως greek (ISO 8859-7). Τέλος τα php χρησιμοποιούσαν ως template HTML αρχεία με δηλωμένο HTML encoding το ISO 8859-7 ωστόσο τα Connection Strings «τραβούσαν» τα δεδομένα από τη βάση με UTF-8.

Ωραίο μπάχαλο ε;!

Παλαιότερα, είχα ένα παρόμοιο πρόβλημα. Τα encodings μου στο ASPX ήταν σωστά, η βάση μου είχε σωστό Collation, αλλά μόλις τα ανέβασα στον provider, «μεταφράστηκαν» τα πάντα σε Κινέζικα.

Σήμερα, έπεσα πάνω σε ένα ερώτημα στο dotnetzone.gr, σχετικά με τα Ελληνικά και το σωστό encoding. Η φόρμα σωστή, το encoding σωστά δηλωμένο ως ISO 8859-7, αλλά μόνο οι Αγγλικοί χαρακτήρες «έφταναν». Οι Ελληνικοί έχαναν το δρόμο.

Πού θέλω να καταλήξω; Απλά να δώσω μια απλή και συνολική απάντηση σε όλα τα παραπάνω προβλήματα.

Ξεχάστε την εθνική υπερηφάνια, γιατί όσο και να λέμε ότι έχουμε δικό μας, κατά δικό μας προσωπικό εθνικό format, το ISO 8859-7 δεν τη κάνει σωστά τη δουλειά του. Ένα είναι λοιπόν το encoding και το όνομα αυτού Unicode Transformation Format – 8 ή UTF-8.

Σε ότι και αν κάνετε ΠΑΝΤΑ και ΜΟΝΟ αυτό το encoding να χρησιμοποιείται. Στο encoding της βάσης (η MS SQL έχει μία μικρή έλλειψη σε αυτό το θέμα, οπότε δηλώνετε ότι θέλετε στο collation), στο HTML encoding, στην XML, στο ASPX, ακόμα και κατά την αποθήκευση του αρχείου, πάντα να επιλέγετε UTF-8.

Και όλα τα προβλήματα θα χαθούν…

Ορισμένα παραδείγματα για τη δήλωση του σωστού (δηλ. UTF-8) encoding:

MYSQL:

@mysql_query(«SET CHARACTER SET ‘utf8′»)) και (@mysql_query(«SET NAMES ‘utf8′»)

MS SQL (είπαμε η MSSQL έχει μια μικρή έλλειψη, απλά δηλώνουμε multi-byte characters, γιατί χρησιμοποιεί Unicode):

ALTER TABLE Pinakas ALTER COLUMN Kolwna NVARCHAR(20)
και
INSERT INTO Pinakas VALUES(‘non_Unicode_Value’, Ν’Unicode_Value_N_makes_the_difference’).

HTML:

<meta http-equiv=»Content-Type» content=»text/html; charset=utf-8″>

XML:

<?xml version=»1.0″ encoding=»UTF-8″?>

ASP.NET:

<%@ Page Language=»C#» ContentType=»text/html» ResponseEncoding=»utf-8″ %>

WEB.CONFIG:

<?xml version=»1.0″ encoding=»utf-8″ ?>
<configuration>
<system.web>
<globalization requestEncoding=»utf-8″ responseEncoding=»utf-8″ />
</system.web>
</configuration>

Χρήσιμα Links

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

Posted by Νικόλας in SQL.
Tags: , ,
add a comment

Πριν από μερικές εβδομάδες, με πήρε τηλέφωνο ένας πελάτης για να μου αναφέρει ένα πρόβλημα που παρουσιάστηκε στην εφαρμογή του. Μια εφαρμογή γραμμένη σε 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