문제해결과 장애조치

개요

이 장에서는 문제해결과 장애조치 방안들에 관해 다룬다. 데이터베이스의 문제로 보일지라도 실제 문제는 네트워크 연결의 문제이거나 혹은 클러스터 환경에서 발생되는 문제라면 클러스터 쪽의 이슈일 수 있으므로 문제를 정확히 파악할 수 있는 유용한 팁을 여기서 제공한다. 로그 파일의 검토와 문제 해결 방안을 기술하는 툴에 관한 얘기도 간략히 있을 것이다. 문제해결과 장애조치를 위해 추천되는 방법들을 수행하고 나서, 데이터베이스 관리자는 이를 문서화할 뿐만 아니라 상세한 절차로 남겨놓아야 한다. 이렇게 하면, 동일한 장애가 계속적으로 일어나는 것을 막을 수 있고, 제대로 해결 절차를 기술해 놓으면 다음 번의 장애시에도 이용할 수 있기 때문이다.

소개

이 장에서 개괄하고 있는 내용은 부딪히게 되는 응용 프로그램 문제 해결에 도움이 될 것이다. 여기서 소개하는 내용이 SQL 서버에 관한 것이긴 하지만, SQL서버는 이를 이용하는 다른 응용 프로그램과 긴밀한 관계를 가지고 있는 까닭에 응용 프로그램에서 제기되는 모든 문제들에 있어서도 여러분은 DBA로서 참여해야 한다. 아래의 절차는 증상에 관련된 데이터를 수집하고 문제를 고립화하며 필요한 조치를 결정하여 운영 환경 전체를 향상시키는데 도움이 될 것이다.

디자인 고려사항

이 장에서는SQL 서버 문제를 중심으로 응용 프로그램 문제를 고립화하고 조치해 들어가는 방법론에 집중할 것이다. 이 방법론은 문제해결을 위해 반드시 넘어야만 하는 가장 큰 장애물을 다루는 것을 목표로 한다. 바로 혼돈스러움, 그것이다. 다양한 증후들이 응용 프로그램 각 계층에서 중층적으로 나타날 때, 문제 해결에 도움이 될만한 의미 있는 증후들을 분리해내는 것은 쉽지 않다. 또한 제시된 프로세스 중 어디부터 손을 대야 할지 판단하기도 쉽지 않다. 문제요인 관리 방법론(Problem Management Methodology)은 바로 이러한 혼돈을 없애기 위해 고안되었다. 이 방법론은 가중치를 둘만한 종류의 증후를 먼저 다룬다. 문제 해결자는 이 방법론의 제시에 따라 가장 공통적인 문제 영역을 다루는 일련의 질문을 던지게 된다. 문제를 일으킬 수 있는 가능한 요인들을 제거해 나가다 보면, 얼마 되지 않아 문제는 고립화된다. 문제가 일단 완전히 고립화되면, 방법론은 문제에 대한 적절한 솔루션을 제시한다. 이러한 체계화된 접근법은 대규모 다층 구조의 응용 프로그램 환경에서 문제 해결의 과정이 혼돈으로 빠지지 않게끔 고안된 것이다.

필요한 리소스

