Datofeltenes forbannelse

Av og til må man hente ut data fra en tabell basert på dato eller tid. Slike tabeller har gjerne en egen tidsmerkekolonne, eller timestamp som det egentlig heter. Problemet er at datatypen som passer i de aller fleste databasemotorer også har en tidskomponent, slik at det er forskjell på 20100830153312 og 20100830073658 selv om de begge er fra samme dag. Man kan selvsagt jukse og sette denne til null, slik at alt blir merket med dato sånn og sånn klokken 00:00:00, men det er ikke så praktisk og krever at man tar hensyn til det hver gang man legger inn data. Og for å gjøre dette morsommere finnes det knapt noen datofunksjoner som er standardiserte på tvers av databaseplattformer, så man må finne de som passer til den versjonen man har. Dette har gitt meg mye “glede” opp gjennom årene, og siden jeg jobber med sånt forholdsvis sjelden forsøker jeg nå å dokumentere noe av det jeg stadig må finne opp på nytt.

Continue reading “Datofeltenes forbannelse”

Kopiere en MSSQL-database

Bakgrunn

Prosedyren beskriver to metoder for å ta en fullstendig kopi (snapshot) av en database på filnivå. En slik backup gir hurtig restore, og kan med fordel brukes før man tester oppgraderinger eller om man ønsker en kopi av databasen for testformål. Eksemplene er fra en MSSQL 2008 server, men prosedyren kan brukes på de fleste MSSQL versjoner. Grensesnittet er varierer på de forskjellige versjonene, men det bør ikke være så vanskelig å finne igjen bildene på en nyere eller eldre utgave. Continue reading “Kopiere en MSSQL-database”

Hibernation (Dvale) på server

Under gitte forutsetninger kan man få slått på hibernation/dvalemodus på en Windows 2008 server som standard ved installasjon. Dersom serveren ved installasjon har mindre enn 4GB minne vil det bli opprettet en hiberfil.sys og hibernation vil bli slått på. Dette fordi den da tror at du kjører demo på en bærbar og derfor trenger støtte for dvalemodus om batteriet går tomt. Siden denne filen vil være like stor som fysisk minne vil den ta opp en del plass som det vanligvis er bedre å bruke til andre ting. Det kan slåes av ved å kjøre følgende kommando:

powercfg.exe /h off

Kommandoen må som de fleste andre systemkommandoer kjøres i et elevated command prompt (Høyreklikk og velg “Run as administrator”).

Symbols i Process Explorer

Det geniale feilsøkingsverktøyet Process Explorer blir enda bedre om det får ta i bruk MS sin symbolserver slik at den kan fortelle mer om hva de forskjellige trådene driver med, nærmere bestemt hvilken funksjon den utfører. Dette forutsetter selvsagt at MS har symbolinformasjon om prosessen man analyserer.

SNAGHTML3979fe1a

For å aktivere, fyll ut Configure Symbols:

SNAGHTML394585fd

Den foreslår dbghelp.dll plassering automatisk, men pass på at den faktisk ligger der. Om den mangler må man installere debugging tools fra SDK-en. Se https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/ for nedlasting og veiledning. Vær obs på at du ikke trenger hele SDK-en, bare debugging tools.

Om symbols path settes til

http://msdl.microsoft.com/download/symbol

vil den laste ned hver gang den trenger noe. Evt kan du be den bruke en cache i en lokal mappe ved å angi

srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Du må da og sette en environment variabel. På vista og nyere gjøres det ved å kjøre

setx _NT_SYMBOL_PATH "srv*c:\symbols*http://msdl.microsoft.com/download/symbols" /M

Denne variablen kan da brukes av alle windows debugging verktøyene, og symboler som er lastet ned dit vil gå mye raskere å slå opp. Dersom du vil laste ned symboler for feks hele windows\system32 katalogen kan du kjøre kommandoen

symchk /r c:\windows\system32 /s SRV*c:\symbols\*http://msdl.microsoft.com/download/symbols

Se http://support.microsoft.com/kb/311503 for mer informasjon.

Bladeservere fusker under/etter oppdatering av UEFI (BIOS)

