Microsoft SQL Server data verplaatsen

[DJ-Promo]

Ik heb een SQL server 2012 met verschillende partities. Nu is er 1 disk (iSCSI) waarop alle database files staan van zowel system als user.
Nu moet die iSCSI disk weg en gaat het over op een nieuw gekoppelde VMDK.
Als je bij de installatie aangeeft dat ie de databases op een aparte disk moet zetten maakt ie ook de folder JOBS en Log etc daar aan.
Nu heb ik via queries alle files omgezet naar de nieuwe disk + de startup paramaters aangepast. Als ik in de event viewer kijk zie ik wel wat fouten voorbij komen over logs die niet weggeschreven kunnen worden. In het register staan ook nog steeds verwijzingen naar de oude disk.
SQL werkt verder wel maar het lijkt mij niet een nette manier.
Iemand tips om dit netter te doen? Heb al geprobeerd om gewoon de hele disk te clone en daarna de driver letter te wisselen maar dit ging niet. Kan ook niet echt clonezilla ofzo gebruiken want de target disk is iSCSI.
Laatste middel is het opnieuw installeren van SQL?

[Meekoh]

Korte versie:
Nieuwe disk toevoegen met andere drive letter.
SQL stoppen
Robocopy /mir alles naar nieuwe disk
Driveletter oude disk naar nieuwe disk
SQL starten
Koffie drinken

[DJ-Promo]

Dit had ik geprobeerd maar vond ie toch niet lekker. Waarschijnlijk door rechten.
Ga dit vanmiddag nog een keer proberen.

[Meekoh]

DJ-Promo schreef op dinsdag 29 november 2016 @ 12:09:
Dit had ik geprobeerd maar vond ie toch niet lekker. Waarschijnlijk door rechten.
Ga dit vanmiddag nog een keer proberen.

Daarom juist robocopy gebruiken die kan rechten ook meenemen mits je de juiste parameters gebruikt.
/SEC dacht ik of /COPYALL

[MrTre]

Dat van Meekoh kan, maar je kan ook de defaults aanpassen waar het opgeslagen wordt, en dan een backup naar .bak van de db's doen en vervolgens weer importeren.

[DJ-Promo]

Heb Meekoh zijn idee nog een keer geprobeerd dit keer met deze opties:

/E /SEC /COPYALL /MIR /R:2

Daarna driveletter veranderd en de server herstart dan start ie ook SQL weer op.
Tot zover geen problemen.

[CMD-Snake]

Je kan binnen SQL Server je databases gewoon verplaatsen. Hiervoor moet het ALTER DATABASE commando gaan gebruiken. Niet prutsen met robocopy maar gewoon via SSMS de nodige commando's afschieten waarna je de .mdf bestanden kan verplaatsen naar de nieuwe disk. Log bestanden kan je ook verplaatsen op die manier.

TechNet is je vriend:
https://technet.microsoft.com/en-us/library/gg452698.aspx
MSDN: Move User Databases
MSDN: Move System Databases

Voordat je begint aan dergelijke operaties zorg ervoor dat je een back-up hebt.

[DJ-Promo]

Ja als ik dat dus doe staan alle databases inderdaad over. Het vervelende is dat als ik in het register kijk dat er nog allemaal verwijzingen zijn naar de oude plek en die disk gaat weg.

[Meekoh]

CMD-Snake schreef op donderdag 1 december 2016 @ 19:07:
Je kan binnen SQL Server je databases gewoon verplaatsen. Hiervoor moet het ALTER DATABASE commando gaan gebruiken. Niet prutsen met robocopy maar gewoon via SSMS de nodige commando's afschieten waarna je de .mdf bestanden kan verplaatsen naar de nieuwe disk. Log bestanden kan je ook verplaatsen op die manier.

TechNet is je vriend:
https://technet.microsoft.com/en-us/library/gg452698.aspx
MSDN: Move User Databases
MSDN: Move System Databases

Voordat je begint aan dergelijke operaties zorg ervoor dat je een back-up hebt.

Daarmee is TS er nog niet. Wat dacht je van de SQL Logs (Error log bijv.), eventuele verwijzingen naar backup locaties etc. De enige manier om consistent dit goed te regelen is met een tool als robocopy en daar is niets prutserigs aan. Zeker omdat je met SQL Server de rechten goed moet hebben. Dus bij een migratie als deze "Alles op Disk A naar Disk B, waarna Disk A verdwijnt" is dit DE methode om te gebruiken.

[Craven]

CMD-Snake schreef op donderdag 1 december 2016 @ 19:07:
Je kan binnen SQL Server je databases gewoon verplaatsen. Hiervoor moet het ALTER DATABASE commando gaan gebruiken. Niet prutsen met robocopy maar gewoon via SSMS de nodige commando's afschieten waarna je de .mdf bestanden kan verplaatsen naar de nieuwe disk. Log bestanden kan je ook verplaatsen op die manier.

TechNet is je vriend:
https://technet.microsoft.com/en-us/library/gg452698.aspx
MSDN: Move User Databases
MSDN: Move System Databases

Voordat je begint aan dergelijke operaties zorg ervoor dat je een back-up hebt.