문제 해결을 위해선 어쨌거나 데이터베이스 관리자는 선정되어 있어야 한다. 문제의 종류에 따라 클라이언트, 미들웨어, 그리고 SQL 개발자의 도움 역시 문제 해결에 필요하다. 응용 프로그램 디버그 툴이나 작동모드(operational mode)가 필요할 수도 있다. 이러한 툴들은 클라이언트와 SQL 서버간의 각 계층에서 응용 프로그램의 상태를 모니터링 할 수 있도록 해준다. 만약 클라이언트와 SQL 서버간의 상태를 점검할 뾰족한 방법이 없다면 이러한 툴의 도움을 받아야 할 것이다. 설정 관련 문제는?계층 1(Tier 1)의 증상 데이터(symptom data)를 분석하여 해결 가능한데, 데이터베이스 관리자가 대략 두시간에서 네 시간 정도의 시간을 투자하면 된다.(각 계층에 대한 정의는 이 장의 뒤에서 설명하기로 한다) 코드 관련 문제도 계층 1의 증상 데이터를 분석해야 하는데, 데이터베이스 관리자는 두 시간에서 네 시간 정도, 코드 개발자는 두 시간에서 길게는 16시간 정도를 투입해야만 한다. 계층 2 분석이 필요한 문제는 데이터베이스 관리자가 엄청난 시간을 소비해야만 하는 경우도 있다. 이런 종류의 문제 분석과 해결은 전 기간에 걸쳐 개발팀과 네트워크 관리 팀의 긴밀한 협조가 필요하다. 데이터베이스 관리자가 문제요인의 다양한 양상과 관련한 해결책을 이해하는 것은 중요하다. 이에 대한 가이드는 폭 넓게 얻을 수 있는데, 마이크로소프트 SQL 서버 2000 레퍼런스 라이브러리나 마이크로소프트 SQL 서버 2000 관리자의 벗 그리고 인사이드 마이크로소프트 SQL 서버 2000 같은 참고서적을 읽어볼 것을 권한다.

일단 장애가 발생하면, 계층 1의 증후 자료라 불리는 자료들을 상세하게 수집해야 한다. 이 데이터들은 이 장 전체를 통해 자세하게 얘기될 것이다.

과정 흐름도

이 장은 문제요인 관리 방법론의 각 단계에 대하여 소개한다.

각각의 단계는 뒤에서 더 심도 깊게 다루어질 것이다. 전체적인 프로세스 흐름은 각각의 단계를 수행하는데 있어 도움이 될 수 있도록 만들어졌다. 프로세스 흐름은 세 개의 서로 다른 흐름도로 나뉘는데, 응용 프로그램 흐름도(Application Flowchart), 데이터 계층 흐름도(Data Tier Flowchart), 그리고 데이터 계층 오퍼레이션 흐름도(Data Tier Operations Flowchart)가 그것이다.

응용 프로그램 흐름도(Application Flowchart)

응용 프로그램 흐름도(그림 7.1) 는 증후관련 데이터를 수집하고 분석하는 과정을 보여준다. 이 흐름도를 따라가다 보면, 문제가 SQL 서버에 관련이 있는지 아닌지를 판단할 수 있게 될 것이다.

이 흐름도의 계층 1 증후 관련 데이터는 다음 다섯 가지 소스로부터 나온 것이다.

계층 1의 증후 데이터를 분석하는 것만으로도 실제 원인을 파악할 수 있는 경우도 있다. 예를 들어, DTC(distributed transaction coordinator) 서비스를 제대로 설정하지 않은 클러스터 환경에서 시스템이 작동하고 있으면 이벤트 뷰어의 시스템 로그에 클러스터 환경에서 DTC를 기동하려면 comclust.exe를 먼저 돌려 한다는 식의 메시지가 표시되는 경우도 있다. 이렇게 명쾌하게 문제 상황과 해결책이 제시되는 경우도 있다!

계층 1의 증후 데이터에서 명확한 문제를 파악하지 못한 경우, 응용 프로그램의 각 계층에 어떤 증후가 있는지 응용 프로그램 흐름을 이용해 클라이언트로부터 시작해 찾아 들어가야 한다. SQL 서버 쪽으로 증후 데이터 수집이 진행될수록 문제가있는지를 파악하여 고립화할 수 있을 것이다. SQL 서버 자체에서 문제가 발생했다는 것을 확신할 경우에만 다음 흐름도로 이동하기 바란다.

데이터 계층 흐름도(The Data Tier Flowchart)

데이터 계층 흐름도 (그림 7.2)는 '이 시스템 환경에서 응용 프로그램이 제대로 동작한 적이 있는가?"라는 질문으로부터 시작한다. 이 질문에 대한 답변은 어떤 종류의 문제해결 과정이 이루어져야 하는지를 결정하게 될 것이다. 만약 응용 프로그램이 이전에는 잘 동작하였고 최근에 들어서서 문제를 야기했다면, 이 흐름도는 모두 건너뛰어도 좋을 것이다.

