변경, 구성 및 배포 관리

개요

이 장은 데이터베이스 관리자들이 마이크로소프트 SQL 서버 2000에서 특정 기능을 변경했을 때, 수행하게 되는 데이터베이스 코드, 개체, 시스템 프로세스, 서버 및 하드웨어 구성과 같은 것의 변경 관리 과정과 절차에 대하여 다룰 예정이다. 또한 변경 관리에 있어 대단히 중요한 요소인 실행 일지 템플릿을 제공하는 등 구성관리의 부분도 포함되어 있다.

소개

변경, 구성, 배포관리 등을 지원할 수 있는 시스템을 설계하려면 해당 역할을 수행할 담당자를 지정한다.

변경 프로세스에 관련된 문서는 데이터베이스 응용 프로그램부터 오프사이트 백업에 이르기까지 데이터베이스 서버에 관련된 모든 정보가 포함된다.

변경 관리 작업을 진행하기 전에 반드시 테스트 환경과 개발 시스템의 테스트 과정과 절차를 만들어야 한다.

친숙해져야 할 기술

마이크로소프트 비쥬얼 소스세이프(Visual SourceSafe) 와 같은 버전 관리 소프트웨어 및 이와 유사한 소스 코드 관리 툴에 익숙해야 한다.

친숙해져야 할 과정과 절차

문서 작성 방법과 서버 구성을 확인하는 방법 및 T-SQL(Transact SQL) 코드를 작성하는 방법에 익숙해야 한다.

과정 흐름도

변경관리

변경관리는 관리상 발생하는 시스템 변경 내용을 관리하는 것으로 이미 확인된 방법과 기술을 이용함으로써 시스템 서비스 레벨에서 발생할 수 있는 새로운 형태의 오류를 회피하고 영향을 최소화하는 것이다. 변경 내용은 변경으로 인해 야기되는 영향과 유형에 의해 달라진다.

변경작업을 수행해야 하는 범위로는 개발 환경 및 개발 환경과 별도로 운영되는 스테이징(Staging) 시스템까지 포함되며, 스테이징 시스템은 가동 환경과 동일하게 또는 아주 비슷하게 구성한다. 변경 계획 및 방법을 수립한 다음 스테이징 환경에서 해당 작업의 영향을 확인하고, 그 다음에 가동 시스템에 적용하는 순서를 따른다. 정책 및 적용 순서의 각 단계마다 변경 내용이 잘 동작하는지 확인한다.

변경 처리 및 관리 과정은 변경 유형과 영향에 깊이 관련되어 있으나 개발 및 스테이징 환경을 통해 충분한 테스트할 수 있다. DBA는 데이터 액세스 코드, 데이터베이스 개체, 서버 아키텍처 및 구성정보와 같은 시스템 구성요소의 설계 및 계획 수립 시 정보를 제공해 주어야 한다.

또한 DBA는 제시된 변경 작업을 수행할 때 해당 작업이 정상적으로 수행되는지 확인하는 단계에 반드시 참가한다. 변경 작업의 최종 단계는 테스트를 통해 확인된 작업 사항을 가동 시스템에 도입하는 과정 이다. 환경을 구현한 다음 검토작업을 수행할 때, DBA 그룹을 참여시켜야 하며, 이 것을 통해 변경 작업에 참여한 DBA 들이 변경 과정 및 절차를 배워, 후에 동일한 작업 또는 상황에 처했을 조치할 수 있게 한다

이 분분은 MSF(Microsoft Solutions Framework)와 MOF간에 공통적으로 관련된 부분으로 DBA가 가져야 하는 능력 중 하나이다. 응용 프로그램 변경으로 일어나거나 혹은 운영 작업의 변경에 의해 일어날 수 있다. 그래서 DBA는 초기 MSF 설계 단계부터 종료 단계까지 참여하여 정상적으로 적용되는 과정을 확인하고 MOF의 변경 적용 단계까지 참여한다. 이와 동일한 순환적 접근 방법은 DBA가 데이터베이스를 유지 관리하는 방안으로 활용될 수 있다. 변경으로 인해 발생할 수 있는 데이터베이스 서버와 제시된 작업 절차상의 잠재적 문제를 지속적으로 평가하려면 DBA는 반드시 MOF 순환과정을 충실히 따라야 한다.

소홀한 시스템 변경 관리는 주로 데이터 센터 시스템 장애로 나타난다. 그러므로 반드시 우선순위, 테스트 및 데이터베이스 환경 변경과 같은 모든 변경관리 과정의 문서화가 필요하다. 변경관리에 포함되어야 하는 것에는 저장 프로시저, 함수 코드, 물리적 데이터 구조, 데이터, 데이터베이스의 스토리지 구성요소, 서버 자체의 정보까지도 포함된다.

환경관리

데이터베이스 서버를 관리하기 위한 두 가지 접근 방법.

두 가지 접근 방법상의 중요한 차이는 각각의 방법에 사용되는 테스트 유형과 구현 방법에 따라 달라진다.

패키징 제품의 데이터베이스 변경 관리

패키징 제품의 데이터베이스 변경 관리는 사용자에게 배포된 제품 변경이 필수적 이다.

개발 및 단위

DBA가 데이터베이스를 새로 만들거나 기존 데이터베이스를 변경하였으면, 다음과 같은 두 가지 방법 중 하나로 변경 관리 작업을 수행한다.

두 번째 방법의 경우는 마이크로소프트 SQL 서버 2000 디벨로퍼 에디션을 사용하는 개발자가 제공한 스크립트만을 이용하여 변경작업이 이루어질 수도 있다. 데이터베이스의 크기가 적어서 적절한 테스트를 수행하지 못했다면 단위 테스트를 위해 만들어진 데이터베이스에 크기가 큰 테이블을 생성하여 테스트 작업을 수행할 수 있다. 개발자들은 이러한 데이터베이스에 접속하기 위하여 연결된 서버(linked server)를 이용, 마치 로컬 컴퓨터에 있는 테이블과 같이 사용할 수 있다.

두 번째 방법의 경우는 마이크로소프트 SQL 서버 2000 디벨로퍼 에디션을 사용하는 개발자가 제공한 스크립트만을 이용하여 변경작업이 이루어질 수도 있다. 데이터베이스의 크기가 적어서 적절한 테스트를 수행하지 못했다면 단위 테스트를 위해 만들어진 데이터베이스에 크기가 큰 테이블을 생성하여 테스트 작업을 수행할 수 있다. 개발자들은 이러한 데이터베이스에 접속하기 위하여 연결된 서버(linked server)를 이용, 마치 로컬 컴퓨터에 있는 테이블과 같이 사용할 수 있다.

프로젝트 개발 단계에서 통합서버를 이용한 단위 테스트 작업은 프로젝트 관리를 위한 이정표이다. 단위 테스트 작업은 완전 자동으로 수행되는 스크립트와 설치 및 제거 프로그램을 이용하며, 스테이징 환경에확인한다. 스크립전 관리 소스 코드에서 확인할 수 있어야 한다.

품질 보증을 위한 통합 테스트 및 스테이징

패키지 제품을 분배하기 전에는 반드시 스테이징 환경에서 해당 제품의 설치 및 구성 테스트 작업을 수행하는 것이 바람직하다. 이 경우 별개의 통합 테스트 환경이 필요할 수도 있다. 통합 테스트 환경을 통해서 새로 만든 응용 프로그램이 다른 시스템과 얼마만큼 잘 동작하는지 확인할 수 있다. 이것을 통해 각 테스트 서버 또는 테스트 환경 정보를 유지 관리할 수 있으며, 그 결과 모든 테스트 과정을 통해 구성한 시스템 정보를 완전하게 문서화 할 수 있다.

개발 및 단위 테스트

DBA는 개발 완료된 데이터베이스를 그대로 구현하고 롤백할 수 있는 스크립트를 만들고 유지관리하며, 또한 소스 관리 도구인 DDL(Data Definition Language) /DML(Data Manipulation Language)로 표시된 모든 정보를 유지 관리 한다. DBA는 가동을 목표로 개발되는 데이터베이스 환경에 존재하는 모든 물리적 개체를 생성할 수 있어야 하고, 사용하게 될 DML 내용을 검토한다. 단위 테스트 작업을 시작할 때, DBA는 데이터베이스 개체를 생성하는 스크립트를 관리하고 변경하게 된다.

개발 및 단위 테스트

DBA는 개발 완료된 데이터베이스를 그대로 구현하고 롤백할 수 있는 스크립트를 만들고 유지관리하며, 또한 소스 관리 도구인 DDL(Data Definition Language) /DML(Data Manipulation Language)로 표시된 모든 정보를 유지 관리 한다. DBA는 가동을 목표로 개발되는 데이터베이스 환경에 존재하는 모든 물리적 개체를 생성할 수 있어야 하고, 사용하게 될 DML 내용을 검토한다. 단위 테스트 작업을 시작할 때, DBA는 데이터베이스 개체를 생성하는 스크립트를 관리하고 변경하게 된다.

