전체 백업에서 포함되는 트랜잭션 범위

 

  • Version : SQL Server 2005, 2008, 2008R2, 2012, 2014

 

SQL Server 전체 백업을 진행 할 때 마지막 포함된 트랜잭션 범위에 대해서 알아보자.

 

 

  1. 백업작업 시 체크포인트를 실행하여 버퍼풀에 있는 모든 더티 페이지를 강제로 디스크에 기록한다. 백업 작업은 데이터베이스에 할당된 페이지를 읽기 시작한다.
  2. 백업 작업이 페이지 X를 읽는다.
  3. 트랜잭션 A가 발생 한다.
  4. 트랜잭션 A가 페이지 X를 변경한다.
  5. 트랜잭션 B가 발생 한다.
  6. 트랜잭션 A가 끝나고 페이지 X에 대한 변경사항을 커밋한다.
  7. 백업 데이터 읽기 작업이 완료되고 트랜잭션 로그를 읽기 시작한다.

 

백업 데이터 읽기 작업이 완료된 시점에 트랜잭션 A에 대한 내용은 트랜잭션로그에 커밋이 완료 되었기 때문에 현재 트랜잭션로그와 일치한다. 가장 오래된 활성 트랜잭션의 LSN(포인트 5번)의 경우 트랜잭션 로그에는 포함되어 있지만 마지막 백업 데이터를 읽은 시점에서(포인트 7)에서의 트랜잭션과는 일치 하지 않는다.

 

트랜잭션 로그에 포함된 최소 LSN은 전체 백업에 포함된 트랜잭션 로그(마지막 체크포인트LSN, 활성 LSN)을 포함한다. 일치하지 않은 트랜잭션에 대한 REDO log 레코드는 최신의 페이지를 가지고 로그 레코드를 다시 실행한다.

 

[참고자료]

http://www.sqlskills.com/blogs/paul/more-on-how-much-transaction-log-a-full-backup-includes/

 

2014-06-12 / 강성욱 / http://sqlmvp.kr

 

 

SQLSERVER, mssql, SQL튜닝, SQL강좌, SQL백업, 트랜잭션 범위, 로그레코드, 트랜잭션 로그, 데이터베이스 백업, Database backup, transaction log

최소한의 다운타임으로 데이터베이스 이동하기

 

  • Version : SQL Server 2005, 2008, 2008R2, 2012

 

SQL Server를 운영하다보면 디스크의 공간 부족 또는 디스크의 성능 등으로 인하여 새로운 드라이브로 데이터베이스를 이동해야하는 상황이 발생 할 수 있다. 이때 대용량 데이터베이스를 최소한의 다운타임으로 이동하기 위한 여러가지 방법에 대해서 알아보자. 각 방법에는 장단점이 있다.

 

[데이터베이스 분리 후 이동하여 연결하기]

데이터베이스를 이동 할 때 많이 사용하는 방법이다. 데이터베이스를 분리하여 데이터 파일을 이동한 다음 데이터베이스를 연결 하는 방법이다.

exec sp_detach_db DBName

 

File Move

 

exec sp_attach_db DBName, Filepath

 

 

장점

  • 데이터베이스를 이동하는 가장 쉬운 방법이다.
  • 테이블과 인덱스에 대한 조각화를 생성하지 않는다.

단점

  • 파일이 이동하는 동안 데이터베이스를 사용할 수 없다.
  • 복제 된 데이터베이스가 분리 된 경우 배포를 할 수 없다.
  • 데이터베이스가 분리 되면 모든 메타데이터가 삭제 된다. 어떤 로그인의 계정의 기본 데이터베이스인 경우 mater 데이터베이스로 변경 된다. 또한 데이터베이스간 소유권이 끊어진다.
  • 데이터베이스를 분리 하기 전 스냅샷을 모두 삭제 해야 한다.
  • 데이터베이스가 미러링 되어 있는 경우 미러링 세션이 종료 될 때 까지 분리 할 수 없다.

 

 

[데이터베이스 백업 후 백업 파일을 이용하여 복원]

데이터베이스를 백업하고 WITH MOVE switch를 사용하여 새 파일의 위치를 지정하는 방법이다.

 

