Färdig!


Då blev jag klar med flytt av databaser till VMDK från iSCSI 🙂
Tror att det var dryga 11 TB som jag flyttade runt på 3 helger (5 dagar/48 timmar eller så).

Det är bara resten av arbetet kvar att göra!

Tänkte passa på att lägga på senaste CU på utvecklingsmaskinerna, medan backuperna pågick på de burkar jag skulle pilla på idag.

AG maskinerna kom upp, men inte SQL server tjänsten. Det gick att kicka igång tjänsten, men det tog evigheter på sig.

Först tänkte jag att det kan vara något med patchen, att första omstarten beter sig så. Det gjorde visserligen inte på alla labbmaskiner som jag hade testat på i torsdags.

Så jag lade på patchen på de andra brukarna i AG med, men alla betedde sig på samma sätt.

Började kolla i loggarna. Samtliga klagade på iSCSI. Men vi har ju inte haft iSCSI diskarna kvar. Det var första helgen jag tog hand om utv, test och pp.

Startade en testmaskin AG. Samma visa där. Skit, vad är detta? Kan jag avaktivera iSCSI tjänsten? Då såg jag att SQL Server (och agenten) var beroende på den.

Googlade på fenomenet och lösningen var att dyka in i registret och rensa värdet i DependOnService. Sen funkade det som det skulle 🙂

Vilken miss 😦 Nu har jag lärt mig en sak till. Det var totalt 3 register hack som man behövt göra för att rensa bort all skräp.

Så då var det vara att lägga upp en lista och beta av denna register hack med. Men alla burkar hade inte detta värdet under DependOnService. Vissa hade inte ens DependOnService.

Tror att de burkar som fick sina diskar via SnapCenter från början inte hade det, eller, ja det rensades efter vid avinstallation av SnapCenter plugins, …

Det strulade när jag skulle ta bort servrarna från SnapCenter med, förstås! Men alla är borta därifrån. Men en del servrar behöver startas om för att ta bort spöken. Tror att bara de som avinstallerades ordentligt som hade kvar värdet i registret.

Det kan förstås vara så att värdet hade rensats om jag hade avinstallerat SnapDrive & SnapManager. Det kom jag tänka på nu. Så går det när man är stressad, … .

Så det som kvarstår (av detta arbete) är att avinstallera SnapDrive & SnapManger. Förhoppningsvis slipper jag omstart för att rensa bort spöken på burkarna. Det där kan jag göra på dagtid som tur är 🙂

Men så sagt hade jag kanske sluppit stulet om jag hade städat redan från början. Men då tror jag knappast att jag hade hunnit med migreringen som jag gjorde.

Det visar sig när jag ska börja städa i burkarna i veckan. Det kanske krävs omstarter, hoppas inte det.

Annars var det problem Analysis Services. Det var inte riktigt samma körschema som det jag hade kört i testmiljön. Det var äldre version i test.

I test hade jag gått efter ett körschema som jag hade hittat på på nätet och anpassat det efter all patrull jag åkt på.

I test flyttades bara en av OLAP mappar (under data) när tjänsten startades upp. Men inte det som fanns under tempdb, logg och backup mapparna.

I prod flyttades inte någon av dessa mappar. Så jag kopierade alla till rätt ställe, men då inte kom tjänsten upp inte.

Kom sedan på att jag inte tilldelat behörighet på mapparna. Borde ha använt mig av robocopy.

Så även Analysis Services kom upp till slut. Men jag visste inte hur jag testa det hela. Allt jag testade på hittade ingen data 😦 Få se om det funkar som det ska nästa vecka. Har en backup på ”databasen” annars.

Annars var samma strul som vanligt, större databaser fick SnapCenter någon typ av timeout på. Men databaserna skapades efter att jag flyttat loggen manuellt. I SCOMs fall, DW databasen, tog det nästan 2 timmar att skapa databasen, efter att jag flyttade logfilen! Så jag fick ta hand om de andra databaserna medan SnapCenter jobbade.

Det var jävla tur att jag upptäckte min miss och tog beroendet till iSCSI, annars hade AG maskinerna stått still efter omstart. Men som sagt kan ha sluppit det om jag hade avinstallerat SnapDrive, SnapManager, …

Nu ska jag försöka låta bli att tänka på jobbet. Det är inte lätt, det går bara runt i skallen, med allt som kvarstår att göra, allt jag gjort och de miss jag gjort och jag ska göra för att undvika det. Så jag maler och maler.