Dat "prutsen met robocopy" zou verreweg mijn voorkeur hebben. Wat SQL betreft is er met de methode van Meeko helemaal niks verplaatst. Je hebt alleen de fysieke disk achter de driveletter omgewisseld. Maar dat ziet SQL niet.

[CMD-Snake]

Craven schreef op vrijdag 2 december 2016 @ 14:02:
Dat "prutsen met robocopy" zou verreweg mijn voorkeur hebben. Wat SQL betreft is er met de methode van Meeko helemaal niks verplaatst. Je hebt alleen de fysieke disk achter de driveletter omgewisseld. Maar dat ziet SQL niet.

Maar gek genoeg ben je niet uit de problemen met robocopy. Anders had je denk ik al veel eerder gemeld dat het gelukt was.

Mijn sterke voorkeur gaat uit om eerst binnen SQL Server de verplaatsing op te geven, daarna kan je veilig de bestanden verplaatsen. Dan blijft SQL Server ook niets vasthouden.

Een dergelijk traject kan je ook prima binnen een paar VM's naspelen om te kijken wat er gebeurt. Je wil hierbij niet "on the job" moeten gaan troubleshooten of nieuwe dingen ontdekken. Dan heb je veel meer tijd dat je applicaties niet beschikbaar zijn.

[Craven]

CMD-Snake schreef op vrijdag 2 december 2016 @ 22:39:
[...]


Maar gek genoeg ben je niet uit de problemen met robocopy. Anders had je denk ik al veel eerder gemeld dat het gelukt was.

Mijn sterke voorkeur gaat uit om eerst binnen SQL Server de verplaatsing op te geven, daarna kan je veilig de bestanden verplaatsen. Dan blijft SQL Server ook niets vasthouden.

Een dergelijk traject kan je ook prima binnen een paar VM's naspelen om te kijken wat er gebeurt. Je wil hierbij niet "on the job" moeten gaan troubleshooten of nieuwe dingen ontdekken. Dan heb je veel meer tijd dat je applicaties niet beschikbaar zijn.

Ehh ik ben de TS niet en de TS geeft wel al gemeld dat het werkt?

[Turdie]

Wat voor fouten zie je in je event viewer? Als je databases toch benaderbaar en draaien en op nieuwe disk staan, zie ik het probleem niet zo.

[SambalBij]

Hele andere mogelijkheid (mits je vSphere licentie Storage vMotion heeft) is om de iSCSI disk aan VMWare toe te wijzen, en die als virtual(!!) Raw Disk Mapping aan de VM toe te wijzen. Vervolgens kun je middels een storage vMotion actie de RDM disk naar een VMDK laten verplaatsen, gewoon met de server online.
(Bij die vMotion aangeven dat je die betreffende disk wil converteren naar thick provisioned)

Kan handig zijn als het erg veel data betreft en je de server niet lang genoeg offline kunt halen. Ook hou je, vanuit Windows gezien, de disk 100% in tact. Geen kopieeracties met mogelijke rechtenkwesties e.d.

(Zie ook http://blog.scottlowe.org...torage-vmotion-with-rdms/)

[Oogje]

shadowman12 schreef op maandag 5 december 2016 @ 16:02:
Wat voor fouten zie je in je event viewer? Als je databases toch benaderbaar en draaien en op nieuwe disk staan, zie ik het probleem niet zo.

Sinds Meekoh zn tip zijn er ook geen problemen meer als ik t zo lees

[Meekoh]

CMD-Snake schreef op vrijdag 2 december 2016 @ 22:39:
[...]


Maar gek genoeg ben je niet uit de problemen met robocopy. Anders had je denk ik al veel eerder gemeld dat het gelukt was.

Mijn sterke voorkeur gaat uit om eerst binnen SQL Server de verplaatsing op te geven, daarna kan je veilig de bestanden verplaatsen. Dan blijft SQL Server ook niets vasthouden.

Een dergelijk traject kan je ook prima binnen een paar VM's naspelen om te kijken wat er gebeurt. Je wil hierbij niet "on the job" moeten gaan troubleshooten of nieuwe dingen ontdekken. Dan heb je veel meer tijd dat je applicaties niet beschikbaar zijn.

Je bent inderdaad niet uit de problemen als je robocopy niet op de juiste manier gebruikt. De reden dat dit soort dingen vaak stuk gaat is het rechten aspect. Afhankelijk van het account waaronder SQL Server draait(Domainuser/GMSA/System/NetworService) heeft het rechten nodig op de mdf en ldf files. Als jij die niet mee kopieerd (dus robocopy zonder /SEC) dan krijg je errors ja, want dan krijgt het de rechten overgeerft van de doel map.
Dan heb ik het nog niet eens over andere data directories/files waar SQL referenties naar bijhoud (Errorlog bijvoorbeeld). Dat zijn namelijk typische dingen die je niet via T-SQL commands KUNT doen

Het gaat namelijk niet alleen maar om de mdf en ldf files!

[DJ-Promo]

Meekoh heeft helemaal gelijk en dat is wat ik tegen kwam.
Ga ook nog naar de optie van SambalBij kijken.