백업에서 SQL 데이터베이스를 복원하면 색인이 다시 작성됩니까?

10

백업에서 SQL 데이터베이스를 복원하면 테이블과 인덱스가 처음부터 다시 작성됩니까? 아니면 백업 당시와 동일한 내부 물리적 순서로 유지합니까?

우리는 Quest Lightspeed 압축 백업과 함께 SQL 2000을 사용하고 있습니다.

sql-server restore

— BradC
소스

16

어떤 백업 소프트웨어를 사용하든 대답은 '아니오'입니다.

백업은 논리적 작업이 아니라 물리적 작업입니다. 할당 된 페이지를 포함하는 모든 익스텐트를 읽습니다 (예 : 8 페이지 익스텐트의 단일 페이지 만 할당 된 경우에도 전체 64K 익스텐트를 백업 함).

복원은 논리적 작업이 아닌 물리적 작업입니다. 데이터 파일의 올바른 위치에 익스텐트를 기록합니다.

인덱스 (또는 이와 유사한 것)를 다시 작성하는 것은 논리적 작업이며 기록해야합니다. 백업 및 복원은 버퍼 풀을 거치지 않고 데이터 파일을 직접 조작하므로이를 수행 할 수 없습니다. 이를 수행 할 수없는 또 다른 이유는 백업 및 복원이 백업중인 데이터에 포함 된 내용을 이해하지 못하기 때문입니다.

그러나이 작업을 수행 할 수없는 주된 이유는 복원 작업 중에 페이지를 이동하면 b- 트리 포인터가 손상되기 때문입니다. 페이지 A가 페이지 B를 가리 키지 만 복원 프로세스에 의해 페이지 A가 이동되면 페이지 B는 어떻게 페이지 A를 가리 키도록 업데이트됩니까? 즉시 업데이트되면 나머지 복원 프로세스에서 덮어 쓸 수 있습니다. 지연 업데이트 된 경우 복원 프로세스에서 페이지 A 또는 페이지 B를 제거한 일부 트랜잭션 로그를 복원하면 어떻게됩니까? 단순히 할 수 없습니다.

결론-백업 및 복원은 데이터를 변경하지 않는 물리적 작업입니다.

도움이 되었기를 바랍니다!

PS이 질문을 직접 다루지는 않지만, 다양한 백업이 내부적으로 작동하는 방법을 설명하는 July TechNet Magazine ( SQL Server 백업 이해)에 대해 쓴 기사를 확인하십시오 . 9 월 잡지는 복원의 이해에 관한 시리즈의 다음을 가질 것입니다.

— 폴 랜달
소스

2

색인 생성이 논리적 작업이라고 설명했다는 사실이 마음에 듭니다.

— Jim B

아, 말이 되네요. 백업은 8k 데이터 페이지가 아니라 64k 물리적 범위를 완전히 차지합니다.

— BradC 2016 년

이것은 말도 안됩니다. 백업 작업은 백업하는 데이터를 자주 압축하며 이는 우리가 이야기하는 일종의 "변경"입니다. 결국 테이블에서 인덱스를 다시 작성할 수 있으며 중복 데이터입니다 (스키마가 백업 된 경우). , 물론이야). 실제 이유는 데이터베이스 개발자의 게으름 때문입니다.

— John

1

@ 존 말도 안되는 말은 무엇입니까? 압축은 여기 어디에서나 언급되지 않습니다. 인덱스를 다시 작성하면 압축과 동일하지 않습니다 (복원 중에는 데이터베이스에서 페이지 또는 위치를 변경하지 않지만 다시 작성하는 경우). 복원하는 동안 인덱스를 처음부터 다시 작성하면 백업에서 그대로 복원하는 것보다 훨씬 느립니다. 나는 당신이 여기서 뭔가를 오해하고 있다고 생각합니다.

— Paul Randal

인덱스 삭제 및 재 구축은 압축 유형이며 압축은 압축 유형에 따라 무엇이든 변경할 수 있습니다. 이미지 처리의 손실 압축을 여전히 압축이라고합니다. 더 작은 공간에서 주어진 정보를 나타내는 모든 메커니즘은 압축의 한 형태이며, 인덱스를 삭제하는 것이 간단한 예입니다. 그러나 재 구축 시간이 느리다는 것은 실제로 구현이 가치있는 노력이되는 것에 반대하는 진정한 논거가 될 수 있습니다.

— John

