Svårt att låta bli sårskorpor


Varför är det så svårt att låta bli att pilla på sårskorpor?

Nu är det läckage från det stora såret i armbågen. Har klippt bort kanterna på sårskorpan nu och lagt på en tejp.

Det andra sårskorpan i armbågen gick det bra att ta bort utan att det blödde.

En del av såret på fingret läckte aldrig. Fel ord. Huden hade lossnat, men det fick fäste igen under olycksdagen. Men en bit fick aldrig fäste och jag kunde inte låta bli att pilla på den, förstås. Klippte bort den till slut.

Och varför ska man envisas med att klippa tånaglarna när det gör ont i revbenen? Det gick, men kul var det inte.

Från andra sidan har jag halverat antal Alvedon piller. 2 till natten och 2 när jag vaknar. Trappade ner redan igår och det har gått bra, utom nu när jag skulle klippa klorna 😦

Ska se om det går bra att sova utan Alvedon. I natt gick det ”bra” att sova en stund på höger sida (den sida som inte fick sig en smäll) förra veckan. Det går framåt 🙂

/* . */


Tog en omväg till jobbet för att känna efter hur det känns att köra längre sträckor. Det gick bra 🙂

Det var 8° – 11° på morgonen. Betydligt mer nu. Det var dis på många ställen, på en sjö i Barnarp och jag var bra sugen att stanna och kolla samt fota, men det var inget bra ställe att stanna.

Fick tag på bovärden som satt upp brandvarnaren ordentligt. Vi snackade att åka runt på våra hojar nästa helg kanske 🙂 Han ska visserligen ska sälja sin supersport hoj, så vi får se om han har det kvar nästa vecka.

Åkte och handlade lite grejer på lokala gårdsbutiken och kom hem och fortsatte jobba en stund till.

Hade fått 2 brev från polisen, en med min anmälan som jag inte läst, men han läste upp detta för mig förra veckan. Den andra att anmälan har lagts ner.

Tankade 9,36 l. Mätarställning: 5385. 7,5 mil blev det.

Availability Groups, tempdb, recovery, SnapManger


Idag utökade jag antal tempdb-filer på en server, samtidigt som jag begränsade storleken på filerna. Nu ska inte dålig kod ta slut på hela diskutrymmet som det gjorde igår.

Sen ändrade jag recovery på tjänsterna så att det görs 3 försök att ta upp tjänsterna innan den ger upp, om det skulle hända något.

Efter det började jag skapa en Availability Group till i testmiljön. Kom på att databaserna ligger i fel mountpoints, så jag använde SnapManagers konfiguration för att migrera databaserna till rätt mountpoints.

Det tog så lång tid så jag blev orolig om det skulle skita sig, men nä, den flyttade valde databaser till rätt mountpoint och dess undermapp.

Vad den gjorde som jag icke gillar är att den tog mapparna Data & Log från de gamla mountpoints 😮 Vad hade hänt om det låg andra databaser där? Skulle den sabba allt?

Sen började jag skapa den Availability Group jag hade tänkt att göra. Det gick så bra sa guiden, men det tog himla lång tid att replikera databaserna till de övriga servrarna. Ska jag ta ur databaser som inte synkats ur denna AG, eller ska jag is i magen?

Men det gick bra till slut. Det som jag hade räknat med max en halv timme tog 1,5 timmar 😮

Man ska inte vara tidsoptimist! Allt som man kan komma på  och inte kan komma på, kan skita sig! Det gäller att ha marginaler.

Har ju testat annan variant att skapa AG, istället för automatiskt seeding, valt backup och restore. Då måste man ha en delad mapp där alla inblandade servrar (SQL Serverns tjänstekonto) har tillgång till.

Efter det, så sätts ens användarid som ägare till databasen. Så för att fixa det hjälper det inte att att ändra ägarskapet i primära replikan, utan man behöver göra failover till varenda replika och byta ägare 😮 Ska inte en sådan operation replikeras till de sekundära replikorna?

Det finns andra alternativ som jag inte testat. Får göra det för att se vilket alternativ är bäst för olika scenarier. Får testa Join only någongång.

En annan grej som jag tycker är en bugg, är att när man lägger till en databas i en befintlig AG, så funkar inte automatiskt seeding alltid, på alla replikorna. Lägger man 2 databaser i en befintlig AG så får ena replikan ena databasen och den andra får kanske den andra databasen! Filerna skapas inte ens på servrarna och guiden visar att allt är OK! 😦

Har försökt följa råden i följande ibland med blandade resultat.

Såg efteråt att seeding mode hade satt till manuell. Något som inte syns och kan väljas när man uppdaterar en befintlig AG via guiden. Man kan ändra på det efteråt dock! Så ska man verkligen behöva skripta detta? Varför syns inte det i guiden? Varför sätts det som manuell som standard?

Read-only routinglist är ännu en grej som felar. När man sätter upp en AG så kan man numera fylla i guiden. Förut har man behövt skripta. Man har kunnat detta ett bra tag med Management Studio 17, vilket är bra. Men, … går man efteråt och kollar inställningar, så är turordningen i fylld på den primära servern, där man skapade AG 😮 Kollar jag på skripten som har generats vid skapandet, så står det exakt vad jag valt, men det har inte gått igenom, utan man är tvungen att göra om det hela 😮

Nu har kommit flera uppdateringar på SSMS, men felen kvarstår. Är det någon som upptäckt och anmält detta fenomen? Får kanske anmäla det till. Kan vara så att ingen annan upptäckt det, eller tror att någon annan har säkert anmält detta, som jag gjort!

Skapade en Basic AG igår. Det är mycket man inte kan göra med den, men det funkar som mirroring. Är ena servern nere så tar den andra över. Få se hur den funkar. Får ligga i testmiljön ett tag innan man går till prod.