장점

  • 백업과 복원 방법만 알면 누구나 할 수 있다.
  • 테이블과 인덱스에 대한 조각화를 생성하지 않는다.

단점

  • 데이터베이스 복원이 완료 될 때까지 데이터베이스나 파일 그룹에 액세스 할 수 없다.
  • 백업 후 데이터가 변경된 경우 최근 백업을 다시 복원해야 한다.

 

 

[데이터베이스 OFFLINE 후 데이터베이스 이동]

데이터베이스를 오프라인으로 설정하고 수동으로 파일을 이동. 데이터베이스의 메타 데이터를 업데이트하는 명령을 실행하고 다시 온라인 시키는 방법이다.

 

장점

  • 데이터베이스 분리처럼 Detach – Attach 방법을 사용한다.
  • 테이블과 인덱스에 조각화를 생성하지 않는다.
  • 데이터베이스 분리와 달리 메타 데이터를 보존 한다.
  • 배포 및 미러된 데이터베이스도 작업 할 수 있다.

단점

  • 파일이 이동하는 동안 데이터베이스에 액세스 할 수 없다.

 

 

[새로운 파일 그룹을 추가하여 이동]

새로운 파일 그룹을 생성하고 테이블과 인덱스를 새로운 파일그룹에 다시 작성한다. 작업이 완료되면 기존 파일 그룹 삭제가 가능하다.

 

장점

  • 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
  • 데이터베이스 메타 데이터가 보존 된다.

단점

주 파일 그룹에 대해서는 작동 하지 않는다.

  • 데이터베이스 설계가 변경되기 때문에 신중한 테스트가 필요하다.
  • 이전의 방법보다 많은 작업이 필요하다.

 

 

[로그 전달을 사용한 데이터베이스 이동]

로그 전달을 구성하여 데이터베이스를 이동한다. 복구모드가 심플일 경우 전체 복구 모두로 전환하여 구성 할 수 있다.

 

장점

  • 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
  • 데이터베이스 메타 데이터가 보존된다.
  • 로그 전달 중에도 사용자는 기존 데이터베이스에 계속 액세스 할 수 있다.

단점

  • SQL Server Agent 실행이 필요하다.
  • 공유 폴더를 사용하기 때문에 폴더 사용 권한 검토가 필요하다.
  • 로그 전달에 대한 전문적인 지식이 필요하다.

 

 

[수동으로 로그 전달 및 복원]

필자가 주로 사용하는 방법으로 대용량 데이터베이스의 경우 전체 백업을 수행하여 먼저 복원해 놓고 주기적으로 트랜잭션 로그 백업을 복사하여 복원하는 방법이다. 마지막에 사용자 접근을 차단하고 마지막 로그 백업을 실행하여 새로운 데이터베이스에 복원한다.

 

장점

  • 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
  • 데이터베이스 복원 시 이름 변경 및 파일 경로 변경 가능하다.
  • 데이터베이스 메타 데이터가 보존된다.
  • 기존 데이터베이스에는 사용자가 계속 액세스 할 수 있다.
  • 로그 전달보다 적은 구성이 사용된다.(백업, 복원만 하면 됨)

단점

  • 백업을 복원할 때 WITH MOVE 옵션을 사용해야 한다.

 

 

[DBCC SHRINK FILE 후 데이터베이스 이동]

DBCC SHRINKFILE 명령을 사용하여 빈 공간을 축소. 데이터베이스를 이동하는 방법이다. (굳이 추천하고 싶은 방법은 아니다.) 이 방법은 위의 모든 방법보다 가장 느린 방법이다. 이 방법은 성능에 영향을 미칠 수 있으므로 주의해야 한다.

 

장점

  • SHRINK FILE 작업 시 사용자가 데이터베이스에 계속 액세스 할 수 있다.

단점

  • 다른 방법보다 더 오래 걸릴 수 있다.
  • 테이블과 인덱스에 조각화를 많이 생산한다.
  • 로그가 기록되므로 전체 복구 모드의 경우 적합하지 않다.
  • SQL 로그 전달이 구성되어 있는 경우 권장되지 않는다.
  • 많은 시스템 리소스(특히 디스크IO)를 소비하므로 시스템 성능에 문제가 발생 할 수 있다.

 

 

