7 VTCS 문제 파악 및 해결

이 절은 무엇인가 잘못되었을 때 어떻게 해야 하는지에 대한 내용입니다. 이미 여러분은 "VTCS 대시보드 사용"에 설명된 대로 일간 작업과 "백업 복사본에서 CDS 복원"에서 설명된 대로 필요시 작업을 수행했는데도 여전히 무엇인가 제대로 되지 않고 있습니다. 여기에서는 "일반적인 문제 해결"에서 발생하는 단순한 문제부터 시작하여 문제가 발생할 때 VTCS를 정상적으로 작동하도록 하는 방법을 설명합니다.

주:

CDS 복구는 주로 HSC 작업이지만 VSM 측면도 있습니다. 자세한 내용은 "PITCOPY를 사용하여 CDS 백업"을 참조하십시오.

일반적인 문제 해결

이 문맥에서 "일반적인"은 최선을 다했음에도 불구하고 잘못될 수 있는 것을 의미합니다. 여러분이 문제에 대해 파악하는 방식은 종종 VTCS 대시보드를 다시 살펴보는 것이고, 해결 방법은 필요시 작업에 있는 경우도 있습니다.

VTV 마운트 성능 문제를 시작하기 전에 이러한 문제는 일반적으로 여러분 스스로 진단하고 해결할 수 있는 일반적인 문제입니다. 하지만 납득할 만한 노력을 한 이후에도 여전히 해결되지 않는 경우 고객 지원 센터의 도움을 요청할 수 있습니다. 추적과 같이 여기에서 다루지 않는 몇 가지 도구도 있지만, 이러한 도구는 기본적으로 오라클 고객 지원 센터의 지시에 따라서만 사용하는 것이 좋습니다.

VTV 마운트 성능 저하

VTV 마운트가 매우 느리게 또는 전혀 발생하지 않는 경우 다음을 확인하십시오.

  • 단일 VTD에서 마운트를 실패합니까? 이 문제는 대개 호스트에서 VSM이 회수할 수 없는 MVC 상주 VTV의 마운트를 요청하기 때문에 발생합니다. 이러한 경우 다음을 수행하십시오.

    • Display Queue DETail 명령을 실행하여 대기열에 있는 회수를 확인합니다. 회수가 MVC를 기다리면서 대기열에 있는 경우 다른 VTCS 프로세스에서 사용 중일 수 있으며, 이 사실은 Display Active DETail을 사용하여 확인할 수 있습니다.

    • MVC가 사용 중이 아닌 경우 다음에 HSC DISPLAY VOLUME 명령을 입력합니다. MVC가 실제로 ACS에 있습니까? 그렇지 않은 경우 MVC를 다시 입력하여 회수를 완료해야 합니다.

    • 그런 다음 VTV를 회수하기 위해 MVC를 마운트하는 데 사용할 수 있는 RTD가 있습니까? Display RTD를 입력하여 RTD 가용성을 확인합니다. 사용 가능한 RTD가 없는 경우 모든 호스트에 대해 Display를 사용하여 활성 및 대기열에 있는 프로세스를 확인합니다.

      필요한 경우 회수를 완료할 수 있도록 Cancel을 사용하여 프로세스를 취소하고 RTD를 확보합니다. Cancel을 사용하면 VTCS가 시스템 리소스나 정보에 영향을 주지 않고 프로세스 중지를 시도하므로 취소가 즉시 발생하지 않을 수 있습니다. 예를 들어, VTCS는 특정 RTD를 사용하는 프로세스를 종료하기 전에 하드웨어 시간 초과 기간을 기다릴 수 있습니다.

      주:

      상위 요청을 취소할 경우 상위 및 모든 하위 요청을 중지하게 됩니다. 하위 요청을 취소할 경우 상위 요청은 처리를 계속합니다.

      주의:

      마이그레이션 스케줄러(MIGrate 매개변수 또는 특정 프로세스 ID)와 연관된 작업을 취소할 경우 이 작업은 종료되지만, 마이그레이션 스케줄러는 다음 타이머 간격에 다른 마이그레이션 작업을 시작합니다. 하지만 migrate-to-threshold를 사용하여 현재 DBU보다 큰 값을 지정하면 자동 마이그레이션을 중지할 수 있습니다.

      팁:

      MGMTclas 명령문 IMMEDmig 매개변수를 KEEP 또는 DELETE로 설정하면 마이그레이션 처리(및 마이그레이션을 위해 RTD 사용)에 유리할 수 있으며 RTD에 대한 I/O를 증가시킬 수 있습니다.

      또한 자동 마이그레이션 작업을 각 VTSS에 대해 정의한 RTD에 대한 다른 작업(예: 회수 및 확보)과 균형을 다시 맞추기 위해 CONFIG MAXMIG 및 MINMIG 매개변수 설정을 변경할 수도 있습니다.

  • 여러 VTD에서 마운트를 실패합니까? 이러한 경우 다음을 확인하십시오.

    • Display VTD를 사용하여 VTD 상태를 확인합니다.

    • Display Active를 입력합니다. 활성 프로세스가 없는 경우 VTCS, HSC, 모든 VTSS 및 모든 통신이 정상적으로 작동 중인지 확인합니다.

    • 충분한 VTSS 공간이 있는지 확인합니다.

    • 시스템이 사용 가능한 MVC 또는 가용 MVC 공간 중에서 실행 중인지 확인합니다.

    • 낮은 AMT를 높이면 더 많은 VTV가 VTSS 공간에 상주하게 되어 가상 마운트 실패를 방지하는 데 도움이 될 수 있습니다.

  • VTD가 온라인 상태인데도 VTV 마운트를 실패하는 경우 MVS VARY 명령을 사용하여 VTD를 온라인으로 전환하고, MVS UNLOAD 명령을 사용하여 VTD를 지운 다음 HSC MOUNT 및 DISMOUNT 명령을 사용하여 작업을 재시도합니다.