그러나, 응용 프로그램이 이 시스템 환경에서 제대로 동작하지 않았었다면, 이런 상태를 야기할 수 있는 응용 프로그램의 배포 과정에 대해 좀더 조사해 볼 필요가 있다. 데이터 계층 흐름도는 이 문제의 원인이 될 수 있는 배포 과정에 대해 조사할 수 있도록 도와준다. 기본적인 목표는 개발, 테스트 그리고 제품화 과정에서 발생할 수 있는 변이를 추적하여 파악하는 것이다.

드러나는 증상과 관련이 깊은 변이가 그 과정에서 나타났다면 그 변이를 없애는 것만으로도 문제를 해소할 수 있을 것이다. 이러한 과정의 숙지는 향후에도 일어날 수 있는 문제를 미연에 예방할 수 있어 배포 과정을 좀더 완벽하게 만들어 나가도록 한다. 잘 알려진 시스템 환경에서도 문제가 해소되지 않을 시에는 다음 흐름도로 넘어가야 한다.

데이터 계층 오퍼레이션 흐름도(Data Tier Operations Flowchart)

데이터 계층 오퍼레이션 흐름도는 장애 관리 프로세스 중 마지막 단계이다. 이 흐름도는 SQL 서버 조작에 중점을 두고 있다. 이를 통해 문제가 잘못된 설정 변경이나 SQL 서버 기반 응용 프로그램의 7가지 통상적인 문제(common problem area) 영역에서 비롯되었는지 판단할 수 있다. SQL 서버의 통상적인 문제 영역을 살펴보면, 이 흐름도가 계층 2의 분석(Tier 2 analysis )을 기반으로 하고 있음을 알 수 있다. 계층 2의 분석은 다음과 같은 세가지 타입의 심층분석을 포함한다.

계층 2 분석은 증상 데이터를 수집하고 난 다음 단계, 즉 그 데이터를 이용하여 실제 문제 해결에 도움이 되도록 만드는 바로 그 단계이다. 프로필러를 이용하면, SQL 서버의 모든 동작을 모니터링 함으로써 문제를 야기할만한 소지를 특정 쿼리문으로 제한하고 고립화할 수 있게 된다. 일단 문제가 될만한 쿼리를 발견하면, 쿼리 분석기의 실행 계획을 이용하여 좀더 깊은 조사가 가능해진다. 여타의 추적 도구들도 해당 시스템에서 일어나는 문제를 고립화할 수 있는 향상된 기능을 제공한다.

그림 7.3 데이터 계층 오퍼레이션 흐름도

계층 2의 분석을 수행하는 것은 아주 시간이 많이 걸리는 작업이지만, 그만한 값어치가 있다. 문제요인을 고립하고 문제의 범위를 정확하게 규정하는 것이 손에 익으면, 문제를 해결할 수 있는 솔루션을 제시하는데 확실한 도움이 될 것이다.

데이터 계층 오퍼레이션 흐름도는 선행 흐름도의 흐름을 따르다가 그 흐름도로 넘어갈 것을 제시 받았을 때에만 착수해야 한다는 점을 명심해야 한다. SQL 서버로 문제 요인을 집중시키기 전까지는, 클라이언트와 중간 계층에서 문제 소지가 전혀 없다는 것을 확실히 해야 하는 것이다. 또한 최근에 설치된 응용 프로그램의 경우에는 우선 설치 과정에서 일어날 수 있는 문제 요인을 점검해보아야 한다는 것도 잊지 말자. 앞서 제시한 프로세스를 처음부터 단계를 정확히 밟아야 한다. 즉 응용 프로그램 흐름도부터- 모든 가능한 문제요인들을 순서대로 제대로 점검한다.

문제요인 관리 (MANAGEMENT)

