Verify Latest Database Backups – T-SQL

A common challenge is to determine when database backups were taken from our databases. As soon as there are more than three user databases, this task is not that easy to accomplish by opening the database properties dialog in SSMS and checking the Last Full/Log Backup lines on the General tab. Scripting is your friend – as always :)

A very simplistic approach is to just get the time of the latest backups taken.

SELECT d.name as DBName, 
      ISNULL(CONVERT(varchar(16), MAX(bs.backup_finish_date), 120),'------ NEVER') as LastBackup
FROM sys.databases d
LEFT OUTER JOIN msdb.dbo.backupset bs ON bs.database_name = d.name
WHERE d.name != 'tempdb'
GROUP BY d.Name
ORDER BY d.Name;

Ok, that was easy – where’s the catch? Well, what kind of backup was taken of your database at that time? Was it a full, a copy-only or just a transaction log? Oops… So, let’s RTFM and find the magic column in the backupset table: type. Typically, we’re interested in the full, incremental and log backups, when applicable. Version 2:

SELECT d.name as DBName, 
      ISNULL(CONVERT(varchar(16), bs_D.LastBackup, 120),'------ NEVER') as LastFullBackup,
      ISNULL(CONVERT(varchar(16), bs_I.LastBackup, 120),'------ NEVER') as LastDiffBackup,
      CASE WHEN d.recovery_model_desc = 'SIMPLE' THEN 'N/A' ELSE ISNULL(CONVERT(varchar(16), bs_L.LastBackup, 120),'------ NEVER') END as LastTLogBackup
FROM sys.databases d
LEFT OUTER JOIN (select database_name, max(backup_finish_date) LastBackup FROM msdb.dbo.backupset WHERE type = 'D' group by database_name) bs_D ON bs_D.database_name = d.name
LEFT OUTER JOIN (select database_name, max(backup_finish_date) LastBackup FROM msdb.dbo.backupset WHERE type = 'I' group by database_name) bs_I ON bs_I.database_name = d.name
LEFT OUTER JOIN (select database_name, max(backup_finish_date) LastBackup FROM msdb.dbo.backupset WHERE type = 'L' group by database_name) bs_L ON bs_L.database_name = d.name
WHERE d.name != 'tempdb'
ORDER BY d.Name;

Looks a bit more fancy – and useful. If you’re really picky, you may want to check the full backups whether they were copy-only backups, by filtering on the is_copy_only column. Enjoy!

SQL 2005-2008 upgrade, játékosan

Alig használt SQL 2005 szerverünket SQL 2008-ra cseréljük, gariban. Jó az a 2005 Enterprise, az online minden félelmetesen jól működik, de hát az ember vérszemet kap, és akar filtered indexet meg tömörítést meg policy managementet meg mindenféle rettenetet, ha már fizetett érte…

Ha upgrade-ről van szó, csakis a side-by-side upgrade-et támogatom, azaz az átköltözést egy új verziójú szerverre, szemben az in-place upgrade-del, amikor az ember lefuttatja az upgrade-et az éppen futó szerverére. Miért? Mert üzemeltető vagyok, és szeretem, ha van hova visszatérni probléma esetén. Nem viccből van az oldal tetejére írva az, hogy ROLLBACK. Az üzemeltetésben fontos szempont, hogy legalább rontani ne rontsunk a helyzeten. A fejlesztő megteheti, neki kísérleteznie KELL, ami magában hordja a bukta lehetőségét – az üzemeltető ezt nem teheti meg. És mégis kísérleteznie kell, ezért jó a rollback. Mint minden jófajta stratégiai játékban.
Continue reading ‘SQL 2005-2008 upgrade, játékosan’ »

Csináljunk Maintenance Plant az adatbázisainkhoz! Csináljunk?

Aki ott volt a Technet üzemeltetői konferencián vagy letöltötte az internetről valamely darabkáját az előadásomnak, az emlékezhet rá, hogy ajánlottam a maintenance planek használatát mentések készítéséhez. A maintenance planek SQL 2005-ben tulajdonképpen Integration Services csomagok, azok csinálják a mentést, DBCC CHECKDB-t, stb. A wizarddal pikk-pakk össze lehet rakni egyet, és már ülhetünk is nyugodtan a babérjainkon (azért ne felejtsük el beállítani, hogy a jobok elbukása esetén küldjön levelet).

Ez mind jól hangzik, de: én nem szeretem, ha az ember dolgozik a gép helyett, tehát az adatbázis létrehozást is automatizáltam – mivel sorban töltöm fel a szerveket, mindig van egy olyan, amelyikre az új adatbázisok kerülnek. Úgyhogy írtam egy scriptet, amelyik létrehozza a teszt és/vagy éles adatbázist, a hozzá tartozó userrel együtt, akinek beállít egy 20 karakteres random jelszót, és íme: a linuxos kollégáim meg tudják csinálni az új adatbázisokat, nem kell várniuk arra, hogy egy DBA megcsinálja, a DBA-nak meg nem kell izgulnia, hogy mit rontott el a sysadmin :) Ebből már csak egy dolog hiányzik: a karbantartás és a mentés. Úgyhogy nekiálltam automatikusan legyártani az Integration Services csomagokat. Hadd fogalmazzak finoman: az egyik legsötétebb zsákutca volt, ahol valaha jártam. Végül eljutottam oda, hogy valami irgalmatlan nagy gányolással meg lehet oldani, és még így is marad benne némi homály. És ez nekem betett.

Úgyhogy szemléletet váltottam: a Transact-SQL kiválóan alkalmas backupok készítésére, akár időbélyeggel is, és mióta feltalálták a powershellt, a régi backup fájlok törlése sem okoz gondot. A full backup előtt természetesen lefut egy DBCC CHECKDB, ez pont plusz egy sor a T-SQL scriptben, és örülhetek, hogy mindig jó mentést teszek el. Az összes egyé karbantartást is meg lehet oldani T-SQL-lel (sp_updatestats, index javítás/újraépítés), úgyhogy nagyon kicsit sajnálkozva, ugyanakkor örülve az automatizált környezetemnek jelentem: kidobtuk a maintenance planeket. Majd ha lehet egyszerűen generálni őket, visszanézek.

(ja, nemsokára felteszem a scripteket is :))

Compressed backup – egy szép történet

Épp olvastam Paul Randal blogjában egy kis high-end SQL szerverről. Mivel egyszer volt egy közepesen kellemetlen beszélgetésem arról, hogy hogyan lehet nagy (terás) SQL adatbázisokat menteni, ez a téma különösen érdekel engem, és hát ők 12 backup device-ra mentettek 2 óra alatt, kicsit tuningolva az opciókon és több hálókártyát használva.
Hab a tortán: SQL 2008 backup compressionnel a 2 TB-ot 36 perc alatt mentik…