Kommer att ta ledigt till tisdag. Så är tanken i alla fall. Behöver ledigheten, samtidigt som jag vet att det finns uppgifter att göra, folk som står i kö, …

Få se om jag orkar åka till Nässjö och kolla på hojar imorgon. Få se hur magen mår.

Då var denna helgs arbete slutförd


Tar helg till imorgon!

Då var denna helgs arbete slutförd. 263 databaser flyttades runt (ca 4,7 TB).

Det var några väntade strul och några oväntade strul.

Drygt 20 timmar blev det denna helg (och under 20 timmar förra).

Tror att 2/3 delar är jag klar med 🙂

Fortsatte flytta på databaser


Såg nu att det nya backupsystemet skyddar 666 databaser 😀

Dagens skörd blev flytt av 1,8 TB (139 databaser på 6 servrar). Eller nja, ännu mera egentligen.

Flyttade system databaserna på 8 AG maskiner med. Få se om jag kan flytta användardatabaserna på AG maskinerna imorgon.

Tror att det är 2/3 av arbetet klart, morgondagen inräknat. Fortsätter nästa helg med, så det blir ingen resa till Uppsala och MC-mässan nästa vecka. Inte heller någon besök att kolla på nya hojar i Nässjö nästa lördag.

Självklart strulade det denna gången med. Mitt i flytt av databaserna på en viss maskin så tog disken slut och 9 databaser ”försvann”.

Använder det gamla backupsystemet att flytta på databaser. Den ska ta ner en databas i taget och flytta på filerna. Sen när filerna är klara så ska de jackas in i servern igen.

Men när disken tog slut, på en viss databas, så fortsatte kommandot till nästa och nästa och nästa, … tills den hade gått igenom listan på databasern.

Alla databaser hade detachats, men inte kunnat flyttas pga utrymmesbrist. Tur (eller skicklighet) att jag inte valde parametern som tar bort originalfilen när den är färdig med databasflytten!

Jag hade räknat fel på storleken. Den största databasen var hittills en klon från annan miljö. Den låg i egna mountpoints och jag hade räknat inte med den 😦 Klantigt!

Så inte så konstigt att disken tog slut.

Men filerna låg kvar i sin gamla enhet så jag kopierade dessa manuellt.

Tänkte göra restore på den största databasen, men den var borta från backupsystemet 😮

WTF? Jag hade tagit för lång tid på mig (mer än 15 minuter) och när backupsystemet inte hittade den databasen, så trodde den att den skulle tas bort.

Men jag hittade backupen i en annan flik. Den hade blivit relic och gick att återställa.

Fast då kom jag på att filerna låg kvar i en mountpoint så jag flyttade filerna manuellt och gjorde attach istället före restore.

Den sista servern krånglade med. När det var dags att flytta den största databasen så bröts kontakten och den orkade inte flytta log-filen. Så jag fick leta efter log-filen. Det tog sin lilla tid, tills jag hittade vilken databas som hade felat.

Skriptet skulle först skriva ut namnet på databasen innan den skulle började flytta på databasen. Men på vissa servrar så skriver den bara ut 3 bokstäver 😮 😦

Inte kul att leta efter en log-fil som börjar med WSS bland alla SharePoint databaser!

Men den hittade jag 🙂 Efter att jag lade dit den filen så fortsatte skriptet (kommando till den gamla backupsystemet) att fortsätta attacha databasen. Detta trots att skriptet hade körts färdig 😮

Strax innan 18 slutade jag, gick ut och käkade, tog en öl. Väl tillbaka loggade in och kollade att rullade på som det skulle.

Känner att det är dags att vila nu.

Dålig i magen


Var väldigt dålig i magen idag 😕

Tappat räkningen på antal gånger jag fått gå på toa på e.m. Jävligt ont gjorde det med.

Tar helg


Tar helg nu ända till lördag. Det har varit en lång vecka, typ 10 dagars vecka.

Få se om jag kan sova lite under ledigheten. Ska till naprapaten imorgon vid 9. Annars tänker jag ta det lugnt 🙂

Då ska man till Värnamo igen


Denna gång blir besök hos ortopedmottagningen för mina händers skull.

12 mars kl 13:30 ska jag vara där.

Nu tar jag helg


Nu tar jag helg till imorgon bitti! Det blev 9 timmars arbete idag.