Det hender at maskiner med UEFI istedenfor BIOS nekter plent å starte opp etter at man har oppdatert UEFI. Det er da viktig å passe på at du har oppdatert management-modulen samtidig (ILO, IMM, DRAC e.l.). Dersom disse ikke er kompatible blir det bare rot. Det samme gjelder forsåvidt de sentrale managementmodulene i chassiet, de må ofte oppdateres samtidig som UEFI for at bladene skal kunne snakke sammen med chassiet. Eksemplene som er nevnt her er stort sett hentet fra IBM Bladecenter H med HS22 blade, men det meste er også opplevd på HP BL460. Flere av løsningene vil med litt fantasi fungere også på HP, eller om ikke ihvertfall peke i retning av en løsning.

Maskinen starter ikke i det hele tatt eller henger på UEFI initialisering

Forsøk disse i rekkefølge til du får respons.

  • Før du begynte burde du ha sjekket at IPv4 innstillingene for eventuelle IBM USB RNDIS nettverkskortet var satt riktig og at dette ikke var deaktivert. Sjekk dette når du får serveren opp igjen for å unngå fremtidige problemer.IBM RNDIS Og så fremt du ikke bruker IPv6, slå dette av på alle nettverkskortene.
  • Slå  av bladet og ta det ut av chassiet. Vent 2 minutt, sett det inn igjen. Vent til On-lampen blinker langsomt(1-5 minutt), og slå på.
  • Vent i minst 10 minutt på at maskinen skal boote.
  • Slå av bladet, ta det ut av chassiet og ta ut biosbatteriet under den blå gummihetten og eventuelle fiberkort. Vent i 2 minutt, sett inn batteriet men ikke eventuelle fiberkort. Sett inn bladet, vent på langsom blink og slå på.
  • Vent i opptil 30 minutt på at maskinen skal boote. Første boot etter batteribortfall eller firmwareoppdatering tar av og til fryktelig lang tid, og så plutselig bare virker den. Etter 30 minutt kan du dog trygt gi opp.
  • Dersom første boot etter batteribortfall feiler, slå av og slå på igjen.
  • Dersom det fortsatt ikke virker, feilmeld til produsenten. Du har da klart å “forsteine” hovedkortet og det må sannsynligvis skiftes.

Maskinen finner ikke boot disk

  • Sjekk at start options er satt riktig i bios:
    Start options
  • Sjekk om du får kontakt med disken ved å boote til en windows server setup cd med samme versjon som er installert på disken. Pass på forskjellen på 64 og 32 bit.
  • Start installasjonen og gå frem til valg av disk. Sjekk at disken står listet der. Avbryt installasjonen, velg repair and recovery, og åpne et kommandoprompt.
  • Start diskpart (den kan bruke noen minutt på å starte opp)
  • Skriv kommandoen “select disk n”, der n er nummeret på den disken som operativsystemet ligger på (Du kan se hvilke du har ved å kjøre list disk)
  • Skriv kommandoen “select volume n”, der n er nummeret på den partisjonen som operativsystemet ligger på (Du kan se hvilke du har ved å kjøre list volume)
  • Skriv kommandoen “online volume”
  • Du kan sjekke om det virker ved å skrive kommandoen “detail volume”
  • Gå ut av diskpart ved å skrive “exit”image
  • Kjør disksjekk på C: (“chkdsk c: /F”) og vent til den er ferdig
  • Restart server.

Maskinen krasjer etter oppdatering, BSOD (HS22)

Under gitte forutsetninger kan man ende opp med et ustabilt system etter oppdatering, der maskinen går en stund for så å gå i blåskjerm. En analyse av minidump ga meg følgende:

BUGCHECK_STR:  0x124_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT_SERVER_MINIDUMP

PROCESS_NAME:  System

CURRENT_IRQL:  f