대용량의 데이터베이스를 이동해야 하는 경우 각 운영 환경에 맞는 방법을 선택하여 최적의 시나리오를 구성하여 연습을 해야 한다. 특히 백업과 파일이동, 복원의 경우 해당 파일의 용량, 복사에 따른 네트워크 속도, 디스크의 성능 등을 고려하여 시간을 산정하면 최소한의 다운타임으로 이동이 가능하리라 생각한다.

 

 

[참고자료]

http://www.mssqltips.com/sqlservertip/3212/options-to-move-a-big-sql-server-database-to-a-new-drive-with-minimal-downtime/

 

 

2014-04-24 / 강성욱 / http://sqlmvp.kr

 

 

SQLSERVER, mssql, SQL튜닝, SQL강좌, DB튜닝, 쿼리튜닝, 데이터베이스튜닝, 데이터베이스 백업, 트랜잭션 백업, 전체 백업, 데이터베이스 이동, 파일그룹, 데이터베이스 복원

백업 LSN 이해하기

 

  • Version : SQL Server 2005, 2008, 2008R2, 2012

 

 

SQL Server에서는 전체 백업, 로그 백업, 차등 백업 등 다양한 백업을 지원한다. 백업을 진행 하면 각 백업에 대해 고유한 LSN(Log Sequence Number)이 생성된다. 백업 파일을 복원 할 때 LSN을 이용하여 복원하기 때문에 LSN에 대한 이해는 중요하다고 할 수 있다.

 

데이터베이스를 복원 할 때 데이터베이스 복원 시퀀스는 데이터베이스의 전체 백업에서 시작해야 한다. 차등 및 트랜잭션 로그 백업 파일에서 복원을 진행 할 수 없다.

데이터베이스를 복원할 때 4가지(FirstLSN, LastLSN, CheckpointLSN, DatabaseBackupLSN)의 중요한 LSN이 있다. 이 값은 SQL Server 백업 파일에서 HEADERONLY 명령어로 확인 할 수 있으며 아래 스크립트를 사용하여 백업 파일에 대한 헤더 정보를 검색 할 수 있다.

USE [master]

RESTORE HEADERONLY FROM DISK = N'C:\Temp\F1.BAK'

RESTORE HEADERONLY FROM DISK = N'C:\Temp\T1.TRN'

RESTORE HEADERONLY FROM DISK = N'C:\Temp\T2.TRN'

RESTORE HEADERONLY FROM DISK = N'C:\Temp\D1.BAK'

 

헤더 정보를 엑셀로 정리해서 보면 다음과 같이 정리 할 수 있다. A컬럼의 정보 백업 유형과 순서를 나타낸다

  • F1 : 전체 백업
  • T1 : 첫 번째 로그 백업
  • D1 : 첫 번째 차등 백업

 

 

전체 백업의 LSN에 대한 특징은 다음과 같다.

  • 첫 번째 전체 백업의 경우 DatabaseBackupLSN 값은 0 이다.
  • FirstLSN값과 CheckpointLSN 값이 동일하다.

 

차등 백업의 LSN속성은 다음과 같다.

  • 차등 백업에 대한 DatabaseBackupLSN 값은 차등 데이터베이스 백업을 적용하기위해 전체 데이터베이스 백업을 식별한다.
  • 채등 백업에 대한 DatbaseBackupLSN 값은 전체 백업의 CheckpointLSN값과 동일한다.
  • CheckpointLSN 값은 차등 백업 이후 첫 번째 트랜잭션 로그 백업의 CheckpointLSN에 매핑 된다.

 

트랜잭션 로그 백업의 LSN 속성은 다음과 같다.

  • 모든 트랜잭션 로그 백업에 대해 고유한 LSN을 식별 한다.
  • 트랜잭션 로그의 LSN 체인은 전체 또는 차등 데이터베이스 백업에 영향을 받지 않는다.
  • LSN은 연속된 값으로 높은 LSN 값은 지정된 시간 이후를 나타낸다.

 

 

SQL Server의 전체 백업과 트랜잭션 로그 백업의 LSN 매핑에 대한 이해를 다음 그림을 통해 살펴보자. 첫 번째 트랜잭션로그 백업의 FirstLSN은 첫 번째 전체 백업을 식별한다. 두 번째 트랜잭션 로그 백업은 첫 번째 트랜잭션 로그 백업의 LastLSN을 참고하여 FirstLSN으로 기록한다.

 

 

