SQL Server: Gestione della migrazione

Database massicci migrazione mai possono essere chiamati un compito facile, ma Microsoft ha uno strumento disponibile che può contribuire ad alleviare il modo e garantire che siete pronti.

Welly Lee

L'iterazione più recente di SQL Server, nome in codice "Denali," offre molte caratteristiche interessanti e guiderà molte organizzazioni per passare a SQL Server. Anche con le prestazioni e costo totale di proprietà (TCO) vantaggi per lo spostamento a SQL Server, però, alcune organizzazioni possono avere preoccupazioni circa il costo e il rischio per la migrazione di database.

Fortunatamente, Microsoft fornisce uno strumento, SQL Server Migration Assistant (SSMA), per automatizzare il processo di migrazione. La più recente SSMA v. 5.1 (pubblicato questo mese allo stesso tempo con SQL Server Denali CTP3) supporta migrazione dai database Oracle, Sybase, MySQL e accesso a SQL Server. È possibile utilizzare SSMA per facilitare il vostro progetto di migrazione di database. Ad esempio, qui è un guardare il processo di migrazione da un database Oracle — il processo e i passaggi sono gli stessi durante la migrazione da altri database.

Valutare il tuo Database

SSMA automatizza la migrazione della maggior parte degli oggetti di database, tra cui stored procedure e trigger, funzioni, pacchetti. Ci sono alcuni tipi di dati speciale come tipo di oggetto o di tipo spaziale supportate dalla versione corrente di SSMA. Inoltre, si possono anche avere la istruzioni di PL/SQL complesse che non possono essere convertite automaticamente. È possibile utilizzare SSMA per eseguire una valutazione migrazione sul database Oracle e determinare se lo schema del database contiene tali dichiarazioni.

Le relazioni di valutazione sommaria contengono le seguenti informazioni:

• Vista ad albero dello schema: un elenco di oggetti dallo schema del database Oracle fonte.
• Tasso di conversione: la percentuale di istruzioni che SSMA è in grado di convertire automaticamente. In questo esempio (vedere Figura 1), lo strumento SSMA può convertire il 99.39 per cento di tutte le istruzioni dello schema di origine Oracle.
• Oggetto conte: il numero di database oggetti trovati nello schema di Oracle e un conteggio degli oggetti "con errori" (più su questo più tardi).
• **In breve messaggio di conversione:**una descrizione dei problemi durante la migrazione di schema di origine Oracle.

Ci sono tre tipi di messaggi di conversione incontrerai durante una migrazione utilizzando lo strumento SSMA: errore, avviso e informazioni:

• Un messaggio di errore viene generato quando SSMA non è in grado di convertire un oggetto di database o un'istruzione all'interno di un oggetto di database.
• A messaggio di avviso viene generato quando SSMA è in grado di convertire l'istruzione di Oracle, ma l'istruzione convertito non possa produrre lo stesso risultato per alcuni casi. Ad esempio, SSMA converte substr Oracle SQL Server substring (). Nella maggior parte dei casi, substring () restituirà le uscite stesse. Ci sono alcune situazioni, tuttavia, dove i risultati sono differenti. Ad esempio, la funzione substr Oracle supporta i valori negativi per la posizione del carattere. SUBSTR('TechNet',-3,3) restituisce la "Rete" in Oracle, mentre SUBSTRING('TechNet',-3,3) restituisce una stringa vuota in SQL Server.
• Un messaggio informazioni è per SSMA fornire ulteriori informazioni su come converte determinati oggetti.

Figura 1 un'occhiata al tasso di conversione quando si converte un database Oracle.

Ogni messaggio di errore include un link che consente di visualizzare l'oggetto che contiene l'errore. C'è anche un confronto-by-side con l'istruzione originale a sinistra e che cosa l'istruzione convertito assomiglierebbe in SQL Server (vedere Figura 2) sulla destra. Il messaggio di errore include anche una stima di quante ore di conversione manuale in genere sarebbero tenute a risolvere il problema.

Figura 2 occasionalmente si otterrà un messaggio di errore di migrazione.

Maggior parte delle organizzazioni spesso eseguire valutazioni contro un certo numero di schemi di database Oracle. Useranno il tasso di conversione totale e il tempo totale stimato di conversione manuale per confrontare e dare la priorità dello schema di database Oracle per la migrazione.