마이그레이션 성능 저하

VTV 마이그레이션이 매우 느리게 발생하는 경우 다음을 확인하십시오.

  • 우선 Display MIGrate를 사용하여 다양한 마이그레이션 작업이 얼마나 좋게 또는 나쁘게 수행되는지 대략적으로 확인합니다. 상황이 더 좋아지도록 설정을 조정할 수 있습니다(예: MAXMIG/MINMIG 값 높임).

  • RTD 및 MVC의 공급이 "가상 테이프 상태 확인(일간)"에 설명된 대로 양호한 상태인지 확인합니다. 더 깊이 있게 상황을 파악하고자 하는 경우 Display Queue DETail을 사용하여 대기열에 있는 프로세스의 상태를 확인할 수도 있습니다. 많은 프로세스가 RTD를 기다리고 있고 RTD를 MVS와 공유 중인 경우 전송을 MVS에 오프라인으로 전환하고 VSM에 온라인으로 전환할 수 있습니다.

주:

JES3 환경에서는 올바른 User Exit 수정을 만들고 설치하지 않은 경우 VTV 마운트를 실패할 수 있습니다.

마이그레이션 실패

마이그레이션 성능 저하보다 좋지 않은 것이 단 한 가지 있는데, 그것은 마이그레이션이 전혀 발생하지 않는 것입니다. 다행히 VTCS는 다음 절에 설명된 대로 마이그레이션 실패에 대한 자세한 정보를 제공합니다.

메시지 개선

마이그레이션 실패에 대한 더 정확하고 자세한 정보를 제공하기 위해 메시지 SLS6700E가 다음 메시지로 대체되었습니다.

  • SLS6853E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - MVCPool poolname is not defined

  • SLS6854E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no MVCs found for specified media

  • SLS6855E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no MVCs found for specified media/SC/ACS

  • SLS6856E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no usable MVCs found for specified media/SC/ACS

  • SLS6857E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no RTDs for requested media and ACS

  • SLS6858E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - all RTDs for requested media and ACS are offline

  • SLS6859E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - unknown reason (X'xx')

또한 스토리지 클래스의 상세 정보를 제공하기 위해 이전 메시지가 표시된 이후 메시지 SLS6860I이 항상 출력됩니다. 해당하는 경우 SLS6860I은 마이그레이션 요구 사항 충족과 관련된 모든 오류도 보고합니다.

  • MVC 풀이 정의되지 않은 경우.

  • MVC 풀에 지정된 매체가 포함되지 않은 경우.

  • MVC 풀에 지정된 매체의 사용 가능 MVC가 포함되지 않은 경우.

  • VTSS/ACS에 마이그레이션 MVC를 쓰도록 정의된 적당한 RTD가 없는 경우.

  • 모든 적당한 RTD가 오프라인인 경우.

