Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 7건
  Cluster의 Disk 접근 문제 
작성일시 : 2008.10.17 11:39 | 분류 : Windows Server/Cluster | 태그 : 1034, clusdb, clussvc, Cluster, connection problem, Disk, mscs, problem, Signature

클러스터를 운영하는 중에 ClusSvc 에 1034 이벤트와 함께 DISK를 찾을 수 없다는 문제가 발생하는 경우가 있습니다.

cluster가 Disk에 접근 하기 까지는 아래와 같은 큐를 통과해야 합니다.
이 큐의 각 구성요소 중 하나라도 문제가 있게 되면 클러스터는 디스크를 찾을 수 없게 됩니다.

---------------------------------------------------------------------
Cluster APP (가칭 :클러스터의 소프트웨어 모듈을 가르킴)
---------------------------------------------------------------------
ClusDisk (Disk 장치의 필터 디바이스로 Ownership 관리)
---------------------------------------------------------------------
HBA 관련 모듈 (장치 드라이버를 비롯한 소프트웨어 모듈)
---------------------------------------------------------------------
HBA 카드
---------------------------------------------------------------------
Cable
---------------------------------------------------------------------
SAN Switch
---------------------------------------------------------------------
Cable
---------------------------------------------------------------------
Controller
---------------------------------------------------------------------
Disk
---------------------------------------------------------------------

1. Cluster APP
Cluster는 Disk를 확인 하기 위해 Signature 를 이용합니다.
이 Signature는 Disk의 MBR에 기록 되고, 서버에서는 자신의 레지스트리에 저장된 Signature 정보를 통해 디스크에 접근 하게 됩니다.
즉 Signature 정보에 문제가 있게 되면 Cluster는 Disk를 확인 할 수 없어 문제가 발생합니다.
해당 정보는 아래 레지스트리에서 확인 할 수 있습니다.
HKLM/System/CurrentControlSet/Services/Clusdisk/Parameters
이경우에는 dumpcfg 라는 툴을 이용해서 Disk의 MBR의 Signature를 쉽게 변경 할 수 있습니다.
참고 : http://support.microsoft.com/kb/280425

2. ClusDisk
Disk에 접근하는데 있어 최 상위 물리 계층에서 동작하는 필터 드라이버 입니다.
주요 Role은 Owner Ship 여부에 따라 디스크 접근 권한을 주거나 뺏는 역활 입니다.
Signature 에 문제가 없다면 ClusDisk 의 문제를 추정할 수 있습니다.
하지만 거의 대부분 ClusDisk의 문제는 없고 쿼럼에 접근이 않된다거나 로컬의 클러스터 정보 및 쿼럼의 정보가 손상된 경우가 대부분 입니다.
문제 판별은 http://support.microsoft.com/kb/280425 의 내용과 같이 장치 관리자에서 해당 필터 드라이버를 Disable 시킨 후 문제 여부를 확인 할 수 있습니다.
일반적으로 클러스터의 정보는 HKEY_LOCAL_MACHINE\Cluster 키 밑에 저장되어 있습니다.
그 파일은 SystemRoot%\Cluster\ClusDB 와 Q:\MSCS\Chkxxx.tmp 입니다.
즉 하나라도 정상으로 판별되는 녀석이 있다면 해당 파일로 동기화를 해주게 되면 문제가 해결 되게 됩니다.
물론 쿼럼 손상의 경우 시작 옵션에 fixquorom 을 주거나 쿼럼을 재 생성해도 문제를 해결할 수 있습니다.

3. HBA 관련 모듈
디바이스 드라이버 및 해당 드라이버를 지원하기 위한 S/W를 통칭 합니다.
즉 이 부분 부터는 장치의 문제로 볼 수 있으며 해당 장치를 fix 해주면 됩니다.

4. HBA 카드 ~ Disk
솔직히 MS만 하는 저는 뭐라 말씀 드릴 부분이 없습니다.
장치의 문제로 볼 수 있으며 해당 구간 구간에 대한 TEST가 진행 되어야 합니다.

[기타]
시작 옵션 정리
net start clussvc /NoQuorumLogging
net start clussvc /ResetQuorumLog
net start clussvc /FixQuorum

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  Clipboard Viewer Chain Problem 
작성일시 : 2008.10.08 11:51 | 분류 : Windows Server/Terminal Service | 태그 : clipboard, Clipboard Viewer Chain, Clipboard Viewer Chain Problem, problem, SBC, Share, Terminal Service, 동기화, 문제, 클립보드