응용 프로그램 문제요인을 관리하는 프로세스는 독립된 구성부분의 서로 다른 레벨?이 올바른 방법론에 입각하여 작업에 동참하기를 원할 것??의 응용 프로그램 계층에서 수집되기를 원여, 단계 단계의 프로세스를 정립하였으며, 이 모든 것들이 총체적으로 문제요인 관리 방법론을 형성하게 되는 것이다.

용어

증후 혹은 증상(symptom)란 응용 프로그램의 정상적인 조작에서는 나타나지 않는 동작, 메시지, 오류 등을 말한다. 문제요인(problem)이란 증후를 야기시키는 코드, 시스템 설정이나 데이터 등을 말한다. 문제요인 관리에 있어 어려운 것은 제시되는 증후들을 그 증후를 야기하는 문제요인과 연관 짓는데 있다. 일단 문제요인이 발견되고 나면 거기서부터는 선택하여 적용할 수 있는 많은 솔루션들이 기다리고 있는 것이다. 문제를 해결하지 못하고 지연시키는 원인은 다름이 아니라 잘못된 문제요인 진단에 있다. 잘못된 문제요인 진단은 그것을 기반으로 이루어진 이후의 스텝들 때문에 더욱 더 문제를 악화시킬 수 있다.

상위레벨 프로세스

상위 단계에서의 문제 해결 과정은 다음과 같다.

분석 과정

일단 문제요인 관리 프로세스에서는 문제요인을 발견하고 고립화하는 것이 가장 중요하다. 만약 증상이 SQL 서버로 귀착되는 것이라면, 문제되는 동작을 분석할 수 있는 최상의 툴은 프로필러이다. 다음은 문제를 발견하고 고립화하기 위한 프로필러 사용에 대한 내용이다:

1. [SQL 서버 프로그램 메뉴]에서 [프로필러] 를 선택.

2. [프로필러] 화면에서 [파일] > [새로 만들기] > [추적] 을 선택

3. 해당 SQL 서버로 로그온

4. [일반 탭]에서 [추적 이름]을 설정, [파일에 저장] 을 선택하고 [파일 롤오버 사용]을 사용하지 않도록 설정

그림 7.x 추적 속성 설정

5. [이벤트 탭]에서 [선택한 이벤트 클래스] 모두를 없애고 다음을 이벤트를 [선택한 이벤트 클래스]에 추가한다.

6. [데이터 열 탭]에서 다음을 [선택한 데이터]로 추가:

7. [필터 탭]에서 [DatabaseName]을 선택, [유사]를 클릭한 다음, 해당 SQL 서버의 이름을 기입

8. [실행] 버튼을 누르고, 추적을 시작한다. 만약 충분한 데이터를 수집 했다면, 붉은 색의 멈춤 아이콘을 눌러 중지한다.

9. 트레이스를 통해 수집한 결과를 분석해보자. 클라이언트의 작동 중에 발생한 오류는 없었는가? 면밀히 검토해야 할 트레이스 결과는 너무 많기 때문에 문제를 일으킬 소지가 있는 코드가 실행될 때 일어난 결과들에 초점을 맞추도록 하자. 만약 찾고자 하는 SQL 문장을 정확히 알고 있다면, 프로필러가 제공하는 검색 기능을 통해 해당 문장을 쉽게 찾아낼 수 있을 것이다. 트레이스의 첫 번째 행을 클릭하고 나서 [ 편집]에서 [찾기]를 눌러 검색한다.

찾고자 하는 문장의 몇 단어를 [검색 값]에 넣고, [데이터 열]에서는 [텍스트 데이터]를 드롭다운 박스에서 선택하여 [다음 찾기]를 누른다. 그러면 프로필러가 발견한 첫 번째 문장부터 보여줄 것이다.

문제해결 vs 장애조치(Problem Management Versus Incident Management)

