오늘 아침 일찍, store.exe가 어떤 식으로든 문제를 일으켰고, 이로 인해 Exchange 서버를 다시 시작해야 했습니다. 오류나 문제 없이 온라인으로 돌아왔고, 모든 트랜잭션 로그가 성공적으로 재생되었으며, 모든 스토어가 정상적으로 마운트되었습니다. 나에게 그것은 무작위 충돌 중 하나에 불과했습니다. 그러나 우리 컨설턴트는 매장 중 하나의 부패로 인해 발생한 것으로 의심합니다. 아마도 그 사람이 나보다 훨씬 더 많은 경험을 갖고 있기 때문에 맞을 수도 있지만, 그게 요점은 아닙니다.
의심되는 오류를 수정하기 위해 그는 ESEUTIL 조각 모음(PerfectDisk를 통해)을 실행하여 오류를 수정할 계획이며, 이를 통해 존재하는 모든 오류도 수정될 것이라고 주장합니다.
내가 이해한 바에 따르면 조각 모음, 확인 및 복구는 3가지 별도 작업이며 조각 모음은 어떤 종류의 무결성 검사도 의미하지 않습니다.이 올바른지? 손상되었을 수 있는 데이터베이스에서 바로 조각 모음을 실행할 위험이 있습니까?
편집하다:
다음은 이벤트 로그의 첫 번째 오류입니다. 이는 우리가 겪고 있는 문제의 시작을 나타냅니다. 그것이 무엇을 의미하는지 아는 사람이 있나요?
Event Type: Error
Event Source: Microsoft Exchange Server
Event Category: None
Event ID: 1000
Date: 11/23/2011
Time: 8:15:47 AM
User: N/A
Computer: SERVER
Description:
Faulting application exsp.dll, version 6.5.7638.1, stamp 430e735b, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00 A.p.p.l.
0008: 69 00 63 00 61 00 74 00 i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00 i.o.n. .
0018: 46 00 61 00 69 00 6c 00 F.a.i.l.
0020: 75 00 72 00 65 00 20 00 u.r.e. .
0028: 20 00 65 00 78 00 73 00 .e.x.s.
0030: 70 00 2e 00 64 00 6c 00 p...d.l.
0038: 6c 00 20 00 36 00 2e 00 l. .6...
0040: 35 00 2e 00 37 00 36 00 5...7.6.
0048: 33 00 38 00 2e 00 31 00 3.8...1.
0050: 20 00 34 00 33 00 30 00 .4.3.0.
0058: 65 00 37 00 33 00 35 00 e.7.3.5.
0060: 62 00 20 00 69 00 6e 00 b. .i.n.
0068: 20 00 6b 00 65 00 72 00 .k.e.r.
0070: 6e 00 65 00 6c 00 33 00 n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00 2...d.l.
0080: 6c 00 20 00 35 00 2e 00 l. .5...
0088: 32 00 2e 00 33 00 37 00 2...3.7.
0090: 39 00 30 00 2e 00 34 00 9.0...4.
0098: 34 00 38 00 30 00 20 00 4.8.0. .
00a0: 34 00 39 00 63 00 35 00 4.9.c.5.
00a8: 31 00 66 00 30 00 61 00 1.f.0.a.
00b0: 20 00 66 00 44 00 65 00 .f.D.e.
00b8: 62 00 75 00 67 00 20 00 b.u.g. .
00c0: 30 00 20 00 61 00 74 00 0. .a.t.
00c8: 20 00 6f 00 66 00 66 00 .o.f.f.
00d0: 73 00 65 00 74 00 20 00 s.e.t. .
00d8: 30 00 30 00 30 00 30 00 0.0.0.0.
00e0: 62 00 65 00 66 00 37 00 b.e.f.7.
00e8: 0d 00 0a 00 ....
답변1
eseutil데이터베이스에서 페이지 수준 손상이 발생하면 오프라인 조각 모음이 실패합니다. /p손상된 페이지를 삭제하려면 옵션(rePair)을 사용해야 합니다 .
논리적 수준의 데이터 손상(데이터베이스의 "구조"가 아닌 데이터베이스의 "데이터" 손상이라고 생각함)은 에서 복구할 수 없습니다 eseutil. 이 isinteg도구는 2007까지의 Exchange 버전에서 데이터베이스의 논리적 불일치를 찾을 수 있습니다. Exchange 2010에서는 isintegcmdlet new-MailboxRepairRequest(자세한 내용은 Exchange 팀 블로그에서 확인할 수 있습니다.).
그렇게 말했는데, 나는 당신 컨설턴트의 조언이 걱정됩니다. 데이터베이스 손상을 나타내는 ESE 또는 Exchange 관련 서비스의 응용 프로그램 이벤트 로그에 이벤트가 표시됩니까? 일반적으로 Exchange는 "무작위로 충돌"하지 않으며 하드웨어 드라이버 또는 하드웨어 자체의 문제는 Exchange 문제보다 더 가능성이 높은 것으로 보입니다. 또한 로그가 문제 없이 재생되었으므로 페이지 수준 손상이 발생할 가능성은 거의 없습니다.
마지막으로, 페이지 수준 손상을 처리하는 경우 해당 손상을 정리하는 것만으로는 해결책이 아닙니다. 손상을 일으키는 근본 원인(하드웨어 결함 등)을 찾아서 제거해야 합니다. 다른 일을 하면 계속 위험에 노출될 뿐입니다.
오프라인 조각 모음 자체는 큰 위험이 아닙니다. 이전의 모든 증분 및 차등 백업은 복원할 수 없으므로 오프라인 조각 모음이 완료된 후 즉시 전체 백업을 수행해야 합니다(새 데이터베이스는 바로 새로운 데이터베이스이므로). 당연히 조각 모음 기간 동안에는 사용자가 서버에 액세스할 수 없습니다.
나는 오늘 아침에 무슨 일이 일어났는지 자세히 조사하고 근본 원인 결론(또는 적어도 가능성이 매우 높은 가설)에 도달한 후 문제를 "수정"하는 데 돈을 쓰기 시작했습니다.
최근 Exchange Server 2003 시스템이 VSS 스냅샷을 찍지 못하고 백업을 시도하는 동안 다양한 JET 오류를 보고한 사례가 있었습니다. 나는 다른 컴퓨터에 새로운 Exchange 설치를 시작하고 모든 사용자 사서함을 새 컴퓨터로 옮긴 다음 원래 서버에서 문제가 있는 데이터베이스를 삭제하고 새 데이터베이스가 생성되도록 허용하기로 결정했습니다. 몇 가지 스트레스 테스트를 수행하고 원래 서버가 제대로 작동하는지 확인한 후 모든 사서함을 다시 옮겼습니다. 귀하가 설명하는 상황에서는 해당 전략을 선호합니다(원본 Exchange Server 컴퓨터의 사서함 데이터베이스에 실제 "손상"을 나타내는 이벤트 로그 메시지가 충분히 있는 경우).
편집하다:
위에 게시한 항목은 Microsoft Search용 Exchange 공급자(Exchange 데이터베이스의 전체 텍스트 색인을 생성함)의 결함입니다. 이후에 무슨 일이 일어났는지 더 자세히 알아보고 시스템 이벤트 로그에서 이 이벤트 직전의 모든 이벤트를 확인하고 싶습니다. 서버 컴퓨터의 볼륨에 디스크 공간이 부족한 상황이 있었습니까?
답변2
ESEUTIL 조각 모음은 광범위한 Exchange 데이터베이스 복구 전용이 아닙니다. 조각 모음 기능은 압축된 새 데이터베이스 파일을 생성하여 데이터베이스의 여유 공간을 확보하고 데이터베이스 성능을 최적화하는 것입니다.
조각 모음을 실행하는 동안 불일치나 문제가 발견되면 데이터베이스에서 특정 복구를 수행할 수도 있습니다. 이는 전체 조각 모음 프로세스의 일부이며 사소한 문제를 해결할 수 있습니다.
Exchange Server 데이터베이스가 손상된 경우 먼저 ESEUTIL /mh 명령을 실행하여 데이터베이스의 전체 상태를 확인하는 것이 좋습니다. 찾았다면 데이터베이스가 더티 상태입니다. 나중에 데이터베이스 손상에 따라 ESEUTIL /P 또는 ESEUTIL /R 명령을 사용할 수 있습니다. 복구 작업을 시도하기 전에 데이터베이스를 백업했는지 확인하십시오.
적절한 복구 단계를 확인하려면 Microsoft 지원팀에 문의하는 것이 좋습니다.
다음 Microsoft 문서를 참조할 수 있습니다.