Migrazione da MSSQL a MySQL - problemi di codifica del char con coppie di surrogati UCS-2, come posso rimuoverli dal database MSSQL?

Question

Mi è stato assegnato il compito di migrare un database Microsoft SQL Server 2005 a MySQL 5.6 (questi sono entrambi i server di database runnig localmente) e apprezzerei davvero un po 'di aiuto.

-Il database di origine MSSQL ha collazione latin1 (quindi ha il set di caratteri ISO 8859-1 giusto?) Ma non ha campi char/varchar (qualsiasi campo stringa è nvarchar/nchar), quindi tutti i dati devono utilizzare il Set di caratteri UCS-2.

-MySQL database di destinazione vuole il set di caratteri UTF-8

ho deciso di utilizzare il toolkit di migrazione di database nella versione più recente del Workbench MySQL. all'inizio ha funzionato bene e ha migrato tutto come previsto. Ma sono stato totalmente inciampato nell'incontrare i personaggi della coppia surrogata UCS-2 nel database MSSQL.

Il programma di copiatura del programma di copia non ha fornito un messaggio di errore molto utile: "Errore durante la conversione del charset di wstring: nessun errore". Inoltre, non forniva alcuna informazione sul campo/riga sui dati che causavano problemi e falliva in blocchi di 100 righe. Quindi, dopo aver cercato tra le 100 righe dopo l'ultimo inserimento riuscito, ho scoperto che il problema sembrava essere causato da due caratteri UCS-2 in uno dei campi nvarchar. Sono elencati come coppie sostitutive nel set di caratteri UCS-2. Erano specificatamente i caratteri DBC0 e DC83 (ho ottenuto questo osservando i dati binari per il campo e confrontando le coppie di byte (little endian) con i dati che venivano migrati con successo).

Quando questa coppia di surrogati è stata rimossa dal database MSSQL, la riga è stata migrata correttamente su MySQL.

Qui è il problema:

Ho provato a cercare questi personaggi in una tabella di test MSSQL (questa tabella chartest si trova a soli varie stringhe di prova di un campo nvarchar) per preparare uno script di sostituzione e continuo a ricevere strani risultati. .. Devo fare qualcosa in modo errato.

Ricerca di

SELECT * FROM chartest WHERE text LIKE NCHAR(0xdc83) 

tornerà carattere coppia di surrogati (se utilizza DC83), ma ovviamente, solo se è l'unico carattere (o parte della coppia) in quel campo. Questo non è un grosso problema dal momento che mi piacerebbe rimuovere qualsiasi istanza di questi comunque (non mi piace rimuovere dati come questo ma penso che possiamo permettercelo).

Ricerca di

SELECT * FROM chartest WHERE text LIKE '%' + (NCHAR(0xdc83))+ '%' 

Will return ogni riga! Indipendentemente dal fatto che abbia o meno un carattere unicode presente nel campo, figuriamoci il carattere DC83. C'è un modo migliore per trovare e sostituire questi personaggi? O qualcos'altro dovrei provare?

Ho anche provato a impostare il databse di destinazione, la tabella e il set di caratteri del campo su UCS-2 ma sembra che non faccia la differenza.

Vorrei anche ricordare che questa migrazione sta usando dati in tempo reale (~ database di 50 GB!), Mentre uno dei siti che lo alimenta è presa in linea in modo che qualsiasi soluzione a questa necessità di avere un tempo di esecuzione rapido ...

Apprezzerei molto ogni suggerimento! Per favore fatemi sapere se ci sono delle informazioni che ho omesso.

Answer 1

Questo problema è stato risolto. Ho usato utente Remus Rusanu's suggerimento here per trovare le righe con questi personaggi coppia di surrogati utilizzando CHARINDEX e hanno deciso di utilizzare SUBSTRING per escludere i caratteri problematici in questo modo:

UPDATE test 
SET a = SUBSTRING(a, 1, (CHARINDEX(0x83dc, CAST(a AS VARBINARY(8000)))+1)/2 - 1) -- string before the unwanted character 
+ SUBSTRING(a, (CHARINDEX(0x83dc, CAST(a AS VARBINARY(8000)))+1)/2 +1, LEN(a)) -- string after the unwanted character 
WHERE CHARINDEX(0x83dc, CAST(a AS VARBINARY(8000))) % 2 = 1 -- only odd numbered charindexes (to signify match at beginning of byte pair character) 

Answer 2

ho avuto questo errore, e ora ho scoperto la fonte del problema. Ho avuto difficoltà a scoprirlo, quindi forse questo sarà utile a qualcuno, anche se mi rendo conto che il mio problema e la soluzione alternativa potrebbero non essere azzeccati nel corrispondere al problema originale dell'op.

Sto migrando i dati da MSSQL a MySQL e il contenuto da migrare è contenuto html da Sitecore CMS (CMS di destinazione è Drupal, btw).

Ho riscontrato che ottengo questo errore durante la conversione del database e il rilevamento di record, che contengono Instagram-embed. Instagram-incorpora lavoro nel modo in cui i dati di post incorporati vengono copiati nel codice di incorporamento (invece di essere caricati asincroni., Etc. - anche l'immagine è inclusa come base64-css ...), e i giovani al giorno d'oggi tendono a mettere un sacco di emoji nelle loro descrizioni di immagini (usando i loro iPhone con tastiera Emoji). Gli Emoji sono rappresentati da caratteri codificati a 4 byte, ma MySQL utf8 consente solo caratteri unicode codificati a 3 byte.

mio errore iniziale esecuzione wbcopytables.exe (che è il modo non-GUI di fare Migrazione guidata in MySQL Workbench) è stato il

Error during charset conversion of wstring: No error

ma l'aggiornamento per MySQL Workbench versione recente (da 5.something a 6.x) rende l'errore un po 'più descrittivo, suggerendo tavola e colonna (purtroppo, non riga):

ERROR: Could not successfully convert UCS-2 string to UTF-8 in table [MyDatabase].[dbo].[MyTable] (column MyColumn). Original string: ...

Comunque - una soluzione * * potrebbe essere quella di utilizzare utf8mb4 che consentirebbe l'emoji. Maggiori informazioni here.

Ma sembra, è a bad idea per fare questo, ad es. il mio caso con Drupal.

Quindi, la soluzione alla quale ho avuto a che fare è stato semplicemente rimuovere questi caratteri nel mio script di migrazione. Non ha senso tenerli per gli utenti del sito in questione, poiché sono comunque visualizzati come rettangoli sulla pagina web. Poiché non è possibile eseguire la ricerca e la sostituzione con espressioni regolari in SQL Server, ho elaborato i dati utilizzando un DAL e C# .NET e ho trovato l'aiuto here (grazie a tonnellata, Jon Skeet) - risulta che esiste un modello regolare per abbinare la metà di una coppia surrogata in UTF-16. Vedi sotto (e usa il modello in un'altra lingua se necessario).

var noUcs2SurrogatePairsString = Regex.Replace(stringWithUcs2SurrogatePairs, @"\p{Cs}", string.Empty); 

Answer 3

ho risolto semplicemente modificando i "dati di importazione script.cmd" dove si legge colonne "Come NVARCHAR" sostituendo quelli con "VARCHAR" solo.

Nota: le colonne della mia tabella erano già di tipo VARCHAR, quindi ... per qualche stupido motivo lo script di migrazione lo ha impresso in modo non corretto al tipo UNICODE (NVARCHAR).

Answer 4

Ho avuto un problema molto simile oggi, e ho scoperto che è stato causato da stringhe vuote, li ha sostituiti con NULL o un valore che rappresenta nessun dato e la migrazione ha funzionato bene.