FireDAC: Fjöldainnsetning með Array-DML og nákvæmri villumeðhöndlun fyrir hverja röð

Ein BDE-endurnýjun með innbyggðu tengi Bulk-Insert mit Array DML er oft hraðasta leiðin til að koma mörgum færslum í gagnagrunn: í stað þúsund einstakra INSERTs er breytulisti bundinn og sendur í einni lotu til þjónsins. Í rekstri kemur hins vegar fljótt viðkvæmur punktur: ein færsla brýtur Unique-Index, eitt NOT NULL-svið er tómt, einn Foreign Key passaði ekki – og skyndilega er óljóst, hver lína stöðvaði batch-ið, hvort hluti hafi þegar verið skrifaður og hvernig þú heldur áfram á öruggan hátt án þess að skapa gagnamisræmi.

Þetta snýst einmitt um það: hvernig þú notar Array DML svo að þú fáir fyrir hverja línu áreiðanlegar villuupplýsingar, heldur utan um viðskiptana (transaction) og getur rekjað í rekstri hvað gerðist. Áherslan er ekki á akademíska API-lestur, heldur á jaðartilfellið sem kemur reglulega upp í raunverulegum innflutningum: stórt batch, fáar brotnar línur, en þú vilt samt hraða.

FireDAC Bulk-Insert mit Array DML: Af hverju er Array DML þess virði við Bulk-Insert

Array DML (Data Manipulation Language) þýðir í FireDAC: þú bindur parameter ekki sem einstakan gildi heldur sem fylki. FireDAC sendir þá (eftir drifara/DB) færri roundtrips, getur unnið skilvirkari á þjónsíðunni og dregur verulega úr yfirkostnaði í client-inum. Þetta er sérstaklega mikilvægt í þremur aðstæðum:

• ETL- og innflutningsleiðir: CSV/XML/JSON inn, normalisering/mapping, síðan í staging- eða marktafluna.
• Tengja-puffrar: REST- eða MQ-payloads eru safnað og vistaðar reglulega.
• Skráninga-/event-töflur: margar litlar INSERTs þar sem latensinn ræður för.

Ávinningurinn kemur þó ekki ókeypis. Með Array DML flytur þú flækjustigið frá „mörg einstaklings-statement“ yfir í „eitt statement með mörgum línum“. Þetta er gott fyrir frammistöðu, en krefst meiri vinnu við villugreiningu, transaktional lógík og endurkeyrslu.

Algengt jaðartilfelli: eitt Batch, ein biluð lína

Klassík í rekstri: þú import-ar 50.000 línur. Þú velur ArraySize 1.000, því þú vilt ekki roundtrip fyrir hverja línu. Batch 17 bilar. Gagnagrunnurinn skilar aðeins „duplicate key“ eða „violates foreign key constraint“. Í UI eða service-logginu stendur þá oft aðeins: „ExecSQL failed“.

Án hreinnar villumeðhöndlunar gerast þá yfirleitt tvö slæm atriði:

• Þú hentir öllu batch-inu, þótt 999 af 1.000 línum væru í lagi.
• Þú rennir aftur í einstök INSERTs og tapar frammistöðukostinum varanlega.

Markmiðið er þriðji kosturinn: viðhalda lotuafköstum, en skrá villur nákvæmlega (línunúmer, lykilgildi, gagnagrunnsvillutexti) og að vild „góðar raðir“ gera commit – allt eftir því hversu mikilvægt samræmi og idempotens (fjölkeyrsla án tvöfaldra áhrifa) er í ferlinu þínu.

FireDAC Array DML: Viðeigandi stillingar (án goðsagna)

Fyrir Bulk-Insert með Array DML eru í reynd alltaf sömu stillingarnar lykilatriði:

1) ArraySize und Batch-Größe

ArraySize (bei TFDQuery/TFDCommand) ræður hversu margar „línur“ FireDAC eru unnar í einu kall. Meira er ekki sjálfkrafa betra. Of stórt þýðir: meiri minni í client, meiri payload á tengingunni, stærri læsingar/aukinn log-byrði á server og í villutilfellum meiri „Blast Radius“. Fyrir trausta innflutninga er oft lotustærð á bilinu 200 til 2.000 gott upphaf, allt eftir fjölda dálka, BLOBs og latens.