품질 보증을 위한 통합 테스트 및 스테이징

이러한 스크립트가 완벽하게 테스트되어 원하는 동작을 수행하는지 확인하려면, 스크립트 변경은 반드시 개발/테스트 단계에서 시작하여 스테이징 및 적용단계까지 지속되어야 한다.

품질 보증을 위한 통합 테스트 및 스테이징

이러한 스크립트가 완벽하게 테스트되어 원하는 동작을 수행하는지 확인하려면, 스크립트 변경은 반드시 개발/테스트 단계에서 시작하여 스테이징 및 적용단계까지 지속되어야 한다.

적절한 테스트를 수행하지 않고 직접 가동 환경을 변경하면 문제가 발생할 수도 있다. 적절한 테스트는 반드시 필요한 작업이다. 가장 이상적인 방법은 모든 시스템에 대하여 중복 테스트 환경을 구축하고 테스트하는 방법이다. 최소한 서버의 구성 환경을 비교해볼 가동 환경은 있어야 한다. 적어도 데이터 센터를 완전하게 재연할 수 있는 소규모 테스트 환경은 구비한다.

변경 수준과 유형

MOF는 변경 수준과 변경 유형을 정의하고 있다.

변경 수준

변경 수준은 매우 중요(major), 중요(significant), 중요하지 않은(minor), 표준(standard)과 같이 4가지 범주로 나눌 수 있다. 변경 범주는 조직에 미치는 파장에 의하여 결정되며, 변경 계획, 방법 개발 및 변경 적용과 같은 작업이 필요하게 된다. 표 2.1은 MOF에 명시된 변경 수준의 설명이다.

표 2.1 MOF 변경 수준

수준	설명
매우중요 (Major)	IT 환경에 넓고 깊게 영향을 미치는 경우라면 계획과 구축에 대단한 주의 필요 시스템 기능상 매우 중요한 변경 작업 관리 및 변경의 승인 필요
중요 (Significant)	계획, 구축, 구현에 많은 자원 필요 변경 통제 업무의 승인 필요
중요하지 않은 (Minor)	영향이 낮으며 소요되는 자원이 적은 경우 변경 통제에 선택적으로 연루된 경우
표준 (Standard)	이미 확정되거나 문서화된 접근 방법 다소 혹은 전혀 위험하지 않은 운영 방법으로 문서화된 복원 계획 변경관리를 위한 문서들

변경 유형

변경의 또 다른 영향에는 다음과 같은 4가지 변경 유형이 있다. 표 2.2는 변경 유형의 범주이다.

표 2.2 MOF 변경 유형

유형	설명
재구성 (Reconfigurations)	모든 하드웨어 및 펌웨어의 대치 작업 또는 소프트웨어 버전 및 환경 구성 변경
강화 (Enhancements)	응용 프로그램의 기능 강화 또는 데이터베이스 최적화를 위한 서버, 스키마, 코드 변경
유지관리 혹은 긴급사태해결 (Maintenance or emergency fixes)	정상적이지 않은 그 무엇인가가 일어났을 때 변경 작업 수행
Unmanaged changes	변경 절차 상의 장애 또는 운영 작업 실수로 인한 변경 또는 DBA가 없거나 DBA가 갖추어야 할 지식을 갖지 못한 경우

변경 과정

변경 절차 관리에 관한 내용으로 개발 환경부터 가동 환경에 이르기까지 변경되는 모든 내용을 잘 관리한다.

기업 데이터베이스를 무리 없이 변경하고 유지하려면, 개발 과정의 주의 깊은 관리가 필요하며, 이 것을 통해서 데이터베이스의 성공적인 변경 또는 데이터베이스 구성 정보의 성공적인 변경을 보증할 수 있다. 변경 관리 작업 중 우선순위가 가장 높은 것은 스테이징 환경을 이용하여 적절한 테스트를 수행한다. 계획, 준비, 개발 단계에서 조차도 정상적인 스테이징 환경 또는 품질 보증 실험실을 통한 작업과 절차가 필요하다.

유능한 DBA는 제안 단계부터 개발단계, 즉 테스트, 스테이징, 개발?으로 참여할 것이다. 또한 이러한 유형의 사람은 시스템 지원과 운영 작업에도 참여하므로 해당 프로젝트가 가동 시스템으로 이행되는 모든 과정에 필요한 작업 내용xt">DBA는 개발자들이 만든 코드를 신중하게 검토함으로써 데이터베이스 개체에 적용된 변경 내용을 감지할 수 있고, 변경 내용이 가동 환경에서 잘 동작할 수 있는지 확인하는 작업에 직접 참여하게 된다. DBA는 구현 스크립트, 롤백 스크립트, 테스트 스크립트의 개발 또는 개발 작업에 도움을 줄 수도 있고, 데이터베이스 생성 및 유지 관리에 관련된 문서를 제공할 수도 있다.

DBA는 업무적 또는 기술적 이유로 인해 변경 작업 일정을 연기하거나 거절할 수 있다. 경우에 따라 업무에 미치는 파장의 평가 및 문서화가 필요할 수도 있다.

구현 스크립트

변경작업 절차가 규격화되어 있는지 확인 하시오. 모든 과정을 처음부터 다시 시작할 수도 있고, 또는 특정 시점에서 중지했다가 계속 진행하는 경우도 있을 수 있으며, 정확히 무엇을 변경하였고, 무엇이 변경되지 않았는지 확인할 수도 있다. 이러한 이유로 각 단계별 논리적 변경을 위한 개별 스크립트 생성 여부를 결정한다.

무엇을 변경했는지 추적하려면 구현된 모든 스크립트에 존재하는 코드, 테이블 작업의 성공과 실패 기록을 감사한다. 이러한 과정을 빨리 처리하려면 순차적으로 해당 스크립트를 수행할 수 있는 도구를 개발하는 것도 하나의 방법이다 (예를 들면 테이블 생성 스크립트를 실행하고, 스크립트 중간에 osql 유틸리티를 통해서 xp_cmdshell 명령을 직접 사용하는 것이다. xp_cmdshell의 정확한 사용법은 SQL의 온라인 설명서를 참조하기 바란다.) 또는 대단위 작업을 수행하는 하나의 스크립트를 만들고 오류가 발생하면 오류를 처리하는 코드를 포함시키는 것이다. 그렇지만 이러한 스크립트에 재시작 코드를 포함시키지 않았는데, 문제가 발생한다면 해당 스크립트를 다시 시작하는 것은 어렵다. 이러한 방법을 선택하려면 포함시킬 코드, 코드의 계획과 오류가 감지되었을 때 무엇을 할 것인지 등과 같이 상당히 많은 것에 대하여 고려한다.

재해 복구작업

테스트를 위한 변경 작업을 수행하는 경우라도 항상 비상 계획은 필요하다. 스크립트의 중간에 잘못된 코드가 삽입되어 있거나 또는 데이터베이스 스크립트 작업을 수행한 이후 응용 프로그램에서 오류가 감지된 상태에서 이전 시스템으로 복원할 수 없는 경우의 대책을 고려해 보아야 한다. 다음과 같이 문제를 최소화하기 위한 두 가지 계획을 항상 준비한다: 모든 변 경 작업을 완전하게 복원할 수 있는 방법준비(동일한 데이터베이스를 사용하는 응용 프로그램이 해당 응용 프로그램의 다양한 버전을 실행할 수 없다면 롤백 또는 데이터베이스를 완전하게 복원할 수 있는 스크립트 필요)하고, 예상할 수 있는 문제에 대한 대처 방법과 예상치 못한 문제가 일어나는 경우 대처할 수 있는 대안을 준비한다. 가능한 많은 시나리오를 준비함으로써 문제 발생시 쉽게 대응할 수 있다. 스크립트 내에 주석을 달아 다른 사람도 쉽게 실제 구현 작업을 할 수 있도록 한다.

대용량 데이터베이스 복원 작업의 경우는 특정 위치까지 변경작업이 수행되었음을 표시하는 트랜잭션 로그 마크 사용을 고려한다. 이 것은 msdb에 특정 일 시, 레이블 등을 저장하여 구현하는 방법이다.

명명된 트랜잭션 복구

마이크로소프트 SQL 서버 2000은 트랜잭션 로그에서 명명된 마크 삽입을 지원하므로 특정 마크로 복구할 수 있다. 로그 마크는 트랜잭션이므로 관련된 트랜잭션이 커밋될 경우에만 삽입된다. 그 결과, 마크는 특정한 작업에 연결될 수 있고 이 작업을 포함 또는 제외하는 지점으로 복구할 수 있다.

트랜잭션 로그에 명명된 마크를 삽입하기 전에 다음 사항을 주의하시오.

트랜잭션 로그에 명명된 마크 삽입

BEGIN TRANSACTION 문과 WITH MARK [description] 절을 사용하여 트랜잭션 로그에 마크한다. 마크 이름은 해당 트랜잭션과 같으므로 트랜잭션 이름이 필요하다. 선택 요소인 description은 표시 텍스트의 설명이다.

