연중 무휴 다중 사용자 환경에서 SQL Server 2014 스키마 변경

연중 무휴 24 시간 이용 가능한 데이터베이스를 실행하기 위해 SQL Server 2014 Enterprise를 설치했습니다. 우리 데이터베이스는 충분히 크다 (200gb +). 또한 새로운 데이터를 읽거나 업데이트하거나 삽입하기 위해 매분마다 데이터베이스에 도달하는 많은 서비스가 있습니다. 우리는 고객에게 "핫"재배치 기능을 제공하고 매일 업데이트 (.net 및 스키마 업데이트)를 클라이언트에게 투명하게 만들려고합니다. 앱의 바이너리를 업데이트하는로드 밸런서가있는 클러스터 기반 솔루션을 찾았지만 데이터베이스 업데이트 배포 프로세스와이 문제를 해결하기위한 모범 사례에 대한 오해가 있습니다.

스키마 변경의 경우 하나의 서버를 중지하고 스키마 변경을 적용한 후 다시 가져온 다음 두 번째 인스턴스에 동일한 변경 사항을 적용하십시오. SQL Server 도구를 사용하여 수행 할 수 있습니까? 이것이 일반적인 접근 방법입니까? 서버 백업 후 데이터 동기화 방법 아니면 완전히 잘못된 방향으로 생각하고 더 나은 해결책이 있습니까?

일반적인 스키마 변경 : 열 추가 / 삭제, 저장 프로 시저 추가 / 삭제

아래에는 좀 더 계획과 테스트가 필요합니다.

청록색 개념 :

Blue-Green Concept의 핵심은 프로덕션을 2 개의 환경으로 나누는 것이며 항상 동일합니다 (데이터 동기화).

1. Blue (Current)는 현재 버전의 스키마 / 빌드 또는 제품을 보유하며 "LIVE"환경이됩니다.

2. 동시에 Green은 스키마 / 빌드 또는 제품을 NEXT 릴리스로 업그레이드하고 전체 회귀 테스트를 수행하고 비즈니스 사용자가 사인 오프하는 스테이징 / 테스트 환경입니다. 컷 오버 기간 동안 행복하면 Green을 "LIVE"환경으로 승격시키고 Blue를 강등하여 다음 릴리스에 대한 사전 준비 / 준비 또는 테스트가됩니다.

이렇게하면 가동 중지 시간이 매우 줄어들고 라이브 시스템 (업그레이드 중이므로 유지 관리 기간에 있음)에서 배포 실패의 위험이 크게 최소화됩니다. 또한 Blue-Green 접근 방식에 따라 다음 버전을 준비 할 LIVE 버전과 PREVIOUS 버전간에 진동이 발생합니다.

다시 말하지만, 더 많은 하드웨어 / 라이센스와 계획 및 테스트가 필요합니다.

DACPAC 및 PowerShell을 사용하여 대부분의 단계를 자동화 할 수 있습니다. 또한 하나의 서버에 여러 인스턴스를 설치하는 경우 파란색과 녹색간에 전환 할 때 메모리 설정의 균형을 다시 조정하십시오. LIVE 환경은 수동 환경보다 더 많은 메모리를 얻습니다.

현재 환경에서는 테스트 및 비즈니스 사인 오프를위한 충분한 시간으로 2 주마다 코드를 홍보 할 수있는 민첩한 코드 배포를위한 Blue / Green 모델을 구현했습니다. 또한 무언가 끔찍한 일이 생길 경우 롤백하는 바람도 있습니다. Dacpac 및 PowerShell을 사용하여 대부분의 배포 작업을 자동화했습니다.

(이미지 소스)

롤백 및 복구 문제 해결 에 대한 Grant Fritchey의 기사를 참조하십시오 . 도전과 전략

데이터베이스가 복제되지 않은 경우 열 추가 및 삭제가 실제로 빠르게 실행됩니다. 추가 열은 SQL이 작성하는 빈 위치이기 때문입니다. 드롭 열은 참조 만 지 웁니다.

그렇지 않으면 제약 조건이나 색인이있는 경우주의하십시오.

ADD/DELETE프로시 저는 실행 자체에 영향을 미칩니다. 권장 사항은 변경 전에 재 컴파일을 실행하는 것입니다.

sp_recompile 'myproc'