SQL Server의 전체 백업과 차등 백업의 LSN 매핑에 대한 이해를 다음 그림을 통해 살펴보자. 차등 데이터베이스 백업은 전체 백업 DatabaseBackupLSN과 같다.

 

SQL Server의 트랜잭션 로그 백업과 차등 백업의 LSN 매핑에 대한 이해를 다음 그림을 통해 살펴보자. 차등백업의 LSN + 1은 트랜잭션 로그 백업의 FirstLSN과 LastLSN 사이에 있을 것이다.

 

 

[참고자료]

http://www.mssqltips.com/sqlservertip/3209/understanding-sql-server-log-sequence-numbers-for-backups/

 

 

2014-04-23 / 강성욱 / http://sqlmvp.kr

 

SQLSERVER, mssql, SQL튜닝, SQL강좌, DB튜닝, 쿼리튜닝, 데이터베이스튜닝, 데이터베이스 백업, 트랜잭션 백업, 전체 백업, LSN, 로그시퀀스,

MySQL/MariaDB 백업 & 복원 - mysqldump

 

  • Version : Mariadb 5.5.4.2-WinX64

 

MySQL/MariaDB 백업 및 복원에 대해서 알아본다. 이번 백업은 MySQL 시절부터 널리 알려진 mysqldump를 사용한다.

 

mysqldump는 논리적 백업을 수행한다. 데이터 크기가 비교적 작은 경우 유연하게 사용할 수 있다. 백업파일은 SQL 형식으로 백업 파일을 생성한다. 이렇게 생성된 백업 형식은 MariaDB, MySQL 또는 완전히 다른 DBMS에서 쉽게 가져올 수 있다.

 

mysqldump는 테이블 및 트리거를 덤프한다. 저장 프로시저나 뷰 등은 명시적으로 추가 매개변수를 사용하여 명시적으로 작성해야 한다.

 

[기본 사용 문법]

-p 옵션 후 명시적으로 패스워드를 적지 않으면 mysqldump 수행시 패스워드를 물어 본다.

mysqldump -u[아이디] -p[패스워드] > [저장파일명].sql

 

 

[전체 데이터베이스 백업& 복원]

MySQL/MariaDB 전체 데이터베이스를 백업받는다.

mysqldump -uroot -p -A > backup_full.sql

 

생성된 덤프를 이용한 복원

mysql -uroot -p < backup_full.sql

 

 

[특정 데이터베이스 백업]

sw_test 라는 데이터베이스만 백업

mysqldump -uroot -p sw_test > backup_sw_test.sql

 

 

[특정 데이터베이스의 특정 테이블 백업]

sw_test 데이터베이스의 tbl_a라는 테이블만 백업

mysqldump -uroot -p sw_test tbl_a > backup_sw_test_tbl_a.sql

 

 

[특정 데이터베이스의 테이블의 특정 값만 백업]

sw_test 데이터베이스의 tbl_a테이블의 emp_no가 100 이상 200이하의 데이터만 백업

mysqldump -uroot -p sw_test tbl_a -w'emp_no >= 100 and emp_no <= 200' > backup_sw_test_tbl_a.sql

 

 

[특정 데이터베이스의 테이블 definition 백업]

실제 데이터백업은 받지 않고 테이블 definition만 백업 받는다.

mysqldump -uroot -p sw_test --no-data > backup_sw_test_definition.sql

 

 

Sw_test 데이터베이스를 백업하여 test로 복원한다. 프로시저는 백업 및 복원에 포함되지 않은것을 확인할 수 있다.

 

백업

 

복원

 

프로시저는 백업 및 복원에 포함되지 않음

 

 

[참고자료]

Backup and Restore Overview : https://mariadb.com/kb/en/mariadb/backup-and-restore-overview/

 

 

 

2015-07-02 / 강성욱 / http://sqlmvp.kr

 

 

mysql백업, MariaDB 백업, MySQL Backup, mysqldump, mysql 복원, MariaDB 복원, 데이터베이스 백업, 데이터베이스 복원

+ Recent posts