Conversione dello Schema di Database

SSMA ti dà molte opzioni per la conversione dello schema. Ad esempio, è possibile modificare il mapping del tipo di dati. SSMA fornisce mapping di tipo di dati predefinito tra Oracle e SQL Server. Tuttavia, è possibile personalizzare il mapping dei tipi di dati per una tabella specifica, per tutte le tabelle, per un oggetto specifico (ad esempio una stored procedure o una funzione) o per l'utilizzo di differente (ad esempio il tipo di dati in una colonna, il tipo di dati nella variabile o tipo di dati nel parametro di input/output della routine).

Convertire lo schema del database facendo clic sul pulsante "Convertire Schema". Allora si può passare all'oggetto database diverso e confrontare l'oggetto dello schema originale e l'oggetto convertito (vedere Figura 3)

Figura 3 vista la conversione dello Schema.

Quando un oggetto contiene un'istruzione che SSMA non è in grado di convertire automaticamente, lo strumento Aggiungi una descrizione errore di migrazione, commentare le specifiche o sostituirlo con un tipo generico. Questo approccio di isolamento consente di continuare con la migrazione di database e risolvere il problema più tardi.

Si potrebbe anche risolvere il problema e modificare l'istruzione direttamente da SSMA. Ad esempio, in Figura 3, c'è una funzione definita dall'utente denominata "Mandato". Questo metodo restituisce un tipo di dati di intervallo che non supporta SQL Server. È possibile modificare il tipo restituito al numero (vedere Figura 4) e la funzione di riconvertire. Questo rimuove l'errore e converte il valore restituito in float(53).

Figura 4 È possibile modificare le dichiarazioni in SSMA per risolvere incompatibilità.

È inoltre possibile modificare le dichiarazioni convertite. Ad esempio, è possibile sostituire il tipo restituito di "float(53)" con "Int." Si noti che qualsiasi modifica apportata con SSMA archiviato localmente. Le modifiche apportate alle dichiarazioni di origine non sono applicate per lo schema del database Oracle che avete in produzione. Analogamente, le eventuali modifiche apportate alla destinazione istruzione SQL Server non sono applicati immediatamente al server. Ciò consente di continuare a perfezionare e apportare le necessarie modifiche allo schema convertito senza influire sul vostro server di destinazione.

Facendovi clic sopra il nome dello schema della finestra Esplora i metadati di SQL Server, è possibile distribuire dello schema convertito alla destinazione SQL Server. È anche possibile generare uno script per creare le informazioni di intero schema, che è quindi possibile distribuire sul server di destinazione (vedere Figura 5).

Figura 5 distribuzione convertito schema per SQL Server.

Migrazione dei dati

Dopo aver creato lo schema del database nella destinazione SQL Server, è possibile utilizzare SSMA per migrare i dati di Oracle. SSMA non è l'unica opzione per la migrazione dei dati, però. È anche possibile utilizzare SQL Server Integration Services (SSIS). Tuttavia, migrazione dei dati con SSMA consente di utilizzare lo stesso tipo di mapping per la conversione dello schema. Esso gestisce anche alcuni dei problemi di migrazione dei dati comuni durante la migrazione da Oracle a SQL Server.

Ad esempio, Oracle ha una vasta gamma di tipi di date supportati da SQL Server. Per impostazione predefinita, SSMA genera l'errore di migrazione dati quando rileva un caso del genere. Si può avere SSMA convertire automaticamente i valori di data out-of-range con NULL o la data più vicina in grado di supportare SQL Server. È possibile modificare questa impostazione attraverso strumenti | Impostazione del progetto | Generale | Migrazione dei dati (vedere Figura 6).

Figura 6 ci sono opzioni per la gestione degli errori di migrazione dei dati.

Dopo aver completato la migrazione dei dati, la volontà SSMA migrato mostra una relazione con il numero di righe, il tasso di successo e i tempi di presa per eseguire la migrazione di ogni tabella (vedere Figura 7).

Figura 7 SSMA vi darà un report completo di migrazione dei dati.

Verifica della migrazione di Database

