Czy zdażyło się wam odtwarzać po raz kolejny bazę danych po logicznym uszkodzeniu plików?
Wlaściwie kiedy ostatnio sprawdzano ją dostępnymi narzędziami?
Kiedy ostanio dokonano pełnej, różnicowej kopii bezpieczeństwa, jak często odkładane są logi transakcyjne?
Czy baza ma poprawny model recovery ?
Jeśli na chociaż jedno pytanie pojawiły się w głowie wątpliwości, to dobrze, że przed awarią…
Pomocny skrypt
if object_id('tempdb..#DBInfo') is not null
DROP TABLE #DBInfo
if object_id('tempdb..#DBCC') is not null
DROP TABLE #DBCC
CREATE TABLE #DBInfo (
Id bigint IDENTITY(1,1),
ParentObject VARCHAR(255),
[Object] VARCHAR(255),
Field VARCHAR(255),
[Value] VARCHAR(255)
)
CREATE TABLE #DBCC(
DatabaseName VARCHAR(255),
LastDBCCCHeckDB_RunDate VARCHAR(255)
)
EXECUTE SP_MSFOREACHDB'INSERT INTO #DBInfo Execute (''DBCC DBINFO ( ''''?'''') WITH TABLERESULTS'');
INSERT INTO #DBCC (DatabaseName) SELECT [Value] FROM #DBInfo WHERE Field IN (''dbi_dbname'');
UPDATE #DBCC SET LastDBCCCHeckDB_RunDate=(SELECT TOP 1 [Value] FROM #DBInfo WHERE Field IN (''dbi_dbccLastKnownGood'')) where LastDBCCCHeckDB_RunDate is NULL;
TRUNCATE TABLE #DBInfo';
SELECT
database_name = DB_NAME(d.database_id)
, log_size_gb = CAST(SUM(CASE WHEN d.type_desc = 'LOG' THEN d.size END) * 8. / 1024/1024 AS DECIMAL(10,4))
, row_size_gb = CAST(SUM(CASE WHEN d.type_desc = 'ROWS' THEN d.size END) * 8. / 1024/1024 AS DECIMAL(10,4))
, total_size_gb = CAST(SUM(d.size * 8. / 1024/1024) AS DECIMAL(10,4)),
db.recovery_model_desc,
cc.LastDBCCCHeckDB_RunDate
FROM sys.master_files d WITH(NOWAIT)
join #DBCC cc
on (cc.DatabaseName=DB_NAME(d.database_id) )
join sys.databases db
on (db.database_id=d.database_id)
GROUP BY d.database_id,cc.LastDBCCCHeckDB_RunDate,db.recovery_model_desc
order by cc.LastDBCCCHeckDB_RunDate,4 desc
;WITH LastBackUp AS
(
SELECT bs.database_name,
bs.backup_size,
bs.backup_start_date,
bmf.physical_device_name,
Position = ROW_NUMBER() OVER( PARTITION BY bs.database_name ORDER BY bs.backup_start_date DESC )
FROM msdb.dbo.backupmediafamily bmf
JOIN msdb.dbo.backupmediaset bms ON bmf.media_set_id = bms.media_set_id
JOIN msdb.dbo.backupset bs ON bms.media_set_id = bs.media_set_id
WHERE bs.[type] = 'D'
AND bs.is_copy_only = 0
)
SELECT
database_name AS [Database],
CAST(backup_size / 1024/1024/1024 AS DECIMAL(10, 2) ) AS [BackupSizeMB],
backup_start_date AS [Last Full DB Backup Date],
physical_device_name AS [Backup File Location]
FROM LastBackUp
WHERE Position = 1
ORDER BY [Database];
Hipotetyczny rezultat powyższego zapytania
database_name | total_size_gb | recovery_model_desc | LastDBCCCHeckDB_RunDate |
XYZ | 153.8079 | SIMPLE | 1900-01-01 00:00:00.000 |
tempdb | 58.6021 | SIMPLE | 1900-01-01 00:00:00.000 |
HURT | 49.2092 | SIMPLE | 1900-01-01 00:00:00.000 |
ABC | 46.6123 | SIMPLE | 1900-01-01 00:00:00.000 |
ZZA | 0.4893 | FULL | 1900-01-01 00:00:00.000 |
model | 0.1470 | SIMPLE | 1900-01-01 00:00:00.000 |
master | 0.0148 | SIMPLE | 1900-01-01 00:00:00.000 |
msdb | 5.8594 | SIMPLE | 2015-10-06 13:34:30.730 |
Na co zwrócić uwagę ?
Bazy systemowe (master, model,msdb,tempdb) mają ustawiony recovery model równy SIMPLE. Żadna z nich, poza msdb nie była nigdy sprawdzona narzędziem DBCC CheckDB ? To dobrze ?
Jedyna baza w trybie FULL teź nigdy nie została sprawdzona.
Do odważnych świat należy,ale nie do nieroztropnych.
https://www.mssqltips.com/sqlservertip/4381/sql-server-dbcc-checkdb-overview/
mmoskit
Warto pamiętać, że kiedy baza jest w FULL recovery mode a nie było zrobionego pełnego backupu bazy to tak naprawdę zachowuje się jak w SIMPLE
djkormo
Nie wiem, czy gratulować takiemu administratorowi ?
Dobry administrator w starym stylu, to taki, którego pracy praktycznie nie widać, a systemy działają tygodniami, miesiącami i latami…..