장애를 조치하는 어떤 순간에 문제가 감쪽같이 사라지는 경우가 있을 수 있다. 이런 경우는 대부분 시스템 부하와 관련한 문제들로써 사용 시스템의 부하가 경감될 경우, 문제가 되는 증상은 사라질 것이다.

이런 경우에는 앞서 밝힌 문제요인 관리 프로세스를 계속 해 나가기가 힘들다. 실제 시스템 환경에 어떤 변화를 주지 않으면서 시스템 부하를 재현할 방법이 없다면, 더 이상 증상 데이터를 수집할 수 없게 된다. 이렇게 고칠 증상이??한지도 측정하기가 매우 어려워진다. 이러한 상황에서는, 장애 조치 접근법으로 전환할 필요가 있다. 장애 조치 접근법은 문제요인 관리를 통한 접근법보다 훨씬 더 간단하다. 장애 조치 접근법을 이용하면 장애로부터 야기되는 피해를 단순히 줄일 수는 있다. 일반적으로 취할 수 있는 조치는 잠시 멈춰버린 서버를 리부트하는 것만큼이나 간단한 것이다. 아니면 이전에 증상이 발생하지 않았던 시스템의 상?? 있을 것이다.

하지만, 문제요인을 파악하여 고치겠다는 생각으로 문제에 접근하면 훨씬 더 좋은 결과를 얻을 것이다. 근시안적으로 현재 문제가 되는 장애만을 어??의미해질 것이다. 시스템 상황이 계속적으로 예측할 수 없게 변화하여 문제요인 관리를 통한 접근법보다는 장애 조치를 통한 접근법이 타당하다고 생각된다면, 장애는 일단 조치하고, 테스트 환경을 별도로 구축하여, 부하 관리 툴을 가지고 문제요인을 파악하는 작업을 계속 진행하는 것이 최선책이다.

데이터베이스 문제로 오인하기 쉬한 문제들

문제요인 관리 방법론의 목표 중의 하나는 응용 프로그램의 문제로부터 데이터베이스 문제를 격리하는 것이다. 이 섹션에서는 흔히들 데이터베이스의 문제로 오진하기 쉬운 두 가지 문제영역을 다루고자 한다. 이 문제들의 성격을 제대로 파악해놓으면 나중에 이런 문제가 나타나더라도 쉽게 파악할 수 있을 것이다.

데이터베이스 접속

데이터베이스 접속(Connectivity)은, 클라이언트에서 데이터 계층으로 접근하기 위하여 다양한 테크놀러지가 사용되기 때문에, 응용 프로그램 구성요소 중에서 가장 해결하기 힘든 문제 중 하나다. 클라이언트가 액세스 할 수 없다면 데이터베이스 접속의 문제라는 것은 아주 명확하다. 그러나 데이터베이스 접속 문제의 원인을 규명하는 것은 매우 어려울 수 있다.

문제 해결의 첫 단계는 더 이상 지원하지 않는 테크놀러지를 데이터베이스 접속에 쓰지 않는 것이다. 만약 클라이언트가 SQL 서버에 접근하기 위해 RDO나 dblib을 이용한다면, 문제는 십중팔구 이런 연결방법이 호환되지 않기 때문일 것이다. 여건이 허락한다면 현재 지원되는 연결 방법으로 교체하고서 응용 프로그램 접속을 테스트해보도록 하자.

다음 단계는 데이터 액세스 계층에서 지원하는 메커니즘이 아니라 응용 프로그램 혹은 클라이언트 단에서 직접 SQL서버로 접속해 보는 것이다. 이 방법으로 서버가 응답을 하고 있는지 아닌지를 확인할 수 있다. SQL 서버로 ping 커맨드라인 명령을 내렸는데도 반응이 없다면 네트워크나 DNS에 문제가 있는 것이다. Ping 커맨드 라인 명령은 수행되었지만 쿼리 분석기를 열어 해당 서버로 세션을 열 수 없다면, SQL 서비스에 문제가 있는 것이다. 쿼리 분석기로 해당 서버와 연결이 된다는 것은 그 세션을 통해 응용 프로그램의 접속 요청도 처리되는 것을 의미하기 때문이다. 쿼리 분석기를 통해 데이터베이스 접속을 테스트할 때는 응용 프로그램이 쓰고 있는 네트워크 라이브러리를 가지고 테스트가 이루어져야 한다.

