t SQL Script is too large

[Pykow]

Beste Tweakers,

ik zit momenteel met een probleem.
Normaal als wij een grote database installeren (zeg maar een DEMO database met heel wat data)
dan maken wij gebruik van het programma. SQL Data examiner. Voordeel hiervan is dat het zelf een script schrijft en op de juiste manier uitvoert.

Nu is het zo dat ik bij iemand alleen de scripts kan aanleveren en dus geen gebruik kan maken van deze tool.

Er zijn twee soorten scripts..

Eerste script is de Data opbouw (dus alle schema's, tabellen, Functions en triggers)
Deze werkt uitstekend.

De tweede SQL Script is een Data script en zorgt voor inhoud van de Database.
In totaal is dit bestand 2 GB en dus te groot om uit gevoerd te worden op de database.
met het programma 10Editor, kan ik de file benaderen en aanpassen (voor andere programma's is het te groot)

Via de Command prompt probeer ik de grote script uit te voeren.
Een voorbeeld hiervan is:
sqlcmd -S myServer\instanceName -i C:\myScript.sql

Na een tijdje krijg ik een error (de exacte melding heb ik niet meer)
Maar het heeft ermee te maken dat de server het niet aan kan of iets dergelijks.
op internet staat REBOOT the server etc. maar dat lijkt mij niet de juiste oplossing.

Zijn er tools om een grote t SQL script op te splitsen in meerdere bestanden ?
Alvast bedankt voor de hulp.

[NMe]

Hoe verwacht je precies hulp te krijgen als je de error niet meer weet? Kun je niet proberen die error nog eens te triggeren?

Verder: Waar hoort mijn topic? staat er niet voor niks.
WEB>>PRG

[Barryvdh]

Eerste hit op 'split sql files': http://www.ontwerps.nl/methods-importing-large-sql-files
Dat al geprobeerd?

[RobIII]

Doe eens gek en split zelf even handmatig het bestand in twee? Dan weet je of 't werkt en kun je gaan zoeken naar een betere/te automatiseren manier. (Een sql bestand in delen splitten is ook geen rocket science; je zou "GO" o.i.d kunnen gebruiken om te bepalen waar een statement stopt; doe dat op X MB intervallen et voila).

Barryvdh schreef op maandag 23 juni 2014 @ 12:45:
Eerste hit op 'split sql files': http://www.ontwerps.nl/methods-importing-large-sql-files
Dat al geprobeerd?

Het idee is hetzelfde, maar dit gaat over MySQL en het topic over T-SQL (MSSQL); de verschillen kunnen nét genoeg zijn om niet (goed) te werken dus dat moet TS dan wel even goed controleren.

[ Voor 38% gewijzigd door RobIII op 23-06-2014 12:50 ]

[Pykow]

MySQL werkt inderdaad net iets anders dan T-SQL en daardoor weet ik dat uw methode helaas niet werkt.

Kijk de bedoeling is simpel.
Wij hebben hier op kantoor een gevulde demo database die geinstalleerd moet worden bij de klant.
Nu weet ik dat scripts werken, maar ik krijg nu steeds de melding dat er niet genoeg geheugen is om dit voor elkaar te krijgen.

Nu vraag ik me af of er een andere mogelijkheid bestaat om de database te installeren bij de klant.
Door middel van MDF ? Backup / Restore ?
Maar daarvan lees ik vooral dat de ServerIp/Naam /Systemname opgeslagen worden in deze dump / backup files en daardoor niet zouden werken op een andere server ?

Je moet het eigenlijk zien als een verhuizing.

Misschien moet ik mijn klant gewoon de MDF files doorsturen en kunnen hun deze gewoon installeren op hun server, maar ik weet niet of alles dan gelijk zal werken.

[RobIII]

Pykow schreef op dinsdag 24 juni 2014 @ 11:04:
Misschien moet ik mijn klant gewoon de MDF files doorsturen en kunnen hun deze gewoon installeren op hun server, maar ik weet niet of alles dan gelijk zal werken.

Again: wat let je om 't eens te proberen? De zinsnede "ik weet niet of..." moet automatisch leiden tot een "Let's find out!" IMHO.
(Ik voorzie wel degelijk potentiële problemen, maar wij hebben daar veel minder / geen zicht op dan jij; er is in dit topic veel te weinig informatie voorhanden om hier iets zinnigs / sluitends op te zeggen).

En waarom zou je een bestand niet in 2 (of meer) delen splitten als één groot bestand problemen geeft? Lijkt mij, gegeven de huidige situatie, de simpelste fix...

[Coca-Cola]

Pykow schreef op dinsdag 24 juni 2014 @ 11:04:
...

Je moet het eigenlijk zien als een verhuizing.

Misschien moet ik mijn klant gewoon de MDF files doorsturen en kunnen hun deze gewoon installeren op hun server, maar ik weet niet of alles dan gelijk zal werken.

Ook dit kan je toch gewoon proberen? Installeer SQL Server op een test machine, haal de Demo DB offline, copy de files en attach ze in je nieuwe server? Ik kopieer regelmatig databases naar andere machines op deze manier en tuurlijk zijn daar ook mogelijke problemen, maar bij voorbaat dingen uitsluiten omdat je denkt dat het misschien niet werkt gaat je niet snel verder helpen!

[Pykow]

Coca-Cola schreef op dinsdag 24 juni 2014 @ 11:27:
[...]


Ook dit kan je toch gewoon proberen? Installeer SQL Server op een test machine, haal de Demo DB offline, copy de files en attach ze in je nieuwe server? Ik kopieer regelmatig databases naar andere machines op deze manier en tuurlijk zijn daar ook mogelijke problemen, maar bij voorbaat dingen uitsluiten omdat je denkt dat het misschien niet werkt gaat je niet snel verder helpen!

Dat is mij al vaker gelukt, echter is nu het probleem dat ik alleen connectie heb met de SQL Management studio.
Dus zocht ik een andere oplossing hiervoor.

Alvast bedankt voor de moeite en ik ga het 1 en ander even uitproberen.

[maxtz0r]

Waarom niet gewoon een back-up en restore? Back-up naar een .bak bestand en geef wellicht nog compressie op in je management studio zodat sql server deze al zelf inpakt. Dan restoren op de server als nieuwe database. Dit moet gewoon werken.

[Pykow]

een .BAK kan ik niet openen op een andere server.

[RobIII]

Pykow schreef op dinsdag 24 juni 2014 @ 12:47:
een .BAK kan ik niet openen op een andere server.

Want...?

Komaan; we kunnen niet in onze glazen bol blijven kijken. Je zult ons toch van iets meer informatie moeten voorzien dan dat...

[maxtz0r]

Pykow schreef op dinsdag 24 juni 2014 @ 12:47:
een .BAK kan ik niet openen op een andere server.

Een .bak hoef je ook niet te openen? Je moet hem restoren via SQL management studio: MSDN: Restore a Database Backup (SQL Server Management Studio)

Of te wel:
- bestand kopieren naar database
- SQL management studio openen
- verbinden met server/instance
- rechtermuisknop op Databases -> restore database
- naam opgeven in To database, aangeven dat je From device wil restoren, bestand selecteren etc....

[RuudvandeBeeten]

Pykow schreef op dinsdag 24 juni 2014 @ 12:47:
een .BAK kan ik niet openen op een andere server.

Kan je aangeven waarom je alleen toegang via Management Studio hebt/krijgt?

Je kan, zoals hierboven al is aangegeven, prima een back-up maken en deze restoren. Hoe je de back-up naar de server van de klant krijgt is mij een zorg..al pak je een USB stick, propt de .bak file erop en ga je fietsen...


ps. Je kan ook zorgen dat je FTP toegang krijgt tot een bepaalde map waarin je de .bak file kan plaatsen

[ Voor 10% gewijzigd door RuudvandeBeeten op 24-06-2014 12:59 ]

[Pykow]

maxtz0r schreef op dinsdag 24 juni 2014 @ 12:53:
[...]


Een .bak hoef je ook niet te openen? Je moet hem restoren via SQL management studio: MSDN: Restore a Database Backup (SQL Server Management Studio)

Of te wel:
- bestand kopieren naar database
- SQL management studio openen
- verbinden met server/instance
- rechtermuisknop op Databases -> restore database
- naam opgeven in To database, aangeven dat je From device wil restoren, bestand selecteren etc....

Het gaat om de laatste stap.
Ik kan de .BAK file niet selecteren, nadat ik een restore heb gedaan.

[maxtz0r]

Pykow schreef op dinsdag 24 juni 2014 @ 13:01:
[...]


Het gaat om de laatste stap.
Ik kan de .BAK file niet selecteren, nadat ik een restore heb gedaan.

Je kan de .bak niet selecteren? Hoe bedoel je? Kan je hem niet vinden, kan je hem niet kopiëren naar klant omgeving?

Let op dat je het bestand daadwerkelijk op de database zet waar je deze op wilt restoren. Het is niet mogelijk om vanaf een netwerkschijf te restoren.

[Pykow]

maxtz0r schreef op dinsdag 24 juni 2014 @ 13:04:
[...]


Je kan de .bak niet selecteren? Hoe bedoel je? Kan je hem niet vinden, kan je hem niet kopiëren naar klant omgeving?

Let op dat je het bestand daadwerkelijk op de database zet waar je deze op wilt restoren. Het is niet mogelijk om vanaf een netwerkschijf te restoren.

Ik heb het volgende getest / gedaan.
Daarvoor heb ik twee werkplekken gebruikt in het netwerk.

Backup / Restore:
- De demo database staat geinstalleerd op Werkplek A. Hiervan heb ik een backup gemaakt en opgeslagen op mijn lokale C:\ Schijf als 'demo.bak'

- Vervolgens heb ik via Werkplek A, verbinding gemaakt met de database server op Werkplek B.
- een nieuwe database aangemaakt met dezelfde databasenaam.
- Vervolgens voor restore gekozen en naar mijn c:\ schijf gegaan en GEEN mogelijkheid voor gehad.
Ik heb de .BAK dus niet op werkplek B gezet en dit werkt dus niet.
Dus als ik het goed begrijp, moet ik de 'demo.bak' op werkplek B zetten en dan de restore uitvoeren.


Daarnaast heb ik ook gewoon de MDF file overgezet.
- Demodatabase offline gehaald, detach.
- MDF en LDF bestand gekopieerd naar de server map.
- Verbinding gemaakt met de database op werkplek B
- Attach en dan gekozen voor de demodatabase.
Hiermee werkt het dus goed.

Wat adviseren jullie ? het is gewoon een nieuwe database op een instantie.

Ik ben nu aan het uitzoeken hoe ik de LDF file kan verkleinen, om te shrinken.

[maxtz0r]

Pykow schreef op dinsdag 24 juni 2014 @ 13:46:
[...]

Dus als ik het goed begrijp, moet ik de 'demo.bak' op werkplek B zetten en dan de restore uitvoeren.

Dat klopt, wanneer je bent verbonden met SQL management studio en je gaat het .bak bestand selecteren dan kun je alleen bestanden benaderen die ook daadwerkelijk op de server staan. Dus je moet zorgen dat je Demo.bak op de c:/ schijf van de database server staat. Uiteraard mag een andere schijf van de database ook.

[Pykow]

maxtz0r schreef op dinsdag 24 juni 2014 @ 14:06:
[...]


Dat klopt, wanneer je bent verbonden met SQL management studio en je gaat het .bak bestand selecteren dan kun je alleen bestanden benaderen die ook daadwerkelijk op de server staan. Dus je moet zorgen dat je Demo.bak op de c:/ schijf van de database server staat. Uiteraard mag een andere schijf van de database ook.

Bedankt.

ik wil iedereen even bedanken voor het helpen en mijn excuses aanbieden dat ik niet altijd even duidelijk ben geweest. Dit kwam doordat er wat druk achter zat van bovenaf en ik hier nog niet zoveel ervaring mee heb.

Ik heb de klant MDF,LDF en BAK bestand doorgestuurd zodat ze daar verder mee aan de slag kunnen gaan, met de uitleg erbij natuurlijk

Zei hebben zelf ook ene IT afdeling, die waarschijnlijk wat meer ervaring hiermee hebben om dit af te ronden.

alvast iedereen bedankt voor de genomen moeite en ik ben weer een lesje geleerd.

[Dekaasboer]

Je kan ook je restore statement in sql schrijven en daar een netwerk url inhangen.
Je kan ook een share van die locatie maken.

code:

RESTORE DATABASE [database naam] FROM  DISK = N'\\srv-waar-de-restore-staat\c$\mapnaam' WITH  FILE = 1,  NOUNLOAD,  REPLACE,  STATS = 10
GO

Waarom zou je trouwens een ldf (logfile willen migreren)
Waarom stuur je een mdf (datbase) door wanneer je een backup doorstuurt

Ik kan je wel uitleggen hoe je een logfile kleiner maakt maar ik denk dat je eerst wat kennis moet opdoen.
Zoek eerst maar eens op SQL recovery model (full, simple, bulk logged) en hoe backups invloed uitoefenen op de grootte van logfiles en wat een logfile eigenlijk is. Ga daarna lezen wat shrink file doet en hoe je de initial file size van je db instelt.

En je hebt het de hele tijd over werkplekken... SQL is een platform. Dat hoort op een server te staan. Als de zaak een licentie op SQL heeft en jij hebt SQL server op allemaal pc's gezet zullen ze niet blij worden bij een audit tenzij je de express versie gebruikt hebt.

[ Voor 55% gewijzigd door Dekaasboer op 24-06-2014 15:46 ]

[Pykow]

Dekaasboer schreef op dinsdag 24 juni 2014 @ 15:34:
Je kan ook je restore statement in sql schrijven en daar een netwerk url inhangen.
Je kan ook een share van die locatie maken.

code:

RESTORE DATABASE [database naam] FROM  DISK = N'\\srv-waar-de-restore-staat\c$\mapnaam' WITH  FILE = 1,  NOUNLOAD,  REPLACE,  STATS = 10
GO

Waarom zou je trouwens een ldf (logfile willen migreren)
Waarom stuur je een mdf (datbase) door wanneer je een backup doorstuurt

Ik kan je wel uitleggen hoe je een logfile kleiner maakt maar ik denk dat je eerst wat kennis moet opdoen.
Zoek eerst maar eens op SQL recovery model (full, simple, bulk logged) en hoe backups invloed uitoefenen op de grootte van logfiles en wat een logfile eigenlijk is. Ga daarna lezen wat shrink file doet en hoe je de initial file size van je db instelt.

En je hebt het de hele tijd over werkplekken... SQL is een platform. Dat hoort op een server te staan. Als de zaak een licentie op SQL heeft en jij hebt SQL server op allemaal pc's gezet zullen ze niet blij worden bij een audit tenzij je de express versie gebruikt hebt.

Hij staat geinstalleerd op mijn werkplek en op een werkplek/server (daar draait gewoon Windows 7 op een geen officiele server omdat we er alleen SQL opdraaien en gedeelde netwerkschijf en maar met 6 man tegelijk werken.

Wij hebben een SQL Develop edition, die mag je onbeperkt installeren voor programmeer doeleinde en niet voor live gebruik.
dus we mogen er een database opzetten voor develop (zoals Demo's en testdatabases) maar we mogen er geen eigen database opzetten, zodat het een echte server is.
Het zijn dus puur voor develop, dit hebben wij grondig uitgezocht, want microsoft kan soms behoorlijk streng zijn met SQL licenties.

het was me nog niet duidelijk hoe ik een nieuwe LDF bestand kon aanmaken en dus ben ik voor de meest eenvoudige oplossing gegaan.

Daarnaast kan je inderdaad kiezen voor een simple recovery mode en daarmee kan je bijvoorbeeld de Log file shrinken, shrinken wordt alleen zelf niet gelogd, dus wanneer er iets mis zou gaan, dan moet je sowiso een backup terug zetten om het te herstellen.

ik ga me hier nog verder in verdiepen.

EDIT: ok duidelijk
Simple recovery is niet echt aan te raden, geen log en als er wat mis gaat, dien je echt alles opnieuw te herstellen en kan je niet een gedeelte herstellen van de database. Dus dat is een not done.

[ Voor 4% gewijzigd door Pykow op 24-06-2014 17:31 ]

[Tribits]

Pykow schreef op dinsdag 24 juni 2014 @ 13:01:
[...]

Het gaat om de laatste stap.
Ik kan de .BAK file niet selecteren, nadat ik een restore heb gedaan.

maxtz0r schreef op dinsdag 24 juni 2014 @ 14:06:
[...]

Dat klopt, wanneer je bent verbonden met SQL management studio en je gaat het .bak bestand selecteren dan kun je alleen bestanden benaderen die ook daadwerkelijk op de server staan. Dus je moet zorgen dat je Demo.bak op de c:/ schijf van de database server staat. Uiteraard mag een andere schijf van de database ook.

Niet helemaal waar. De restore (inclusief het selecteren van de bestanden) wordt uitgevoerd onder de service account waar SQL-Server onder draait. Die account heeft normaal gesproken natuurlijk geen network mappings en vaak ook geen network access maar het is wel mogelijk dat aan te passen.

Zie bijvoorbeeld:
Restore database backup over the network
Backup and Restore SQL Server Database to a network shared drive