Operationel statusmonitorering af Zylinc-løsninger, del 6
I denne post (den sidste i serien) ser vi på, hvordan du overvåger status på Zylinc-løsningens SQL Server-databaser
Baggrund: Mange organisationer ønsker at kunne monitorere deres kritiske IT- og kommunikationsløsningers performance, så de hurtigt kan tage sig af potentielle problemer, inden alt for mange brugere bliver påvirket. Hvis du arbejder med IT-drift i IT Operations eller en lignende afdeling, er denne blog-serie skrevet til dig. Den beskriver det, du bør vide, hvis du skal overvåge driften af en Zylinc-løsning.
På en Zylinc-løsning er der to vigtige SQL Server-databaser. De hedder ZyDB og ZyStatDB.
Når man installerer Zylinc-løsningen, sætter man en SQL Server-service op, som kører de to databaser. Servicen kan sættes op på Zylinc Windows Application Serveren (som er den server, der kører al Zylinc-backendens Windows-baserede software), men man kan også vælge at sætte servicen op på en dedikeret server eller på et cluster.
Vi anbefaler, at du overvåger SQL Server-servicen, lige meget hvor I har sat den op.
Proaktiv monitorering
En af de oftest forekommende grunde til at en Zylinc-løsning kan holde op med at virke er, at en database løber tør for ledig plads og bliver read-only. Heldigvis kan du proaktivt holde øje med dette, og forhindre at det sker, ved at:
- Monitorere at alle diske på jeres SQL Server altid har tilstrækkeligt med ledig plads, for eksempel mindst 5GB ledig plads pr disk
- Tjekke recovery models (det hedder ifølge Microsoft genoprettelsesmodeller på dansk, men her bruger jeg altså de engelske begreber) og backup schedules på jeres databaser
Lad os begynde med at se på, hvordan du tjekker recovery models og backup schedules. Det kan du gøre manuelt, men du kan også bruge et script til at automatisere processen:
Tjek databasernes recovery models og backup schedules
Hvis jeres backup schedule ikke inkluderer en regelmæssig backup af transaktionslogs, og en databases recovery model er sat til Full eller Bulk-logged, vil databasens transaktionslogfiler (LDF-filer) vokse og vokse indtil disken er fuld. Hvis det sker, bliver databasen read-only, og så vil jeres Zylinc-løsning holde op med at virke. Det ønsker vi ikke!
Du kan bruge SQL Server Management Studio til at gennemgå jeres databaser og manuelt tjekke deres recovery models. Hvis du finder en database, der har dens recovery model sat til Full eller Bulk-logged, skal du tjekke, at dens Last Database Log Backup ikke er for gammel, for eksempel ældre end 24 timer.
Fordelen ved regelmæssig backup af logs er, at de pågældende logs så ofte vil blive trunkeret, hvilket reducerer filstørrelserne. Hvis Last Database Log Backup ikke er for gammel, kan du derfor med stor sandsynlighed regne med, at databasen har en backup schedule, der inkluderer en regelmæssig backup af databasens transaktionslogs.
Faktisk er der en nemmere måde at undersøge dette på: Du kan automatisk tjekke jeres konfiguration ved hjælp af et SQL-script, som du kan downloade fra Zylinc unified help.
Scriptet returnerer advarsler, hvis backups er for gamle, eller der aldrig er blevet lavet backups. Du kan få scriptet til automatisk at køre med jævne mellemrum, og du kan tilpasse den højeste acceptable alder for en backup. Du kan også få scriptet til at returnere et overblik over de senest foretagne backups, hvis du får brug for det.
Defragmentér databasernes indexes
Databaser indeholder indexes som kan blive fragmenterede. Vi anbefaler derfor, at du regelmæssigt tjekker, om det er nødvendigt at defragmentere jeres databasers indexes. Du kan læse mere om, hvordan du gør det – og om, hvad du skal gøre, hvis fragmenteringsgraden er for høj – på Zylinc unified help.
Alternativt kan en databaseadministrator (dba) sætte maintenance planer op, som kan udføre opgaverne automatisk.
Avanceret analyse med SQL Server Profiler
Hvis du, eller jeres dba, vil bruge SQL Server profiler til at sætte en trace op, kan de her kolonne-filtre være nyttige:
- Duration med greater than or equal to sat til, for eksempel, 2000ms vil advare dig, hvis queries på jeres SQL Server tager for lang tid at eksekvere
- Reads med greater than or equal to sat til, for eksempel, 65000 pages vil advare dig, hvis queries på jeres SQL Server ikke længere kan udføres effektivt
Hvis du opdager noget, der kræver ændringer i fx indexes eller stored procedures, skal du kontakte Zylinc support for at få hjælp til at lave ændringerne. Det skyldes, at jeres licensaftale med Zylinc typisk ikke tillader, at I selv laver ændringer i indexes, stored procedures mv. i databaser fra Zylinc.
Monitorér SQL Server-servicens netværksport
Du bør overvåge SQL Server-servicens default-netværksport. Det er typisk port 1433/tcp.
Monitorér SQL-brugeren som Zylinc-systemet anvender
Når man installerer Zylinc-løsningen, laver man typisk en mixed mode security-bruger, der har navnet ZyUser og rollen db_owner på begge Zylinc-databaserne, altså ZyDB og ZyStatDB. Zylinc-løsningen bruger så ZyUser, når den skal tilgå de to databaser.
Vi anbefaler, at du overvåger, at ZyUser altid kan tilgå de to databaser: Begge databaserne har en tabel ved navn database_info, som du kan lave en query på. Query’en skal altid returnere minimum én række.
Du kan sætte monitorering op, hvor du bruger ZyUser til at logge ind på de to databaser, ZyDB og ZyStatDB, og eksekverer denne her query:
select * from database_info
Query’en skal som sagt altid returnere minimum én række.
Monitorér at begge databaserne kan opdateres
Selv om en database er online, og man kan læse data fra den, kan disken der indeholder databasens transaktionslog gå hen og blive korrupt eller løbe fuld, og så vil Zylinc-løsningen holde op med at virke. Det samme gælder, hvis databasens størrelse overskrider det maksimalt tilladte (hvilket på SQL Server Express Edition typisk kan være så lidt som 10GB). Igen: Det ønsker vi ikke!
Derfor anbefaler vi, at du sætter monitorering op, der tjekker status på updateability på både ZyDB og ZyStatDB:
SELECT DATABASEPROPERTYEX('zydb', 'Updateability');
SELECT DATABASEPROPERTYEX('zystatdb', 'Updateability');
Hvert af de to queries skal returnere en række der indeholder værdien READ_WRITE.
Hvis du vil vide mere, er der meget mere at komme efter i dokumentationen til Microsoft SQL Server og højst sandsynligt også i dokumentationen til dit monitoreringsværktøj.
Regnorme har to ender, eller sådan ser det i hvert fald ud, men den her blog-serie har kun én, og vi er lige ved at nå den: Her slutter vores serie om operationel statusmonitorering. Jeg håber, at du har kunnet bruge nogle af de ting, vi har gennemgået i løbet af serien.