Dopo che hai migrazione database, il passo successivo è la convalida. Quando la migrazione da Oracle e Sybase, SSMA permette di confrontare il database di origine e migrati. È possibile definire una serie di casi di test; SSMA esegue quindi i casi di test sia la fonte e il database di destinazione. Metterà a confronto i risultati, come pure eventuali modifiche dei test case fatti sulle tabelle sottostanti.

Per definire un banco di prova, selezionare nuovi casi di Test dal menu Tester. Una procedura guidata Test Case vi guiderà attraverso il processo di creazione di un banco di prova. È inoltre possibile selezionare oggetti di database specifico per testare. Ad esempio, esiste una procedura chiamata ADD_EMPLOYEE. Questa procedura consente di inserire un nuovo record della tabella employee in base al valore fornito dal parametro di input. È possibile definire i parametri di input specifici da utilizzare nella prova attraverso la scheda valori Call (vedere Figura 8). È possibile definire come molti valori chiamata come avete bisogno.

Figura 8 Specifying chiamare valori nel caso di Test guidata.

Oltre ad oggetto l'esecuzione del test di confronto, SSMA può anche testare le modifiche alla tabella sottostante. Ad esempio, quando l'esecuzione il ADD_EMPLOYEE stored procedure, SQL Server sarà inserire una riga aggiuntiva nella tabella dipendenti. SSMA confronta le righe modificate nella tabella colpita tra l'origine e la destinazione. Se necessario, è inoltre possibile specificare il livello di granularità per il confronto (vedere Figura 9).

Figura 9 Specifying tabelle sottostanti per confronto.

Il passaggio finale nel definire i test case è impostazioni aggiuntive. Una impostazione importante è se il rollback di tutte le modifiche apportate alla tabella di test (vedere Figura 10). Nel mio esempio, quando la ADD_EMPLOYEE in esecuzione di stored procedure, un nuovo record verrà aggiunti al database Oracle di origine sia il database di SQL Server di destinazione. Se si seleziona l'opzione di ripristino dati, SSMA rimuoverà il valore inserito dopo il test è completo.

Figura 10 impostazioni di test case di definizione.

Dopo aver definito il caso di test, è possibile eseguire molte volte come necessari. Per ogni esecuzione, riceverai un report di risultato del test che confronta i risultati (vedere Figura 11).

Figura 11 SSMA vi darà una prova completa di risultato report.

SSMA offre ricche funzionalità per automatizzare la migrazione di database. È possibile utilizzare lo strumento per valutare la complessità del database si intende migrare, convertire lo schema del database, risolvere problemi comuni relativi alla migrazione di database, la migrazione dei dati dal database di origine e convalidare il database migrato.

Lo strumento è stato progettato per la migrazione a SQL Server, ma supporta anche diretto migrazione a SQL Azure (dal database MySQL, Sybase e accesso). Durante la migrazione a SQL Azure, SSMA prende in requisiti relativi all'account per la piattaforma SQL Azure. Ad esempio, SQL Azure richiede che le tabelle abbiano un indice cluster. Se la tabella di origine non include una chiave primaria o indice cluster, lo strumento può automaticamente aggiungere una colonna ROWID e imposta l'indice cluster nella colonna durante la conversione.

È possibile Scarica SSMA dal sito Web di Microsoft SQL Server. Non solo è lo strumento gratuito, ma è anche possibile ottenere supporto e-mail gratuito da servizio clienti Microsoft e supporto. Per ulteriori informazioni su SSMA, visitare il il blog del team SSMA per una dimostrazione video e articoli pratici, come pure la guida sulla risoluzione dei problemi comuni relativi alla migrazione.

Welly Leeè un senior program manager con il team di SQL Server Migration Assistant, ed è il proprietario di funzionalità per lo strumento di migrazione di database da Oracle e MySQL per SQL Server. Prima di unirsi a Microsoft nel 2007, ha lavorato come consulente per lo sviluppo di soluzioni database e implementazione di applicazioni enterprise per più di 10 anni.

Contenuto correlato

• SQL Server: Pianificazione della migrazione a SQL Server 2008 R2
• SQL Server: Protezione dei dati a tutti i costi
• Lavorare insieme: SQL Server 2008 R2 Reporting Services Integration in SharePoint 2010