누적 업데이트 3으로 SQL Server 2005 SP4를 실행하는 두 개의 프로덕션 SQL Server가 있습니다. 두 서버 모두 동일한 물리적 시스템에서 실행됩니다. 4 x 12 코어 CPU 및 512GB (예 GB) 램, 모든 SQL 데이터베이스 및 로그를위한 10GB iSCSI SAN 연결 드라이브를 갖춘 DELL PowerEdge R815. OS는 모든 SP 및 Windows 업데이트가 포함 된 Microsoft Windows Server 2008 R2 Enterprise 버전입니다. OS 드라이브는 3 x 72GB 2.5 "15k SAS 드라이브의 RAID 5 어레이입니다. SAN은 48 x 10K SAS 3.5"드라이브가 장착 된 Dell EqualLogic 6510이며 RAID 50으로 구성되어 있으며 2 개의 SQL Server를 위해 다양한 LUN으로 슬라이스되어 공유됩니다. Exchange 시스템과 여러 VMWare 서버와 함께.
우리는 20 개가 넘는 데이터베이스를 보유하고 있으며 그 중 11 개는 미러링 모니터 서버를 사용하여 고 가용성으로 미러링됩니다. 미러링 모니터 서버는 미러링 모니터 서비스를 제공하는 것 외에 다른 용도로 사용되는 SQL Server 인스턴스를 실행하는 저전력 시스템입니다. 가장 큰 미러링 된 데이터베이스는 450GB이며 약 100-300 개의 iops를 생성합니다. 데이터베이스 미러링 모니터는 초당 약 100kb-10mb의 현재 전송 속도와 (일반적으로) 0 밀리 초의 미러 커밋 오버 헤드를보고합니다. 미러 서버는 보안 주체를 유지하는 데 아무런 문제가 없습니다.
지속적으로 미러링 장애 조치가 발생합니다. 때로는 단일 데이터베이스가 페일 오버되고 다른 경우 거의 모든 데이터베이스가 동시에 페일 오버됩니다. 예를 들어, 어제 밤 11/11 개의 데이터베이스 장애 조치가 발생했으며 수동으로 장애 조치를 수행 할 때까지 나머지 데이터베이스에 액세스 할 수있었습니다.
문제를 식별하기 위해 몇 가지 문제 해결 단계를 거쳤지만 지금까지 문제를 해결할 수 없었습니다.
1)이 기계에는 Broadcom BCM5709C NetXtreme II 4 포트 기가비트 네트워크 어댑터가 기본 제공되어 기본 네트워크 연결로 사용되었습니다. 이후 두 시스템 모두에 Intel (R) PRO / 1000 PT 듀얼 포트 서버 어댑터를 설치하여 NIC를 문제로 제거했습니다.
2) 모든 데이터베이스에는 미러링과 관련된 데이터베이스에 대한 로그 백업과 함께 매일 밤 자동 전체 백업이 있습니다. 로그 파일 사용량이 모니터링되고 거의 15 % 이상 사용되지 않습니다. 기본 데이터베이스의 로그 파일은 125GB이며 크기는 511MB에서 1GB 사이의 159 개의 가상 로그 파일로 구성됩니다. TempDB는 자체 LUN에 있으며 24 x 2GB 파일로 구성됩니다.
3) 감시 서버의 SQL Server 로그에 다음 이외의 오류가 표시되지 않습니다. "TCP : //SQL02.DOMAIN.INET : 5022"에 대한 미러링 연결이 응답없이 30 초 후에 "Data"데이터베이스에 대해 시간 초과되었습니다. 서비스 및 네트워크 연결을 확인하십시오.
기본 및 보조 서버의 SQL Server 로그에는 미러링과 관련된 메시지가 표시됩니다.
"TCP : //SQL01.DOMAIN.INET : 5022"에 대한 미러링 연결이 응답없이 30 초 후에 "Data"데이터베이스에 대해 시간 종료되었습니다. 서비스 및 네트워크 연결을 확인하십시오.
역할 동기화로 인해 미러 된 데이터베이스 "Data"가 역할을 "PRINCIPAL"에서 "MIRROR"로 변경하고 있습니다. 실제 메시지가 표시되는 방식이므로 동기화는 의도적으로 철자가 잘못되었습니다.
장애 조치 (failover)로 인해 미러 된 데이터베이스 "Data"가 역할을 "PRINCIPAL"에서 "MIRROR"로 변경하고 있습니다.
파트너의 페일 오버로 인해 미러 된 데이터베이스 "Data"가 역할을 "MIRROR"에서 "PRINCIPAL"로 변경하고 있습니다.
SQL Server 서비스가 계속 실행되고 네트워크 연결이 계속 유지되는 것 같습니다. 우리는 각 서버 (단일 데이터베이스의 서비스 브로커 큐에 연결되는 주로 로봇 응용 프로그램)에 연결된 500에서 2500 사이의 세션을 가지고 있습니다.
4) NET SH 구문을 사용하면 TCP Chimney 및 RSS 등이 비활성화됩니다.
5) 두 컴퓨터 모두에 대해 SQL Server 2005 Best Practices Analyzer를 실행했으며 가끔 발생하는 응용 프로그램 이벤트 로그 오류 833 이외의 다른 것을 찾지 못했습니다.
SQL Server에서 데이터베이스 [Data] (9)의 파일 [F : \ Data.MDF]에서 15 초 이상 걸리는 I / O 요청이 1 회 발생했습니다. OS 파일 핸들은 0x00000000000010A0입니다. 최신 긴 I / O의 오프셋은 0x000007d4b10000입니다.
6) 때때로 "클라이언트가 연결 풀링을 위해 재설정 된 SPID XXX의 세션을 재사용 할 수 없습니다.이 오류는 이전 작업 실패로 인한 것일 수 있습니다.이 오류 메시지 직전에 오류 로그에서 오류 작업을 확인하십시오. " 두 서버에서 생성됩니다. 문제를 나타내는 "이전"메시지가없는 것 같습니다.
7) 때때로 데이터베이스 메일이 응용 프로그램 이벤트 로그에 오류를 기록합니다.
예외 유형 : Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException 메시지 : 연결에 오류가있었습니다. 이유 : 시간 종료가 만료되었습니다. 작업을 완료하기 전에 시간이 초과되거나 서버가 응답하지 않습니다. 연결 매개 변수 : 서버 이름 : MGSQL02, 데이터베이스 이름 : msdb 데이터 : System.Collections.ListDictionaryInternal TargetSite : Void OpenConnection (Microsoft.SqlServer.Management.Common. SqlConnectionInfo) HelpLink : NULL 원본 : DatabaseMailEngine
Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci)의 StackTrace 정보 Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection (String dbServerName, String dbName, String userName, String password )에서 Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)
시간 초과로 인해 장애 조치가 발생하고 있다고 생각합니다. 이 시간 초과의 원인은 무엇입니까? 케이블 불량 또는 스위치 불량과 같은 실제 네트워크 문제가 패킷 손실과 시간 초과를 유발할 수 있지만 다른 일로 인해 시간 초과가 발생하는 원인은 무엇입니까? 블로킹? MSDB 또는 다른 일부 시스템 데이터베이스에 I / O 시간 초과가있어 미러링 장애 조치를 유발할 수 있습니까?
조언을 주셔서 감사합니다!
MSDN에는 시간 초과 메커니즘 자체에 대해 다음과 같은 내용이 있습니다 .
미러링 시간 초과 메커니즘
소프트 오류는 서버 인스턴스에서 직접 감지 할 수 없으므로 소프트 오류로 인해 서버 인스턴스가 무기한 대기 할 수 있습니다. 이를 방지하기 위해 데이터베이스 미러링은 미러링 세션의 각 서버 인스턴스를 기반으로 각 열린 연결에서 고정 간격으로 핑을 보내는 자체 시간 제한 메커니즘을 구현합니다.
연결을 열린 상태로 유지하려면 서버 인스턴스는 정의 된 시간 초과 기간에 해당 연결에서 핑을 수신하고 한 번 더 핑을 보내는 데 필요한 시간을 받아야합니다. 시간 종료 기간 동안 ping을 수신하면 연결이 여전히 열려 있고 서버 인스턴스가 통신 중임을 나타냅니다. Ping을 수신하면 서버 인스턴스는 해당 연결에서 시간 초과 카운터를 재설정합니다.
시간 초과 기간 동안 연결에서 핑이 수신되지 않으면 서버 인스턴스는 연결 시간이 초과 된 것으로 간주합니다. 서버 인스턴스는 시간 초과 연결을 닫고 세션의 상태 및 작동 모드에 따라 시간 초과 이벤트를 처리합니다.
netsh interface tcp show global 보여줍니다 :
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled
netsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510
SELECT name, value_in_use FROM sys.configurations
애드혹 분산 쿼리 0
선호도 I / O 마스크 0
선호도 마스크 0
affinity64 I / O 마스크 0
선호도 64 마스크 0
XP 요원 1
업데이트 허용 0
경외 활성화 0
차단 된 프로세스 임계 값 5
c2 감사 모드 0
clr 활성화 1
공통 기준 준수 활성화 0
병렬 처리 4에 대한 비용 임계 값
DB 간 소유권 체인 0
커서 임계 값 -1
데이터베이스 메일 XP 1
기본 전체 텍스트 언어 1033
기본 언어 0
기본 추적 사용 가능 1
트리거 0에서 결과를 허용하지 않습니다
채우기 비율 (%) 0
크롤링 대역폭 (최대) 100
크롤링 대역폭 (분) 0
ft 알림 대역폭 (최대) 100
ft 알림 대역폭 (분) 0
인덱스 생성 메모리 (KB) 0
인다 우트 xact 해상도 0
경량 풀링 0
자물쇠 0
최대 병렬 처리 수준 6
최대 전체 텍스트 크롤링 범위 4
최대 서버 메모리 (MB) 393216
최대 텍스트 해상도 크기 (B) 65536
최대 작업자 스레드 0
미디어 보존 0
쿼리 당 최소 메모리 (KB) 2048
최소 서버 메모리 (MB) 52427
중첩 트리거 1
네트워크 패킷 크기 (B) 1400
올레 자동화 절차 1
열린 객체 0
PH 시간 초과 60
사전 계산 순위 0
우선 순위 부스트 0
쿼리 관리자 비용 한계 0
쿼리 대기 -1
회복 간격 (분) 0
원격 액세스 1
원격 관리자 연결 0
원격 로그인 시간 초과 20
원격 절차 트랜스 0
원격 쿼리 시간 초과 600
복제 XP 0
시작 procs 스캔 0
서버 트리거 재귀 1
세트 작업 세트 크기 0
고급 옵션 표시 1
SMO 및 DMO XP 1
SQL 메일 XP 0
노이즈 단어 변환 0
두 자리 연도 컷오프 2049
사용자 연결 0
사용자 옵션 4216
웹 길잡이 절차 0
xp_cmdshell 1
얼마 전에 mirroring_connection_timeout문제를 해결하려고 모든 미러 된 데이터베이스 의 값을 30 초로 수동으로 수정했습니다 . 이것은 단순히 페일 오버 이벤트 사이의 시간을 증가 시켰습니다. 으로 mirroring_connection_timeout10 초의 기본값으로 설정 설정, 우리는 볼 을 많이 보다 장애 조치.
한 의견에서 IPSec이 비활성화되어 있는지 확인하라는 요청을 받았으므로 netsh운영 체제의 IPSec 구성을 표시하는 여러 명령 의 내용을 게시하고 있습니다.
C : \> netsh ipsec 동적 모두 표시 현재 할당 된 정책이 없습니다. 기본 모드 정책을 사용할 수 없습니다. 빠른 모드 정책을 사용할 수 없습니다. 일반 메인 모드 필터를 사용할 수 없습니다. 특정 주 모드 필터를 사용할 수 없습니다. 일반 빠른 모드 필터를 사용할 수 없습니다. 특정 빠른 모드 필터를 사용할 수 없습니다. IPsec 주 모드 보안 연결을 사용할 수 없습니다. IPsec 빠른 모드 보안 연결을 사용할 수 없습니다. IPsec 구성 매개 변수 ------------------------------ StrongCRLCheck : 1 IPsecexempt : 3 IPsec 통계 ---------------- 액티브 어소시에이트 : 0 오프로드 SA : 0 보류 키 : 0 키 추가 : 0 키 삭제 : 0 리키 : 0 활성 터널 : 0 불량 SPI Pkts : 0 암호화되지 않은 Pkts : 0 인증되지 않은 Pkts : 0 재생 감지 기능이있는 Pkts : 0 전송 된 기밀 바이트 : 0 받은 기밀 바이트 : 0 보낸 인증 바이트 : 0 인증 된 바이트 수신 : 0 전송 바이트 전송 : 0 받은 전송 바이트 : 0 터널에서 보낸 바이트 : 0 터널에서받은 바이트 : 0 보낸 오프로드 바이트 : 0 오프로드 된 바이트 수신 : 0 C : \> netsh ipsec 정적 모두 표시 ERR IPsec [05072] : 정책 저장소에 정책이 없음
업데이트 : 2012-12-20
이제 프로덕션 시스템을 SQL Server 2012로 옮겼습니다. 12 월 17 일 아침부터 지금까지 장애 조치가 발생하지 않았습니다. 그러나 며칠은 2005 기반 시스템에서 보았던 것입니다.
새로운 시스템의 성능을 문서화하기 위해 sys.dm_os_wait_stats보다 신중하게 살펴 보았습니다 . 그리고 DBMIRROR_DBM_EVENT문서화되지 않은 대기 유형 인 noticed 입니다. Microsoft의 Graham Kent는 예기치 않은 장애 조치 및이 대기 유형 문제 해결에 관한 흥미로운 기사 를 제공합니다. 나는 그의 발견을 여기에서 요약 할 것이다
고객은 모든 헤드 차단기가 DBMIRROR_DBM_EVENT를 기다리는 대용량 OLTP 데이터베이스에 구축 된 거대한 차단 체인을 경험했습니다. 내가 겪은 일련의 사건은 다음과 같습니다.
블로킹 체인 자체를 검토하십시오. 여기서 볼 수 있듯이 DBMIRROR_DBM_EVENT를 기다리고 있다는 것입니다.
문서화되지 않은 대기 유형의 소스를 검토하십시오. 분명히 MS 외부 에서이 작업을 수행 할 수는 없지만 쓰기 시점 에서이 대기 유형은 보안 주체가 LSN을 강화하기 위해 미러를 대기 할 때 사용되는 대기 시간을 나타냅니다. 즉, 일부 트랜잭션은 커밋 할 수 없습니다 . 이것은 즉시 주체가 미러를 기다리는 트랜잭션을 커밋 할 수 없다는 문제를 지적합니다. 이제 미러가 트랜잭션을 커밋하지 않는 이유 또는 주체가 왜 트랜잭션인지 알지 못하는지 조사해야합니다.
msdb 시스템 테이블을 검토하십시오.
(a) [backupset] 테이블을보고 문제 발생시 생성 된 로그의 크기가 정상보다 훨씬 더 큰지 확인하십시오. 그것들이 예외적으로 크면 미러가 트랜잭션으로 넘쳐서 단순히 볼륨을 따라 잡지 못할 수도 있습니다. 그렇기 때문에 인덱스 재 구축과 같이 매우 큰 로그 작업을 수행해야하는 경우 온라인 서적에서 때때로 미러링을 비활성화하도록 지시합니다. (이것이 http://technet.microsoft.com/en-us/library/cc917681.aspx 에있는 이유에 대한 참조 ). 여기에 다음 TSQL을 사용했습니다.
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(b) 둘째로 [dbm_monitor_data] 테이블의 데이터를 살펴 보았습니다. 여기서 핵심은 문제가 발생한 기간을 찾은 다음 다음 중 하나에서 중요한 변화가 있었는지 확인하는 것입니다.
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate이들은 모두 응답하지 않은 구성 요소 또는 아키텍처를 표시 할 수 있다는 점에서 (a)와 유사한 표시기입니다. 예를 들어, send_queue가 갑자기 커지기 시작하지만 re_do 큐가 커지지 않으면 프린시 펄은 로그 레코드를 미러에 보낼 수 없으므로 연결을 보거나 서비스 브로커 큐를 원할 것입니다. 실제 전송 처리.
이 특정 시나리오에서는 모든 크기의 로그 백업이 정상 크기로 진행되고 있지만 상태 변경, 전송 큐 0, 다시 실행 큐 0, 고정 전송률 및 플랫이 없다는 점에서 모든 카운터에 이상한 값이있는 것으로 나타났습니다. 재실행 속도. 이는 DBM 모니터가 문제점 기간 동안 어느 곳에서도 값을 기록 할 수 없음을 의미하므로 매우 이상합니다.
SQL Server 오류 로그를 검토하십시오. 이 경우 오류 또는 정보 메시지가 없었지만 이와 같은 다른 시나리오에서는 1400 범위의 오류가보고되는 것이 일반적이며, 예를 들어 다른 미러링 블로그의 다른 위치에서 찾을 수 있습니다. 이 오류 1413 예
기본 추적 파일을 검토하십시오.이 시나리오에서는 기본 추적이 제공되지 않았지만 모든 파트너에 대한 상태 변경 이벤트를 기록하므로 환상적인 DBM 문제점 정보 소스입니다.
이는 종종 하나 또는 모든 파트너간에 네트워크 연결이 실패한 후 파트너쉽 상태가 된 후와 같은 시나리오에 대한 훌륭한 그림을 제공합니다.
결론 :
이 특정 시나리오에서 현재 2 가지 주요 데이터 포인트가 누락되어 있지만 위의 정보에 대해서는 여전히 합리적인 가설을 세울 수 있습니다. 우리는 확실히 차단기가 모두 DBMIRROR_DBM_EVENT 대기 유형을 기다리고 있기 때문에 DBM이 활성화되어 있기 때문에 차단이 발생했다고 말할 수 있습니다. 대규모 로그 작업으로 미러를 플러딩하지 않았으며이 배포는 일반적으로이 모드에서 정상적으로 실행된다는 것을 알고 있으므로 비정상적인 대규모 작업은 제외 할 수 있습니다. 이는이 단계에서 2 개의 잠재적 후보자가 있음을 의미합니다.
일부 또는 모든 파트너 간의 연결에 하드웨어 문제가 있습니다.
미러 서버의 CPU 소진 – 단순히 리두를 따라 잡을 수 없음 – CPU 소진 자체가 SQL Server 외부 또는이 미러 파트너쉽 외부의 프로세스에서 발생할 수 있습니다.
미러링 코드 자체의 문제 (실제로이를 확인하려면 메모리 덤프가 필요합니다).
1 또는 2로 의심되는 경험을 바탕으로 항상 3에 대해 열린 마음을 유지합니다.이 문제를 자세히 살펴보기 위해 지금 더 많은 데이터를 수집하려고합니다.