arrow_back Siard --> MariaDB: Hvordan best løse feil i Spectral Core

Question

Hei,
Jeg forsøker å overføre en Siard ver. 1 base til MariaDB. Målet er å få den konvertert til Siard 2.1, men DBPTK klarer ikke jobben, så derfor denne omveien. Det er en gammel Extens-base, og Spectral Core feiler på tre tabeller. De to som har for store rader, blir ikke overført i det hele tatt. Den som har CONNECTION-feil, blir etablert, men uten rader (data).

Jeg forsøkte å endre en del kolonner av typen VARCHAR (200) til BLOB, uten at det gjorde noen forskjell.

Den andre feilen der, ang. CONNECTION, finner jeg ikke noe sted jeg kan endre på i det hele tatt.

Noen som har en idé til hva som kan gjøres for å løse opp i floken?

Comments

Kan du legge ved feilmeldingene som tekst under bildet? Enklere å lese dem da, så kan jeg også få sjekket disse litt.

---

Jeg kunne skrevet i svaret mitt under at det kan være lurt å teste Full Convert med Source = Siard 1.n som du nevner, men da med andre Target enn MariaDB

Target kan da testes mot f. eks.
- SIARD
- CSV
- MySQL
- PostgreSQL

Test mot SIARD vil gi deg indikator på fra til på både XML tabeller og LOBs.
Test mot CSV vil gi deg indikator på datainnhold.

---

Her er feilmeldingen i tekst:

[2021-12-07 08:42:13]
    Table: IST.ENHET,
    Message: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

[2021-12-07 08:42:26]
    Table: IST.INTEGRATION,
    Message: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

[2021-12-07 08:42:42]
    Table: IST.AKTIVITET,
    Message: Failed to read the result set.

[2021-12-07 08:42:42]
    Table: IST.AKTIVITET,
    Message: Failed to read the result set.
Connection must be Open; current state is Closed

---

Det kan synes som om MariaDb må konfigureres for å takle den Row size?
Eller er det spec for den databasevarianten som ikke takler dette?

Dette kan relateres til hvordan vi må sette opp MySQL for å takle store uttrekk:

Hvordan konfigurere MySQL for kontroll av ordnede (beskrevet) SIARD-uttrekk?
https://lok.as/41/hvordan-konfigurere-mysql-kontroll-ordnede-beskrevet-uttrekk?show=41#q41

Answer 1

Her fant jeg noe om din feilmelding i MariaDB row size, og mulig løsninger:
Troubleshooting Row Size Too Large Errors with InnoDB

Du må vel da opprette en tom MariaDB database og konfigurere den slik først, og så kjøre Full Convert med SIARD 1.n til MariaDB deretter.

Answer 2

1. Listeelement

Her er flere steg i prosessen som må undersøkes og konkretiseres

1. SIARD 1.n uttrekk kvalitetsikring

1. Utpakking av SIARD-uttrekket f. eks. med 7zip (eller hvis nødvendig PKZIP eller annet hvis 7zip ikke tar produsert format)
2. Kjøre PRONOM filtype-analyse av utpakkede LOBs i SIARD-uttrekket (dvs. content\schema[n]\table[n]\ de av mappene som har \lob[n] undermapper)
3. Lage en kopi av mapper med LOBs og teste med stikkprøve å endre filending til f. eks. doc eller docx for Word, .rtf for RTF osv og prøve å åpne filene

Det er en mulighet for at originalsystemet som SIARD 1.n-uttrekket ble tatt ut fra hadde lagret binære filer i CLOB tekstfelter, se egen artikkel om dette:
Binære filer i databasefelt beregnet på tekst

Hvis det ble lagret binære filer i et tekstfelt, så vil en migrering inklusiv et SIARD-uttrekk av dette feltet bli lagret som en UTF-8 tekstverdi. Der vil spesialtegn utenfor UTF-8 sitt datområde bli lagret som omvendt ? eller lignende og dermed blir originale binærfil ødelagt, eller i beste fall kan man bare få ut bruddstykker av originalfil (avhengig av hva den var).

Forøvrig kan ikke ntext konverteres direkte til blob, dette fordi databasene ikke støtter en slik direkte overgang. I stedet må man gå varchar(max) og så videre til varbinary(max). Her nevnt med MSSQL sine datatyper. Når det er MySQL/MariaDB, så må de nøyaktige muligheter for datatyper og transformasjoner testes i det miljøet. Vår erfaring er at Full Convert gjør jobben, forutsatt at de valgte datatyper faktisk er korrekt opp imot databasene som er involvert.

2) SIARD 1.n til MariaDB med Spectral Core Full Convert

Ser at du bruker Full Convert v21.11.1658, som nesten er siste versjon 21.11.1660. Jeg ville ha spurt Spectral Core via support@spectralcore.com om de nevnte feilmeldinger du får. Pass da også på at du i hovedside går inn på Options og velger Auto-fill logs, slik at du kan analysere de fulle logger fra Full Convert. Hvis Spectral Core trenger mer informasjon fra debugging så er der alternativer for debugging i setup også i Full Convert.

Answer 3

Saken er løst :)

Jeg sjekket med supporten til Spectral Core også, og de refererte meg til samme informasjonen som Torbjørn. Etter å ha endret alle forekomster av datatype varchar til text, løsnet det for to av tabellene, og de ble overført.

Den siste, IST.AKTIVITET, feilet fortsatt med samme melding

      Table: IST.AKTIVITET,
          Message: Failed to read the result set.

I tillegg dukket det opp en advarsel som tidligere hadde druknet i alle de andre;

      Table: IST.AKTIVITET, 
      Message: Index - Skipping index PK_U_AKTIVITET on table IST.AKTIVITET, some columns can't be found "SYS_NC00113$, SYS_NC00114$, SYS_NC00115$, SYS_NC00116$, SYS_NC00117$, SYS_NC00118$" 

Jeg sjekket igjen med supporten, og de svarte:

"What I believe happened is that the original SIARD file was created
from Oracle (columns named SYS_NC% are typically hidden virtual
columns created to support function based indexes in Oracle databases)
and the app captured even those automatically generated indexes. Now,
when the database is restored on another database type - MariaDB, this
warning shows that those columns are missing."

Status på basen i MariaDB var nå at alle tabellene var etablert, bortsett fra "spøkelseskolonnene" i IST.AKTIVITET. De øvrige kolonnene i den tabellen var på plass, men uten noen rader. Ingen av dataradene, 27K til sammen, kom med over.

Litt mer diskusjon med supporten endte med at jeg skrudde på

"Insert 1 record at a time" 

...og dermed kom de på plass.

Det interessante å ta med seg her, er vel at Oracle produserer virtuelle kolonner i tabeller, og disse kan skape problemer senere. Har noen av dere andre vært borti denne problemstillingen, og evt. funnet måter å unngå problemet på?

Tusen takk for hjelpen, Torbjørn og Ole :)