Det strulade på 3 ”stora” databaser som det gjorde igår. Sen krånglade AG synkningen på 2 AG så en viss replika fick tas ut och in igen på dessa.

Sen upptäckte jag att Det inte bara var filestream mappen som inte togs hand om av skriptet igår, utan skriptet sket i hela databasen, utan att säga det. Så databasen dök ner när gamla diskarna kopplades bort.

Efter att diskarna kopplades på så kunde jag kopiera databasfilerna med. Få se det systemet funkar som det ska, eller om jag får göra restore på backupen.

Backup och restore får det bli hur som helst på det systemet nästa helg.

Sen får vi kolla varför AG får fnatt mitt i natten det tas vm-backup. Databasbackuperna funkar som det ska.

Magen krånglade lite med 😦

Strul med magen och …


Har varit rätt så dålig i magen i dryga veckan. Men idag, så här långt har bara vanliga magsmärtor.

Det blev 10 timmars arbete idag, lördag. Tror och hoppas inte att det blir lika långt imorgon.

Har flyttat databaser, inklusive systemdatabaser på 9 servrar. från iSCSI till VMDK.

SnapManger stöder inte flytt av systemdatabaser. Kan vara att det inte stöds i den version vi kör.

Fick istället lägga på servrarna i SnapCenter. Där hittas inte diskar utanför iSCSI. I SnapCenter kan man köra konfig och sätta i en bock i ett par rutor. Sånt finns inte i SnapCenter.

Men en kollega hittade ett PowerShell kommando och på det sätt kan man flytta alla databaser dit man vill 🙂

Men, … det skiter sig på ”stora” databaserna (typ över 50-100 GB). Det blir någon typ av timeout/kommunikationen bryts för just den databasen som är lite större. Vet inte var jag ska ändra på dessa värden i SnapCenter. Får skapa ett ärende på måndag. Har löst det i utv, test & preprod. Men det finns riktigt stora databaser i prod så jag vill inte sitta med det nästa helg.

5 databaser sket det sig på. I samtliga fall kopierades inte log-filen. Den flyttar alltså datafilerna som är betydligt större, men orkar inte med logfilerna!

Lösningen har varit att kopiera logfilerna manuellt till den nya enheten. I 1 av 4 fall kunde jag attacha databasen. De andra 4 databaserna gick det inte att attacha databasen då det pågick annan transaktion!

Så har man tålamod så attachas databasen till slut och till och läggs tillbaka i AG! 😮 Men då får man vänta bra länge (har för mig att det var en kvart av vänta och ovisshet!)

Kommandot flyttade inte mappar och filer som tillhörde Filestream & Full text … heller. Få se om systemet funkar med att jag kopierade mapparna manuellt. Får annars göra restore på databasen till nya enheten, för det skapar allt som ingår i databasen.

Så jag får öppna ett ärende och försöker förklara för någon som inte kan detta och hänvisar till massa med andra länkar som inte riktigt stämmer med vårt problem 😦

Minst 3 fel lär det blir imorgon, det är jag rätt såå säker på! Men vågar inte satsa pengar på det 😉

Fick vända


Var ut och gick en vända, men kände att det var dags att vända.

Klarade mig till jobbet som tur var. Jag som trodde att allt var OK efter morgonens 3:e toabesök, men icke.

Det bubblar i magen nu, så jag får se hur det går med det. Lär inte våga mig ut mer idag i alla fall.

Annars var det fint väder och knäppte några kort.

Tar långhelg nu


Tar långhelg nu. Det gäller att inte falla i frestelsen att läsa mejl och jobba bara.

Sen blir det rivstart på måndag. Bestämde att patcha SQL Servrarna vid 05 istället för 17. Det blir färre drabbade, inte så många som är vakna då tänkte jag!

Jag är ju ändå uppe långt innan dess, normalt sett. Men jag oroar mig att jag somnar om just denna dag! Får aktivera väckarklockan på söndag.

Export istället för Mount


Så, nu har jag jobbat klart för denna vecka.

Nya backupsystemets kloningsfunkation funkar inte som det ska så jag återställde en kopia av databaser som ska uppgraderas imorgon nu istället.

Det tog dryga 1,5 timme (nästan 2 för samtliga 4 databaser).

KLonen tappar kontakt och vid 3 tillfällen har databasklonen hamnat i recovery läge (sista gången idag i labb-miljön).

Gjorde 3 klonen med för att om det händer samma sak på annan server och annan miljö.