최근에 Clipboard 와 관련된 문제가 있었습니다.
Windows 에서 가끔씩 Clipboard 의 내용이 공유가 않되는 경우가 있습니다.
특히 Terminal Service를 이용할 때 자주 발생하게 되는데, 이 가장 큰 이유는 RDPClip.exe의 Clipboard viewer Chain이 끈어지기 때문입니다.
그와 관련해 제 친구 동조 블로그에 좋은 글 (http://dongjo.tistory.com/102) 이 올라와서 부연 설명을 더해 드립니다.

Windows 에서 Clipboard의 내용은 각 Application 들이 각자 관리 하게 됩니다.
Clipboard를 사용하도록 선언이 되게 되면 이 App 들은 각자 Clipboard를 관리하게되며, 각 App들에서 Clipboard의 내용이 변경 되게 되면 해당 내용을 update 받게 됩니다. 이를 Clipboard viewer chain 이라 합니다.
이런 연관 관계를 Clipboard viewer chain 이라 합니다.

[Clipboard Viewer Chain의 생성]
최초로 A 라는 Clipboard를 사용 하는 app가 실행 됩니다.
-> A

B app 가 실행 됩니다.
-> B -> A

C 와 D app 가 차례로 실행 됩니다.
-> D -> C -> B -> A

[Clipboard Viewer Chain 에서 Clipboard 내용 변경]
-> D -> C -> B -> A 와 같은 체인의 B app에서 사용자가 clipboard 의 내용을 변경 합니다.
-> D -> C -> B -> A
                    ^
        clipboard 내용 변경

해당 내용의 자신의 Chain의 가장 앞 노드인 D에 알리게 되고 D는 자신과 연결된 Chain에 해당 Update 내용을 전달 하게 됩니다.

[Clipboard Viewer Chain 에서 app 종료]
-> D -> C -> B -> A 에서 B가 종료 됩니다.
-> D -> C -> A

이 경우 B의 위치에 A가 자리 하게 됩니다.
즉 B의 Windows 핸들 값을 A 값이 대체하게 됩니다.

[일반적인 문제 현상과 그 원인]
위의 예에서 B가 종료 되면서 자신의 핸들값을 A의 값으로 대체 하지 못하고, 종료 되는 경우 A는 고립이 되게 되며 clipboard의 update를 확인 할 수 없습니다.

이런 경우는 보통 B app 소스에 문제가 있는 경우 가 있습니다.
일반적으로 Windows.close 같은 함수를 이용하여 종료할 경우에는 위와 같은 문제가 발생 하지 않습니다.
하지만 process.kill 과 같은 함수를 이용할 경우 해당 kill 에 대한 예외 처리를 하지 않으면 종종 발생하는 것으로 보입니다.

아래와 같이 예외 처리를 해줍니다.
간단하게 자신의 Windows 핸들을 다음 노드의 핸들로 대체해주는 구문입니다.
그리고 WM_DESTROY는 바로 비정상 종료를 가르키는 상수 값입니다.

case WM_DESTROY:      ChangeClipboardChain(hwnd, hwndNextViewer);
     PostQuitMessage(0);
     Break;

[Terminal Service 이용시 Clipboard 공유 문제]
사용자가 Terminal 연결을 할 경우 Windows에서는 해당 사용자를 위한 세션을 생성하고 그 위에서 다양한 Terminal 환경을 위한 App 를 구동하게 됩니다.
이 중 서버와 클라이언트의 Clipboard 내용을 동기화 하게 위해서 사용하는 app가 있는데, 이 app가 RDPClip.exe 입니다.
사용자가 터미널 서버에 접속하게 되면 RDPClip.exe가 hidden Windows 를 생성하여 위에서 설명한것과 같이 clipboard를 공유하게 됩니다.
이때 중요한 것이 해당 app가 chain의 가장 첫번째 생성 노드라는 점 입니다.
즉 해당 노드 app 중 하나의 app만 정상 종료가 않되게 되는 상황이 발생하게 된다면 이 RDPChain.exe는 clipboard update 내용을 확인 할 수 없는 것입니다.

[Terminal Service 이용시 Clipboard 공유 문제 해결 방안]
근본적으로는 위에서 언급한 것과 같이 clipboard를 사용함에 있어 다양한 예외 상황에 대한 처리를 app에서 해주는 것이 좋습니다.
하지만 그게 불가능 하다면 단순하게 RDPClip.exe를 재 시작하여 문제를 해결 할 수 도 있습니다.
RDPClip.exe가 신규 노드로 추가가 된다면 당연 이전의 고립 문제는 해결이 되게 되는 것이죠.

Windows Vista 및 Windows 2008에서는 OS 차원에서 System Controlled Clipboard Chain을 제공하고 있어 위와 같은 문제가 발생 하지 않습니다.

[클립 보드 문제 해결 방법]
.

참고 및 출처
http://blogs.msdn.com/ts/archive/2006/11/16/why-does-my-shared-clipboard-not-work-part-1.aspx

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  SQL Server CPU Performance Problem 01 
작성일시 : 2008.09.22 20:00 | 분류 : SQL Server/Administration | 태그 : CPU, cpu performance, performance problem, problem, SQL Server, SQL Server 2005

원문 : http://technet.microsoft.com/en-us/magazine/cc137784.aspx

- CPU 하이퍼 쓰래딩은 일반적으로 Disable 하는 것이 좋다.

- CPU 가 DB의 Page을 읽을 때 Access 속도는 Physical Memory (RAM) 의 경우 약 0.5ms 가 Disk 일 경우 2~4ms (최적의 경우) 에서 4~10ms가 소요 된다. 결과적으로 Physical Memory의 데이터를 읽는 것이 성능상 가장 큰 이점이 있다.
설명 : Physical Memory에서 page를 read 하는 것을 soft page fault 라 하고 Disk에서 page를 읽는 것을 hard page fault 라 한다.

하나! 작업 부하 증가

%Processor Time 이 80%가 지속적으로 상회하고 있으면 CPU에 성능 로드가 있다고 봐도 무방하다. 이와 동시에 System\Processor Queue Length 를 확인해야 한다. SQL Server 는 하나의 논리 CPU에 하나의 Thread를 할당한다. 일반적으로 5배가 넘을 경우 성능에 문제가 있는 것으로 볼 수 있으며, 2배가 되더라도 성능에 문제가 있을 수 있다.

다만 해당 서버가 DBMS 외 다른 Role을 추가로 가지고 있다면 Processor Time 및 Context Switches/sec를 동시에 검토하여 서버 분산 여부를 판별 할 수 있다. 즉 Processor Time이 높고 동시에 Context Switches가 많이 발생 하게 되면 Role들 사이에 CPU 자원에 대한 경합이 일어나는 것으로 볼 수 있다. 이러한 현상이 지속적으로 발생하고 있다면 Role 분산을 통해 문제 현상을 해결 할 수 있다. 특히 Exchange 서버 Role이 동시에 운영되게 된다면 각 Role은 Physical Memory를 쓰고자 하고 이로 인해 극심한 Context Switching 동시에 Memory의 Hard Page Fault가 발생하게 된다. Context Switching운 논리 CPU 당 5000번 이상 발생 할 경우 일경우 성능에 문제를 발생 시키는 것으로 볼 수 있다.

높은 CPU 사용률과 함께 대기중인 큐가 많은 경우 SQL Server:SQL Statistics 성능 개체에 있는 Compilations/sec와 Re-Compilations/sec 카운터를 검토하는 것이 좋다. 쿼리 계획 컴파일 및 재컴파일은 CPU 사용률을 높힌다. Re-Compilations 값은 0에 가까워야 하지만, 시스템의 추세를 주의 깊게 검토하여 서버의 일반적인 동작과 정상적인 컴파일 수를 판단하는 것이 좋다. SQL Server:SQL Statistics 성능 개체에 있는 Batch Requests/sec를 검토하여 실제로 요청되는 쿼리와 해당 쿼리가 재컴파일 되는 빈도를 비교할 수 있다.

둘 ! 메모리 부족

SQLServer:Buffer Manager\Buffer Cache Hit Ratio 가 97% 미만 인 경우 메모리가 부족을 의심 할 수 있다.
또한 PLE (SQLServer:Buffer Manager\Page Life Expectancy)가 300초 미만 일 경우 해당 데이터 페이지는 자주 플러쉬 되고 있는 것으로 볼 수 있다. 다만 Checkpoint가 발생한 경우에는 버퍼 케쉬를 정상적으로 디스크에 플러쉬 함에 따라 일시적으로 PLE 값이 감소 할 수 있다.

Physical Memory (RAM)이 부족할 경우 버퍼 캐시 및 프로시저 캐시를 디스크로 플러시 해서 부족한 메모리를 확보해야 한다. 리소스 모니터는 플러쉬할 페이지를 결정하는 SQL Server 프로세스로써, RAM 부족할 경우 빈번하게 발생하게 된다. SQL Server: Buffer Manager\Lazy Writes/sec 카운터를 통해 확인 할 수 있다.

셋! 쿼리 성능

SQL Server로 새 쿼리가 제출될 때 쿼리 계획이 평가, 최적화 및 컴파일되어 프로시저 캐시에 저장된다. 서버로 쿼리가 제출될 때마다 요청과 일치하는 쿼리 계획이 있는지 확인하기 위해 프로시저 캐시가 검토된다. 일치하는 쿼리 계획이 없으면 SQL Server에서 새 쿼리 계획을 만들게 되는데 이 경우 비용이 들 수 있다.
SQLServer:Plan Cache\Cache Hit Ratio: SQL Plans 가 70% 미만인 경우 쿼리에 문제 있는 것으로 대략적인 판별은 가능하다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  Microsoft SQL Server 로그 관련 장애 해결 방법 
작성일시 : 2008.05.13 15:01 | 분류 : SQL Server/Administration | 태그 : log, Microsoft sql server 2005, opentran, problem, shrink, sqlperf, Transaction log

오랫만에 원론적인 애기를 한번 할까 합니다.
뭐 단편화된 나만의  스킬일 수 도 있고... 모두가 다들 겪는 일이지만, 종종 로그를 삭제 하기 위해 로그 백업을 받았음에도 로그가 삭제 되지 않는 경우가 있습니다.

자 왜? 그렇게 된 것일까요?
그리고 어떻게 해야 할 까요?
로그에 대한 내용은 http://maystyle.tistory.com/257 를 참조 하시기 바랍니다.

먼저 로그가 왜 안 잘리는지 확인 합니다.

dbcc opentran(DB 명)
이 명령어를 통해 활성 트랜젝션의 여부 및 크기를 확인 할 수 있습니다.
즉 활성 트랜젝션이 크면 당연히 해당 로그는 활성이기 때문에 잘리지 않는 것입니다.

그리고 해당 로그의 사용현황을 보기 의해서 dbcc sqlperf(logspace) 를 사용하시면 로그 사용 여부 및 상태를 확인 할 수 있습니다.

그리고 다른 이유가 존재 한다... 즉 이미 Dirty Page 가 된 로그가 잘리지 않고 있다면 다음 쿼리를 사용합니다.
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases
여기서 log_reuse_wait_desc 를 확인 하면 어떤 이유 때문에 사용 되지 않고 있는지 알 수 있습니다.

만약 게시 및 배포와 관련된 문제 (게시는 및 배포는 되어 있으나 구독자가 적용하지 안아 로그가 활성으로 표시되는 문제)는 게시 및 배포 삭제 후 EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1 go 를 수행하여 활성으로 표시해 주시면 됩니다.

[참고]
sp_repldone
http://msdn2.microsoft.com/ko-kr/library/ms173775.aspx
데이터베이스 미러링 모니터(상태 페이지)
http://msdn2.microsoft.com/ko-kr/library/ms365413.aspx
데이터베이스 미러링 모니터(경고 페이지)
http://msdn2.microsoft.com/ko-kr/library/ms365355.aspx

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  Exchange Database를 새 서버에 복원이 않된다. 
작성일시 : 2008.04.30 13:57 | 분류 : Exchange Server | 태그 : 904, callback, error, ese backup, Exchange 2003, problem, restore

Exchange Database를 새 서버에 복원이 않된다.

[이벤트 로그]

[해결 방법]
복원시 해당 저장소를 Dismount 시킨 이 후 각 DB의 옵션에 This database can be overwritten by a restore 를 선택한다.

[관련 문서]
http://support.microsoft.com/kb/602233/ko#top

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  성능 카운터가 숫자로만 나올때 
작성일시 : 2008.01.30 09:41 | 분류 : Windows Server/Kernel | 태그 : Performance, problem, 성능 카운터

해당 레지스트리는 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\012\Counter입니다.

간단하게 동일한 머신 및 문제 없는 머신에서 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\012\Counter 를 복사해서 문제가 생긴 머신에 불어넣어주면 됩니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  x64 기반의 SQL 에서 Oracle DB를 linked server로 추가하자 
작성일시 : 2007.12.17 01:18 | 분류 : SQL Server/Administration | 태그 : linked Oracle server, problem, SQL Server based on x64 CPU

결론만 말하겠습니다.
10g client for oracle x64 버전을 사용해야 합니다.

10g client for oracle 을 설치하면 자동으로 Provider 목록에 oracle OLEDB 가 등록 됩니다.

오라클은 원래 하위 1개 버전에 대한 연동에 대해 보장을 합니다. 즉 9i와의 연동만 지원 된다는 것이죠. 물론 외국애들 애기로는 7~9까지 Linked Server로 연결해서 문제 없었다고 합니다. 하지만 보장을 않하는 설정을 할 순 없죠...

방법은 사내의 타 Oralce DB를 경유 하는 방법 입니다.
즉 8 > 9 > MSSQL 이런 식으로 경유를 하는 거죠...

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 Prev   1   Next 

티스토리 툴바