Il passaggio principale da eseguire è eseguire Upgrade Advisor sul database SQL Server 2000 e risolvere tutti i problemi da esso segnalati.
Come best practice, utilizzare lo strumento Upgrade Advisor sul database legacy di SQL Server 2000 e importare un file di traccia nello strumento Upgrade Advisor per l'analisi. Il file di traccia consente a Upgrade Advisor di rilevare problemi che potrebbero non essere visualizzati in una semplice scansione del database, come TSQL incorporato nelle applicazioni. È possibile acquisire tracce di TSQL utilizzando SQL Profiler sul server SQL Server 2000 durante le ore tipiche e analizzarle utilizzando Upgrade Advisor.
Quindi il resto dei passaggi sarebbe:
Il giorno della migrazione:
- script nostri accessi sul server 2000 utilizzando sp_help_revlogin .
- Eseguire lo scripting di lavori e server collegati dal server sql 2000.
- interrompere i server web che si collegano al server 2000. Assicurarsi che nessuna applicazione sia connessa al server 2000.
- eseguire il backup dei database e ripristinare sul server sql 2008 R2 di destinazione (nota: non scollegare / collegare poiché le cose potrebbero andare storte e si otterrà un database distaccato e nessun backup!)
- Una volta ripristinati i backup sul server 2008 R2, eseguire l'output da sp_help_revlogin sul server 2008 R2 per ricreare gli accessi.
- Sincronizza gli utenti orfani (se presenti) e ricrea i lavori dell'agente sql e i server collegati sul nuovo server.
- modificare il livello di compatibilità sui database ripristinati su 100.
- Dbcc checkdb con opzioni all_errormsgs e data_purity attivate:
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
- eseguire DBCC UPDATEUSAGE sui database ripristinati
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
- Aggiorna le statistiche su tutte le tabelle con scansione completa:
Update Statistics table_name with FULLSCAN
- Opzionale: controllare i livelli di frammentazione e, a seconda del livello di frammentazione, eseguire un rimbalzo / ricostruzione di tutti gli indici. Puoi usare gli script di Ola .
- Ricompila tutti gli SP utilizzando
sp_recompile 'procedureName'
- Aggiorna le tue opinioni
SP_REFRESHVIEW view_name
- assicurati di cambiare l'opzione del database: pagina verifica su CHECKSUM.
- Modificare il modello di recupero (se diverso da sql 2000) su FULL. Se si passa al modello di recupero COMPLETO, ASSICURARSI di eseguire frequentemente i backup del registro delle transazioni. Questo ti aiuterà a ripristinare il point-in-time e non gonfiare il tuo T-Log.
In SQL Server 2005 e versioni successive è stata introdotta Posta elettronica database . Quindi devi migrare da SQLMail a Posta database.
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO
Inoltre, se si dispone di una replica, è necessario reimpostarla. Se qualsiasi DR gradisce il log shipping o il mirroring (nuovi nel 2005 e successivi, ma ammortizzati nel 2012), è necessario ripristinarli.
I vecchi pacchetti DTS devono essere migrati su SSIS usando C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTSMigrationWizard.exe(riga di comando) o usando la Migrazione guidata pacchetti .
Inoltre, puoi utilizzare il mio script disponibile su /dba//a/36701/8783 . Tuttavia, utilizza il metodo scollega / collega, ti consiglio vivamente di utilizzare il metodo BACKUP / RESTORE . Cambia lo script di conseguenza.
Come nota a margine:
- attiva l' inizializzazione dei file istantanei sul nuovo server.
- Avere più file di dati tempdb con dimensioni uguali.
- Abilita flag di traccia 1118
- Configurare correttamente la memoria massima e minima. Soprattutto memoria Max lontano dal default.
- Regolare correttamente le impostazioni MAXDOP. Fare riferimento a /dba//a/36578/8783 per maggiori dettagli.
- La cosa migliore è installare sp_Blitz da Brent Ozar. Eseguilo e risolvi i problemi critici e di alta priorità segnalati da esso.
- Puoi persino utilizzare SQL Power Doc da kendalvandyke: SQL Power Doc funziona con tutte le versioni di SQL Server da SQL Server 2000 a 2012 e tutte le versioni di Windows Server e sistemi operativi Windows consumer da Windows 2000 e Windows XP a Windows Server 2012 e Windows 8. Utile anche per gli aggiornamenti di Planning: scopri quali funzioni nascoste sono in uso in un'istanza.
- Abilita Ottimizza per carichi di lavoro ad hoc e opzioni di compressione di backup predefinite.
Rispondiamo alle tue domande ...
Cos'altro dovrei fare per completare la migrazione?
Fare riferimento alla mia risposta. Ti aiuterà a elaborare correttamente un piano di migrazione. Testare sempre il piano di migrazione in un UAT (non di produzione) insieme a test delle applicazioni adeguati da parte degli utenti aziendali.
utilizzare nuove funzionalità come checksum e modello di recupero completo.
CHECKSUMè nuovo in SQL Server 2005 e versioni successive. L'ho coperto come parte dei passaggi di migrazione sopra descritti.
full recovery modelnon è nuovo. Dipende dal tipo di azienda e determina la quantità di dati che è possibile perdere in caso di disastro.
La modalità di recupero completo con frequenti backup del registro delle transazioni ti consentirà di ripristinare il punto temporale e lì riducendo la quantità di perdita di dati.
rendere questo database esattamente come è stato creato in SQL Server 2008 R2.
rendere questo database completamente compatibile, corretto e perfettamente adatto per il nuovo motore di database SQL 2008 R2.
Non capirlo completamente! Ma sopra i passaggi di migrazione ti aiuteranno. Devi solo ripristinare il database e modificare il livello di compatibilità 10 100insieme ai passaggi precedenti.
Voglio solo sapere come convertire correttamente e completamente il vecchio database SQL Server 2000 nel nuovo database 2008 R2, essere calmo che tutto è fatto bene ed essere felice con tutte le nuove funzionalità.
Devi stare attento con questo, poiché ciò richiederà anche modifiche al codice dell'applicazione. Se il codice dell'applicazione viene modificato per utilizzare le nuove funzionalità in SQL Server 2008 R2, non si verificheranno problemi. A condizione che sia stato eseguito un test di regressione completo dell'applicazione in un ambiente UAT o DEV. Ciò ti darà la massima sicurezza quando esegui la migrazione effettiva in PROD.
Nota: sopra sono alcuni passaggi che potrei ricordare e sono abbastanza sicuro che nulla è lasciato fuori. Se vedo che ho perso alcune cose, allora lo aggiungerò o altri esperti su questo sito - sentiti libero di aggiungere!
Tutto ciò che è stato descritto sopra deve essere prima riprodotto in un ambiente NON PRODUCTION per evitare sorprese durante la migrazione effettiva.
----------
Qualche altra domanda:
Mi consiglia di utilizzare il metodo di backup / ripristino, ma ho fatto come scritto sopra, quindi ora posso riscontrare problemi? Tutto ha funzionato senza alcun problema.
Se tutto ha funzionato bene e sei stato in grado di collegare il database, allora NO non avrai problemi. Scollega / Collega vs Backup / Ripristina è solo un metodo su come spostare i database in una posizione diversa. Cordiali saluti .. Backup / Ripristino è più sicuro e affidabile come se qualcosa dovesse andare storto (nei casi peggiori) quindi almeno hai un backup per ripristinare e ripristinare i tuoi database.
Informazioni sul checksum e sul modello di recupero completo: non era disponibile / abilitato su SQL Server 2000, quindi voglio usarli ora. Hai detto che l'unica cosa che devo fare è abilitare quelle opzioni nelle proprietà del database? Ho letto da qualche parte che non è abbastanza e dovrei anche ricostruire indici o qualcosa del genere. Davvero non lo so, lo sto solo chiedendo.
Come ho detto, checksum è nuovo nella versione 2005 e successive. È un meccanismo mediante il quale SQL Server rileverà il danneggiamento della pagina, in particolare a causa dell'I / O. Fare riferimento alla mia risposta qui per maggiori dettagli.
Per abilitare CHECKSUM e modificare il modello di recupero su FULL, è possibile farlo utilizzando il codice T-SQL seguente:
USE master;
GO
ALTER DATABASE [your_database_name] -- change this !!
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO
Nota: una volta impostate le opzioni del database, questo verrà mantenuto quando si esegue la migrazione da 2008R2 a 2012.
Mi sto preparando a migrare questo database su SQL Server 2012 - quindi prima era dal 2000 al 2008 R2, ora lo sarà dal 2008 R2 al 2012 (era impossibile farlo direttamente a causa della mancanza di supporto di 2000 database in SQL Server 2012). Quindi capisco che dovrei seguire la tua guida: esegui il backup nel 2008 R2 e ripristina nel 2012, quindi fai il resto dei tuoi consigli, giusto?
Sì grazie. Come ho detto, il ripristino di backup è il metodo preferito , a meno che tu non abbia una buona ragione per non farlo.
Per favore, spiegami il metodo di backup / ripristino: è come un dump del database per le query SQL e poi ripristinarlo eseguendo una serie di query? Questo metodo "deframmenterà" il mio database? In caso contrario, come deframmentarlo / ottimizzarlo manualmente?
Il backup / ripristino è ... simile al dump e al caricamento utilizzati in Sybase, Oracle o probabilmente anche MySQL. È solo SQL Server che lo chiama .. backup / restore.
A deve leggere: Comprensione dei backup di SQL Server di Paul Randall.
Sintassi semplice (per sintassi completa fare riferimento a BOL ):
backup database database_name
to disk = 'D:\backup\database_name_full.bak'
with init, stats =10
Quindi il ripristino può essere eseguito sul server di destinazione come:
- presupponendo che il layout del disco di destinazione non corrisponda a quello del server di origine
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
move 'logical_data_fileName' to 'physical_path\database_name.mdf'
move 'logical_log_fileName' to 'physical_path\database_name_log.ldf'
with recovery, stats = 10
- presupponendo che il layout del disco di destinazione corrisponda a quello del server di origine
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
with recovery, stats = 10
Questo metodo "deframmenterà" il mio database? In caso contrario, come deframmentarlo / ottimizzarlo manualmente?
il backup / ripristino non deframmenterà il database. È necessario utilizzare Alter Index Reorganize o Rebuild in base al livello di frammentazione.
Dato che sei un nuovo utente di SQL Server, ti consiglio vivamente di utilizzare Ola Hallengren:
Poiché usavamo SQL Server 2000 Express da anni (nessuna interfaccia di gestione), stavamo facendo i backup semplicemente arrestando il motore e RAR la directory DATA. Per ora, poiché siamo su SQL Server 2008, non è ancora meglio dell'uso della funzione di backup in Management Studio?
Arrestare il motore è la cosa peggiore che puoi fare per fare un backup !!
Leggi il link di Paul sui backup che ho citato e usa lo script di Ola. Microsoft ha un articolo KB con lo script per eseguire backup automatici: come pianificare e automatizzare i backup dei database di SQL Server in SQL Server Express
Modalità di recupero completo con frequenti backup del registro delle transazioni - Dove è archiviato il registro delle transazioni - è il file LDF? Come posso effettuare il backup correttamente?
Ogni database di SQL Server ha un registro che registra tutte le transazioni e le modifiche apportate al database da ciascuna transazione. Il registro delle transazioni è un componente critico di qualsiasi database.
La normale estensione della convenzione di denominazione per il registro delle transazioni è '.LDF', ma può essere qualsiasi.
Non scriverò di più su questo in quanto ciò renderà la risposta molto snella. Fare riferimento a
Gestione dei registri delle transazioni e la mia risposta qui ha anche collegamenti eccellenti.
EDIT: 24/8/2016 .. Questo aiuterà i futuri lettori:
Se si sta eseguendo la migrazione dell'intera istanza da una versione a un'altra versione, si consiglia vivamente di utilizzare la soluzione basata su PowerShellStart-SqlMigration