Fick starta kloningen på 2 databaser på nytt, de det felade mitt i kloningen.

Det största databasen var jag tvungen att återställa (Export) ändå, då kloning (mount) inte funkar på FileStream.

Vem var det som sa, riktiga karlar ta ingen backup ? 🤣

Får fixa behörigheterna imorgon.

Det blir nog sängen nu, trots att klockan inte är 20 än.

Promenad, …


Efter att ha jobbat en stund hade jag telefonsupport för flera grannar i några timmar.

Gick sedan en runda. Det är för kallt (halt) för att ta ut hojen 😦 Dessutom har jag mer strul med händer och fingrar idag.

Strul med skript


Nä, nu är blir jag trött på det här. Har kämpat med ett skript ett tag. Kom på en lösning och testade på min dator och fick den att funka.

Loggade på jobbet och där sket det sig 😦

Det som ska göras är:

  1. Klon (Mount) från backupsystemet till en viss server
  2. Skapa snapshot på klonen
  3. Köra DBCC CHECKDB mot snapshoten
  4. Ta bort snapshoten
  5. Ta bort klonen (Unmount)

Punkt 1: Klon/mount har jag kört skriptet manuellt och fick veta igår e.m. att det är bäst att köra med REST API för ett tjänstekonto. Får lära mig REST API! Dels fanns det exempel sa leverantören och visade mig sen har jag kollegor som jobbar med sånt. Så det löser sig.

Punkt 2: fick jag att funka i torsdags, men jag hade inte tagit hänsyn till om en databas innehåller flera datafiler. Flera olika skript hittades på nätet, men jag fick den inte att funka. De hade hårdkodat databasnamnet! Så ikväll kom jag på hur jag fixar det så att det blir dynamiskt med hjälp av cursor. Kan säkert göras på bättre sätt.

Punkt 3: DBCC CHECKDB på _snapshot funkar

Punkt 4: Ta bort snapshot funkar

Punkt 5: Får titta på de skript som leverantören visade igår e.m. Då det jag hittade på tog bort ALLA snapshot som en viss databas hade och inte bara det vill skapa för att köra checkdb.

Det jag fick att funka hemma var att skapa en procedur som skapar snapshot på en viss databas, oavsett antal datafiler i databasen.

Sen anropar jag proceduren i ett annat skript med hjälp av cursor.
Cursorn behöver snyggas till, men den kör bara på databaser som slutar på _LM (Live Mount)

DECLARE @DB_Name nvarchar(max) 
DECLARE @Command nvarchar(max) 

DECLARE CreateSnapshot_Cursor CURSOR FOR 
SELECT name 
FROM MASTER.sys.sysdatabases WHERE name LIKE N'%_LM'

OPEN CreateSnapshot_Cursor 

FETCH NEXT FROM CreateSnapshot_Cursor INTO @DB_Name 

WHILE @@FETCH_STATUS = 0 
BEGIN 
     SELECT @Command = N'EXEC dba..usp_CreateDBSnapshot ' + @DB_Name 
     EXEC sp_executesql @Command 

     FETCH NEXT FROM CreateSnapshot_Cursor INTO @DB_Name 
END 

CLOSE CreateSnapshot_Cursor 
DEALLOCATE CreateSnapshot_Cursor  

Skapade 3 databaser, 2 med 2 datafiler och en med en datafil. Samtligas namn slutar på _LM.

Skriptet funkade bra hemma, men inte på jobbet som sagt 😦

Orsak? Strul med Live Mount. En databas hade blivit korrupt och stod på Recovery på. Så jag gjorde unmount på .

Den databas som jag hade skapat manuellt med 2 datafiler accepterades, men inte de mountade databaserna. Skapade en ny _LM databas och skriptet tog den databasen med och skapade snapshot på, men inte de som är en klon från en backup 😦

Får testa att skapa en ny procedur baserad på ett annat skript, där jag vet det funkar på klonade databaser och se om problemet är skriptet, eller om det nya backupsystemet. Klon skapas, men vi får larm på dessa och ibland hamnar de i Recovery läge 😦 Får skapa ännu ett ärende om klonade databaserna, igen.

Men nu ska jag försöka slappna av och ta helg, till imorgon (söndag kväll).

Det blev dryga 58 timmar extra i januari minus de 2 dagar jag tog ledigt och de timmar jag åkte hem i veckan då jag var dålig i magen. Typ bara 40 timmar extra.