그 다음으로 응용 프로그램이 사용하고 있는 보안증명이 제대로 되어 있는지를 점검해야 한다. 로그인 아이디와 암호는 유효한가? 쿼리 분석기 세션을 해당 보안증명을 가지고 열었다면, 보안 증명은 더 이상 문제요인이 될 수 없다.

다음으로 응용 프로그램이 데이터 액세스 계층에서 일어날 수 있는 접속 오류를 제대로 처리하고 있는지를 확인해봐야 한다. ADO(ActiveX?? Data Objects)를 사용할 때는 시스템 모니터에서 제공하는 Connection 객체의 Errors 컬렉션을 점검해보자. 데이터 액세스 계층에서 제공되는 오류들은 데이터 접속 문제에 관해 가장 쓸만한 실마리를 제공하기 때문이다.

접속 문제에 있어 또 다른 문제 양상은 응용 프로그램이 SQL 서버로 연결은 되지만, 데이터베이스와의 커넥션을 응용 프로그램에서 이용할 수 없는 경우이다(이것은 보통 클라이언트의 잘못된 코드에 의해 비롯된다). 엔터프라이즈 관리자에서 관리, 현재 동작, 프로세스 정보를 열어보면, 문제가 코드 문제인지 아닌지 금방 알 수 있다. 호스트 컬럼에서 클라이언트의 이름이 보인다면(물론 클라이언트에서 응용 프로그램을 제외한 다른 프로세스가 접속을 하고 있지 않다면), 클라이언트는 SQL 서버에 제대로 접속하여 있는 것이다. 프로세스 정보의 해당 클라이언트 프로세스를 더블 클릭해보면, [마지막 TSQL 명령 일괄 처리]를 볼 수 있다. 이것은 클라이언트가 쿼리를 던졌다면, SQL 서버에 어떤 쿼리를 던졌는지를 보여준다. [현재 동작]에서 [새로 고침]을 하면 가장 최근의 쿼리를 볼 수 있다.

프로필러를 이용, 해당 클라이언트 이외의 호스트는 모두 제외시켜 클라이언트가 제대로 쿼리를 보내는지 확인할 수 있다. 쿼리를 보내고 있다면, 데이터베이스의 접속 문제는 더 이상 아니다.

마지막으로 데이터베이스 접속 문제의 양상은 서버 사이드 커서를 과도하게 사용하는 경우이다. 대량 레코드 집합을 처리하기 위하여 클라이언트 사이드에서 커서를 만들지 않았다면, SQL 서버가 직접 커서를 관리하게 된다. 대량의 레코드인데다 업데이트가 가능하도록 잠금(lock)까지 걸어놓은 커서를 SQL 서버가 관리하면 대규모의 잠금 현상이 SQL 서버에서 발생할 것이다. 물론 이것은 SQL 서버에서 일어나는 것이긴 하지만, 데이터베이스 접속 문제인 것은 확실하다. 클라이언트의 접속이 느린 연결을 이용하고 있다면 걸어 놓은 잠금을 제때에 맞추어 풀지 못할 것이다. 또한 세션을 끊지 않고서 응용 프로그램 사용자가 사용자 인터페이스를 통해 작업하고 있다면, 세션은 계속 연결되어 있을 것이고 잠금 역시 계속 남아 있게 된다. 이러한 문제는 커서 선언문에서 클라이언트 사이드 커서를 만들어 버리면 쉽게 해결 할 수 있다. 이렇게 하면SQL 서버는 레코드셋에 대한 최초 요청이 있을 때, 네트워크를 통해 해당 레코드셋 전체를 클라이언트로 전송한다. 이 때부터는 커서를 SQL 서버가 아니라 클라이언트가 관리하게 되는 것이다.