STACK_TEXT:
fffffa60`01b91958 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx

STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hardware

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel__UNKNOWN

BUCKET_ID:  X64_0x124_GenuineIntel__UNKNOWN

Followup: MachineOwner

Dette gjentok seg en par tre ganger i løpet av 12 timer, så jeg feilmeldte. De hyggelige folkene hos IBM kunne da fortelle meg at jo, dette var en kjent feil. Det har seg nemlig sånn at dersom man hadde rett type ekspansjonskort installert i serveren så må man endre en av standardinnstillingene i BIOS. Mer spesifikt må man endre System Settings –> Devices and I/O Ports –> PCIe Gen1/Gen2 Speed Selection fra Gen2 til Gen1.

image

Tilleggskort som fører til denne feilen per 2010.11.12:

Broadcom 10 Gb 2-port Ethernet Expansion Card (CFFh) for
IBM BladeCenter, Option 44W4466, FRU 44W4469
Broadcom 10 Gb 4-port Ethernet Expansion Card (CFFh) for
IBM BladeCenter, Option 44W4465, FRU 44W4472
Emulex 8 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 46M6140, FRU 46M6138
NetXen 10 Gb Ethernet Expansion Card (CFFh), Option
39Y9271, FRU 39Y9269
QLogic 2-port 10 Gb Converged Network Adapter (CFFh) for
IBM BladeCenter, Option 42C1830, FRU 42C1832
QLogic 4 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 46M6065, FRU 46M6068
QLogic 8 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 44X1945, FRU 44X1948
QLogic Ethernet and 4 Gb Fibre Channel Expansion Card
(CFFh) for IBM BladeCenter, Option 39Y9306, FRU 39Y9304
QLogic Ethernet and 8 Gb Fibre Channel Expansion Card
(CFFh) for IBM BladeCenter, Option 44X1940, FRU 44X1943
SAS Connectivity Card (CIOv) for IBM BladeCenter, Option
43W4068, FRU 46C4069
ServeRAID-MR10ie (CIOv) Controller for IBM BladeCenter,
Option 46C7167, CRU 46C7171

Shrinkfile

Innimellom vokser  SQL data eller logfiler til gigantiske proporsjoner, uten at de nødvendigvis inneholder noe fornuftig.Du kan få en liste over  loggbruk og størrelse ved å kjøre følgende kommando:

DBCC sqlperf(logspace)

Transaksjonsloggen bør vanligvis ikke være større enn ca 25% av databasestørrelsen, men det kommer an på hvor ofte den tømmes. Dersom den plutselig blir betydelig større enn normalt for en gitt database er det grunn til bekymring og videre etterforskning.

Hvor stor databasen er og hvor mye av plassen som brukes til noe fornuftig kan du sjekke for en og en database med følgende kommandoer:

USE [DatabaseNavn];
GO
EXEC sp_spaceused @updateusage = N'TRUE';
GO

I SQL 2008 management studio kan du også få opp en Disk usage rapport som gir fancy kakediagram og forklaringer i tillegg.

For å krympe en fil må du vit hva den heter. Dette sjekkes i databaseinnstillinger. Det er ikke det faktiske filnavnet du er ute etter, men det logiske navnet.

USE [Databasenavn]
GO
DBCC SHRINKFILE ([logisk filnavn], [Ønsket størrelse i MiB])
GO

For å unngå diskfragmentering bør du angi en størrelse som er omtrent det du tror den trenger å være. For loggfiler har vi en tommelfingerregel som sier at samlet størrelse på loggfilen (og det skal helst bare være en) bør være 25% av samlet størrelse på datafil(ene). Dette vil gi et godt utgangspunkt.

Feilsøking

Innimellom vil en shrinkfile resultere i en eller annen feilmelding (sjekk messages-vinduet). Det skyldes vanligvis en av følgende:

  • For lite ledig diskplass
  • Slutten av filen er i bruk. (loggfiler er delt opp i mindre virtuelle logger)
  • Databasen/loggen er korrupt

Først og fremst bør du sjekke i feilloggen om databasen er korrupt eller om den har andre feil relatert til problemdatabasen.

Dersom du har for lite diskplass, frigjør plass om mulig. Eventuelt kan du dismounte basen og flytte den til en annen større disk først.

For å sjekke hvor mange elementer loggen består av kan man kjøre DBCC LOGINFO:

image

Status 0 angir at fragmentene kan fjernes ved krymping. Siden Shrinkfile bare sletter fra slutten av filen(som er bunnen  av listen over), kan den bare slette opp til og med den siste fragmenten med status 0.

Dersom siste fragment ikke har status 0 kan du korrigere dette. Hvordan du går frem avhenger av om du bruker Simple recovery eller ikke. Dersom du har simple recovery, kjør denne kommandoen isteden:

USE [Databasenavn]
GO
CHECKPOINT
DBCC SHRINKFILE ([logisk filnavn], [Ønsket størrelse i MiB])
GO>

Dersom det ikke virker første gang, kjør den flere ganger. Du kan sjekke fremgang ved å kjøre Loginfo som nevnt over.

Om du bruker full eller bulk logged recovery, ta en backup av loggen og prøv igjen. Kjør eventuelt flere backup etter hverandre om det ikke hjelper på første forsøk. Om alt annet feiler kan du bytte til simple recovery model midlertidig, men det bør være siste utvei. Noen anbefaler å ta basen offline og slette loggfilene. Dette er direkte farlig, da det kan føre til at basen ikke lar seg åpne igjen etterpå. Siden prosedyren over ofte brukes for å rydde opp etter en feilsituasjon er dette særdeles risikabelt. Loggfilen er den viktigste filen til databasen.

Se https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/ for mer informasjon (engelsk).

Korrigere windowsupdate

Situasjonsbeskrivelse

Innimellom når man installerer en ny w2k8 server blir det en konflikt i Windows update etter at man har kjørt den første gang. Lignende feil kan også oppstå senere.

Diagnose

Feilen gjenkjennes ved å se etter følgende:
• Eventid 4385 fra Servicing i systemloggen:

• Ikke mulig å kjøre windows update, for eksempel alle updates feiler.
• maskinen kommer med en popup ved pålogging som sier ”Unable to download updates from windowsupdate” eller noe i den dur.
• Hver gang du logger på får du beskjed om at du må restarte for å aktivere oppdateringer, selv om du nettopp har restartet.
• Maskinen går i en boot loop, der den bare kommer til ”Applying updates, stage x av 3” (Se fix 2 for denne)

Fix1

For å korrigere dette kjøres Microsoft Fixit nr 50202 (ligger på http://support.microsoft.com/kb/971058 ). Pass på å hake av aggressive options når den starter opp. Samme fix kan brukes på klienter om nødvendig, og den løser de fleste windows update relaterte problemer. Fixen krever omstart av maskinen.
Sjekk at ting virker ved å kjøre manuell windows update etterpå.

Fix2

Dersom man ikke korrigerer problemet og fortsetter å installere programmer, kan man ende opp med en maskin som nekter å starte. Den booter til ”Windows is applying updates, stage x of 3”, står der en stund, og så restarter maskinen. Den går altså i en loop.
For å korrigere denne feilen må man boote fra installasjonsmedia, velge Repair my computer, åpne ett konsollvindu og endre navn på filen [Drive]:\windows\winsxs\pending.xml. (Drive varierer, men er ofte D)
Etter omstart får man boote igjen, men windows update er pooched. Utfør fix1 for å korrigere.

Maintenance plans–change owner

Problem

Sometimes you might want to change the owner of a job connected to a maintenance plan. For instance, the current owner could be a deleted account, something that will cause the jobs to fail with not so funny error messages regarding permissions or missing accounts. It is possible to change the job owner using TSQL or Management Studio, but each time the plan is updated, the owner is overwritten by the owner of the maintenance plan. To change this, you have to use TSQL AFAIK.

 

Solution

NB: Running this is dangerous if you don’t know what you are doing! The msdb.dbo.ssispackages table contains system objects as well as your manually created plans, and could also contain SSIS packages as the name indicates. Always take a backup of MSDB before making changes.

Changing the maintenance plan owner on MSSQL 2000:

update msdb.dbo.sysdbmaintplans
set
owner=’SQL Systembruker’
where owner like ‘Feil bruker’

On MSSQL 2008R2:

UPDATE msdb.dbo.sysssispackages
SET
ownersid=suser_sid(’New User’)
WHERE ownersid = suser_sid(’Old user’)

or just set sa as the owner of everything:

UPDATE msdb.dbo.sysssispackages
SET
ownersid=0x01
WHERE ownersid != 0x01

Afterwards, either save the plan to update job ownership or run the following to change the job owner as well.

update msdb.dbo.sysjobs
set
owner_sid=suser_sid(’SQL Systembruker’)
where suser_sname(owner_sid) like ‘Feil bruker’

or just set sa as the owner of everything here as well:

update msdb.dbo.sysjobs
set
owner_sid=0x01
WHERE owner_sid != 0x01

If it doesn’t seem to work as expected, restart the agent service.