우리는 SQL Server 2016 서버에서 ERP 소프트웨어를 VMware ESXi의 VM으로 실행하고 있습니다. 현재 VM은 2개의 드라이브로 구성되어 있으며 데이터는 1개로 이동하고 다른 하나는 로그로 기록됩니다. VM이 손상되었을 때 문제가 발생하여 VEEAM 백업으로 되돌렸습니다. 복원하는데 꽤 시간이 걸렸지만 성공적으로 완료되었습니다. 안타깝게도 약 4시간 동안의 데이터가 손실되었습니다. 그리고 트랜잭션 로그가 서버와 함께 남쪽으로 이동했기 때문에 트랜잭션 로그에서 복원할 수 없었습니다.
그래서 우리는 다른 네트워크 공유에 트랜잭션 로그를 쓰는 것을 고려했습니다. 그러나 테스트 데이터베이스에서 이를 설정하려고 하면 SQL Server가 이를 허용하지 않는 것 같습니다.
이 작업을 수행할 수 있는 방법이 있나요? 상당한 성능 저하가 있습니까? 더 나은 접근 방식이 있습니까?
답변1
이 작업을 수행할 수 있는 방법이 있나요?
예, 그러나 아마도 당신은 이것을 하고 싶지 않을 것입니다. 활성화할 수 있습니다.추적 플래그 1807SQL Server가 데이터 및 로그 파일에 UNC 경로를 사용하도록 합니다. 그러나 해당 문서에서는 다음과 같습니다.
Microsoft에서는 일반적으로 Microsoft SQL Server 데이터베이스 파일 저장을 위해 SAN(Storage Area Network) 또는 로컬로 연결된 디스크를 사용할 것을 권장합니다. 이 구성이 SQL Server 성능과 안정성을 최적화하기 때문입니다.
(링크된 문서에는 SQL 2016이 기본적으로 이를 허용해야 한다고 나와 있지만 "SQL Server에서는 이를 허용하지 않는 것 같습니다"에 대해 자세히 설명해야 합니다.)
상당한 성능 저하가 있습니까?
때에 따라 다르지귀하의 하드웨어에. 이는 "로컬" 스토리지가 어디에 있는지(ESXi 호스트 내부의 회전 디스크, SAN 또는 다른 위치)에 따라 다릅니다. 그리고 사용을 고려 중인 네트워크 공유의 기반이 되는 스토리지에 따라 다릅니다. 결국에는 동일한 하드웨어를 사용하게 될 수 있으며, 이 경우 성능 차이가 약간의 VMware 오버헤드로 귀결될 수 있습니다. Microsoft는 위에 링크된 문서에서 성능 고려 사항에 대해 자세히 설명합니다.
더 나은 접근 방식이 있습니까?
예
트랜잭션 로그 파일 자체(일반적으로 *.ldf)는 재해로부터 복원하는 데 사용하려는 파일이 아닙니다. 서버에 로컬로 두는 것이 적절합니다. 그리고 이전처럼 데이터 파일(일반적으로 *.mdf)과 별도의 드라이브에 저장하는 것이 좋습니다.
재해가 발생하여 백업에서 복원해야 하는 경우 전체 백업에서 복원한 다음 일부 차등 백업에서 복원한 다음 일부 트랜잭션 로그 백업에서 복원할 수도 있습니다. 따라서, 당신은 당신의 글을 작성해야백업서버에서 멀리 떨어진 곳으로. 또는 최소한 로컬에서 작성해야 하는 경우 다른 곳으로 즉시 복사하는 프로세스를 갖추십시오. 알아낸 바와 같이 다양한 유형의 오류로 인해 모든 로컬 데이터를 사용할 수 없게 됩니다.
적절한 백업 메커니즘을 설정하는 방법에 대한 많은 자습서가 있습니다.브렌트 오자 무제한좋은 게 몇 개 있어요.