클라이언트의 SQL 서버에 많은 데이터베이스가 있습니다. 이 데이터베이스는 개발 중이므로 개발자는 데이터를 디자인, 리팩토링 및 수정하는 등의 작업을 수행 할 수 있습니다. 거의 변경되지 않는 일부 데이터베이스가 있습니다. 내 고객은 모든 것을 안전하게 (백업) 유지하고 환경 관리에 시간을 투자해야합니다. (회사에는 DB 관리자 위치가 없습니다.) 긴 토론 후, 클라이언트는 복원 용이성으로 인해 매일 전체 백업 전략을 사용하기로 결정했습니다.
상황에 대한 요약은 다음과 같습니다.
- 데이터베이스 수는 매일 달라질 수 있습니다.
- 변경된 데이터베이스 (데이터 및 / 또는 구조가 변경됨)는 백업되어야합니다.
- 변경되지 않은 데이터베이스는 백업하지 않아야합니다.
- 솔루션은 데이터베이스 구조에 영향을 미치지 않습니다 (요구 사항이 제한되지 않음)
- 이 "백업 엔진"은 자동으로 작동합니다.
주요 문제점 : 데이터베이스가 변경되었음을 감지하는 방법. 문제의 첫 번째 부분 (DDL 변경)은 DDL 트리거 를 사용하여 해결할 수 있습니다 . 그러나 데이터 변경 (DML 변경)은 문제입니다. DML 트리거를 모든 데이터베이스의 모든 테이블에 적용하여 변경 내용 (성능, 확장 개체 관리 등)을 추적 할 수는 없습니다. 백업 엔진은 각 데이터베이스를 백업 준비 상태로 표시하기 위해 모든 변경 사항을 추적해야합니다.
Change Data Capture 는 솔루션이지만 너무 무거워 보입니다 (SQL Server Enterprise Edition도 필요함).
다른 방법은 데이터베이스 파일 변경 사항 (크기 또는 마지막 변경 시간)을 추적하는 것이지만 제대로 작동하지 않습니다. 데이터베이스가 예약 된 모든 여유 공간을 초과하고 sp_spaceused 가 해결책이 아닌 경우 크기를 변경할 수 있습니다 .
추적은 솔루션이지만 성능 문제를 일으키고 추가 관리가 필요합니다.
통계와 같은 다른 데이터베이스 관리 개체에 영향을주지 않고 실제 데이터베이스 사용 크기를 계산할 수있는 솔루션이 있습니까? 테이블의 크기를 변경하지 않는 테이블 데이터의 변경이 트리거되지는 않지만 (아마 생각보다) 더 낫습니다. 실제로 SQL Server 2008에 대한 직접 또는 간접 솔루션을 찾고 있습니다.
의견, 해결책 및 생각에 감사드립니다.
추가 :
다음은 해결책입니다 ( Marian 덕분에 ).
Select
NextLSN = MAX(fn.[Current LSN])
,Databasename = DB_NAME()
from fn_dblog(NULL, NULL) fn
LEFT JOIN sys.allocation_units au
ON fn.AllocUnitId = au.allocation_unit_id
LEFT JOIN sys.partitions p
ON p.partition_id = au.container_id
LEFT JOIN sys.objects so
ON so.object_id = p.object_id
WHERE
(
(Operation IN
('LOP_INSERT_ROWS','LOP_MODIFY_ROW',
'LOP_DELETE_ROWS','LOP_BEGIN_XACT','LOP_COMMIT_XACT')
AND so.is_ms_shipped = 0)
OR
([Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%')
)