Σε προηγούμενα μου posts μίλησα για την διαδικασία του upgrade σε SQL Server 2012. Σε αυτό θα σας δώσω μερικές συμβουλές για το πως μπορείτε να κάνετε migration μια ή περισσότερες databases από μια παλαιότερη έκδοση του SQL Server σε SQL Server 2012.

Οι προτεινόμενοι τρόποι για να γίνει κάτι τέτοιο είναι οι παρακάτω και δεν υπάρχει καλύτερος ή χειρότερος τρόπος. Ο κάθε ένας έχει τα συν και τα πλην του και θα πρέπει να κατανοήσουμε αυτά πριν διαλέξουμε αυτόν με τον οποίο θα δουλέψουμε.

Method: Detach Database

Μια από τις προτεινόμενες διαδικασίες για database migration είναι αυτή του να κάνουμε detach την database μας από το instance τις προηγούμενης έκδοσης, να μεταφέρουμε τα αρχεία αυτής στο νέο SQL Server 2012 instance και να κάνουμε attach.

Για να μπορεί όμως να γίνει κάτι τέτοιο θα πρέπει να υπάρχουν οι εξής προϋποθέσεις:

1. Η database να μην συμμετέχει σε διαδικασίες replication. Σε αυτή την περίπτωση θα πρέπει να κάνουμε unpublish αυτή.
2. Να μην είναι σε database mirroring. Σε αυτή την περίπτωση θα πρέπει να καταργηθεί το mirroring.
3. H database να μην έχει database snapshots. Σε αυτή την περίπτωση θα πρέπει να σβήσουμε όλα τα snapshots.
4. Να μην είναι system database. Αυτό το γράφω για την περίπτωση που κάποιος θα πει ότι θέλει να μεταφέρει πχ την msdb.
5. Να μην είναι συνδεδεμένοι χρήστες στην database.

Να επισημάνω για την περίπτωση που κάποιος θεωρήσει ότι η διαδικασία αυτή μπορεί να λειτουργήσει και αντίστροφα ( από SQL Server 2012 σε SQL Server 2005, 2008, 2008R2) ότι αυτό δεν μπορεί να γίνει καθώς δεν υπάρχει περίπτωση μια database μεγαλύτερης έκδοσης να γίνει database μικρότερης έκδοσης.

Την διαδικασία αυτή μπορείτε να την πραγματοποιήσετε είτε μέσα από το SSMS είτε με την sp_detach_db, CREATE DATABASE FOR ATTACH.

Σε κάθε περίπτωση θα πρέπει να έχουμε συνειδητοποιήσει ότι αυτό θα βγάλει την βάση μας από την παραγωγή από τον παλαιό server και θα είναι πάλι διαθέσιμη στην παραγωγή σε τέτοιο χρόνο που είναι αυτό που χρειάζεται για να  μεταφερθεί η βάση στον νέο server,  να γίνει πάλι attached, να ενημερωθούν τα connection strings των εφαρμογών που χρησιμοποιούν αυτή, και τέλος να μεταφερθούν και τα logins που χρειάζονται για να μπορούν οι users να συνδέονται στον SQL Server και στη συγκεκριμένη databases.

Συνολικά αυτός είναι και χρόνος του downtime που θα έχουμε. Με την ολοκλήρωση της διαδικασίας αυτής οι users συνεχίζουν από το σημείο που έγινε detached η database.

Και μια παρατήρηση σχετικά με το db compatibility level για την περίπτωση μας. Αν η βάση μας που θα γίνει attached στον SQL Server 2012 είναι σε compatibility level 80 ή μικρότερο αυτό θα γίνει 90. Αν είναι 90 ή 100 αυτό θα παραμείνει ως έχει.

Method: Backup / Restore database.

Επόμενη προτεινόμενη μέθοδος για την υλοποίηση του migration είναι να κάνουμε backup την database που είναι στο instance της προηγούμενης έκδοσης του SQL Server και την οποία θέλουμε να μεταφέρουμε στο νέο μας SQL Server 2012 instance κάνοντας την restore σε αυτό.

Με την διαδικασία αυτή στην ουσία πετυχαίνουμε να μεταφέρουμε την βάση μας χωρίς να έχουμε διακοπή στην εργασία των χρηστών. Όμως στην ουσία αυτό που μεταφέρουμε είναι ότι περιέχει το backup που έχουμε πάρει. Αυτό σημαίνει ότι αν μετά από την ολοκλήρωση του backup γίνουν αλλαγές στη βάση όπως εισαγωγή νέων δεδομένων ή αλλαγές σε υπάρχοντα, αυτά δεν θα είναι διαθέσιμα στον νέο server. Για την επίλυση του θέματος αυτού μπορούμε να δράσουμε με πολλούς διαφορετικούς τρόπους και πάντα σε συνάρτηση με το μέγεθος της βάσης.

Σε κάθε περίπτωση όμως θα υπάρξει κάποιος χρόνος που η μεταφερόμενη βάση θα πρέπει να μην είναι διαθέσιμη στο instance της προηγούμενη έκδοσης. Συγκεκριμένα:

1. Αν η βάση μας είναι μικρή μπορούμε να σταματήσουμε την δραστηριότητα πάνω σε αυτή να κάνουμε full backup και αυτό να το μεταφέρουμε στο SQL Server 2012 instance και να το κάνουμε restore. Μετά από αυτό να αλλάξουμε τις εφαρμογές και να βλέπουν το instance του SQL Server 2012.
2. Αν η βάση μας είναι μεγάλη μπορούμε να πάρουμε full backup σε αυτή χωρίς να σταματήσουμε την δραστηριότητα πάνω σε αυτή, όπως δηλαδή κάνουμε με το καθημερινό μας backup. Αυτό το κάνουμε restore with norecovery στο SQL Server 2012 instance. Αυτό το κάνουμε γιατί θέλουμε να κάνουμε restore την μεγάλη μας βάση που πιθανόν να χρειαστεί ώρες για να γίνει αλλά δεν την φέρνουμε σε κατάσταση λειτουργίας και ο λόγος είναι φυσικά ότι θέλουμε να μεταφερθούν οι αλλαγές που έχουν γίνει στο διάστημα αυτό. Για να κάνουμε κάτι τέτοιο μπορούμε στο παλαιό instance να πάρουμε transaction log backup, αφού έχουμε σταματήσει την δραστηριότητα σε αυτή την βάση και  το οποίο κάνουμε restore στο SQL Server 2012 instance with recovery. Με αυτό τον τρόπο μειώνουμε το χρόνο του downtime.

Φυσικά υπάρχουν και άλλα σενάρια που μπορούμε να φτιάξουμε με την χρήση της μεθόδου αυτής ώστε να καλύψουμε όλο και περισσότερες ανάγκες και φυσικά να έχουμε το μικρότερο δυνατό downtime.

Μια παρατήρηση μόνο. Πρέπει να μεταφερθούν και τα logins από το παλαιό instance στο νέο  για να μπορούν οι χρήστες αφενός να κάνουν Login και αφετέρου να χρησιμοποιούν την βάση αυτή.

Method: Copy database Wizard

H τελευταία ουσιαστική μέθοδος μεταφοράς μιας βάση είναι αυτή με την χρήση του Copy Database Wizard. Ουσιαστικά με την μέθοδο αυτή μπορούμε κάνουμε μεταφορά στον νέο Instance και διαγράφη από το παλαιό, κάτι αντίστοιχο με την πρώτη μέθοδο detach/attach αλλά με αυτοματοποιημένο τρόπο. Επίσης με αυτόν μπορούμε να κάνουμε την μεταφορά των logins, των jobs των τυχών custom errors. Ακόμα μπορούμε να προγραμματίσουμε το πότε θέλουμε να γίνει ξεκινήσει η διαδικασία.

Οι προϋποθέσεις για να γίνει αυτό είναι  οι ίδιες με την μέθοδο detach/attach που έχω αναφέρει και παραπάνω. Απλά για να γίνει η διαδικασία αυτή θα πρέπει ο χρήστης που θα την κάνει να είναι sysadmin στους SQL Servers. Τέλος θα πρέπει να είναι ενεργοποιημένος ο SQL Server Agent και στα δύο εμπλεκόμενα instances.

Όπως ανέφερα και προηγούμενα είναι κάτι αντίστοιχο με την διαδικασία detach/attach. Πράγματι όταν ξεκινάμε το wizard μας δίνει δύο επιλογές για το πώς θα δουλέψουμε η μία είναι η μέθοδος detach/attach. Ισχύουν όλα όσα έχω ήδη αναφέρει για αυτή. Εύκολη στην υλοποίηση και γρήγορη διαδικασία, απλά μέχρι να ολοκληρωθεί δεν είναι διαθέσιμη η βάση στους χρήστες.

Υπάρχει όμως και η επιλογή της μεταφοράς των αντικειμένων της βάσης με την χρήση του SMO (SQL Management Object). Με την διαδικασία αυτή επιτυγχάνουμε το να είναι online η βάση στο instance το παλαιό αλλά σχετικά είναι αργή η όλη διαδικασία μεταφοράς στο νέο instance του SQL Serve 2012.

Τέλος θα πρέπει να επισημάνω ότι για την υλοποίηση των μεθόδων που έχει ο wizard αυτός απαιτείτε η ύπαρξη των SQL Server Integration Services.

Method: Script Generation/Publish to Web Service.

Μια ακόμα μέθοδος υπάρχει που είναι όμως ειδικού σκοπού. Το να μεταφερθεί η βάση μας σε κάποιον web hosting provider. Φυσικά αυτό είναι κάτι το οποίο πρέπει να υποστηρίζει ο provider και ο οποίος θα πρέπει να μας έχει εξοπλίσει με τα απαραίτητα δεδομένα για την επίτευξη της συγκεκριμένης διαδικασίας. Δεν θα αναφερθώ λεπτομερώς στο post αυτό αλλά μπορείτε να διαβάσετε για αυτή στα BOL. Σε επόμενο post θα μιλήσω για αυτή.

Μεταφορά Logins

Όπως ήδη έχω αναφέρει παραπάνω εκτός από την μεταφορά της βάσης θα πρέπει να μεταφέρουμε και τα logins. Αυτό μπορεί να γίνε με πολλούς τρόπους:

1. Να δημιουργήσουμε τα scripts αυτών από το αρχικό μας instance και αυτά να τα τρέξουμε στο νέο. Φυσικά θα πρέπει να έχουμε φροντίσει να έχουμε και τα αρχικά SID καθώς αν δεν το κάνουμε αυτό θα δημιουργηθούν μεν αυτά αλλά με άλλα SID που στην ουσία θα είναι και άχρηστα.
2. Μπορούμε να φτιάξουμε SSIS Package στο οποίο να βάλουμε το task Transfer Logins.
3. Μπορούμε να δημιουργήσουμε την sp_help_revlogin και με αυτή να κάνουμε την όλη διαδικασία. Περισσότερα για αυτή σε παλαιότερο μου post.

/*antonch*/