완전한 문제 설명을 생성하려면 다음 질문을 해결하십시오.
    - 어떤 상황에서 프로세스가 충돌합니까? 이 동작은 일관성이 있습니까?
    - 이전에 이 작업이 더 잘 작동했습니까?
    - 발생 시간 및 관찰된 동작 추세
- 백업 환경이나 백업 또는 특정 유형의 백업 그룹에 부하가 많을 때만 문제가 발생합니까?
    - 문제가 처음 발생한 시기 그때 무엇이 바뀌었습니까?
    - 문제의 범위(모든 클라이언트/일부 클라이언트, 모든 백업 대상 또는 일부)
- 지금까지 수정하려고 시도한 내용과 이를 통해 도출된 결론.

     - 응답하지 않는 NetWorker 프로세스 및 시스템(서버, 스토리지 노드 또는 클라이언트)
     - NetWorker Server 버전 및 플랫폼
- 백업 데이터 영역
의 크기 및 특성 개요 - 이러한 백업용 타겟 미디어

      - 온라인 NetWorker 호환성 가이드를 사용하여 모든 구성 요소(NetWorker Server, 파일 시스템 버전, 프록시, 스토리지 노드, 클라이언트, 타겟)가 지원되는지 확인합니다.
      - 프로세스 충돌(디스크 오류, 디스크 가득 참, 네트워크 오류 등)을 설명할 수 있는 기본 운영 체제 또는 하드웨어 결함이 없는지 확인합니다.

      NetWorker 성능 최적화 계획 가이드에는 최적의 NetWorker 환경을 만들기 위해 구현해야 하는 몇 가지 권장 소프트웨어 및 하드웨어 요구 사항과 권장 사항이 포함되어 있습니다. 이 데이터 존에 대한 모범 사례를 따르고 있는지 확인하기 위해 이를 검토해야 합니다. 이는 부하가 가장 많을 때 응답하지 않는 프로세스가 발생하는 경우와 관련이 있습니다.

       프로세스가 응답하지 않는 문제의 근본 원인을 찾는 방법은 1단계에서 정의한 동작에 따라 달라집니다. 트리거를 알 수 없는 경우 테스트를 수행하여 충돌을 유발하는 원인을 규명할 수 있습니다.

    - 과부하
상태에서 시스템 성능 모니터링 - 충돌 시 운영 체제 로그 파일에서 동작
의 공통성을 검사합니다. - NetWorker 스케줄을 읽고 특정 NetWorker 스케줄이 지정된 활동과 발생 시간 간에 상관 관계가 있는지 확인합니다.
    - 이 시스템에서 실행되는 비 NetWorker 작업 중 동작에 영향을 줄 수 있는 작업과 해당 스케줄이 충돌 시간과 상관 관계가 있는지 확인합니다.
    - 충돌이 지속적으로 발생하는 경우 일부 매개 변수를 변경하여 원인을 좁히십시오.  다른 타겟 미디어에 백업하거나 동일한 NetWorker Client에서 서로 다른 유형의 데이터를 백업하는 경우를 예로 들 수 있습니다

coredump는 일반적으로 프로그램이 비정상적으로 종료되었을 때 특정 시간에 프로세스의 작업 메모리 덤프를 나타내는 특수 파일입니다.  코어 덤프 파일은 충돌 시 실행 중이던 프로세스의 기능과 액세스 중이던 데이터를 분석하여 응답하지 않는 프로세스의 이유를 진단하는 데 사용할 수 있습니다.

대부분의 운영 체제는 코어 덤프 파일을 자동으로 생성하지 않습니다.  프로세스 충돌 시 코어 덤프 파일이 생성되도록 운영 체제 매개변수를 수정해야 합니다.  이 수정은 충돌 전에 수행해야 합니다.

1) /nsr/cores 디렉토리에서 unix 또는 Linux에서 NetWorker 프로세스의 최근 코어 덤프를 확인하거나 Windows 레지스트리에 정의된 crash 디렉토리를 확인합니다(2단계 참조).

2) 없는 경우 프로세스 충돌이 있는 경우 운영 체제가 코어 덤프 파일을 생성하도록 설정되어 있는지 확인합니다.  자세한 내용은 운영 체제 설명서를 참조하시기 바랍니다만, 간단히 말해서 여기에는 Linux 또는 UNIX에서 ulimit -c 및 -f 값을 변경하고 Windows에서 레지스트리를 변경하는 작업이 포함될 수 있습니다.

Windows 2008R2의 경우:  
- http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx에 제공된 새 키로 레지스트리를 업데이트합니다.
- 권장 값을 사용하면 C:\Users\Administrator\AppData\Local\CrashDumps
- 전체 크래시 덤프를 활성화합니다.

3) 코어 파일은 호스트 머신 자체에서 검사하거나 다른 머신에서 분석하기 위해 패키징할 수 있습니다.  이러한 코어 파일을 패키징하는 방법에 대한 자세한 내용은 UNIX

및 Linux 코어 파일 패키징:
489272에서 확인할 수 있습니다. 코어/크래시 덤프 정보 및 관련 로그를

수집하는 방법Windows의 경우 다음 지침을 따르십시오.198564
: Windows

에서 멈춘 프로세스에 대한 커널 및 사용자 덤프를 수집하는 방법 4) 사용 가능한 데이터 분석: - 운영 체제 로그 파일
-

NetWorker Server 및 관련 스토리지 노드의 NetWorker 데몬 로그 파일.           
- 코어 파일 또는 충돌 파일

: 코어 파일을 자세히 분석하려면 NetWorker 내부 작업에 대한 고급 지식이 필요하며 EMC NetWorker 지원 부서에서 수행해야 합니다.  그러나 core 파일의 초기 읽기를 수행하여 core 파일의 내용을 알려진 문제와 비교할 수 있습니다.

Linux 및 HP-UX
gdb [프로세스의 전체 경로] [코어 파일]
(gdb) 여기서

AIX
dbx [프로세스의 전체 경로] [코어 파일]
(dbx) where

Solaris
pstack [코어 파일]
dbx [프로세스의 전체 경로] [코어 파일]
(dbx) where

Windows
- windbg Windows 디버거 프로그램
시작- 파일을 클릭하고 windbg에서 덤프 파일을 엽니다.
- 아래쪽 명령 창에 analyze --v를 입력하여 전체 정보를 검색합니다.
    
5) 시스템 동작에 대한 위의 분석 및 지식을 바탕으로 인시던트를 최신 버전의 NetWorker 릴리스 노트에 자세히 설명된 알려진 문제 목록과 비교할 수 있습니다.

응답하지 않는 프로세스의 원인이 되는 NetWorker 소프트웨어 결함이 있다고 의심되는 경우 충돌 파일을 패키지화하고(3단계 참조) 문제를 자세히 분석할 수 있도록 관찰된 동작에 대한 전체 설명을 Dell Technologies NetWorker 지원 팀에 제공해야 합니다.