03. juni 2003 - 10:22Der er
20 kommentarer og 3 løsninger
Avanceret import
Hej, jeg sidder med en kæmpe import og ville egentlig bare gerne have nogle kvalificerede bud på hvad der ville være den bedste løsning.
Situationen er at importen består af en f.eks. 600MB .txt fil der indeholder data på lad os sige 250000 poster. Det er ikke komma sepereret men en lang linie hvor 1-5 er dit og 6-12 er dat osv. Det har jeg prøvet at lave en ASP side der kan dele ud og det virker også 100% - problemet er så bare at hvis der skal laves en masse opdateringer til databasen tager det vildt mange timer. INSERT og DELETE er ikke slem, men alligevel er det ikke nogen fed løsning. Grunden til det er at importen skal køres flere gange. Helst startes af noget systemet gør automatisk 1 gang om ugen, så der tænkte jeg at SQL serveren kunne lave det kald?
Jeg har prøvet at rodde lidt med at have en .vbs fil der indeholder database forbindelse og en simpel insert, men det kan jeg ikke få til at virke som et job overhovedet. Hverken ved at kalde det som VBscript eller ved at køre det som et command job, der kalder noget eksternt...
Ved ikke om der er nogle geniale hoveder derude der kan hjælpe :)
Mit bedste bud var noget der importerede alle poster til en tom tabel, og så kunne noget store prod. eller hvad ved jeg klare resten afhængigt af indholdet? Første import skal så bare også startes på en eller anden måde.
Nej, import formatet er som det er, men nu lykkedes det faktisk at køre et vbs script der indsætter i en tabel... Hvis jeg kan få det script til at hente alt ind så burde det være meget hurtigere end at en ASP side gør det når SQL serveren afvikler det?
Du kan jo prøve - dit vbs burde jo kunne køre inde i en ASP, så det er ren script-performance vi taler om - men: Med 250,000 rækker og kombinerede INSERT/DELETE så vil du få en hel del disk-aktivitet. Så din script-performance kan drukne i SQL Server der skal extende database-filerne. Er de 250K poster statiske (samme hver gang), eller vokser databasen ved det her?
Vokser eller skrumper, poster kan komme til og gå. Performance på serveren imens gør ikke noget, det køres f.eks. lørdag nat kl. 4 hvor ingen burde bruge systemet.
Jeg ved bare at en stored prod. tog utrolig kort tid at afvikle i forhold til at ASP siden gjorde det, men det så også klart nok at en SQL sætning er en del hurtigere i SQL serveren.
Jeg ville helt sikkert anbefale dig at bruge DTS (Data Transformation Services). Det er lige præcis sådan nogle opgaver det er lavet til.
I DTS-pakker kan du specificere import-formatet på masser af forskellige måder, og det vil ikke være noget problem at hente dine data.
Jeg har selv en masse store importer kørende (150k, 80k, 85k poster der opdaterer en tabel med 210k poster, og skriver historik over ændringerne). De importer startede vi også med at lave med VBS. Men idag har vi udelukkende DTS-pakker.
Til de mere komplicerede ting kan man også lave små VBscripts inde i DTS-pakken.
Så, som zapzap siger: Læs i Books Online - der står en masse om DTS.
Spørger om den vokser, da din performance vil degradere hvis du hver gang (uge) får 250K nye poster - hvis du ikke gør noget ved det. DTS-pakker kan også køre 'schedulet', så det er også svar på det sidste i dit spm.
Ahh, nej det sker ikke, der vil i alt altid kun være omkring de 250K - men der er tilgange og afgange.
Har lige kigget lidt på DTS og kan se det godt kan indlæse efter start/slut positioner. Hvis min tekstfil ikke har en first row med coloum navne, så det ikke muligt at angive det i importen så vidt jeg kan se?
Nej, så er det vist ikke muligt at angive navne. Men når du længere inde i din TRANSFORMATION skal vælge hvilke felter der overføres til hvilke, så står der bare Column1, Column2, etc.
Et udtræk kan du ikke se dig ud af uden at kende indekseringen. Det er næsten Matrix noget af det :)
En linie er over 2500 tegn lang, så den er ikke helt sjov at prøve at dele rigtigt op på den linial.
i VB er det nemt bare at sige at startpos x til slutpos y er det osv. Lidt derfor det er lavet i VB i første omgang. Så vidt jeg kan se tager det VB scriptet 30min måske at importere.
Som jeg forstod det, skal maxikoll parse filen lidt, for at hitte ud af om det er DELETE eller INSERT? Så kan man da ikke lave det med bulk insert, vel?
En update er en DELETE og INSERT :O) - Så mon ikke man kan klare det på den måde... Men ligefrem ingen delimeters... Den er lidt dum, men så må alle textlinjer vel være ligelange ? , medmindre indexet står i starten af hver linje...
Njah, nu skal vi vel ikke diskutere det ihjel, men pointen var vel, at maxikoll kan have alle mulige ting og sager i text-filen - hvis det er tilfældet er VBS/DTS vel bedst.
Alle linier er lige lange med hver deres data selvfølgelig. Har et par A4 ark der beskriver hvad de forskellige indeks er til osv. Ja, zapzap. Hver linie indeholder også en kode der afgører om det er en ny post, noget der skal opdateres, noget der skal slettes eller noget der skal sprænges osv.
Jeg kan se et VB script ikke nødvendigvis er meget hurtigere end en ASP side til det for den skal vel stadigt hen og loop hver eneste linie og finde ud af hvor hvad data skal hen.
Hurtigste jeg har prøvet er at f.eks. et VB script ligger alle de poster ind der skal bruges i en tabel. Så køres nogle stored p. der kører en update / insert / delete osv. Det tager omkring 1-2 min for SQL serveren at loop alle posterne igennem og lave hvad der skal. Det er imponerende nok :)
Jeg tror derfor at bulk insert kan dømmes ude - det kan den ikke. Så udover script-varianter (asp eller VBS), er der nok kun een mulighed tilbage - et 'rigtigt' program. Du kan lave en ActiveX DLL/exe i VB (eller i noget andet), som du så skyder af fra SQL Server. Men jeg tror ikke at der er meget at vinde i performance, det er nok snarere noget fejl-håndtering etc. der bliver nemmere.
Tjoh, programmet vil jo være kompileret - så derfor burde det køre hurtigere. Men det afhænger så af, hvor meget kode du selv laver - det meste af dit vil jo nok være recordset ting og fil-læsning, så det kan meget nemt blive næsten ingenting du får ud af det. Der er så den bagdel ved det, at for at rette evt. fejl o.l. skal du genkompilere og gendistribuere - ikke så fedt altid. Jeg synes at din VBS -> arbejds-tabel + stored proc. lyder som en Ok løsning.
Ja, tror jeg også er metoden jeg vælger. Tak for hjælpen alle, har delt lidt point ud for jeres tanker :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