6

네이티브 SQL 백업은 "아니오"가 답 있도록 백업 파일의 단지 페이지 별 덤프입니다. Quest lightspeed 백업은 일종의 압축 압축 알고리즘을 사용하지만 데이터 파일이나 인덱스를 "재 구축"하지는 않지만 큰 데이터베이스에서 끔찍하게 많은 시간이 걸립니다.

— 아론 앨턴
소스

네,하지만 어쨌든 모든 페이지를 디스크에 써야합니다. 조각난 순서가 아닌 논리적 인 순서로 작성하지 않겠습니까? (이것은 아마도 복원 질문이 아닌 백업 질문 일 것입니다. 백업은 물리적 순서로 또는 논리적 순서로 페이지를 기록합니까?)

— BradC

색인 순서로 데이터를 기록한 제품이 있다고 가정하면 어떤 순서로 테이블을 저장 하시겠습니까? product_id, productname 및 price 열이 3 개인 테이블이 있다고 가정하겠습니다. 페이지를 색인 순서대로 저장하기 위해 정렬 할 올바른 열은 어느 것입니까? BTW는 전체 테이블 (클러스터형 인덱스) 또는 각 행 (복합 인덱스)에서 인덱싱을 멈추지 않습니다.

— Jim B

@ Jim B : 쉽습니다. 테이블은 클러스터 된 인덱스 순서로 저장됩니다. 비 클러스터형 인덱스는 키 순서로 저장됩니다. 힙은 원래 (정렬되지 않은) 순서로 유지됩니다. (Aaron과 Paul은 백업 / 복원이이 작업을 수행하지 않는 유효한 이유를 언급했습니다. "선호 순서"를 파악할 수없는 것도 이러한 이유 중 하나가 아니거나 전체 인덱스를 다시 작성하면 동일한 문제가 발생합니다. )

— BradC 2016 년

데이터는 데이터베이스 파일 내에 저장된 것과 동일한 실제 페이지 순서로 백업됩니다. 데이터가 복원되면 데이터는 백업 된 것과 동일한 페이지 순서로 복원됩니다. SQL은 여러 가지 이유로 데이터를 이동하지 않습니다. 로그를 복원하는 트랜잭션 및 페이지 체인 문제와 관련된 문제가있을 수 있으며, 멀티 TB 데이터베이스에서 데이터를 섞는 데 필요한 추가 시간은 말할 것도 없습니다.

— mrdenny

2

백업은 정기적으로 매우 자주 이루어집니다 (희망). 따라서 설계자들은 백업이 가능한 빨리 이루어 지도록했습니다. 가장 빠른 I / O는 무엇입니까? 잇달아 일어나는. 정확한 물리적 순서로 디스크에서 블록을 읽으면 최상의 성능을 얻을 수 있습니다.

왜 지구상에서 매일 밤마다 데이터베이스가 번거로운 임의 I / O 작업을 수행해야 합니까? 차이는 약 2 배 정도입니다. 이것에 대한 가능한 이득은 없습니다.

— 쿠반 치크
소스

전반적인 관점에 동의하지만 기본 스토리지 구성에 따라 임의 I / O가 순차적 I / O (예 : 수십 개의 스핀들에 분산 된 SAN 드라이브)보다 훨씬 나쁘지 않을 수 있습니다. 실제로 데이터 파일이 하드 드라이브에서 조각화되면 "순차적"I / O조차도 실제로 순차적 인 것은 아닙니다. 그러나 Paul의 요점은 어쨌든 이것을 무시합니다 (포인터 업데이트 문제와 조각 모음이 기록 된 작업이어야 함)

— BradC

0

흠. BradC, 메인 백업 / 복원 유틸리티 / API가 SSMS / EM의 "데이터베이스 복사 ..."와 더 유사한 Firebird / Interbase를 사용해 본 적이 있습니까? 그렇다면 MS SQL Server가 마음에 들지 않는다는 것을 알아야합니다.

SQLServer 백업은 "AS-IS"로 복원되는 데이터베이스 덤프입니다. "다른 위치에서 분리-복사-재 부착"작업을위한 편리한 온라인 바로 가기와 비슷합니다. 복원 된 데이터베이스는 원본 데이터베이스 파일과 거의 동일한 사본입니다 (복원 된 데이터베이스의 데이터베이스 파일 배치를 변경할 수 있기 때문에).

— Fabricio Araujo
소스