결과적으로 이제 마이그레이션 실패가 실제로 발생할 경우 더욱 자세한 정보와 해결을 위한 더욱 구체적인 권장 사항을 얻을 수 있습니다.

STORCLas 표시

표시가 STORCLas 매개변수로 개선되었습니다. 출력은 다음과 같습니다.

  • 스토리지 클래스의 특성(ACS, MVC 풀 및 매체).

  • 모든 VTSS에서 스토리지 클래스로 마이그레이션 대기 중인 VTV.

  • 마이그레이션에 사용할 MVC의 요구 사항.

  • 마이그레이션 MVC에 쓰는 데 필요한 RTD의 장치 유형.

  • 마이그레이션 요구 사항 충족과 관련된 모든 오류.

다시 말하지만, VTCS는 마이그레이션 시나리오에서 중요 요소(스토리지 클래스)에 대한 정보를 제공합니다.

MVC 풀 검증 개선

일반적인 설정 오류를 확인하도록 MVC 풀 검증이 개선되었습니다.

  • 적어도 하나의 유효한 MVC 풀이 정의되었는가? 그렇지 않은 경우 메시지 SLS6845E가 표시됩니다. 마이그레이션이 발생할 수 없으므로 VTCS 기능이 심각하게 저하됩니다. 이 메시지가 나타날 경우 알맞은 MVC 풀을 정의해야 합니다. 다음 글머리 기호 내용을 참조하십시오.

  • 기본 MVC 풀(DEFAULTPOOL)이 존재하는가? DEFAULTPOOL은 명명된 MVC 풀을 지정하지 않은 스토리지 클래스로 마이그레이션할 때 그리고 스토리지 클래스 !ERROR의 오류 상황에서 사용됩니다. DEFAULTPOOL이 존재하지 않을 경우 메시지 SLS6846W가 표시됩니다.

    STORCLAS 명령문에서 MVCPool(pool-name)을 코딩하여 스토리지 클래스로의 마이그레이션에서 특정 MVC 풀을 사용하도록 지정합니다. MVCPool(pool-name)이 코딩되지 않은 경우, VTCS는 STORCLAS를 MVCPool(DEFAULTPOOL)이 코딩된 것처럼 취급합니다.

스토리지 클래스 검증 개선