2) Transaktionsgrenze

Þú þarft skýra ákvörðun: Commit per lotu eða Commit fyrir allan innflutninginn. Þetta er ekki smekkmál, heldur rekstrarleg ákvörðun:

• Commit per lotu: takmarkar læsingar og transaktionslogg, einfaldar endurræsingu, en millistöðvar sjást (eftir isolation level). Villur í lotu 17 skilja lotur 1–16 eftir í kerfinu.
• Commit í lokin: „allt eða ekkert“, faglega samhangandi, en við stórar magntir ógnaðu löngum læsingum, miklu rollback og í villutilfellum tapast allt.

Fyrir mörg viðmót- og innflutningsferli er „Commit per lotu“ raunsærri rekstrarstefna – en aðeins ef þú hefur idempotens og stefnu gegn afritum vel til fyrirmyndar (t.d. með náttúrulegum lykilum, Upserts eða Import-ID).

3) UpdateOptions und Prepared Statements

Hjá endurteknum lotum borgar sig að hafa yfirlýsinguna undirbúna. „Prepare“ þýðir: FireDAC lætur DB parsa/kompílera yfirlýsinguna og endurnýta hana. Fer eftir DB, þetta getur haft veruleg áhrif, einkum við mikla tíðni. Mikilvægara en „bragð“ er hér: stöðug endurnotkun sama Query-objekts (eða sama TFDCommand) og stöðugir parametertýpur.

Skýr villa-meðhöndlun á hverri línu: Það sem þú raunverulega þarft

Ef þú vilt meðhöndla villur „á hverri línu“, þarft þú þrjú atriði:

1. Úthlutun: Hvaða fylkisvísir (0..N-1) misheppnaðist?
2. Samhengi: Hvaða faglegu lykilgildi hefur þessi lína (t.d. ytri ID, viðskiptavinanúmer, tímastimpill)?
3. Stjórnun: Hvað gerir þú eftir það? Hætta, sleppa aðeins slæmum línum eða kljúfa lotuna?

FireDAC getur eftir driver skilað villum fyrir hvert fylkiselement. Í framkvæmd er það þó ekki „einangrað alltaf til staðar“. Þú þarft að búast við því að sum gagnagrunns/veitendakerfi tilkynni aðeins fyrstu villuna eða að villa í lotu stöðvi RESTina. Einmitt þess vegna er traust mynstur oftast tvíþrepa:

• Stig A: Reyndu lotuna sem Array DML.
• Stig B: Ef lotan mistakast, kljúfðu hana (helminga) eða farðu stýrt niður á einstaklingslínur – en aðeins fyrir þessa lotu – og skráðu vandlega.

Þetta hljómar eins og aukavinna, en í innflutningsleiðum er munurinn á „kl. 02:00 stöðvast allt“ og „innflutningur heldur áfram, 7 línur enda í villulista“.

Hagnýtt mynstur: Lotan fyrst, síðan markvisst einangra

Eftirfarandi mynstur hefur reynst vel fyrir ferlisnálægar hugbúnaðarlausnir þar sem gagnagæði eru breytileg:

Skref 1: Pakka gögnum í lotuuppbyggingu (með villusamhengi)

Geymdu gögnin sem á að flytja inn ekki aðeins sem hrá gildi, heldur með lágmarks samhengi: ytri auðkenni, raðnúmer línu úr upprunalegu skrá, og jafnvel hash/umsýslu-summa. Þetta er ekki „nice to have“: í villutilfellum viltu ekki þurfa að parse-a CSV-skrána aftur til að komast að því hvað er að.

Skref 2: Framkvæma Array DML

Stilltu ArraySize á lengd lotunnar, bindu parametrana sem fylki og keyrðu ExecSQL. Mikilvægt: haltu parametrategundum stöðugum (t.d. ekki að binda töluleg reiti stundum sem String og stundum sem Integer), annars mun gagnagrunnurinn framkalla implicit casts eða FireDAC þarf að umbreyta fyrir hvert stak.

Skref 3: Villutilvik – þrengja lotuna í stað þess að endurtaka blindt

Ef ExecSQL bilar hefur þú tvær traustar leiðir:

• Binary Split (skipta í tvennt): Skiptu lotunni í tvo helminga og reyndu hvoran helminginn aftur sem Array DML. Endurtaktu þetta þar til þú ert með lítið magn sem þú getur skoðað stak fyrir stak. Kostur: þú heldur mikilli afköstum ef aðeins fáar línur eru bilaðar. Ókostur: flóknari rökfræði, og ef villan er kerfisbundin (t.d. rangur gagnategund) hjálpar þetta lítið.
• Fallback á einstakar línur fyrir þessa lotu: Stilltu ArraySize=1 (eða bindu einstaka gildi) og keyrðu línu fyrir línu, skráðu villur og haltu áfram. Kostur: einfalt og örugg aðferð fyrir hverja línu. Ókostur: tapar hraða fyrir þessa lotu.

Í raun og veru sameini ég báða nálgunina: byrjar með 1–2 skiptingum (til að keyra „góða kubba“ hratt í gegn) og fæst svo yfir á einstakar línur þegar eftir eru litlar leifar, til að skrá nákvæmar villuupplýsingar.

Villaobjekt og tilkynningar: Hvað þú ættir að ná úr FireDAC

FireDAC umlykur gagnagrunnsvillur í Exceptions (algengt er EFDDBEngineException) með smáatriðum. Fyrir rekstur eru þrjú stig mikilvæg:

• DB-villunarkóði (gagnagrunns-sértækur): t.d. SQLSTATE hjá PostgreSQL, Error Number hjá SQL Server.
• Nafn takmarkana/hlutar: oft innifalið í villutextanum (Unique-index, FK-constraint).
• Yfirlýsingarsamhengi: tafla, aðgerð og ef við á parametragildi (varlega með persónuupplýsingar).

Ef þú ætlar að skrá fyrir hverja línu þarftu í villutilfellum einnig að bera kennsl á línuna. FireDAC getur stundum gefið upp fylkisvísinn (Array-Index). Treystu þér þó ekki eingöngu á það. Búðu alltaf til þinn eigin vísir (staða í lotunni) og skráðu við þessa stöðu a.m.k. eitt faglegt lykilgildi.

Fellihnútar sem kosta tíma í raunverulegum innflutningum

1) „Það var bara ein lína“ — en færslan er þegar „dirty“

Fer eftir gagnagrunni og drifara getur villa valdið því að allt statement-útfærslan sé talin misheppnuð og færslan (transaction) sé komin í ástand þar sem þú þarft annað hvort að gera rollback eða þar sem frekari statements munu mistakast. Sérstaklega hjá sumum drifurum er „að halda áfram eftir villu“ ekki örugg forsendu.

Afleiðing: Ef þú ert að vinna innan færslu og lotan bilar er staðlaður leiðarljós: Rollback á núverandi lotusamhengi (eða á alla færsluna) og byrja upp á nýtt. Þetta passar vel við „Commit per lotu“ nálgun.

2) Autocommit vs. skýr færslustjórnun

Ef þú byrjar ekki skýra færslu ákveður oft drifari/provider hvernig statements eru commit-að. Fyrir bulk-innflutninga er það sjaldan það sem þú vilt. Skýr færslustjórnun gefur þér stjórn á:

• Læsingartími
• Hegðun við rollback
• Endurkeyrslupunktar

Og: „Explizit“ þýðir ekki „ein risastór viðskipti“. Það þýðir „meðvitað“.

3) Trigger, Constraints og aukaverkanir

Array DML flýtir fyrir flutningi gagna en eykur ekki sjálfkrafa vinnu á þjónhlið. Ef þú átt Trigger á mark-töflunni (t.d. audit-logging, sjálfvirk útreikning á stöðu), þá er flöskuhálsinn hugsanlega ekki Insert-aðgerðinn heldur Trigger-kóðinn. Þá getur batch haft færri roundtrips, en CPU á gagnagrunnsþjóninum verður áfram takmarkandi þáttur.

Fyrir Admins og tæknilega ábyrgðarmenn: Við frammistöðuvandamál er þörf á að skoða Wait Events/Locks og transaktionsloggið. Bulk-Insertinn er þá oft aðeins kveikjan, ekki orsökin.

4) Datentypen und implizite Konvertierungen