트랜잭션 로그는 표시 이름, 설명, 데이터베이스, 사용자, datetime 정보, 로그 시퀀스 번호(LSN) 등을 기록한다. 이들을 재사용하기 위해서 트랜잭션 이름이 반드시 고유한 이름일 필요는 없다. datetime 정보는 표시를 고유하게 식별하는 이름으로 사용된다.

로그 마크로 복구

로그 마크로 복구하는 방법은 다음과 같은 두 가지 방법이 있다.

WITH STOPATMARK와 WITH STOPBEFOREMARK 절은 선택적인 AFTER datetime 절을 지원한다. AFTER datetime이 생략되면 지정한 이름이 있는 첫 번째 표시 지점에서 복구가 중지된다. AFTER datetime이 지정되면 datetime이나 datetime 후에 지정한 이름이 있는 첫 번째 표시 지점에서 복구가 중지된다.

참고

표시로 복구하면 지정 시간 복구와 같은 제한에 종속된다. 특히 데이터베이스가 대량 로그 작업을 거치는 사이에 표시로 복구될 수 없다.

재구성 및 업그레이드

데이터베이스를 재 구성하거나 업그레이드 할 때는 계획, 사용자 의견 수렴과 작업 일정 조정, 재난 복구, 테스트, 응용 프로그램 및 공급업체 문제 등과 같이 고려할 많은 작업이 있다. 다음은 그러한 작업 예이다.

기타 시스템 변경 시 고려할 사항은 다음과 같다.

개발 환경 관리

DBA는 가동 시스템과 개발 시스템의 환경을 분할 유지함으로써 가동 환경의 작업을 단순화시킬 책임이 있으며, 또한 개발자가 개발 데이터베이스의 무제한적 권한을 갖지 못하도록 통제해야 하는 책임이 있다. 이렇게 하는 방법 중 가장 간단한 것은 데이터베이스에 db_owner 역할을 추가하는 방법보다는 개발자 전용 데이터베이스를 생성하여 각 개발자들이 저장 프로시저 및 각종 부가 기능을 생성하도록 명시적으로 권한을 부여하는 것이다. 이 것으로 각 개발자는 자신의 스키마를 소유하고, dbo 개체를 온전하게 유지하며, 하나의 단위 테스트 환경을 구성할 수 있게 되는 것이다.

개발자 자신 소유의 데이터베이스 개체의 변경 작업은 개발환경 외의 다른 시스템에는 아무런 영향도 미치지 않을 것이다. 개발자들은 작업을 종료하는 시점까지 해당 개체에 대하여 부여 받은 권한을 가지고 작업을 수행할 것이다.

이것은 일종의 보안 격리 계층이며, 개발자 환경을 보호하기 위한 방법이다. 이 것은 또한 초기단계에서 코드를 검토하고 최적화할 수 있는 기회를 제공하게 된다.

코드 검토를 수행하는 동안 데이터베이스 명령 코드에 적절한 주석이 포함되어 있는지를 확인할 수 있는 기회를 얻을 수 있다. 최소한 각 실행 코드의 목적과 무슨 시스템에서 사용하며 누가 변경하였는지, 그리고 변경 항목과 서비스 요청서 번호와 샘플 구문을 원할 것이다. 쿼리 분석기에서 테스트할 수 있는 샘플 구문은 가장 유용한 주석이다. 또한 선택적으로 해당 라인이나 코드를 실행시켜 실행 계획과 자원 사용량 등을 확인할 수 있다.

별도의 개발 환경을 유지함으로써 얻을 수 있는 또 다른 이점은 자연스럽게 개발 데이터베이스의 dbo 개체 단위로 테스트 환경을 만들 수 있다는 점이다. 또한 이것은 dbo 권한을 가지고 만든 실행 스크립트를 생성하고 확인할 수 있게 한다. 이 때 주의사항을 확인하고 요약해야 한다. 예를 들면, 어느 서버/데이터 베이스를 대상으로 변경 작업을 수행할 것인가? 연결된 서버 설정과 같이 이행 작업 시 필요한 변경 작업이 있는가? 작업 완료 후, 개발자가 해당 시스템에서 코드를 실행시켜 본다. 비록 데이터를 보호할 수는 있지만 모든 dbo 개체는 단위 테스트 환경의 일부이다.

테스트 준비가 완료 되었으면 테스트 서버에서 스크립트만을 이용하여 모든 데이터베이스 변경과 구성작업을 수행한다. 가장 좋은 방법은 모든 변경 작업을 제거할 수 있는 롤백 스크립트를 만들어서 스크립트 테스트를 수행한 다음, 변경한 데이터베이스 환경을 다시 변경하는 것이다. 그렇게 함으로써 스크립트 테스트와 롤백 수행 테스트를 모두 수행할 수 있다. 가동 시스템에 새로운 작업을 수행하려면 이미 테스트한 동일 스크립트를 재사용하고, 작업 완료 후 문서에 변경할 내용이 있으면 문서 변경작업을 수행한다.

긴급 상황 해결

너무 긴박하여 테스트 작업을 수행할 수 없는 경우를 제외하고는 긴급 상황을 조치하는 방법도 다른 변경 작업과 동일한 기본적 조치 방법을 사용한다. 긴급상황에 직면한 경우라도 작업을 수행하기 전에 반드시 최소한의 약식 위험 분석과정을 수행한다. 안정성이 낮기 때문에 변경 작업으로 인해 시스템 손상 가능성이 높은 시스템에 대하여 치밀한 테스트작업도 하지 않고 변경 작업을 수행하는 일은 절대로 없어야 한다.

실행 시스템 장애와 같이 최악의 상황이 일어났을 때, 사람들은 시스템에 어떤 내용이 변경되었는지도 추적하지 못하며, 가장 최근에 변경한 시점도 알지 못한다. 이러한 상황에서는 이 문제를 해결할 수 있도록 가능한 한 빨리, 그리고 많은 상위 엔지니어에게 요청(escalation)한다. 모든 서버 관리자들은 시스템의 치명적 문제를 해결할 수 있는 방법에 대하여 많은 교육을 받은 사람들 이다. 문제가 발생했을 때를 대비하여 구조적이고 통제하기 쉬운 우선순위 프로세스를 정립한다. 경험 많은 관리자는 이러한 유형의 변경 작업에 빈번하게 참여하게 될 것이다. 경험이 많지 않은 DBA는 선임 DBA에게 알리고 도움을 요청할 것이다. 이러한 조치 방법을 통해서 경험이 많지 않은 구성원들에게 훌륭한 기술 습득 기회를 제공하고, 팀의 기술 수준을 한층 높일 수 있게 되는 것이다.

가동 중인 시스템에 변경 작업을 수행하는 가장 이상적인 방법은 한번에 하나의 변경 작업을 수행하고, 변경 전후의 상황을 관찰하는 것이다. 그리고 위험상황에서 때로는 냉정하게 대처한다. 장애조치 서버가 준비되지 않은 상황에서는 이전에 경험한 기술을 기반으로 다양한 테스트 하지 못한 변경 시나리오를 스스로 만들고 방법을 찾아야 한다.

테스트해보지 않고, 표준이 아닌 방법으로 변경작업을 수행하면서 위험을 회피하는 방법은 경험 많은 DBA가 해당 작업을 수행하거나, 또는 마이크로소프트의 PSS(Product Support Services) 지원을 받으면서 진행하는 방법이다.

문제가 일어나면 즉시 문서에 기록된 모든 변경 사항을 확인한다. 긴급 상황에 대하여 무엇 때문에 그러한 의사결정을 하였고, 문제를 일으킬 가능성이 가장 높은 것으로 생각하lass="text">다시 시스템의 환경이 안정적으로 돌아오면 남아있는 문제들을 문서화하고 인시던트 관리 시스템에 문제를 등록한다(보다 상세한 자료는 "MOF 인시던트 관리" 백서를 참고하십시오). 해당 시스템 구성 환경이 과거 환경구성 문서에서 확인되지 않았으면, 이미 않는 것이 중요하다.

여러 개의 변경 작업을 동시에 실행하면 문제 해결을 위해 무엇을 해야 할지 난감해질 수 있다. 또한 변경한 내용 중 하나만이 다른 문제를 일으킬 수도 있다. 불필요한 변경 내용의 제거 작업은 일상적인 프로세스를 통해서 수행할 수도 있다. 대기 서버를 사용할 수 있도록 시스템을 설계하면 장애 발생시 대기 서버가 대신 동작하도록 하고, 장애가 발생한 원본 서버에서 문제를 보다 상세하게 분석하여 인시던트로 등록 관리하여 향후 비슷한 문제가 일어났을 때 참고할 수 있는 데이터베이스로 활용한다.

영향 분석