같은 맥락에서, 일반적인 설정 오류를 확인하도록 스토리지 클래스 검증이 개선되었습니다.

  • 스토리지 클래스에서 명명된 MVC 풀을 지정할 경우(STORCLAS NAME(stor-clas-name) MVCPOOL(poolname)), VTCS는 명명된 MVC 풀이 정의되었는지 확인합니다. 따라서 STORCLAS NAME(stor-clas-name) MVCPOOL(poolname)을 코딩할 경우, 명명된 MVC 풀이 존재하는지 확인하십시오. 그렇지 않은 경우 VTCS에서 메시지 SLS6848W를 표시합니다. 이 메시지가 나타날 경우 명명된 MVC 풀을 정의하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

  • 마찬가지로 스토리지 클래스에서 명명된 MVC 풀을 지정하지 않을 경우(STORCLAS NAME(stor-clas-name), VTCS는 DEFAULTPOOL이 정의되었는지 확인합니다. 따라서 STORCLAS NAME(stor-clas-name)을 코딩할 경우, 명명된 MVC 풀을 만들지 않는 적어도 하나의 MVCPOOL 명령문이 있는지 확인하십시오. 그렇지 않은 경우 VTCS에서 메시지 SLS6846W를 표시합니다. 이 메시지가 나타날 경우 명명된 MVC 풀을 만들지 않는 적어도 하나의 MVCPOOL 명령문을 코딩하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

  • 스토리지 클래스에서 MVC 매체를 지정할 경우(STORCLAS NAME(stor-clas-name) MEDIA(media-type)), VTCS는 MVC 풀에 media-type 유형의 매체가 포함되어 있는지 확인합니다(명명된 MVC 풀이 지정되지 않은 경우 DEFAULTPOOL로 간주됨). 그렇지 않은 경우 VTCS에서 메시지 SLS6849W를 표시합니다. 매체 유형이 해당하는 풀에 존재하는지 확인하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

  • 스토리지 클래스에서 ACS 및 매체 유형을 지정할 경우(STORCLAS NAME(stor-clas-name) ACS(acs-id) MEDIA(media-type)), VTCS는 지정된 매체 유형과 호환되는 지정된 ACS에 RTD가 있는지 확인합니다. 그렇지 않은 경우 VTCS에서 메시지 SLS6851W를 표시합니다. 필요한 RTD 유형이 지정된 ACS에 존재하는지 확인하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

  • 스토리지 클래스에서 특정 ACS 없이 매체 유형을 지정할 경우(STORCLAS NAME(stor-clas-name) MEDIA(media-type)), VTCS는 지정된 매체 유형과 호환되는 구성에 RTD가 있는지 확인합니다. 그렇지 않은 경우 VTCS에서 메시지 SLS6851W를 표시합니다. 필요한 RTD 유형이 구성에 존재하는지 확인하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

RTD/MVC 실패

처음에는, 매체 실패인지 드라이브 실패인지 알지 못할 수 있습니다. 즉, VTCS가 MVC에서 읽기/쓰기 오류를 감지할 경우 VTCS는 MVC를 다른 RTD로 바꿉니다. VTCS가 MVC에서 더 이상 읽기/쓰기 오류를 감지하지 못할 경우 VTCS는 첫번째 RTD에서 오류가 발생했다고 간주합니다.

메시지 SLS6662A는 RTD가 유지 관리 모드임을 나타내고, 이 상태는 Display RTD 출력에도 보고됩니다. 유지 관리 모드의 RTD는 일반적으로 오류 상태이고 하드웨어 운영 또는 서비스 담당자의 지원이 필요합니다. 복구 모드의 RTD는 초기화 중(예를 들어, 온라인으로 전환될 때)이며, 일반적으로 오류 상태가 아닙니다.

실패한 RTD를 빠르게 복구할 수 없거나 실패한 RTD가 원격 ACS에 연결된 경우 해당 RTD에 할당을 시도하지 못하도록 구성에서 RTD를 제거할 수 있습니다. RTD에 대한 RTD 명령문을 제거하고 CONFIG를 다시 실행하십시오.

주의:

듀얼 ACS 구성(두 ACS가 단일 VTSS에 연결됨)에서는 두 ACS의 모든 RTD를 오랫동안 VTSS에서 사용하지 못하도록 두지 마십시오. ACS에서 사용 가능한 RTD가 없을 경우, 해당 ACS에 대해 마이그레이션이나 회수가 발생할 수 없으며 VTSS 공간이 가득 찰 수 있습니다. 또한 이 조건으로 인해 다른 ACS에서 RTD로의 마이그레이션이 중단될 수 있습니다.

따라서 듀얼 ACS 구성에서 ACS의 모든 RTD를 오랫동안 사용하지 못하도록 해야 하는 경우 위에 설명된 대로 구성에서 RTD를 제거하십시오.

불량 MVC?

RTD 문제에 대해 위의 확인 목록을 검토했지만 해당하는 문제가 없었고, 더 많은 MVC 공간을 사용 가능하도록 만들기 위해 할 수 있는 모든 작업도 수행했으며, MVC 요약 보고서의 volser를 HSC 볼륨 보고서와 비교한 결과 MVC가 실제로 ACS에 있었습니다. 그렇지 않으면 HSC 볼륨 보고서에 나열되지 않은 모든 MVC를 다시 입력하거나 교체합니다.

실제로 매체 문제가 아닌 것 같습니다. "가상 테이프 상태 확인(일간)"에 설명된 MVC 및 VTV 보고서를 보면 어떤 종류의 매체 문제인지 알 수 있습니다. 이 절에서는 가장 분명한 MVC 비정상 문제에 대한 몇 가지 해결 방법을 설명하고 있습니다. 다음은 MVC 및 VTV 보고서에서 보고 싶지 않은 까다로운 MVC 상태 및 이에 대처하기 위한 작업 목록입니다.

BROKEN

MVC, 드라이브 또는 이 둘의 조합에 문제가 있음을 나타내는 일반적인 오류입니다. VTCS는 이 상태의 MVC를 사용하지 않으려고 시도합니다. 일반적으로 이 상태를 해결하려면 다음과 같이 하십시오.

MVC가 문제의 원인인 경우 DRAIN(EJECT) 명령을 사용하여 MVC를 서비스에서 제거합니다.

RTD가 문제의 원인인 경우 MVCMAINT 유틸리티를 사용하여 MVC 상태를 재설정합니다.

또한 BROKEN 상태에 대해 표시되는 SLS6686, SLS6687, SLS6688, SLS6690 메시지 중 하나 이상을 검토하십시오. 이러한 메시지에 대한 자세한 복구 절차는 VTCS 메시지 및 코드를 참조하십시오.

DATA CHECK

이 MVC에 대해 데이터 확인 조건이 보고되었습니다. VTCS는 이 상태의 MVC를 사용하지 않으려고 시도합니다. 이 상태를 해결하려면 다음과 같이 하십시오.

MVC의 모든 VTV가 이중화된 경우 MVC에서 Eject 옵션 없이 MVCDRain을 사용합니다. 그러면 모든 VTV가 복구되고 MVC가 서비스에서 제거됩니다.

MVC의 모든 VTV가 이중화되지 않은 경우 VTCS가 MVC를 감사합니다. 감사는 실패할 수 있습니다. 감사 후 MVCDRAIN(eject 없이)을 수행합니다. 그러면 오름차순 블록 ID 순서로 데이터 확인 영역 이전의 VTV 및 내림차순 블록 ID 순서로 데이터 확인 영역 이후의 VTV가 회수됩니다. 이 순서로 VTV를 처리하면 VTCS가 매체에서 가능한 많은 VTV를 복구하게 됩니다. 그런 다음 MVC에 여전히 남아 있는 모든 VTV에 대해 데이터를 다시 만들어야 합니다.

데이터 확인을 마쳤으면 "MVC 영구 제거"에 설명된 대로 데이터 확인 오류가 있는 MVC를 제거하고 교체합니다. 이 절차에서는 MVC를 VTCS 사용에서 제거하고 니어라인 작업에 반환하는 방법도 설명합니다.

DRAINING

MVC가 현재 배수 중이거나 실패한 MVCDRain의 주체가 되었습니다.

IN ERROR

MVC가 마운트될 때 오류가 발생했습니다.

INITIALIZED

MVC가 초기화되었습니다.

LOST - FAILED TO MOUNT

VTCS가 MVC를 마운트하려고 시도했지만 15분 시간 초과 기간 이내에 마운트가 완료되지 않았습니다. VTCS가 하드웨어 문제, HSC 문제 또는 ACS에서 제거 중인 MVC로 인해 발생할 수 있는 상황으로부터 복구를 시도하는 중입니다. VTCS는 이 상태의 MVC를 사용하지 않으려고 시도합니다.

VTCS가 LOST(ON) 상태에서 MVC의 다음 마운트를 성공적으로 수행할 경우 VTCS는 상태를 LOST(OFF)로 설정합니다.

오류의 원인을 파악하고 해결하십시오. 또한 다음 이벤트에 대해 VTCS MVCMAINT 유틸리티를 사용하여 LOST(OFF)를 설정할 수도 있습니다.

해결된 LSM 실패 또는 드라이브 오류로 인해 LOST(ON)이 설정되었습니다.

MVC가 ACS 외부에 있었고 다시 입력되었기 때문에 LOST(ON)이 설정되었습니다.

MARKED FULL

MVC가 가득 찼고 이후 마이그레이션에 대한 후보가 아닙니다.

MOUNTED

MVC가 RTD에 마운트되었습니다.

NOT-INITIALIZED

MVC가 CONFIG 유틸리티를 통해 정의되었지만 사용된 적이 없습니다.

READ ONLY

MVC가 다음 조건 중 하나로 인해 읽기 전용으로 표시되었습니다.

  • MVC가 내보내기 또는 통합 프로세스의 대상입니다. 읽기 전용 상태가 MVC를 추가 업데이트로부터 보호합니다.

  • MVC 매체가 파일 보호로 설정되었습니다. 오류를 해결하고 MVCMAINT 유틸리티를 사용하여 READONLY(OFF)를 설정하십시오.

  • VTCS가 MVC를 업데이트하도록 설정된 적절한 SAF 규칙이 MVC에 없습니다. 오류를 해결(자세한 내용은 Installing ELS의 ”Defining A Security System User ID for HSC, SMC, and VTCS” 참조)하고 MVCMAINT 유틸리티를 사용하여 READONLY(OFF)를 설정하십시오.

BEING AUDITED

MVC가 현재 감사 중이거나 실패한 감사의 주체가 되었습니다. 감사를 실패한 경우 VTCS는 마이그레이션을 위해 MVC를 사용하지 않습니다. 이 조건을 해결하려면 이 MVC에 대해 AUDIT 유틸리티를 다시 실행하십시오.

LOGICALLY EJECTED

MVC가 MVCDRain Eject의 주체가 되었거나 MVC가 RACROUTE 호출로 업데이트를 위해 추출되었습니다. MVC는 마이그레이션이나 회수를 위해 다시 사용되지 않습니다. 이 조건을 해결하려면 MVC에 대해 Eject 옵션 없이 MVCDRain을 사용하십시오.

RETIRED

MVC가 폐기되었습니다. VTCS는 MVC에서 회수하지만 MVC로 마이그레이션하지 않습니다. 가능한 빨리 MVC를 교체하십시오.

WARRANTY HAS EXPIRED

MVC의 보증이 만료되었습니다. VTCS는 계속해서 MVC를 사용합니다. MVC가 폐기됨 상태에 도달할 때 교체하기 위한 계획 수립을 시작해야 합니다.

INVALID MIR

VTCS가 RTD로부터 9x40 또는 T10000 매체에 대한 MIR(media information record)이 잘못되었음을 나타내는 상태를 수신했습니다. 잘못된 MIR로 인해 데이터에 액세스하지 못하는 것은 아니지만, 테이프의 레코드에 액세스할 때 중대한 성능 문제가 발생할 수 있습니다. MVC는 유효한 MIR 항목이 없는 테이프의 영역에서 고속 검색을 수행하지 못합니다.

VTCS는 이 조건의 MVC를 사용하지 않으려고 시도합니다. 회수의 경우, VTV가 여러 MVC에 상주한다면 VTCS는 잘못된 MIR을 가진 MVC보다 먼저 유효한 MIR을 가진 MVC를 선택합니다. VTCS는 마이그레이션이 테이프의 시작 지점에 있지 않다면 잘못된 MIR을 가진 MVC 사용을 피합니다. 테이프의 시작 지점에서 마이그레이션하면 MIR이 수정됩니다.

VTCS는 마운트 시점 또는 마운트 해제 시점에 잘못된 MIR 조건을 감지합니다. 마운트 시점에 감지하고 다른 MVC를 사용하여 작업을 완료할 수 있는 경우, VTCS는 첫번째 MVC를 마운트 해제하고 대체 MVC를 선택합니다. 단, VTCS는 대체 MVC로 전환할 수 있는 능력이 제한적이라는 사실을 기억하십시오. 즉, 마이그레이션 및 가상 마운트에 주로 사용됩니다.

잘못된 MIR을 가진 MVC의 경우, 오류의 원인(매체 또는 드라이브 문제 등)을 파악하고 오류를 해결하십시오.

잘못된 MIR을 가진 MVC를 복구하려면 INVENTRY 유틸리티를 사용하십시오. 예를 들어, MVC707을 복구하려면 다음과 같이 입력합니다.

INVENTRY MVCID(MVC707) 

데이터 확인을 사용하여 MVC 복구

이것은 일반적인 ”불량 MVC” 문제의 매우 구체적인 예이며, MVC 및 VTV 보고서에서 MVC 데이터 확인 오류를 발견할 때 필요하다는 사실을 알고 있습니다.

데이터 확인을 사용하여 MVC를 복구하려면 다음과 같이 하십시오.

  1. MVC에 대해 MVC 감사를 실행합니다.

    감사는 MVC에서 순차적으로 VTV 메타데이터를 읽으려고 시도합니다. 데이터 확인을 발견하면 감사를 실패하고, MVC는 감사 중 상태로 남겨집니다. 그러면 VTCS가 출력을 위해 이 MVC를 선택하지 못하게 됩니다.

  2. MVC에 대해 MVCDRain Eject를 실행합니다.

    그러면 모든 사용 가능한 VTV가 VTSS로 회수된 다음 오류가 없는 새 MVC로 다시 마이그레이션됩니다. 이 작업은 MVC 풀에서 MVC를 논리적으로 제거합니다.

    주:

    • MVC의 오류 상태로 인해 가능한 경우 VTCS는 대체 MVC에서 VTV를 회수합니다.

    • 오류 상태의 MVC에서 VTV를 회수해야 하는 경우(사용 가능한 다른 복사본 없음) 다음과 같이 수행됩니다.

      • 데이터 확인 영역 이전 VTV가 오름차순 블록 ID 순서로 회수됩니다.

      • 데이터 확인 영역 이후 VTV가 내림차순 블록 ID 순서로 회수됩니다.

  3. VTV를 MVC에서 복구할 수 없는지 판단합니다.

    MVC에 대한 MVC 상세 보고서를 실행합니다. VTV가 여전히 MVC에 있는 것으로 보고될 경우 이러한 VTV는 복구가 불가능합니다. 다른 방법을 사용하여 데이터를 복구해야 합니다.

  4. 다음 중 하나의 작업을 수행하여 결함이 있는 MVC를 관리합니다.

    결함이 있는 MVC를 동일한 내부/외부 레이블의 초기화된 테이프 볼륨으로 교체:

    1. 결함이 있는 MVC에 대해 HSC EJECT 명령을 입력합니다.

    2. 교체 MVC에 대해 HSC ENTER 명령을 입력합니다.

    3. 필요에 따라 테이프를 초기화합니다.

    4. 새 MVC에 대해 HSC AUDIT을 입력합니다.

    5. MVCDRAIN(EJECT 없이)을 실행하여 MVC를 MVC 풀에 반환합니다.

    시스템에서 MVC 제거:

    1. 결함이 있는 MVC에 대해 HSC EJECT 명령을 입력합니다.

    2. MVC 풀 정의를 편집하여 풀에서 결함이 있는 MVC를 제거합니다.

    3. 모든 활성 호스트에서 VT MVCDEF를 입력하여 새 MVC 풀 정의를 활성화합니다.

RTV 유틸리티 사용

RTV는 VTCS의 도움 없이 MVC에서 직접 VTV 데이터를 읽도록 설계되었으므로 RTV 유틸리티는 오라클 고객 지원 센터에 문의한 후에만 사용해야 하는 또 다른 도구입니다(예: 실제로 CDS를 손실한 경우).

RTV는 독립형 유틸리티이며, 작동 방식은 MVC에서 VTV를 읽고 VTV를 압축 해제한 다음 데이터를 단일 출력 테이프(실제 테이프 볼륨)에 기록하여 데이터를 사용자 응용 프로그램에서 읽을 수 있도록 합니다. RTV 유틸리티는 독립형 유틸리티이므로 VSM이 작동 중지되었지만 MVS 시스템은 작동 중일 때 RTV를 실행할 수 있습니다.

RTV 유틸리티로 복구 가능한 항목

RTV 유틸리티로 다음 항목을 복구할 수 있습니다.

  • 지정된 MVC에서 모든 또는 지정된 VTV. MVC에서 최신 버전의 VTV 위치를 알지 못하는 경우 VTV volser만 지정하면 RTV가 이 MVC에서 찾은 최신 버전의 VTV를 변환합니다.

  • 지정된 MVC에서 지정된 블록 ID의 VTV. LISTONLY 매개변수 목록은 VTV를 니어라인 볼륨으로 변환하기 위해 RTV 유틸리티에 입력으로 사용할 수 있는 블록 ID 값을 제공합니다. volser 및 블록 ID를 지정하면 위치 찾기 시간이 단축됩니다.

  • 지정된 MVC에서 논리 데이터 세트 번호로 지정된 VTV. volser 및 논리 데이터 세트 번호를 지정하면 volser 및 블록 ID 지정에 비해 위치 찾기 시간이 훨씬 더 길어집니다. volser 및 블록 ID를 사용하는 것이 단일 VTV에 액세스하기 위한 더 좋은 방법입니다.

주:

둘 이상의 VTV가 지정되거나 블록 ID 또는 FILEnum 매개변수가 지정되지 않은 경우 전체 MVC를 읽고 MVC 내용이 출력의 일부로 표시됩니다. 전체 MVC를 읽는 것은 가장 최근의 VTV 복사본만 압축 해제하기 위해 필요합니다.

일반적인 사용 지침  

  • 변환된 VTV를 포함하는 출력 볼륨은 개별 VTV를 포함할 수 있도록 최대 VTV 크기(400Mb, 800Mb, 2Gb, 4Gb 또는 32Gb) 이상이어야 합니다.

  • VTCS MVC 및 VTV 보고서는 RTV가 복구할 VTV 복사본을 지정하도록 하기 위한 정보를 제공합니다. RTV 유틸리티를 실행하기 전에 이러한 보고서의 최신 버전을 가지고 있는지 확인하십시오. 또한 변환할 VTV를 식별하는 데 도움이 되도록 LISTONLY 매개변수를 사용하여 MVC의 VTV 목록을 생성할 수 있습니다.

    동일 VTV의 여러 복사본이 동일하거나 서로 다른 MVC에 존재할 수 있으므로 VTV 및 MVC 보고서와 LISTONLY 목록을 면밀히 조사하여 가장 최근의 VTV 복사본을 변환하기 위해 올바른 MVC를 사용하고 있는지 확인하십시오!

  • RTV 유틸리티는 변환된 볼륨에 대한 정보로 시스템 카탈로그 또는 TMC를 업데이트하지 않으므로 이 작업은 수동으로 해야 합니다.

보안 고려 사항

  • 변환할 VTV 및 이러한 VTV를 포함하는 MVC 모두에 대한 읽기 액세스 권한을 가지고 있어야 하며, 그렇지 않으면 시스템의 보안 응용 프로그램을 실행할 수 없습니다. 또한 변환을 실패합니다.

  • APF에서 RTV 유틸리티가 라이브러리를 로드하도록 권한을 부여하는지 확인하십시오.

  • RTV는 TMS 보호를 우회하려고 시도하지 않습니다. 모든 RTV 테이프 마운트는 전체 TMS 제어로 귀속됩니다.

주:

RTV 유틸리티는 출력 장치의 테이프 표준 레이블을 재작성할 수 있어야 하고 입력 장치의 레이블 정보보다 우선할 수 있어야 하므로 테이프 볼륨에서 BLP(bypass label processing)를 호출하기 위해 동적 할당이 사용됩니다. 이를 위해서는 SWSRTV 실행 코드를 포함하는 라이브러리가 APF의 권한 부여를 받아야 합니다.

JCL 예

다음은 RTV 유틸리티를 사용하는 JCL 예를 표시합니다.

MVC의 VTV 나열

다음은 MVC MVC001의 VTV를 나열하는 샘플 JCL을 보여줍니다.

//JOBVRECJOB(account),programmer 
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’ 
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR 
//SLSPRINTDD SYSOUT=A 
//SLSINDD * 
RTV  MVC(MVC001)INUNIT(/1AB4) LISTONLY  
/* 
// 

Volser를 지정하여 단일 VTV 변환

다음은 RTV 유틸리티를 실행하여 3490E 전송에 마운트된 MVC MVC001의 VTV VTV200을 변환하는 샘플 JCL을 보여줍니다. 출력(변환된 VTV VTV200)은 전송 280에 마운트된 출력 볼륨으로 이동하고, RTV는 VTV에서 출력 볼륨으로 VTV VOLID를 복사합니다.

//JOBVRECJOB(account),programmer 
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’ 
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR 
//SLSPRINTDD SYSOUT=A 
//SLSINDD * 
  RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) CPYVOLID OUTUNIT(280) 
/* 
// 

Volser 및 블록 ID를 지정하여 단일 VTV 변환

다음은 RTV 유틸리티를 실행하여 3490E 전송에 마운트된 MVC MVC001의 블록 ID x’8EA484AB’에 있는 VTV VTV200을 변환하는 샘플 JCL을 보여줍니다. 출력(변환된 VTV VTV200)은 전송 480에 마운트된 출력 볼륨으로 이동합니다.

//JOBVRECJOB(account),programmer 
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’ 
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR 
//SLSPRINTDD SYSOUT=A 
//SLSINDD * 
  RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) BLOCK(8EA484AB) OUTUNIT(480) 
/* 
//