Einn algengasti „af hverju er þetta hægt?“-áfanginn er að parametrar eru bundnir sem strengir og gagnagrunnurinn kastar línu fyrir línu í Integer/Date/Decimal. Þetta gerist ósýnilega en er dýrt. Fyrir stöðuga frammistöðu:

• Stilltu gagnategundir parametranna rétt (dagsetning sem dagsetning, tala sem tala).
• Varastu villur við Decimals vegna locale (komma vs. punkt). FireDAC er hér yfirleitt rétt val, en blandaðar upprunaleiðir eru það ekki.
• Skilgreindu tímabelta-/UTC-stefnu fyrirfram (timestamps eru klassískur vandamálapunktur við imports).

5) Fehlertexte sind für Menschen, aber nicht für Automatisierung

Það er freistandi að parse-a villutexta („duplicate key value violates unique constraint …“). Gerðu það aðeins sem síðasta úrræði. Betra er að nota strúktúruð kóða (SQLSTATE, Error Number). Því miður skila ekki allir driverar þessum upplýsingum jafnt vel. Hönnun skal því taka tillit til bæði: kóða og texta, auk valfrjálsrar „constraint-nafns úr texta“, en án harðrar háðarstöðu við þá lausn.

Debugging-Hinweise: So findest du schnell die kaputte Zeile

Batch reproduzierbar machen

Ef import mistekst sporadískt þarftu að geta endurgert villuna. Skráðu fyrir hvern batch lítinn greiningarskrá eða log-pósti sem inniheldur:

• Batch-númer og tíma
• ArraySize og transaktionsmodus
• lista yfir faglega lykla (t.d. ytri IDs) í batchinu

Þetta er oft nóg til að keyra síðar mini-import eingöngu fyrir þessi IDs og finna bilunina beint.

Finale SQL sichtbar machen (aber ohne Datenleaks)

Í debug-vinnu viltu vita: Er SQL-in rétt? Eru parametrarnir réttir? FireDAC býður upp á monitoring/tracing í gegnum FDMoni-Komponenten og Treiber-Logging. Í umhverfum nálægt framleiðslu er mikilvægt:

• Virkja tracing markvisst og aðeins tímabundið (frammistaða og persónuvernd).
• Skrá aðeins parametergildi í öruggu umhverfi eða með masking/dulkóðun.
• Fyrir persónugreinanleg gögn: í loggi skrá aðeins tæknilega lykla (IDs) og ekki persónuupplýsingar í auðskeyrslu.

Wenn du split-testest: Abbruchkriterien definieren

Við binary-splitting viltu ekki skipta endalaust. Settu undirstöðuviðmið, t.d. „ef undir 20 línum skiptirðu yfir í einstakan ham“. Leggðu einnig takmörk á hversu marga villur þú þolir í heild áður en þú hættir importi (t.d. við kerfisbundin mapping-vandamál). Annars lendir þú í endalausum villulistum sem hindra áframhaldandi vinnslu.

Wann sich der Aufwand wirklich lohnt (und wann nicht)

Array DML með per-línu error-handling borgar sig sér í lagi þegar:

• Margar línur eru unnar (þúsundir til milljónir).
• Fáar línur eru villugar, en þú vilt samt keyra áfram.
• Import þarf að ganga stöðugt í rekstri (t.d. næturvinnsla eða þjónusta án UI).
• Þú þarft að skila villulista til fagdeildar/upplýsingagjafa (með tilvísun í línur).

Það borgar sig síður þegar:

• þú skrifar aðeins nokkrar tugir lína (einstaklinséttingar eru í lagi),
• gæðin á gögnunum eru svo léleg að 30–50% línanna mistakast (þá er staging-stefna hentugri),
• þú notar þegar gagnagrunnsinnfædda bulk-innflutningsaðferð (t.d. COPY í PostgreSQL, BCP/BULK INSERT í SQL Server) – þá er Array DML ekki verkfærið.

Alternatíf arkitektúr: staging-tafla í staðinn fyrir „beint í áfangastað“

Ef þú mætir reglulega blönduðum gagnagæðum er hreint „Insert beint í áfangataflu“ oft röng ákvörðun. Ein staging-tafla (forstig) er tafla þar sem þú vistir gögn tæknilega rétt fyrst (ef þess þarf með sveigjanlegum gerðum) og staðfestir síðan og flytur í áfangatafluna.