클러스터링

윈도우 2000에서의 클러스터 관리와 MSSQL의 장애조치 클러스터에 관해서는 정말로 많은 문서들이 있다. 그러나, 문제해결을 목적으로 할 경우에는 단지 이러한 클러스터 기술에 대한 아주 일반적인 사항만 알면 된다. 반드시 이해해야 하는 가장 기본적인 개념은?스탠드-어론 리스타트(stand-alone restart)이다

클러스터는 자동화된 장애조치 (failover) 시스템을 제공하는 것이다. 응용 프로그램의 입장에서 본다면, 이것은, 본질적으로 일련의 리스타트 과정의 연속인 것이다. SQL서버는 실패한 트랜잭션의 완료도에 따라 로그에 있는 트랜잭션을?전행 복구(fail forward)혹은?후행 복구(fail back)로 리스타트한다. 메모리에 있는 트랜잭션도 다를 것이 없다. 제 아무리 장애조치가 아주 즉각적이고 빈틈없이 수행되었다 하더라도 말이다. 클러스터를 이용하여 최대의 효과를 보기 위해서는 응용 프로그램은 이러한 리스타트 동작을 제대로 처리할 수 있어야 한다.

대부분의 웹 기반 응용 프로그램들은 클러스터 환경에서 문제가 될 것이 없다. 액세스가 잦은 경우, 상태 정보가 표 단위로 저장되거나 혹은 쿠키나 URL 문자열에 실리는 경우, 클라이언트 커서를 쓰는 경우 등은 앞서 말한 리스타트가 성능에 영향을 전혀 미치지 않는다. 만에 하나, 데이터 페이지가 한참 클라이언트 쪽으로 공급되고 있는 순간, 리스타트가 일어났고, 끊어진 데이터베이스 연결로 해서 클라이언트가 더 이상 데이터 페이지를?터 페이지를 없애고 새로운 페이지를 새로운 접속을 통해 얻으면 되는 것이다.

그러나, 만약 응용 프로그램이 SQL 서버와의 연결을 잃은 다음, 재 접속할 수 없다면, 응용 프로그램은 위의 리스타트 과정을 견뎌낼?을 이용하여 SQL 서버에 접속할 경우, 일단 그 커넥션이 더 이상 유효하지 않다면 서버와의 재 접속은 이루어질 수 없는 것이다. 이럴 때는 유효하지 않은 접속을 커넥션 풀에??을 맺으면 될 것이다.

클러스터가 문제의 요인인지를 판단하는 가장 좋은 방법은 액티브 노드를 클러스터에서 빼고 클러스터 서비스를 내린 후, 이전의 액티브 노드에 직접 접속해보는 것이다. 이렇게 접속하려면 더 이상 클러스터의 가상 서버로 접속하는 것이 아니므로 응용 프로그램에서 새로운 서버를 지정해야 할 것이다. 응용 프로그램을 그렇게 설정한 후, 이전에 있었던 증상이 계속 나타나는지를 확인해보자. 증상이 없어졌다면, 해당 시스템의 문제는 응용 프로그램의 문제라기 보다는 클러스터와의 관계 때문에 생긴 것이다.

요약

지금까지 문제를 고립화하고 해결하기 위한 전략에 대해 소개하였다. 그렇다면 어떻게 그런 문제들이 일어나는 것을 막을 수 있을까? 현재 직면한 문제를 분석하는 과정에서 문제의 소지를 다분히 안고 있는 데이터베이스 조작 과정을 발견할 수 있을 것이다. 이러한 문제점들에 관해 체득한 지식을 가지고 회사 전체로 현 관리기법에서의 개선점이나 좀더 나은 관리기법을 전파해야 한다. 이것이 바로 현재의 문제를 해결하고 취해야 하는 다음 스텝이다. 이렇게 회사 전체의 관리기법이 성숙되어 나가도록 함으로써 오랜 시간 동안 장애가 발생하지 않도록 할 수 있다.