SQL Server FILESTREAM을 사용할 때 (부분) 백업을 작게 유지


12

FILESTREAM백업 할 필요가없는 거의 1TB의 데이터 가있는 데이터베이스가 있습니다 (데이터가 삭제되면 몇 시간 안에 자동으로 다시 생성되므로 중요하지 않습니다). 대부분의 데이터는 며칠마다 변경되므로 차등 백업은 실제로 크기를 줄이는 데 도움이되지 않습니다.

복구 모드를로 설정 Full하고에 대한 별도의 파일 FILEGROUP을 만든 FILESTREAM다음 "기본"만 백업하여 백업이 필요한 방식으로 작동하도록했습니다 FILEGROUP. 이로 인해 발생하는 문제는 로그 파일 (백업되기도 함)이 FILESTREAM데이터를 포함하기 때문에 불필요하게 커졌기 때문 입니다.

SIMPLE복구 모드는 특정 백업을 수행 할 수있는 능력을 없애 FILEGROUP므로 그중 하나가 옵션이라고 생각하지 않습니다.

내 생각은 FILESTREAM데이터를 별도의 데이터베이스 로 옮기는 것이지만 이제는 참조 무결성을 잃어 버리고 다른 많은 문제를 상속받습니다.

테이블을 읽기 전용으로 Simple설정하지 않고 복구 모드 에서 부분 백업을 작성하는 방법이 FILESTREAM있습니까? 그렇지 않은 경우 내 문제에 대한 다른 적절한 해결책이 있습니까?

답변:


3

이로 인해 FILESTREAM 데이터가 포함되어 있기 때문에 로그 파일 (백업되는 파일)도 불필요하게 커질 수있었습니다.

로그 파일 자체가 너무 크거나 로그 파일 백업이 너무 커지는 지 확실하지 않습니다.

전자의 경우 로그를 얼마나 자주 백업 했습니까? 응용 프로그램 디자인에 따라 더 자주 백업하여 크기를 줄일 수 있습니다 (5 분마다 너무 자주는 아님). 그러나 이미 그렇게하고 있고 여전히 풍선 모양이라면 운이 나쁠 것입니다. 큰 로그 파일이 다시 문제가되는 이유는 무엇입니까?

후자 인 경우-간단한 복구 모델을 계속 사용하는 것이 좋으며 백업을 더 작게 만들면 특정 시점으로 복원하지 않는 것처럼 들립니다. 이 경우 전체 모드를 유지하고 로그 백업을 삭제하십시오.


종종 드물지 않은 로그 백업을 인식하지 못했습니다! "큰 로그 파일이 왜 다시 문제가됩니까?" 질문은 실제로 그것에 대해 생각하게했으며 대답이 없었습니다. +100 당신에게!
David Murdoch

3

복구 모드 SIMPLE로 설정된 데이터베이스에 대한 솔루션은 FILESTREAM 데이터를 읽기 전용 파일 그룹 (이상적인 옵션은 아님)에 저장하고 다음과 같이 DIFFERENTIAL을 사용하여 읽기 / 쓰기 파일 그룹 만 백업하는 것입니다.

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

읽기 / 쓰기 파일 그룹에서 변경된 모든 데이터를 가져옵니다. FILESTREAM 데이터를 가져 오지 않고도 부분 백업을 관리 할 수있는 가장 쉬운 방법입니다. 그러나 위에서 언급 한 데이터의로드 프로세스는 파일 그룹을 읽기 / 쓰기로 수정하고 추가 데이터를로드 한 다음 다시 읽기 전용으로 설정해야합니다. 확실히 이상적이지 않습니다.


자동화 된 시스템이 때때로 FILESTREAM을 READONLY로 처리하도록 설계 되었으면 완벽했을 것입니다. 불행히도, 모든 서비스를 리팩토링하는 데 너무 많은 시간이 걸렸을 것입니다. 특히 문제가 발생했을 때 하드 드라이브를 던질 수 있기 때문입니다. 덕분에 앞으로 모든 새로운 서비스가이를 염두에두고 설계 될 것이며 시간이 지남에 따라 기존 서비스를 업데이트 할 계획이 적용됩니다. (나는 당신에게 현상금의 절반을 보상 할 수 있기를 바랍니다!
David Murdoch

2

이것을 옵션으로 제공하는 것이 더럽지 만 FILESTREAM 데이터를 자체 데이터베이스로 분리하기로 선택한 경우 트리거 를 통해 별도의 DB에서 테이블 간 RI를 유지할 수 있습니다 .

트리거-> 설명-> 제한 사항 :
트리거는 현재 데이터베이스에서만 작성됩니다. 그러나 트리거는 현재 데이터베이스 외부의 오브젝트를 참조 할 수 있습니다.

좌절에 머리 털의 술을 뽑은 후 성능 문제와 두피 부분이 털이 없어 질 것으로 예상하지만 이론적으로 그렇게 할 있습니다. 어느 수준에서나이 방법을 권장하지 않습니다. 대신 로그 백업 빈도를 늘리거나 대량 로그 복구 모델로 전환 하고 저장 공간이 얼마나되는지 확인하는 것이 좋습니다. 그러나 이것이 가능한 솔루션입니다. 실제로이 데이터를 분리하고 Frankensteinian 데이터베이스 설계를 처리 할 경우 얻을 수있는 이점을 고려해야합니다. 그러나 이는 선택 사항입니다.

... 지금 샤워를해야 해요 ...


1

나는이 질문에 이미 답변되었지만 다른 사람들을 도울 수있는 다른 해결책이 있다는 것을 알고 있습니다. 최근 Brent Ozar의 블로그 에서 로그 백업을 즉시 버리는 옵션이 있다는 것을 알게되었습니다 .

BACKUP LOG MyDb TO DISK='NUL:'

따라서 데이터베이스를 Full복구 모드로 유지하고 파일 그룹을 백업 할 수 있습니다. 트랜잭션 로그가 너무 커지면 backup log 명령을 실행하면 완료됩니다.


예기치 않은 활동으로 인해 로그 파일 크기가 부당하게 증가하지 않도록 로그 백업을 예약 된 작업으로 실행하는 것이 좋습니다.
RDFozz
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.