Kostir í rekstri:

• Villugagnalínur haldast geymdar og eru rekjanlegar (þ.á.m. hrágögn).
• Þú getur keyrt staðfestingu sér og endurtekið.
• Þú aðskilur móttöku viðmótsins frá faglegri vinnslu.

Array DML er þá oft fljótlegasta leiðin í staging-tafluna, á meðan flutningurinn í áfangatafluna fer fram sem set-basað SQL (eða Stored Procedure). Þetta færist aukinn hluti villumeðhöndlunar yfir á gagnagrunnshliðina, sem eftir skipulagi (DBA-hlutverk, deployment) getur verið æskilegt eða óæskilegt.

Rekstur og stjórn: Hvað IT-leiðtogar og stjórnendur ættu að vita

Eftirlit: Villuhlutfall og gegnumstreymi eru kjarnamælikvarðar

Fyrir stöðugan rekstur bulk-innflutnings eru tveir mælikvarðar meira upplýsandi en „keyrslutími“ einn og sér:

• Gegnumstreymi: línur á mínútu (eða á lotu) þar með taldir hámarks- og miðgildi.
• Villuhlutfall: villugar línur á keyrslu, helst flokkaðar eftir villuflokkum (Unique, FK, NOT NULL, tegundarárekstur).

Ef þú fylgist reglulega með þessum tveimur gildum sérðu snemma hvort eitthvað hafi breyst við uppsprettuna (t.d. nýtt snið) eða hvort áfangakerfið (t.d. nýjar takmarkanir) hafi herðast.

Lásar og álagsgluggar

Bulk-innsetningar geta valdið læsingum og IO-álagi. Ef notendur vinna samtímis á sömu töflum þarftu að hugsa um einangrunarstig (Isolation Level), index og, ef við á, skiptingu (Partitionierung). Í reynd þýðir þetta: annað hvort setja innflutninga í álagsglugga, eða byggja gagnaflæði þannig að það geti samverkandi starfað með gangandi rekstri (t.d. með staging + ósamstilltri yfirtöku).

Hagnýt athugunarlisti fyrir traustan bulk-innsetning með Array DML

• Lotustærð stilla (upphafsgildi 500–1.000) og fínstilla mælanlega.
• Sértæk viðskipti: Commit fyrir hverja lotu sem sjálfgefið, „Commit í lokin“ aðeins meðvitað.
• Stöðugar parametergerðir setja, ekki neyða til duldra umbreytinga.
• Villusamhengi fyrir hverja færslu halda með (ytri ID, uppsprettulína).
• Villustefna: lota fyrst, síðan Split/Fallback, skrá fyrir hverja línu.
• Logging: kóðar + texti, en í samræmi við persónuvernd; skrá Batch-ID og keyrslu-ID.
• Endurkeyrsla: tryggja idempotens (lykill/Upsert/Import-ID).

Niðurstaða: Array DML er fljótur – hann verður traustari með réttu ferli og villumeðhöndlunarstefnu

Eitt FireDAC Bulk-Insert með Array DML er öflugt tæki, svo lengi sem þú gerir ekki eins og engar villur væru til. Í raunverulegum gagnastraumum eru alltaf undantekningar: tvöföld eintök, vantar tilvísanir, ógild dagsetningargildi. Sniðugur aðgangur er því: Array DML fyrir frammistöðu, samsett með stýrðri einangrunarstefnu (Split eða Fallback) og fyrir hverja línu rekjanlegum villulista. Með þessu sameinar þú hraða og rekstraröryggi — og það er einmitt það sem skiptir máli þegar innflutningar þurfa að keyra áreiðanlega hverja nótt, ekki aðeins í tilraunaaðstæðum.

Ef þið viljið stöðugleika fyrir núverandi innflutnings- eða viðmótferli í Delphi/FireDAC (frammistaða, transaction-stjórnun, endurkeyrslur, skráning), ræðum við það gjarnan skipulega í tæknilegu samtali:

Fyrir þetta efni eru einnig Delphi Bulk Insert og Bulk Insert Delphi FireDAC mikilvæg. Greinin setur þessa þætti skýrt í samhengi og sýnir hvað skiptir máli í daglegu starfi.

Ræddu verkefni eða núvæðingarverkefni með Net-Base.