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 😦