시스템의 다른 부분과 변경 작업이 어떠한 관계를 갖는지 분석함으로써 보다 낳은 계획을 수립하고 대처할 수 있다. 분석결과는 서비스 수준과 동등한 (8장 서비스 관리를 참조하십시오) 결과를 나타내며, 오류 및 변경 또는 잠재적 문제 등과 같은 위험에 주의한다. 시스템 변경 분석 자료는 프로젝트 수행 계획의 한 부분으로 포함되도록 준비할 수 있다. 계획단계의 정보는 제안된 변경작업의 영향을 분석하고, 변경작업을 통해 기능상 향상되는 것은 무엇이며, 기존 시스템에 어떠한 영향을 미칠 것인지를 파악하는데 유용하게 사용된다.

테스트

테스트 결과의 질적 수준은 테스트 스크립트가 실제 가동 환경을 얼마만큼 동일하게 표현했는가에 따라 달라진다. 스크립트가 가동 환경의 최고 및 보통 사용 상태와 같은 시스템 부하를 적절하게 표현해야 하므로 훌륭한 테스트 스크립트를 만든다는 것은 힘겨운 과정의 연속이다. 테스트 스크립트에 관련된 정보는 MSDN의 SQL 서버 홈 페이지를 참고하시오.?( http://msdn.microsoft.com/sqlserver/Default.asp)

표준 범주에 속하지 않는 모든 변경 테스트 작업은 베이스라인 모니터링 작업을 수행하면서 테스트 스크립트를 수행할 수 있는 가동 시스템 환경을 모사한 테스트 환경에서 테스트한다. 변경 작업의 효과를 알기 위해서는 변경 작업 전후의 베이스라인 결과를 비교한다. 비교할만한 테스트 결과를 얻으려면 각각의 테스트에 이용하는 스크립트가 동일한 것인지를 확인한다. 최적화 및 기타 변경 사항에 대해서는 응용 프로그램 변경이 가능한 시점에 스테이징 환경에 도입할 수 있다.

테스트 및 테스트 스크립트 개발을 위한 베이스라인을 만들고, 그 다음에 동일한 방법으로 서버를 정확하게 모니터링 하면서 스테이징 서버에서 스크립트를 실행시킨다. 새로운 응용 프로그램을 테스트하지 않고 스테이징 서버에서 재연할 추적 파일을 만들 수 있다. 새로운 실행 작업이 테스트도 하지 않고 SQL 명령을 변경해야만 하는 경우라면 추적 파일을 수집하여 발생하는 쿼리 유형의 비율을 분석하여 이용할 수 있다.

테스트 작업은 많은 분석 과정을 거쳐야 하는 시간 소모적 작업 이다. 데이터베이스의 테스트 스크립트를 구성하려면 MSDN ( http://msdn.microsoft.com/sqlserver/Default.asp) 에 있는 툴을 이용하거나 또는 프로필러를 사용할 수도 있다.

변경 통지

가동 시스템에 변경 내용을 적용하기 전 관련된 모든 부서에 작업내용을 알리고, 환경을 재구성하고 기능을 강화하는 작업에 앞서 문제 해결 방법에 보다 높은 우선순위를 두어야 한다: 네트워크 관리자, 헬프 데스크(작은 규모의 사용자 그룹), 사용자 그룹, 운영작업 관리 부서. 변경할 시스템의 특성에 따라 목록에 관리할 내용이 달라질 수 있다.

변경작업 완료 후, 작업 후의 상태를 네트워크 관리자, 헬프 데스크(작은 규모의 사용자 그룹), 사용자 그룹, 운영작업 관리 부서 사람들을 통해 확인해 볼 필요가 있다.

변경 중 대체 시스템 접속

시스템 다운이나 정전을 일으키지 않고 수행할 수 있는 사소한 변경 작업이라도 여러 팀이 함께 작업하는 것이 바람직할 수도 있다.

변경작업을 수행하는 동안 주요 시스템이 온라인 상태를 유지할 수 없으면, 대기 시스템에 수동으로 장애조치 기능을 구현할 수 있다. 그렇지만 데이터베이스 스키마를 크게 변경 했다면 새로운 데이터 구조에 맞도록 시스템을 개발하고 테스트하기 전까지는 대기 시스템에 데이터를 입력하거나 변경할 수 없다.

일반적인 기술은 가동 서버를 대기 서버로 변환하기 전에 특정 컬럼에 시작 값을 설정하여 식별이 가능하도록 하고 그 다음에 시스템을 재설치하고 데이터를 복사하여 대기 서버에서 생성된 데이터를 구분할 수 있도록 만드는 방법이다. 이 방법을 사용하려면, 온라인 상태인 사용자가 존재하는 경우 복사 작업 수행 시간이 너무 길어, 데이터가 저장되지 않았다고 생각하고 데이터를 다시 입력하여 데이터 중복이 발생될 수도 있다는 점을 인식한다.

관리할 수 없는 변경

시스템 관리자, DBA 및 기타 다른 IT 관련 직원이 변경 작업 후, 예상치 못한 또는 처리할 수 없는 상황에 대하여 대처할 수 있는 방안을 반드시 준비한다. 다행스럽게도, 이러한 준비 작업은 구성관리와 변경관리를 조합하는 작업 외에 추가적인 노력이 필요하지는 않다.

이러한 과정을 통해 관리할 수 없는 변경 내용은 무엇이고 무엇이 바뀌었는지 정확히 파악할 수 있다. 이미 기존 시스템의 정확한 시스템 구성 문서를 가지고 있으면 데이터베이스 코드의 완벽한 현재 버전을 가지고 있는 것이고, 두 가지 시스템의 정보를 비교하여 차이점을 비교할 수 있다. 시스템 문서에 관한 보다 상세한 자료는 "구성정보 관리" 부분을 참고하시오.

이러한 작업은 시간 소모적이며 단조롭고, 기껏해야 약간의 자동화만이 가능하다. 예를 들어 파일 복사 전후의 비교가 필요하다고 가정해 보자. 또는 설치 확인 스크립트를 만들 수 있다. (이 것은 쉽게 비교할 수 있도록 테이블로 구성하는 것을 원할 수도 있다.)

IT 관련 직원들이 원치 않는 결과를 반환하는 시스템 변경을 할 수 도 있고, 또 다른 가능성은 사용자들이 이러한 결과를 만들 수도 있다. 새로운 시스템을 관리할 때는 시스템을 사용하는 사용자 유형을 이해해?다. 일반적인 경우는 응용 프로그램에서 db_owner 권한을 갖는 사용자를 필요로 하거나 또는 특정 데이터베이스에 존재하는 테이블을 직접 열고 데이터를 변경해야 하기 때문에 직접 접근해야 하는 경우이다. 원칙적으로 모든 사용자는 윈도우 인증을 사용하고 권한은 응용 프로그램 역할에 따라 다르게 매핑 된다. 보안 목적상 추상 계층을 추가하고, 주어진 사용자 및 역할에 따라 뷰나 저장 프로시저 만을 이용하여 기초 데이터에 접근할 수 있다.

문서 변경

시스템 변경을 문서화하는 작업은 아주 중요한 작업 중 하나이다. 반드시 프로젝트와 관련된 모든 전자메일은 보관하며, 특히 폐기되는 디자인 아이디어는 현재 아이디어가 계획대로 잘 수행되지 못하는 경우 다시 사용될 수도 있으므로 반드시 보관한다.

변경 스크립트를 아주 면밀하게 검토하여 만들었으면 문서화 작업에 유용하게 사용할 수 있다. 인시던트, 시스템 또는 데이터베이스 정보와 같이 분명하게 스크립트에 주석을 달아 현재 위치에 저장한다. 스크립트를 사용하지 않고 수행한 변경작업을 문서화 하는 것은 대단히 어렵지만, 그렇게 함으로써 미래에 재사용할 수 있는 훌륭한 참고 자료가 생긴다는 점을 명심하기 바란다.

변경 및 배포 관리

변경 관리 주요 요소 중 하나는 스크립트를 사용하여 버전을 유지할 수 있는 처리 절차를 수립하는 것이다.

변경 및 배포 관리

변경 관리 주요 요소 중 하나는 스크립트를 사용하여 버전을 유지할 수 있는 처리 절차를 수립하는 것이다.

스크립트 준비

DBA는 스크립트를 스테이징 환경에 적용하기 전에 스크립트를 생성하고, 테스트하고, 실행에 관한 제반 사항을 준비한다.

스크립트를 이용한 설치 방법이 변경관리 목적에 가장 잘 부합된다. 스크립트를 이용함으로써 반복, 통제, 높은 수준의 자동 설치가 가능하며, 설치 과정의 어느 단계에서든지 쉽게 이전 상태로 환원할 수 있다. 스크립트 기반 설치의 장점은 다음과 같다:

버전관리

버전 관리는 새로운 오류와 그로 인해 일어날 수 있는 서비스 수준 또는 기타 다른 영향을 최소화하기 위한 확인된 방법과 기술적 도움을 통해 변경 작업을 처리하는 일련의 실습 과정이다.

소스 저장 방법

소스 코드를 저장하기 위한 가장 쉬운 방법은 보호된 폴더에 간단한 디렉터리 구조로 데이터를 관리하는 방법이다. 또 다른 대안 중 하나는 버전 관리 소프트웨어를 사용하는 방법이다. 이 것은 디렉터리 저장소를 사용하는 방법보다는 직관적 장점을 가지고 있는 반면 약간의 관리작업이 필요하다. 버전 관리 소프트웨어를 사용하면 개발자에게 익숙한 방법으로 쉽게 읽기 권한을 부여하고, 개발자들이 코드가 최종 버전임을 확인하고 이용 함으로써 심적 안심을 줄 수도 있다.

그렇지만 SQL 서버는 아직 버전 관리 소프트웨어와 통합되지 못한 관계로 데이터베이스 관리 작업은 많은 시간을 소요하는 작업이며, 특히 스크립트 변경에 주의한다. 관련된 모든 사람들이 작업하는 방법을 정확히 이해하고, 일관성을 유지할 수 있도록 한다. 데이터베이스 스크립트를 저장하는 모든 저장 시스템의 주요 약점은 모든 작업을 수작업으로 변경한다는 점이다.

버전 관리 프로그램은 배포 단위로 가장 최근에 변경한 모든 복사본을 쉽게 확인할 수 있도록 꼬리표를 부착할 수 있는 특징이 있다. 특정 배포 그룹으로 나누어진 개체의 코멘트와 상태 및 방법 등이 동일한지 확인한다. 익숙하게 작업하던 변경작업용 스크립트의 변경과 개체 생성 스크립트의 기록을 보존하기 위한 버전 관리 스크립트의 변경작업은 근본적으로 다르다. 그러므로 이러한 스크립트는 반드시 분리하여 관리한다.

이 정도 수준의 소스관리는 단순 파일 디렉터리에 스크립트를 보관하고 특정 시점에 하나의 특정 응용 프로그램을 선택하는 방법으로도 할 수 있다. 마이크로소프트 윈도우의 시작 버튼을 클릭한 다음, 검색을 클릭하여 디렉터리 검색이 가능하다. 또한 파일 이름이나 키워드를 이용한 검색도 가능하다. 버전 관리 소프트웨어를 이용하면 또한 텍스트 코드 및 코멘트 검색도 제공된다.

소스 코드 트리

응용 프로그램의 코드를 관리하는 방법 중 하나는 다음과 같이 소스 코드 트리를 구성하는 것이다.

데이터베이스 환경이 관리되지 않고 있으면 다음과 같이 동일한 구조를 이용 서버 정보를 관리할 수 있다.

응용 프로그램, 시스템 구현, 서버 구성과 관련된 문서를 저장하는 것 또한 유용한 방법이다. 전자메일의 규칙 마법사와 같은 다양한 옵션을 사용하여 관련된 메일의 내용을 보관하고, 사용 여부와 관계없이 모든 설계 문서와 품질보증 승인 및 기타 변경 관련 사항을 저장 관리할 필요가 있다. 이러한 자료들은 추후 시스템을 보다 잘 설계하기 위한 자료로서 유용하며, 시스템 디자인 제안서로 제안할 수 있는, 그리고 제안서 탈락 원인에 관한 거의 모든 문서를 소유하게 될 것이다. 이 것을 통해 다른 작업에서 요구되는 적절한 답변을 제공하기 위해 필요한 분석 시간을 줄일 수 있다.

변경 기록

다음은 변경 처리 프로세스를 가지고 있지 않으면 사용할 수 없는 하나의 변경 요청 예이다(이 것은 전자적 문서 형태로의 사용도 가능). DBA와 품질인증 그룹에서 서명한 후 변경 요청서는 변경 이력 기록으로 남게 된다.

비상 계획

계획 단계에서도 이행 과정에서 발생할 수 있는 문제의 고려가 필요하다. 이러한 위험 관리는 무엇을 변경하고 어떠한 방법으로 이행 작업을 진행할 것인지에 관한 것으로 이행 작업의 성공을 위한 필수 요소이다.

최소한 부딪히게 될 문제에 대하여 나열하고 원치 않은 결과가 나타났을 때 대처할 적절한 대안은 무엇이 있는지 확인한다. 또한 이행과정에서 치명적이지는 않지만 어떠한 문제가 일어났을 때 이행 작업용 스크립트를 수정하고, 문서 및 코드상에 추가할 내용을 추가함으로써 추후에 발생될 문제 검토 시 도움을 얻을 수 있을 것이다. 이러한 작업의 두 가지 이점으로는 첫째 무엇이 잘못되었는지 확인하기 쉽고, 두 번째 작업에 참여한 모든 사람들이 이행 경험을 통해서 노하우를 습득할 수 있다는 점이다.

잠재적인 문제점을 정리한 후 또는 과거에 경험한 문제들을 관찰한 후에 위험도의 차트를 만들고 각각의 문제를 해결하기 위해서 무엇을 수행하였는지 기록한다. 즉, 잠재적인 위험 요소를 제거하여 이행 작업을 안전하게 종료할 수 있다. 무슨 위험이 존재하는지 확인하는 것이 문제가 아니며, 무슨 문제인지 확인조차 할 수 없는 상황에서도 가동 시스템의 복원 전략은 반드시 준비한다.

롤백 전략

시스템 복원 계획 없는 시스템 변경 계획을 수립해서는 절대로 안 된다. 이행 작업 중 약간 또는 지속적으로 시스템 단절현상이 발생된다면, 보유하고 있는 보조서버를 이용하여 로그전달 서버, 구독 서버, SQL 서버 이외의 시스템을 통해 데이터 관리가 가능한 데이터 적재 시스템 등의 롤백 계획을 수립한다.

롤백 전략은 단순히 변경된 모든 내용을 복구할 수 있는 문서를 이용하여 변경작업 수행 전으로 되돌리는 것이다. 이런 문서는 연속적인 단계로 변경 내용을 롤백하기 위하여 사용할 수 있다. 이 것은 대부분이 T-SQL 스크립트로 구성된다. 아무리 완전한 계획일지라도 변경내용을 모두 롤백할 수 있는 방법이 필요하다. 시스템을 완전히 손상시키거나 예상치 못한 문제를 일으킬 수 있는, 그리고 확인조차 할 수 없는 위험이 존재할 수 있다. 개발자와 테스터는 이행 후 테스트 과정에서 설치 완료 승인을 얻지 못하게 할 수 있는 문제를 찾아 낼 수도 있다. 설치 사항을 롤백하기로 결정한 경우, 모든 변경 내용을 수행 전 상태로 되돌리는 시간이 매우 짧을 수 있다.

데이터베이스의 크기가 매우 작다면, 롤백 전략에 의거 백업 데이터를 복구할 수 있다. 최초 변경 작업 수행 전 상태로 되돌리기 위한 방법으로 트랜잭션 마크를 사용하여 복원할 수 있다. 대용량 데이터베이스나 코드 개체 및 테이블 외적인 요소를 변경한 경우는 보다 치밀한 복구 계획이 필요하다. 이러한 문서는 최초 단위 테스트 또는 품질보증 과정에서 테스트할 수 있다.

모든 서버나 인스턴스를 동시에 업그레이드할 수 없으면 해당 인스턴스 및 서버를 변경할 수 있는 계획과 문서가 필요하다. 이러한 작업은 단순 변경 관리보다 훨씬 복잡하다. 예를 들어 여러 데이터베이스를 하나로 통합해야 하는 데이터베이스 변경 작업을 가정해 보자. 변경 작업에 의해 사이트에서 분리되어 대기중인 서버에 대하여 직접적인 작업은 지연시킬 것이고, 일반적으로 가장 중요한 서버에 대해서는 하루 정도 후에 해당작업을 수행할 것이다. 가동 환경이 구성된 후, 사이트에서 분리된 대기 서버들은 단지 변경 전 상태로 시스템을 쉽게 복원할 목적으로만 존재한다. 주요 사이트에서 장애가 발생하면 대체 사이트의 신규 시스템으로 작업을 유지하고, 즉시 복구할 수 있는 계획이 필요하다. 가장 이상적인 방법은 모든 가능성을 생각하고, 적합한 방법을 준비하는 것이다.

배포 및 구현

누가 가동 시스템의 변경 작업을 수행할 것인가?가 DBA 그룹에서 논의할 주제일 것이다. 개발 DBA와 가동 시스템의 DBA가 둘 다 있으면, 다음과 같은 트레이드오프가 있다: 개발 DBA는 연관된 모든 부분을 이해하므로 변경작업 등을 책임질 것이고, 궁극적으로 가동 시스템의 DBA는 시스템의 전반적인 책임을 갖게 된다. 이론적으로 모든 DBA는 프로젝트의 전 주기에 걸쳐 역할 을 수행할 수 있다. 작업 수행 매뉴얼이 아주 정확하다면 개발팀에서 직접 변경 작업을 수행한다.

결국 소유권 문제이다. 시스템 변경 작업을 직접 수행할 사람은 시스템에 내재하는 문제와 변경된 사항을 잘 알고 있어야 한다. DBA는 필요하다면 지체 없이 아주 정확한 작업을 수행할 수 있는 권한을 가져야 하고, DBA는 아니라도 운영작업에 도움을 줄 수 있는 모든 사람에게 연락할 수 있는 방법을 알고 있어야 한다.

윈도우 구현 결정

24x7로 가동되는 시스템이라면 프로젝트 팀은 변경 작업과 관련된 모든 사용자 그룹이 납득할??-크리티컬한 시스템의 경우는 아주 짧은 시간 동안 시스템 중단도 허용할 수 없으므로 데이터베이스 접근 방법을 읽기 전용 모드로 변경할 수 있다. 이 경우 프로젝트 팀은 소수의 핵심 사용자를 확인하고 핵심 사용자들의 데이터베이스 연결을 ODBC(Open Data Base Connectivity)를 통해 다른 서버로 돌릴 수 있다.

이러한 작업을 효과적으로 수행하려면 IT관련 연락처가 필요하고, 시스템 관리 및 스텝 수준의 사용자에 관한 연락처도 필요하다. IT 부서는 예상되는 시간 동안 서비스 장애 상황에 대하여 명백하게 이야기할 수 있고, 신뢰할 수 있는 사용자 그룹의 유지 관리가 필수적이다. 계획 하에 수행하는 모든 변경작업에 대해서는 관련 당사자와의 협의 하에 작업을 수행해야만 한다. 또한 대체 접근 방법이 필요하면 시스템을 읽기 전용 접속할 수 있도록 하고, 사용자와 헬프 데스크 지원 인력과 관련 정보를 공유한다.

구현 계획

정보 시스템을 사용하는 또는 영향권에 있는 모든 사람에게 배포될 실행 계획을 수집한다. 이러한 계획은 단순히 단계를 기술한 수준이고, 각 작업의 책임은 해당 작업을 수행할??게 연락한다. 작업 수행 도중 전화하거나 온 사이트 요청이 필요한 모든 사람의 휴대전화와 호출기 번호를 확인한다.

일어날 수 있는 모든 상황을 가정하여, 문제를 회피할 수 있는 두 번째 계획을 수립한다. 상세한 시스템 표준화 작업을 수행하려면 응용 프로그램 및 하부구조의 경험이 필요하다. 그리고 모든 작업을 취소하거나 롤백 계획을 적용할 때 많은 주의가 필요하다.

팀으로 구성된 작업자들은 데이터베이스 백업 계획을 수립하며, 백업 계획은 데이터베이스의 단순 롤백 전략과는 다소 다 르다. 전체적인 작업 중 특정한 사람이 수행하는 부분에서만 오류가 발생되었다면 작업자들은 전체적인 상황을 파악하기 위한 계획을 가지고, 의사결정을 한 다음, 그 동안 수행한 작업을 취소한다.

배포 준비 검사

운영자들이 작업의 소유권을 갖기 시작하는 것은 배포 준비 상황을 검토, 작업 수행을 할 것인지 말 것인지의 회의, 어느 시스템에 또는 무엇을 변경할 것인지 등을 확인하는 단계이다. 비록 운영자들이 프로젝트의 처음부터 끝까지 투입되었더라도 이것은 개발자들이나 품질보증 팀이 아닌 운영자들이 개최하는 최초의 회의일 것이다.

이 미팅의 목적은 각 팀의 구성원들에게 운영자들이 최종 승인을 할 것인지 아니면 기각할 것인지, 제기할 문제가 무엇인지를 알리기 위한 것이다. 이 회의가 치명적 시스템 장애를 제외한 작업 일정 변경을 할 수 있는 마지막 기회이다. 모든 그룹이 시스템 변경 작업 실행을 준비한다. 운영자들이 제품이나 시스템의 운영 작업을 지원할 충분한 지식과 준비가 완료되었는지 하는 점이 매우 중요하다.

심각하게 작업 내용을 검토한 다음, 작업을 수행할 수 없다고 결정할 수도 있다. 현 문제를 해결할 방법이 없으면 문제를 해결할 때까지 또는 시니어 IT 직원이 해당 문제를 해결할 때까지 작업 수행 불가에 관한 미팅을 연기한다. 어떤 경우는 미래에 시스템 문제를 일으킬 수 있는 위험이 있기 때문이다.

이 미팅에서 협의할 내용에는 다음과 같다.

• 배포 준비
• 물리적 환경 변경
• 운영직원과 처리절차 준비
• 설치 계획
• 재난 복구 계획
• 다른 시스템에 미치게 될 영향

작업 수행을 위해 공식적인 변경관리 절차 등록이 필요하면 그러한 절차를 준수하였는지 확인한다. 데이터베이스에 대하여 변경 작업을 수행하려면 파일 형태로 요청해야 할 수도 있다. 공식적인 변경관리 절차가 없으면 시스템에 연관된 모든 사람들에게 변경 작업, 작업 중 문제가 일어났을 때 또는 작업이 완전히 끝났을 때 전자메일 공지를 보낼 수 있다. 여기에는 최소한 기술지원 스텝, 헬프 데스크 기술자, 네트워크 및 보안 관리자 등이 포함되어야 한다. 더 이상 고려할 내용은 없을 것이다.

응용 프로그램 변경 조정

가장 먼저 수행할 일은 현 시스템의 백업을 받는 일이다. 백업 완료 후, 백업 결과를 확인하고 작업을 시작할 준비를 한다. 그렇지만 DBA들은 좀처럼 변경 작업을 선도하지 않고, 일반적으로 개발책임을 가지고 있는 프로젝트 팀원 중 한 사람이 해당 작업을 수행한다. 시스템 관련 담당자들에게 연락하여 백업이 완료되었는지, 아니면 준비 중인지를 확인한 다음 시스템에 하나의 변경 작업만 수행하고 확인하는 형태로 작업을 진행한다.

구현과 적용

작은 조직이 아니면 항상 작업을 수행할 수 있는 제2의 DBA가 대기상태로 존재한다. 작업 범위가 매우 커다란 경우는 시스템 변경 작업에 여러 명의 DBA가 참여하지만, 갑작스런 질병 또는 해당작업으로 인한 시스템 장애 및 예상치 못한 문제를 처리할 수 있는 추가적인 DBA를 여전히 보유한다. 변경 작업을 수행하는 도중 다른 가동 서버에서 장애가 일어나더라도 변경 작업은 계획대로 계속 진행해야 한다. 작업이 완료될 때까지 DBA를 지지할 수 있는 합리적인 모든 노력을 기울려야 한다.

또한 DBA가 이행 작업을 지원하고 있으면 DBA는 작업을 수행하는 사람을 지원할 수도 있다. 작업 중 도움을 청할 수 있는 서버 엔지니어, 네트워크 관리자, 보안 관리자 등의 연락처가 준비되었는지 확인하고, 전화번호는 가용한 것인지 확인한다.

계획에서 누락된 내용과 절차 문서화

때로는 이러한 모든 노력에도 불구하고 가동 시스템에 변경 작업을 수행하는 도중 예상치 못한 문제가 일어나는 경우가 있다. 문제 심각성 정도와 무관하게 수행 매뉴얼에 내용을 기록한다. 실행 코드와 수행 작업등을 포함하는 모든 것을 기록한다. 장애 발생 시 즉시 매뉴얼에 기록한다. 지원을 요청하고, 후에 이행 작업을 친숙하게 할 수 있도록 하고, 작업 후 분석을 하는 등 일련의 문제 및 작업 조치 과정은 후에 매우 중요한 자료가 될 것이다. 작업 과정에서 순서를 누락하는 것보다는 아주 정확하게 기록하는 것이 중요하다는 사실을 기억한다. 당연히 실수한 것조차 기록하는 부단한 노력이 필요하다. 지금 철저하게 작업 내용을 기록하지 않으면 나중에 누군가가 동일한 실수를 할 것이고, 철저히 작업 내용을 기록하는 습관을 통해 작업자들이 팀 구성을 위해 중요한 부분인 팀워크 뿐 아니라 기술적 문제의 훌륭한 팀워크까지 배우고, 많은 IT 부서와 연관관계를 맺게 되며, 팀 구성원들에게 정확한 정보를 제공하게 될 것이다.

롤백 계획 문서

롤백 계획 문서시스템 설치 및 업그레이드 작업 실패를 가정하여 반드시 롤백 계획을 수립한다. 이러한 일은 거의 일어나지 않겠지만 만일 롤백 작업을 수행해야 하는 경우는 훌륭한 롤백 계획의 가치를 충분히 인정할 수 있을 것이다. 롤백 스크립트나 데이터베이스 복구 작업을 통해 시스템을 복원했더라도 이행 계획의 취소 경위를 전자메일을 통해 설명하는 것이 바람직하다. 데이터베이스의 변경은 전혀 없지만 계속 관심을 가져야 하는 문제이며, 관련된 사람들에게 정보를 제공해주어야 하다. 초기에 이행 작업을 진행할 예정이라는 통지를 받은 모든 정보 시스템 담당자들에게 정보를 제공한다. 사용자 그룹에 직접 정보를 제공하지 않으면 프로젝트 관리자나 변경 작업 관리자 들에게 라도 관련 정보를 제공한다.

구현작업이 완료되었을 때

담당자가 이행 작업을 완료한 다음 즉시 다음 작업을 진행할 담당자에게 통보한다? 필요한 경우를 대비하여 이제 대기상태를 유지하며, 이행 작업이 성공적으로 완료되었으면 테스터들이 가동 시스템에 적용한 모든 작업이 정상적으로 동작하는지 테스트 작업을 수행하고, 그 다 음으로 사용자들에게 해당 시스템에서 작업을 재개하도??션 아이템을 가지고 있는 담당자에게 연락한다. 이러한 이상 작업을 수행해야 할 내용이 있는지 알 수 있다.

이행 작업 검사

이행 작업을 완료한 다음 프로젝트의 성공을 평가하기 위한 미팅을 소집한다. 프로젝트 계획, 설계, 개요, 솔루션, 위기 및 최종 결과물에 이르기까지 프로젝트의 모든 면을 확인한다. 이러한 과정을 통해서 발생된 문제를 통해 배우는 것이다. 내용을 추가하거나 문서를 공유할 수도 있다. 무엇이 잘되었고 무엇이 잘못되었는지의 피드백을 기억한다. 검토 작업을 완료한 다음 응용 프로그램 개발 주기를 다음 배포 시각으로 다시 시작한다.

구성 관리

여기서 살펴볼 내용은 수행일지에 포함된 내용이 무엇인지 파악하여 SQL 서성 관리까지 포함된다.

시스템 구성 베이스라인

모든 서버에 대하여 표준 서버 환경을 정의하는 것이 필요하다. 비록 관리 서버들이 현재 표준화와는 먼 상태에 있더라도 여전히 표준화는 현 상황에서 서버 구성 정보를 가장 쉽게 찾을 수 있는 방법이다. 표준과 다른 사항에 대해서는 약간의 관심을 가지면 문서화가 가능하다. 이 방법이 무수한 서버 구성 방법을 개별적으로 기억하는 것보다는 단순한 접근 방법이다.

구성 정보의 베이스라인은 제품 또는 시스템이 마지막으로 성공한 구성 정보의 기록이다. 베이스라인은 추후에 시스템 또는 제품을 다시 구성할 때를 대비하여 아주 상세한 문서화가 필요하다. 환경 관리를 통해 업무용 응용 프로그램 서비스와 IT 기반 구조를 구성하고 있는 모든 아이템을 분명하게 구분함으로써 변경 작업을 용이하게 할 수 있다.

시스템 기본 구성과 관련된 것에는 다음과 같은 사항이 포함된다.

• 식별하부 구성 요소를 구분하고 구성 요소간의 관계 설정.
• 통제구성 요소 변경 승인.
• 상태?감사환경 구성 요소의 기록 및 보고서.
• 확인환경 구성 요소의 기록 및 하부 구성 요소의 상황 감사.
• 인벤토리환경 구성 요소의 인스턴스 식별.
• 지원문제 해결을 위해 필요한 환경 구성 요소의 속성 식별.
• 연락처 유지관리환경 구성 요소 및 환경 구성 요소의 인스턴스의 관리 권한을 위임
  받은 사용자.

구성환경 관리의 이점

환경구성 정보를 기록하여 유지하면 여러 가지 이점을 얻을 수 있다. 첫 번째는 재해 상황이 발생했을 때 재 구축 작업에 도움이 된다. 이러한 이유로 모든 작업이 기록된 수행일지는 재해 복구 계획에 있어서 대단히 중요한 자료이다. 수행 일지에는 단편적인 구성 정보를 포함시킬 수도 있고, 또는 필요에 따라 매우 상세한 수준의 환경 정보도 포함시킬 수 있다.

수행일지를 통해 매일매일 수행하는 시스템 정보를 쉽게 얻을 수 있다. 수행일지에 각 시스템 담당자의 연락처 같은 정보까지 기록했다면, 관리하는 시스템에서 송수신되는 데이터를 확인하는 작업과 시스템 성능 문제 및 비상사태 발생시 기꺼이 답변을 해줄 수 있는 담당자와 연락하는데 도움이 될 것이다.

수행일지는 실제 책처럼 인쇄할 필요는 없지만 주기적으로 여러 권을 복사하는 것은 필요하다. 복사본은 테이프로 보내져 재해가 발생된 사이트의 복구 작업에 활용될 수 있다. 또한 수행일지의 내용을 웹을 통해 공지할 수도 있다. 예를 들면, 최신 서비스 팩, 핫 픽스, CPU 정보 등을 테이블 형태의 정보로 제공하는 웹 페이지를 만들 수 있다. 또는 XML 형태로 제공하여 XML 데이터를 그대??, 시스템, 지원 그룹, 서비스 등의 구성관리 체계 및 절차를 문서화 할 수도 있다.

수행일지 만들기

변경, 가용성, 재해 복구 계획의 성공적인 관리를 위해서는 시스템과 관련된 인력, 프로세스, 절차 및 상세한 구성환경을 간단하고 구체적으로 문서화하여 유지하거나 그러한 문서를 수집하는 것이다. 이런 종류의 문서가 때로는 수행일지로 참조되는 것이며, 꼼꼼하고 즉각적으로 변경되는 동시에 팀원 모두가 공유할 수 있는 체계를 갖추어야 한다.

SQL 서버 관리를 위한 지식

다음 항목들이 데이터베이스 시스템의 운영 가이드를 위한 기본 사항이다. 이 항목들은 표준 운영 지원 가이드 고도화를 위해 필요한 요소로서 SQL 서버 2000을 기반으로 작성되었지만, 개념적으로는 다른 버전에도 동일하게 적용된다. 본 항목들은 마이크로소프트 내부의 필드 지원 인력과 운영 인력들이 확인하고 인정한 내용으로 현재 견해와 이상적인 항목이라고 생각하는 것이다.

DBA로서 책임을 충실히 수행하려면 최소한 다음과 같은 시스템 정보는 숙지하고 있어야 한다.

• 유지관리 계획에 관한 정보: 관련된 모든 스크립트, 분석을 위한 데이터를 이동시키는 방법, 오류 및 경고 처리 방법, 원격지 서버에 관한 정보
• 데이터베이스 백업 파일, 백업 파일의 위치 및 유형(완전 데이터베이스, 차등 , 파일, 파일 그룹, 로그)과 현재 파일 구조가 어떻게 구성되었는지에 관한 정보. 및 테이프, 기타 이동식 저장 매체에 저장된 파일과 저장 횟수, 저장 위치, 반드시 백업해야 하는 디렉터리, 데이터 및 파일의 정보 기록. 백업 시 암호를 사용하여 백업 작업을 수행했으면 암호를 기억하고, 기타 관련된 모든 정보를 기록한다.
• 규칙적으로 sqldiag.exe을 수행하여 결과 값을 텍스트 파일로 저장한다.중요:sqldiag의 결과를 이해할 수 있어야 한다. 만일 sqldiag의 분석에 익숙하지 못하다면 관련된 내용의 추가적인 지식을 쌓아야 한다.
• DTS(Data Transformation Services) 패키지를 파일로 저장하여 복원 및 이전 작업 수행 시 쉽게 활용할 수 있도록 한다. 패키지와 데이터 변경과 관련된 암호와 로그인 정보를 주의하여 관리한다.
• 모든 시스템 정보와 sa를 포함하는 응용 프로그램 사용자 계정과 암호를 만들 수 있는 스크립트를 생성한다. 응용 프로그램의 역할, 암호, 연결 서버 및 원격 서버를 등록할 수 있는 스크립트를 만든다.
• 소프트웨어의 일련 번호를 기록 및 관리하고, 서비스 팩과 핫 픽스를 포함하는 CD를 복제하고, 그리고 네트워크 공유 파일을 어디에서 참조할 수 있는지 확인.
• 연락처, 구성 정보, 데이터 처리와 관련된 문서와 같이 시스템 관련 모든 기록 유지관리.
• 서버 유지 및 관리를 위해 DBA가 기록한 모든 정보 활용.
• 하드웨어/소프트웨어 공급업체의 지원 전화 번호 및 관련 웹사이트의 로그인 계정과 암호와 같은 계정 기록 및 관리
• 원격 사이트가 있다면 원격 사이트의 연락처 관리
• SQL 서버를 새로 만들고 사용자 계정과 암호를 재설정할 때 통지 받아야 하는 담당자 정보.
• 스키마, 설치 및 롤백 스크립트, 유지관리 스크립트 또는 테스트용 스크립트에서 이용하는 스크립트 버전을 모두 관리하려면 마이크로소프트 비주얼 소스세이프(Visual SourceSafe)를 사용하시오. 특히 개체 암호화를 위한 스크립트는 중요하다.
• 연락처 정보를 기록하자. 각 담당자의 업무 역할을 기록하여 담당자의 업무 변경이 있을 때 쉽게 정확한 연락처 정보를 알 수 있도록 한다. 실질적으로는 부서, 전자메일 토론 그룹 주소록 등과 같이 관리한다.

응용 프로그램 시스템 정보

응용 프로그램 정보는 다음과 같다.

• 해당 시스템에서 실행되는 모든 응용 프로그램 리스트(서버 내에서 실행되거나 또는 다른 시스템 상에서 실행되는). 여기에는 주문 생산 소프트웨어도 포함된다.
• 응용 프로그램의 보안구조, 로그 인을 위해 사용하는 인증 유형, 고정 암호, 승인 역할에 관한 문서. 다중 사용자 로그 인의 경우에 암호 변경 과정에 주의한다.
• 응용 프로그램과 관련된 연락처 정보 기록: 개발자와 응용 프로그램 변경에 관여한 모??들 및 시스템 관련자들의 연락처 포함한다.
• 연락처, 구성 정보, 데이터 처리와 관련된 문서와 같이 시스템 관련 모든 기록 유지관리.

데이터베이스 구성요소

다음은 데이터베이스 구성요소의 것이다.

• 데이터베이스 스키마, 콜레이션(collation: SQL 서버 2000에서 국가별 언어 설정), 작업, 오류 메시지에 관련된 모든 내용을 스크립트화하여 저장하고, 이력을 관리한다.
• DDRT(Data Dependent Routing Tables)와 분산 트랜잭션 마크 등과 같은 분산 데이터베이스 또는 파티션에 관련된 모든 정보 기록

스토리지 구성요소

다음은 스토리지 구성요소와 관련된 내용이다.

• 서비스 팩과 핫 픽스 같은 운영체제 버전에 주의
• 사용하는 정확한 하드웨어 목록 유지 및 하드웨어 구성 정보 관리
• CPU, 메모리, BIOS 정보
• 펌웨?과 디스크 컨트롤러 정보(라이트 캐시 정보를 포함하는)를 포함하는 문리적/논리적인 디스크 구성 정보, 디스크 타입과 크기, 할당 단위 또는 블록 단위처럼 특별히 사용한 옵션의 기록
• 서버, 하드웨어, 구성정보, 위치 등에 관한 특이 사항의 정보를 관리한다. 예를 들면 동일한 디스크 어레이 컨트롤러에 연결된 다른 쉘프에 꼽힌 디스크의 정보 등이다.

서버 구성요소

다음은 서버 구성요소에 관한 정보이다.

• 서비스 팩과 핫 픽스 같은 운영체제 버전에 주의
• 설치된 서비스 팩과 서비스 팩을 포함하는 SQL 서버 구성정보
• SQL 서버 인스턴스 이름, IP 주소, 포트, 구성 옵션, 데이터베이스 파일의 위치, 서비스 로그인 계정과 암호, 전자메일 계정, 가용 네트워크 프로토콜 및 프로토콜의 배열 순서의 기록
• 파일 공유 정보 기록. UNC(Universal Naming Convention) 이름으로 찾아갈 수 있는 공유 이름 또는 서비스 로그인 인증에 필요한 기타 프로토콜
• 동일 서버 상에서 수행되는 기타 다른 소프트웨어의 구성정보 관리. 설치 및 환경 구성 자료와 지원 인력의 정확한 정보들이 문서화되어 있고, 활용할 수 있는지 확인한다. 또한 각 소프트웨어의 지원 계약 번호 및 웹 사이트 목록을 확인
• 원격 데이터베이스에 연결하기 위하여 클라이언트에 설치되는 툴과 구성 방법에 주의한다(예를 들어 이 기종 데이터베이스에 접속하기 위한 툴)
• DNS가 설치된 서버 및 DNS 자체의 정보
• SQL 서버 2000 장애조치 클러스터링, 복제, 로그 전달 설치 문서와 기타 구성 정보 및 토플로지 명세
• 다중-인스턴스 구성의 문서
• 각 서버 관한 예외 상황의 기록 유지. 예를 들면 IIS(Internet Information Services)의 XML 지원, 마이크로소프트 액티브디렉터리 지원 등과 같은 특정 기능에 주의한다

수행일지는 고가용성을 유지해야 하는 시스템을 새로 구축하고 구성 정보를 최신상태로 유지해야 하는 경우에도 유용하게 사용된다. 또한 이러한 과정을 자동화하고 싶으면 자동화도 가능하다.

오프사이트 스토리지

반드시 최신 수행일지의 오프사이트 복사본을 유지해야만 한다. 원칙적으로 이 복사본이 백업도 없고 GUI를 이용하여 별개로 설치된 경우라면 하나의 문서로 인쇄하거나, 프로그램 내에 요약하여 포함시키거나 또는 두 가지 모든 방법을 사용할 수 있다. 계속해서 만들어지는 수행일지의 모든 변경 사항을 유지하고, 소프트웨어 CD의 모든 오프사이트 복사본을 유지하려면 버전관리 도구를 사용한다.

표준화의 중요성

표준화는 제품의 기술 명세, 작업 방법, 동일한 시스템에 존재하는 유사한 구성 요소를 정의하는 과정 이다. 표준 명세를 사용하면 종속관계에 있는 필수 구성 요소를 알 수 있다. 원론적인 목적은 시스템에 관한 모든 것에 대하여 표준을 만드는 것이며, 그 다음으로 표준으로부터 분리된 시스템 상태를 간략하게 기록하는 것이다. 이러한 방법이 개별 시스템을 별도로 문서화하는 것보다는 훨씬 간단한 방법이다.

예를 들면 관리 및 지원 전략의 표준화, 디렉터리 표준화, 하드웨어와 하드웨어 구성의 표준화 등을 통해서 이상적 관리 시스템 구축에 가까이 다가갈 수 있다. 시스템 표준화를 통해서 얻을 수 있는 실질적인 이득은 익숙한 표준 환경에 근거한 보다 실질적이고 정확한 의사결정을 할 수 있다는 점이다.

구성환경 관리 데이터베이스

시스템 관리를 위한 별도의 데이터베이스를 개발할 수도 있지만 이 것은 대단히 많은 작업이 필요하다. 시스템 관리용 데이터베이스를 별도로 구성하거나 수행일지를 사용하는 방법도 모두 운영 작업의 한 부??를 기록할 것인가를 결정하려면 데이터센터에 등록된 데이터가 너무 많아서 제 기능을 수행하지 못하는 상황이 초래되어 오프사이트로 서버를 재구축하는 상상을 해보면 될 것이다. 몇몇 상세한 정보는 기존 데이터 센터와 새로운 데이터 센터간에 차이가 존재하므로 무시할 수 있다. 그렇지만 사용자와 응용 프로그램 요구사항은 동일할 것이다.

예를 들어 서버를 건물 출입 관리 내역 보관용 서버를 추가한 경우라면 구성 관리 데이터베이스에 이러한 정보를 유지관리 하는 것이 유용하지 않을 것이다. 대신 장비 또는 빌딩 관리자가 관리하는 시스템에 속할 것이다.(어떤 경우는 완전한 설비 레이아웃을 보여줄 수 있는 공간관리 데이터에 포함될 수 있다.) 두 데이터 저장소 간에 링크를 통해 이익을 얻을 수는 있으나 각각의 시스템이 명백하게 다른 목적을 가지고 있다는 점이다. 시스템 구성 문서를 수정하는 프로세스를 연기 또는 복잡하게 만들 필요는 전혀 없다. 언제, 왜, 누가 변경 했는가에 관한 정보에 관심이 있다면 인스턴스 마다 트리거로 로그 테이블에 또는 별도의 버전관리 소프트웨어를 이용하여 자동 감사 프로세스를 만들자.

예를 들어 서버를 건물 출입 관리 내역 보관용 서버를 추가한 경우라면 구성 관리 데이터베이스에 이러한 정보를 유지관리 하는 것이 유용하지 않을 것이다. 대신 장비 또는 빌딩 관리자가 관리하는 시스템에 속할 것이다.(어떤 경우는 완전한 설비 레이아웃을 보여줄 수 있는 공간관리 데이터에 포함될 수 있다.) 두 데이터 저장소 간에 링크를 통해 이익을 얻을 수는 있으나 각각의 시스템이 명백하게 다른 목적을 가지고 있다는 점이다. 시스템 구성 문서를 수정하는 프로세스를 연기 또는 복잡하게 만들 필요는 전혀 없다. 언제, 왜, 누가 변경 했는가에 관한 정보에 관심이 있다면 인스턴스 마다 트리거로 로그 테이블에 또는 별도의 버전관리 소프트웨어를 이용하여 자동 감사 프로세스를 만들자.

요약

이 장에서는 데이터베이스의 구성 환경 변경관리를 위한 과정과 절차의 것으로 소프트웨어, 하드웨어, 시스템 프로세스, 코드 등의 변경을 관리하기 위한 방법에 대하여 살펴보았다. 특히 작업 수행 일지에 기록 관리할 항목에 대하여 살펴보았고, 또한 시스템 구성을 관리하기 위해서 고려되어야 하는 요소에 대하여 알아 보았다.