8 STA 2.1.0으로 업그레이드

이 장에서는 이전에 릴리스된 모든 STA 버전을 STA 2.1.0으로 업그레이드하는 방법에 대한 지침을 제공합니다. 다음과 같은 절로 구성됩니다.

• 업그레이드 프로세스 개요

• 유효한 STA 2.1.0 업그레이드 경로

• 업그레이드 방식

• STA 2.1.0에 대한 환경 변경 사항

• 업그레이드 준비 작업

• 업그레이드 작업

처음으로 STA를 설치하는 경우 새로운 기본 설치를 수행해야 합니다. 자세한 내용은 제 3 장 STA 설치를 참조하십시오.

부록 C에는 업그레이드 작업을 구성하고 설정을 기록하는 데 사용할 수 있는 워크시트가 포함되어 있습니다.

업그레이드 프로세스 개요

업그레이드 중 기존 STA 데이터는 현재 STA 버전에서 새로운 버전으로 변환됩니다. 이 변환이 완료되어야 사용자의 STA 데이터베이스를 새 STA 버전에서 유효하게 사용할 수 있습니다. 업그레이드 후 STA는 새로운 STA 스키마 및 분석 규칙에 따라 새 데이터를 처리합니다(과거 데이터는 다시 처리되지 않음).

업그레이드를 시작하기 전에 이 장의 모든 지침을 읽고 전체 프로세스에 충분한 시간을 할당하십시오. 일부 업그레이드 준비 작업에서는 네트워크 관리 등의 영역에서 사이트의 다른 그룹과 협력해야 할 수 있습니다. 가능한 한 짧은 시간에 업그레이드 자체를 완료할 수 있도록 미리 모든 준비 작업을 완료해야 합니다.

업그레이드 프로세스 자체가 시작되면 STA가 실행될 수 없으므로 모니터되는 라이브러리로부터 교환 정보가 수신되지 않습니다. 또한 새 STA 버전은 업그레이드의 모든 단계를 완료하고 모니터되는 각 라이브러리에 대한 SNMP 연결을 테스트할 때까지 라이브러리에서 정보를 수신하지 않습니다.

주:

일부 업그레이드 단계에는 계획 용도로만 제공되는 시간 예상이 포함됩니다. 실제 시간은 CPU 수, CPU 속도, 디스크 속도, 메모리, 사용 가능한 스왑 공간 등의 서버 용량에 따라 달라질 수 있습니다.

유효한 STA 2.1.0 업그레이드 경로

릴리스된 다음 STA 버전에서 STA 2.1.0으로 업그레이드할 수 있습니다.

• STA 2.0.x:

  • STA 2.0.0.83

  • STA 2.0.1.4

• STA 1.0.x:

  • STA 1.0.0.99

  • STA 1.0.1.133

  • STA 1.0.2.24

  주:

  STA 1.0.x에서 업그레이드하는 경우 STA 2.1.0을 설치하기 전에 새 Linux 버전도 설치해야 합니다. 자세한 내용은 STA 요구 사항 설명서를 참조하십시오.

업그레이드 방식

사용자의 목표 및 사용 가능한 리소스에 따라 단일 서버 또는 두 대의 서버를 사용하여 STA 업그레이드를 수행할 수 있습니다. 이 두 방식에서 수행되는 업그레이드 작업은 대략 비슷하지만 작업이 다른 순서로 수행됩니다. 이 두 방식은 다음 절에서 설명합니다.

• 단일 서버 업그레이드 방식

• 두 대의 서버 업그레이드 방식

단일 서버 업그레이드 방식

단일 서버 방식을 사용하는 경우 STA를 제거한 후에 새 버전을 설치하고 같은 서버에서 데이터베이스를 업그레이드해야 합니다. 이 프로세스를 수행하는 동안 STA는 라이브러리를 모니터하지 않습니다.

이 방식에서는 업그레이드를 위해 추가로 전용 서버가 필요하지 않다는 이점이 있습니다. STA 2.0.x에서 업그레이드하는 경우 새 Linux 버전을 설치할 필요가 없으므로 이 방식으로 충분합니다.

그림 8-1은 단일 서버 방식을 보여 줍니다. 작업 1~작업 9를 순번대로 수행합니다. 요약하면 다음과 같습니다.

• 현재 데이터베이스를 덤프한 다음 안전하게 보관하기 위해 백업 서버로 전송합니다(작업 1 및 작업 2).

• 현재 STA 버전에 따라 Linux 6.x를 설치하거나(작업 3a) STA 2.0.x를 제거합니다(작업 3b).

• STA 2.1.0을 설치하고 예방 조치로 새 데이터베이스를 덤프합니다(작업 4 및 작업 5).

• 이전 데이터베이스 덤프를 백업 서버에서 전송한 다음 이를 새 STA 버전으로 로드하고 업그레이드합니다(작업 6~작업 8).

• 모니터되는 라이브러리로의 연결을 재설정하고 필요한 수동 구성 작업을 수행합니다(작업 9). STA 2.1.0을 설치하기 전에 이전 STA 버전을 제거해야 하기 때문에 일부 사용자 구성 데이터를 수동으로 다시 입력해야 합니다.

그림 8-1 단일 서버 업그레이드 작업 개요

설명 그림 8-1 단일 서버 업그레이드 작업 개요

두 대의 서버 업그레이드 방식

두 대의 서버 업그레이드 방식에는 두번째 전용 STA 서버가 필요하지만 STA 응용 프로그램 작동 중지 시간이 줄어든다는 이점이 있습니다. 이 방식은 STA 1.0.x에서 업그레이드하는 경우 특히 유용한데, 그 이유는 새 서버에 Linux와 새 STA 버전을 설치하는 동안 이전 STA 버전이 이전 서버에서 라이브러리를 계속 모니터할 수 있기 때문입니다.

하지만 이 방식에서도 현재 데이터베이스를 새 STA 버전으로 업그레이드하는 동안에는 STA가 라이브러리를 모니터하지 않습니다. 작동 중지 시간의 길이는 현재 데이터베이스의 크기에 따라 다릅니다.

그림 8-2는 두 서버 방식을 보여 줍니다. 표시된 순서대로 작업을 완료해야 합니다. 작업은 순번대로 수행되지 않으며 작업 6은 생략됩니다. 새 서버에 새 STA 버전을 설치할 때까지 현재 STA 데이터베이스를 덤프하지 않는다는 점을 유의하십시오. 요약하면 다음과 같습니다.

• 두번째 서버가 현재 STA 버전을 실행 중인지 여부에 따라 Linux 6.x를 설치하거나(작업 3a) STA 2.0.x를 제거합니다(작업 3b).

• 새 서버에 STA 2.1.0을 설치하고 예방 조치로 새 데이터베이스를 덤프합니다(작업 4 및 작업 5).

• 이전 서버에서 현재 데이터베이스를 덤프하여 새 서버로 전송합니다(작업 1 및 작업 2).

• 현재 데이터베이스를 새 STA 버전으로 로드하고 업그레이드합니다(작업 7 및 작업 8).

• 모니터되는 라이브러리로의 연결을 재설정하고 필요한 수동 구성 작업을 수행합니다(작업 9).

그림 8-2 두 대의 서버 업그레이드 작업 개요

설명 그림 8-2 두 대의 서버 업그레이드 작업 개요

STA 2.1.0에 대한 환경 변경 사항

다음은 STA 2.1.0으로의 업그레이드를 계획할 때 고려해야 하는 환경 변경 사항을 요약한 것입니다.

Linux 버전

STA 2.1.0에는 Linux 6.3 이상이 필요합니다(자세한 내용은 STA 요구 사항 설명서 참조). 현재 STA 버전에 따라 STA 업그레이드 프로세스의 일환으로 새 버전의 Linux를 설치해야 할 수 있습니다.

• STA 1.0.x에서 업그레이드하는 경우 STA 2.1.0을 설치하기 전에 Linux 6.3 이상을 설치해야 합니다. Linux는 Linux 5.x에서 Linux 6.x로의 in-place 업그레이드를 지원하지 않습니다. 따라서 STA 서버에 Linux 6.x를 새로 설치해야 합니다.

• STA 2.0.x에서 업그레이드하는 경우 이미 Linux 6.3 이상을 실행하고 있습니다. 하지만 STA 2.1.0을 설치하기 전에 현재 STA 버전을 제거해야 합니다. 필요한 Linux RPM 패키지를 설치 또는 업데이트해야 할 수도 있습니다. 업그레이드 준비의 일환으로, 필요한 모든 RPM 패키지 레벨이 설치되었는지 확인합니다. 최종 확인으로 STA 설치 프로그램은 누락된 패키지가 있는 경우 사용자에게 이를 알립니다.

기본 WebLogic 포트 번호

STA 2.1.0에서는 기본 WebLogic 관리 콘솔 포트 번호가 변경되었습니다. 현재 이전 기본 포트 번호를 사용하고 있다면 새 기본값으로 변경해야 합니다. 새 기본 포트 번호와 이전 기본 포트 번호는 다음과 같습니다.

• STA 2.1.0의 새 기본값—7019(HTTP) 및 7020(HTTPS)

• 이전 기본값(STA 1.0.x 및 STA 2.0.x)—7001(HTTP) 및 7002(HTTPS)

주:

WebLogic 관리 콘솔 포트는 외부 포트입니다. 네트워크 관리자는 STA 서버와 WebLogic 관리 인터페이스에 액세스하는 클라이언트 사이의 통신을 열기 위해 방화벽 및 라우터를 구성해야 할 수 있습니다.

STA 2.0.x 이상에 필요한 포트

주:

이 내용은 STA 2.0.x에서 변경되었으므로 STA 1.0.x에서 업그레이드하는 경우에만 관련이 있습니다.

STA 2.0.x에서 StaUi 및 StaEngine 관리 서버에 대해 STA 포트가 추가되었습니다. STA 2.0.x 및 STA 2.1.0에 대한 기본 STA 관리 서버 포트 번호는 다음과 같습니다.

• StaUi—7021(HTTP) 및 7022(HTTPS)

• StaEngine—7023(HTTP) 및 7024(HTTPS)

• StaAdapter—7025(HTTP) 및 7026(HTTPS)

주:

StaUi 포트는 외부 포트입니다. 네트워크 관리자는 STA 서버와 STA 사용자 인터페이스에 액세스하는 클라이언트 사이의 통신을 열기 위해 방화벽 및 라우터를 구성해야 할 수 있습니다.

사용자 이름 및 암호 요구 사항

STA 2.1.0에서는 STA 및 MySQL에 대한 사용자 이름 및 암호 요구 사항이 변경되었습니다. 이러한 요구 사항을 사용자 사이트의 내부 요구 사항과 조정해야 합니다.

사용자 이름 요구 사항은 다음과 같습니다.

• 길이가 1~16자여야 합니다.

• 모든 사용자 이름은 고유해야 합니다.

암호 요구 사항은 다음과 같습니다.

• 길이가 8~31자여야 합니다.

• 최소한 숫자 1개와 대문자 1개를 포함해야 합니다.

• 공백을 포함할 수 없습니다.

• 다음 특수 문자를 포함할 수 없습니다.

  & ' ( ) < > ? { } *  \ ' "
  

업그레이드 준비 작업

STA 업그레이드를 시작하기 전에 다음 작업을 수행합니다. 이 작업의 대부분은 선택 사항이며 테이블 8-1은 각 작업을 수행하는 경우에 대한 지침을 제공합니다.

테이블 8-1 업그레이드 준비 작업을 수행하는 경우에 대한 지침

작업	수행하는 경우
사이트가 업그레이드할 준비가 되었는지 확인	모든 업그레이드
기존 로그 저장(선택 사항)	현재 STA 버전의 서비스 로그를 보존하려는 경우
현재 STA 사용자 및 구성 설정 기록(선택 사항)	STA 사용자 이름 및 구성 설정을 보존하려는 경우
STA– 로 시작하는 사용자 정의 템플리트 이름 바꾸기(선택 사항)	이름이 "STA–"로 시작하는 사용자 정의 템플리트가 있는 경우
현재 사용자 정의 템플리트 설정 기록(선택 사항)	기존 사용자 정의 템플리트의 소유권 및 가시성 설정을 보존하려는 경우
실행 보고서 정책 설정 기록(선택 사항)	기존 실행 보고서 정책의 소유권 설정을 보존하려는 경우

사이트가 업그레이드할 준비가 되었는지 확인

이 절차를 사용하여 업그레이드 요구 사항을 검토하고 사이트가 준비되었는지 확인합니다.

업그레이드 필요 조건 확인

이 절차에 따라 사용자 환경이 모든 STA 2.1.0 필요 조건을 충족하는지 확인합니다.

1. 현재 STA 버전을 표시합니다. 일부 업그레이드 작업은 STA 1.0.x에서 업그레이드하는지 STA 2.0.x에서 업그레이드하는지에 따라 달라집니다.

   1. STA 관리자의 사용자 이름을 사용하여 STA에 로그인합니다.

   2. 상태 표시줄에서 About를 누릅니다.

   3. 현재 릴리스된 STA 버전을 실행 중인지 확인합니다. 자세한 내용은 유효한 STA 2.1.0 업그레이드 경로를 참조하십시오.

2. 단일 서버 업그레이드 방식을 사용할지 두 대의 서버 업그레이드 방식을 사용할지 선택합니다. 자세한 내용은 업그레이드 프로세스 개요를 참조하십시오.

3. 사용자 사이트 및 대상 서버가 STA 2.1.0 요구 사항을 충족하는지 확인합니다. 자세한 내용은 STA 요구 사항 설명서를 참조하십시오.

4. 대상 STA 서버의 /tmp 파일 시스템에 업그레이드를 위한 충분한 공간이 있는지 확인합니다. /tmp의 크기는 압축되지 않은 기존 STA 데이터베이스 크기 이상이어야 합니다. 최소 4GB가 필요하며 큰 데이터베이스의 경우 Oracle은 /tmp의 크기를 최소 32GB로 늘릴 것을 권장합니다.

   /tmp의 크기를 늘리기로 결정하는 경우 업그레이드 스크립트를 실행하기 직전에 해당 크기를 늘릴 수 있습니다. 자세한 내용은 작업 8: 이전 데이터베이스 업그레이드를 참조하십시오.

5. 업그레이드 경로와 관련된 환경 변경 사항을 검토하고 필요한 경우 계획 또는 환경을 조정하십시오. 자세한 내용은 STA 2.1.0에 대한 환경 변경 사항을 참조하십시오.

6. STA 2.0.x에서 업그레이드하는 경우 필요한 모든 RPM 패키지가 STA 서버에 설치되어 있는지 확인합니다. 자세한 내용은 필수 Linux 패키지 설치를 참조하십시오. 최종 점검으로 STA 설치 프로그램은 누락된 패키지가 있는 경우 사용자에게 이를 알립니다.

현재 STA 작업 확인

이 절차를 사용하여 STA 환경이 정상적으로 작동 중인지 확인합니다.

1. 다음 단계를 사용하여 현재 STA 버전이 모니터되는 각 라이브러리와 최근에 통신을 성공했는지 확인합니다.

   1. STA 관리자인 사용자로 STA에 로그인합니다.

   2. Setup & Administration 탭에서 SNMP Connections를 선택합니다.

   3. Monitored Libraries 테이블에서 다음 값을 확인합니다.

      • Recent SNMP Trap Communication Status—GOOD

      • Last Connection Status—SUCCESS

2. 다음 단계를 사용하여 STA가 모든 라이브러리에서 교환을 처리 중인지 확인합니다.

   1. Tape System Activity 탭에서 Exchanges – Overview를 선택합니다.

   2. Filter 아이콘을 선택하고 Exchange End (No. Days) Less Than 1로 필터링합니다.

   3. Table 도구 모음에서 View, Sort, Advanced를 차례로 선택합니다. Drive Library Name, Drive Serial Number 기준으로 정렬합니다.

   4. 모든 라이브러리에 교환 작업이 있는지 확인합니다.

기존 로그 저장(선택 사항)

STA 2.1.0을 설치하기 전에 현재 STA 버전을 제거하거나 새 Linux 버전을 설치해야 하므로 업그레이드 후 기존 응용 프로그램 및 서비스 로그는 보존되지 않습니다. 이 절차를 사용하여 보존할 모든 로그를 저장할 수 있습니다.

1. 보존할 모든 설치 및 데이터베이스 로그를 찾아 안전한 장소로 이동합니다. 관련된 로그는 사용자가 설치에 대해 정의한 STA 로그 위치에 있습니다. 자세한 내용은 STA 파일 시스템 레이아웃 검토를 참조하십시오.

2. 다음 단계를 사용하여 현재 STA 설치에서 서비스 로그 스냅샷을 만듭니다. 이 단계는 선택 사항이지만 Oracle 고객지원센터가 이 로그를 사용하여 업그레이드 전에 존재했던 문제를 해결할 수 있기 때문에 이 단계를 수행하는 것이 권장됩니다.

   1. STA 관리자인 사용자로 STA에 로그인합니다.

   2. Setup & Administration 탭에서 Logs를 선택합니다.

   3. Service – Logs 화면에서 Create New Log Bundle 아이콘을 누릅니다.

   4. Create New Log Bundle 대화 상자에서 번들 이름을 지정하고 Save를 누릅니다. 프로세스를 완료하는 데 몇 분이 걸릴 수 있습니다.

3. 다음 단계를 사용하여 방금 만든 서비스 로그 번들 및 보존하려는 기타 모든 번들을 다운로드합니다. 번들은 한 번에 하나씩 다운로드해야 합니다.

   1. Service – Logs 화면에서 다운로드할 번들을 선택합니다.

   2. Download Selected Log Bundle 아이콘을 누릅니다.

   3. 대화 상자에서 대상 위치를 지정하고 로그 번들을 저장합니다.

현재 STA 사용자 및 구성 설정 기록(선택 사항)

이 절은 STA 2.1.0의 현재 STA 사용자 이름 및 구성 설정을 보존하려는 경우에만 적용됩니다. 이 절차를 사용하여 STA 2.1.0에 다시 입력할 수 있도록 현재 값을 표시 및 기록합니다. 업그레이드 후 이 값 중 대부분을 다시 입력합니다. 자세한 내용은 작업 9: 새 STA 버전 구성을 참조하십시오.

MySQL 사용자 이름 기록

이 절차를 사용하여 STA 데이터베이스에 액세스하는 데 사용되는 MySQL 사용자 이름을 표시 및 기록합니다. STA 설치 프로그램은 이 값을 묻는 메시지를 표시합니다. 암호는 검색할 수 없습니다.

1. 현재 STA 서버에서 터미널 세션을 열고 시스템 루트 사용자로 로그인합니다.

2. 다음 질의를 실행하여 모든 STA 데이터베이스 사용자 이름을 표시합니다. 메시지가 표시되면 데이터베이스 루트 사용자 암호를 입력합니다. 예를 들면 다음과 같습니다.

   $ mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql
   Enter password: password
   +--------+
   | user   |
   +--------+
   | root   |
   | staapp |
   | stadba |
   | starpt |
   +--------+
   

3. 사용자 이름을 기록합니다.

STA SNMP 클라이언트 설정 기록

이 절차를 사용하여 STA에 대한 SNMP 클라이언트 설정을 표시 및 기록합니다. 업그레이드 후 이 값을 다시 입력합니다.

주:

새 STA 버전에서 SNMP 값은 모니터되는 라이브러리에 지정된 값과 일치해야 합니다.

1. STA 관리자의 사용자 이름을 사용하여 STA에 로그인합니다.

2. Setup & Administration 탭에서 SNMP Connections를 선택합니다.

   Client Attributes 테이블에 STA SNMP 클라이언트에 대한 구성 설정이 표시됩니다.

   
   그림 설명 snmp_clientupgrade.png
   
   

3. 다음 열의 값을 기록합니다.

   • SNMP Username

   • User Community

   • Trap Community

WebLogic 사용자 이름 기록—STA 1.0.x에서 업그레이드하는 경우만 해당

STA 1.0.x에서 업그레이드하는 경우 이 절차를 사용하여 STA에 로그인하는 데 사용되는 기존 WebLogic 사용자 이름을 표시 및 기록합니다. 업그레이드 후 이 값을 다시 입력합니다. 암호는 검색할 수 없습니다.

주:

STA 2.0.x부터 사용자 이름은 STA 사용자 인터페이스를 통해 만들어지고 유지 관리됩니다. 자세한 내용은 STA 사용자 이름 기록—STA 2.0.x에서 업그레이드하는 경우만 해당을 참조하십시오.

1. 컴퓨터에서 지원되는 웹 브라우저를 시작한 다음 WebLogic 관리 콘솔의 URL을 입력합니다.

   http(s)://STA_host_name:port_number/console/
   

   여기서 각 항목은 다음과 같습니다.

   • host_name은 STA 서버의 호스트 이름입니다.

   • port_number는 현재 STA 버전의 WebLogic 관리 콘솔의 STA 포트 번호입니다.

   • STA는 대문자여야 합니다.

   예를 들면 다음과 같습니다.

   https://staserver.example.com:7002/console/ 
   

2. WebLogic 관리 콘솔 사용자 이름과 암호를 사용하여 로그인합니다.

3. Domain Structure 탐색 트리에서 Security Realms를 누릅니다.

   
   그림 설명 wl_secrealm.png
   
   

   Summary of Security Realms 화면이 표시됩니다.

4. Name 열에서 myrealm 활성 링크를 선택합니다(확인란 선택 안함).

   
   그림 설명 wl_myrealm.png
   
   

   Settings for myrealm 화면이 나타납니다.

5. Users and Groups 탭을 선택합니다.

   
   그림 설명 wl_checkusers.png
   
   

   Users 테이블에 사용 가능한 사용자 이름이 나열됩니다.

   
   그림 설명 wl_userstable.png
   
   

6. 보관할 사용자 이름을 기록합니다.

STA 사용자 이름 기록—STA 2.0.x에서 업그레이드하는 경우만 해당

STA 2.0.x에서 업그레이드하는 경우 이 절차를 사용하여 STA에 로그인하는 데 사용되는 사용자 이름을 표시 및 기록합니다. 업그레이드 후 이 정보를 다시 입력합니다. 암호는 검색할 수 없습니다.

주:

STA 1.0.x의 경우 사용자 이름은 WebLogic 관리 콘솔을 통해 만들어지고 유지 관리됩니다. 자세한 내용은 WebLogic 사용자 이름 기록—STA 1.0.x에서 업그레이드하는 경우만 해당을 참조하십시오.

1. STA 관리자의 사용자 이름을 사용하여 STA에 로그인합니다.

2. Setup & Administration 탭에서 Users를 선택합니다.

   Configuration – Users 화면에 모든 STA 사용자 이름 및 해당 역할이 표시됩니다.

   
   그림 설명 upgrade_users.png
   
   

3. 보존할 사용자 이름 및 역할을 기록합니다.

STA 전자 메일 서버 설정 기록

이 절차를 사용하여 STA 전자 메일 프로토콜과, 전자 메일 서버에 인증이 필요한 경우 계정 사용자 이름을 표시 및 기록합니다. 업그레이드 후 이 값을 다시 입력합니다. 암호는 표시할 수 없습니다.

1. STA 관리자의 사용자 이름을 사용하여 STA에 로그인합니다.

2. Setup & Administration 탭에서 Email을 선택합니다.

3. SMTP Server Settings 테이블에서 StorageTek Tape Analytics Alerts 레코드를 선택한 다음 Edit Selected SMTP Server 아이콘을 누릅니다.

   Define SMTP Server Details 대화 상자가 나타납니다.

   
   그림 설명 email_smtpserverd.png
   
   

4. 다음 필드의 값을 기록합니다.

   • Use Secure Connection Protocol

   • Username

STA– 로 시작하는 사용자 정의 템플리트 이름 바꾸기(선택 사항)

이 절차는 이름이 "STA–"로 시작하는 사용자 정의 템플리트가 있는 경우에만 적용됩니다. STA 2.1.0 설치 중 "STA–"로 시작하는 모든 템플리트는 삭제되고 미리 정의된 새 STA 템플리트로 교체됩니다.

이 절차를 사용하여 업그레이드 중 템플리트가 보존되도록 템플리트에 새 이름을 지정합니다.

주:

미리 정의된 STA 템플리트는 "STA–"로 시작하므로 Oracle은 사용자 정의 템플리트의 이름을 지정할 때 이 접두어를 사용하지 않도록 권장합니다.

1. 관리자의 사용자 이름으로 STA에 로그인합니다.

2. Setup & Administration 탭에서 Templates Management를 선택합니다.

3. STA 설치 날짜 이후에 수정된 템플리트에 집중하기 위해 Created/Updated 날짜순으로 테이블을 정렬합니다.

4. 이름이 "STA–"로 시작하는 사용자 정의 템플리트의 텍스트 링크를 선택합니다.

   선택한 템플리트가 적용된 화면으로 이동합니다.

5. Templates 도구 모음에서 Save Template를 누릅니다.

   Save Template 대화 상자가 표시됩니다.

6. Template Name 필드에서 "STA‐"로 시작하지 않는 새 이름을 지정합니다. 항목은 고유해야 합니다.

7. Save를 누릅니다.

   템플리트가 저장됩니다.

현재 사용자 정의 템플리트 설정 기록(선택 사항)

이 절은 사용자 정의 템플리트가 있는 경우에만 적용됩니다. 업그레이드에서는 사용자 정의 템플리트가 보존되지만, 업그레이드 후 모든 사용자 정의 템플리트는 가시성이 공개로 설정되어 STA 소유가 됩니다.

이 절차를 사용하여 모든 사용자 정의 템플리트의 현재 소유권 및 가시성 설정을 기록하면 업그레이드 후 필요한 경우 해당 설정을 복원할 수 있습니다. 템플리트 소유권 및 가시성이 사용자의 구현에 중요하지 않은 경우 이 절차를 건너뛸 수 있습니다.

1. 관리자의 사용자 이름으로 STA에 로그인합니다.

2. Setup & Administration 탭에서 Templates Management를 선택합니다.

3. Filter 아이콘을 선택하여 STA가 소유하지 않은 템플리트만 표시하도록 화면을 필터링합니다. 이렇게 하면 사용자 정의 템플리트만 표시됩니다.

   
   그림 설명 upgrade_filternotsta.png
   
   

4. 각 사용자 정의 템플리트의 현재 Owner 및 Public Visibility 설정을 기록합니다. 템플리트가 여러 개인 경우 스크린샷을 만들면 좋습니다.

실행 보고서 정책 설정 기록(선택 사항)

이 절은 사용자가 실행 보고서 정책을 개인적으로 소유한 경우에만 적용됩니다. 업그레이드 작업은 모든 실행 보고서 정책을 보존하지만 업그레이드 후 모든 개인 정책에는 공용 소유권이 지정됩니다.

이 절차를 사용하여 모든 개인 정책의 현재 소유권 설정을 기록하면 업그레이드 후 필요한 경우 해당 설정을 복원할 수 있습니다. 실행 보고서 정책 소유권이 사용자의 구현에 중요하지 않은 경우 이 절차를 건너뛸 수 있습니다.

1. STA 관리자의 사용자 이름을 사용하여 STA에 로그인합니다.

2. Setup & Administration 탭에서 Executive Reports Policies를 선택합니다.

3. Filter 아이콘을 선택하여 STA가 소유하지 않은 정책만 표시하도록 화면을 필터링합니다. 이렇게 하면 개인 정책만 표시됩니다.

   
   그림 설명 upgrade_rptnotsta.png
   
   

4. 각 정책에 대해 현재 Report Owner를 기록합니다. 정책이 여러 개인 경우 스크린샷을 만들면 좋습니다.

업그레이드 작업

주의:

Linux 관리자 및 STA 관리자만 업그레이드를 수행해야 합니다. 모든 작업은 필수이며 지정된 순서대로 정확하게 수행되어야 합니다. 그렇지 않으면 데이터가 손실될 수 있습니다.

단일 서버 업그레이드 방식을 사용하는 경우 작업을 순번대로 수행합니다. 자세한 내용은 그림 8-1 단일 서버 업그레이드 작업 개요를 참조하십시오.

두 대의 서버 업그레이드 방식을 사용하는 경우 작업을 순번대로 수행하지 않으며 작업 6은 생략됩니다. 작업 순서는 그림 8-2 두 대의 서버 업그레이드 작업 개요를 참조하십시오.

• 작업 1: 이전 STA 데이터베이스 덤프

• 작업 2: 이전 데이터베이스 덤프 전송

• 작업 3a: 새 Linux 버전 설치(STA 1.0.x에서 업그레이드)

• 작업 3b: 이전 STA 버전 제거(STA 2.0.x에서 업그레이드)

• 작업 4: 새 STA 버전 설치

• 작업 5: 새 STA 데이터베이스 덤프(선택 사항)

• 작업 6: 이전 STA 데이터베이스를 STA 서버로 전송

• 작업 7: 이전 STA 데이터베이스 처리 및 로드

• 작업 8: 이전 데이터베이스 업그레이드

• 작업 9: 새 STA 버전 구성

• 실패한 데이터베이스 업그레이드 복구(선택 사항)

작업 1: 이전 STA 데이터베이스 덤프

이 절차를 수행하여 이전(현재) STA 데이터베이스의 전체 덤프를 수행합니다.

1. 다음 단계에 따라 현재 STA 데이터베이스의 크기를 표시합니다.

   1. STA 관리자의 사용자 이름을 사용하여 STA에 로그인합니다.

   2. 상태 표시줄에서 About를 누릅니다.

   3. About 대화 상자에서 Database Current Size가 표시된 위치까지 아래로 스크롤한 다음 해당 값을 기록합니다.

2. 다음 단계에 따라 데이터베이스를 덤프할 위치에 충분한 공간이 있는지 확인합니다.

   1. STA 서버에서 터미널 세션을 열고 시스템 루트 사용자로 로그인합니다.

   2. 데이터베이스 덤프 대상의 사용 가능한 공간을 표시하고 이 공간이 덤프 파일에 충분한지 확인합니다. 예를 들면 다음과 같습니다.

      # df -h /dbdumpfiles
      Filesystem            Size  Used Avail Use% Mounted on
      /dev/mapper/sta_server-STA_DbVol
                            200G   53G   243G  27% /dbdumpfiles
      

3. 모든 STA 서비스를 중지합니다.

   # STA stop all 
   

4. MySQL 서비스를 시작합니다.

   # service mysql start
   

5. STA 데이터베이스를 단일 파일로 덤프합니다. 메시지가 표시되면 데이터베이스 루트 사용자 암호를 입력합니다.

   # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql
   Enter password: mysql_root_password
   

   주:

   선택 사항인 –v 매개변수(상세 정보 출력용)는 권장되지 않습니다. 이 매개변수를 지정하면 많은 수의 메시지가 터미널 창에 표시되어 큰 데이터베이스의 경우 명령 프로세스 속도가 매우 느려질 수 있습니다.

   예 8-1에서 STA 1.0.x 데이터베이스는 Dec14_dump.sql이라는 파일 이름으로 STA 서버의 /dbdumpfiles 폴더에 덤프됩니다.

   예 8-1 이전 데이터베이스 덤프

   # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dbdumpfiles/Dec14_dump.sql
   
   Enter password: mysql_root_password
   ...
   -- Retrieving view structure for table v_library_complex_io...
   ...
   -- Retrieving view structure for table v_library_summary_averages...
   -- It's base table, skipped
   ...
   -- Retrieving table structure for table v_mdv_status_codes...-- It's a view, create dummy table for view
   ...
   -- Disconnecting from localhost...
   

6. 덤프 파일 크기를 약 50%로 줄이기 위해 파일을 gzip으로 압축합니다.

   # cd /path_to_dump_file/
   # gzip dump_file_name.sql
   

작업 2: 이전 데이터베이스 덤프 전송

이 절차를 사용하여 이전 STA 데이터베이스의 압축된 덤프를 오프 플랫폼 백업 서버(단일 서버 방식) 또는 새 STA 2.1.0 서버(두 대의 서버 방식)로 전송합니다.

주의:

단일 서버 방식으로 STA 1.0.x에서 업그레이드하는 경우 STA 데이터베이스를 다른 서버에 백업해야 합니다. 작업 3a: 새 Linux 버전 설치(STA 1.0.x에서 업그레이드)에서 Linux 6.x를 설치하면 서버의 모든 데이터가 삭제되므로 데이터베이스를 현재 STA 서버의 파일 시스템에 백업하지 마십시오.

1. 아직 실행 중인 STA 서비스가 있는 경우 모두 중지합니다.

   # STA stop all 
   

2. 파일을 백업 서버로 전송하기 전에 체크섬을 수행합니다.

   # cksum dump_file_name.sql.gz
   

   출력에는 체크섬 값과 바이트 수가 포함됩니다. 체크섬 값을 기록하십시오. 이 값은 파일을 백업 서버로 전송한 후 파일 무결성을 확인하는 데 사용됩니다.

3. SCP와 같은 전송 유틸리티를 사용하여 파일을 대상 서버로 전송합니다. –p 옵션은 시간 기록 값을 유지합니다.

   # scp -p dump_file_name.sql.gz target_host:/path/
   

   예 8-2에서는 SCP를 사용하여 압축된 데이터베이스 덤프 파일 Dec14_dump.sql.gz를 백업 호스트 backup1의 /dbdumpfiles 폴더로 전송합니다. /dbdumpfiles 폴더는 백업 호스트에 이미 존재합니다.

   예 8-2 백업 서버로 이전 데이터베이스 전송(단일 서버 방식)

   # cd /dbdumpfiles
   # scp -p Dec14_dump.sql.gz backup1:/dbdumpfiles
   

   예 8-3에서는 SCP를 사용하여 압축된 데이터베이스 덤프 파일 Dec14_dump.sql.gz를 STA 2.1.0 호스트 sta_new의 /dbdumpfiles 폴더로 전송합니다.

   예 8-3 새 STA 서버로 이전 데이터베이스 전송(두 대의 서버 방식)

   # cd /dbdumpfiles
   # scp -p Dec14_dump.sql.gz sta_new:/dbdumpfiles
   

4. 대상 서버에서 전송된 파일의 체크섬을 수행합니다. 체크섬 값이 일치하는지 확인합니다.

   # cd /path_to_dump_file/
   # cksum dump_file_name.sql.gz
   

작업 3a: 새 Linux 버전 설치(STA 1.0.x에서 업그레이드)

이 절차는 STA 1.0.x에서 업그레이드하는 경우에만 적용됩니다. STA 서버에 Linux 6.3 이상을 설치합니다. 자세한 내용은 제 2 장 Linux 설치를 참조하십시오.

주의:

이 작업을 수행하면 서버의 모든 데이터가 삭제됩니다. 단일 서버 업그레이드 방식을 사용하는 경우 작업 1: 이전 STA 데이터베이스 덤프 및 작업 2: 이전 데이터베이스 덤프 전송을 수행한 후에만 이 절차를 수행하십시오.

작업 3b: 이전 STA 버전 제거(STA 2.0.x에서 업그레이드)

이 절차는 STA 2.0.x에서 업그레이드하는 경우에만 적용됩니다. 현재 STA 버전을 제거합니다. 자세한 내용은 STA 제거 및 성공적인 제거 확인을 참조하십시오.

주의:

이 작업을 수행하면 서버의 모든 STA 데이터가 삭제됩니다. 단일 서버 업그레이드 방식을 사용하는 경우 작업 1: 이전 STA 데이터베이스 덤프 및 작업 2: 이전 데이터베이스 덤프 전송을 수행한 후에만 이 절차를 수행하십시오.

작업 4: 새 STA 버전 설치

이 절차를 사용하여 STA 2.1.0을 설치합니다.

1. STA 2.1.0을 설치합니다. 자세한 내용은 STA 설치를 참조하십시오.

2. STA가 제대로 작동하는 지 확인하고 WebLogic에서 STA Administrator 설정을 완료하기 위해 STA 응용 프로그램에 로그인합니다.

   Dashboard가 표시됩니다.

   주:

   업그레이드 프로세스가 아직 완료되지 않았으므로 Dashboard 포틀릿에 "No data to display"라는 메시지가 표시되는데 이것은 정상적인 동작입니다. 데이터베이스를 업그레이드하고 새 STA 버전을 구성하면 라이브러리 데이터가 올바르게 표시됩니다.

3. STA에서 로그아웃합니다.

4. STA 서버에서 터미널 세션을 열고 시스템 루트 사용자로 로그인합니다.

5. 모든 STA 서비스를 중지합니다.

   # STA stop all
   

6. 이 단계는 STA가 SNMP v2c를 사용하여 라이브러리를 모니터하는 경우에만 적용됩니다(부록 F SNMP v2c 모드 구성 참조). STA 2.0.x부터는 SNMP v2c가 기본적으로 사용으로 설정됩니다. 다음 단계를 사용하여 SNMP v2c가 사용으로 설정되었는지 확인합니다.

   1. STA 구성 파일 디렉토리로 변경합니다.

      # cd /Oracle_storage_home/Middleware/user_projects/domains/TBI
      

   2. SNMP 버전 등록 정보 파일을 표시하고 V2c 매개변수가 true로 설정되었는지 확인합니다.

      # cat TbiSnmpVersionSupport.properties
      V2c=true
      Verbal=false
      

   3. 매개변수가 true로 설정되지 않은 경우 해당 매개변수를 변경하는 방법은 STA에 대해 SNMP v2c 모드 사용으로 설정을 참조하십시오.

작업 5: 새 STA 데이터베이스 덤프(선택 사항)

이 절차는 선택 사항이지만 권장됩니다. 이 절차를 사용하여 만약을 위해 빈 STA 2.1.0 데이터베이스를 덤프합니다. 데이터베이스 업그레이드(작업 8: 이전 데이터베이스 업그레이드)를 완료할 수 없는 경우 빈 데이터베이스를 복원하여 STA 2.1.0을 데이터 없이 새로 설치된 것처럼 실행하도록 구성할 수 있는 상태로 복원할 수 있습니다. 복구 프로세스에 대한 자세한 내용은 실패한 데이터베이스 업그레이드 복구(선택 사항)를 참조하십시오.

1. STA 서버에서 터미널 세션을 열고 시스템 루트 사용자로 로그인합니다.

2. 아직 실행 중인 STA 서비스가 있는 경우 모두 중지합니다.

   # STA stop all 
   

3. MySQL 서비스를 시작합니다.

   # STA start mysql
   

4. 데이터베이스 백업 파일을 만듭니다. 메시지가 표시되면 데이터베이스 루트 사용자 암호를 입력합니다.

   # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql
   

   주:

   선택 사항인 –v 매개변수(상세 정보 출력용)는 권장되지 않습니다. 이 매개변수를 지정하면 많은 수의 메시지가 터미널 창에 표시되어 큰 데이터베이스의 경우 명령 프로세스 속도가 매우 느려질 수 있습니다.

   예 8-4에서 STA 2.1.0 데이터베이스는 STA_FRESH_INSTALL_BACKUP.sql이라는 파일 이름으로 STA 서버의 /dbdumpfiles 폴더에 덤프됩니다.

   예 8-4 새 데이터베이스 덤프

   # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb >  /dbdumpfiles/STA_FRESH_INSTALL_BACKUP.sql
   Enter password: mysql_root_password
   ...
   -- Retrieving view structure for table v_mdv_request_states...
   -- Retrieving view structure for table version_info...
   ...
   -- Disconnecting from localhost...
   

   주:

   "Can't connect to local MySQL server"라는 메시지가 표시되면 MySQL 서버가 실행되지 않는 것입니다. MySQL을 시작했는지 확인하십시오(3단계).

작업 6: 이전 STA 데이터베이스를 STA 서버로 전송

주:

이 절차는 단일 서버 방식에만 적용됩니다.

이 절차를 사용하여 STA 1.0.x 또는 STA 2.0.x 데이터베이스 백업을 STA 2.1.0 서버로 전송합니다.

1. 아직 실행 중인 STA 서비스가 있는 경우 모두 중지합니다.

   # STA stop all 
   

2. 데이터베이스를 전송합니다. SCP에 대해 –p 옵션을 지정하면 시간 기록 값이 유지됩니다.

   # scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path
   

   예 8-5에서는 SCP를 사용하여 압축된 데이터베이스 덤프 파일 Dec14_dump.sql.gz를 호스트 backup1의 /dbdumpfiles에서 STA 2.1.0 서버의 /dbdumpfiles 폴더로 전송합니다.

   예 8-5 새 STA 서버로 이전 데이터베이스 전송

   # scp -p backup1:/dbdumpfiles/Dec14_dump.sql.gz /dbdumpfiles
   

3. 전송된 파일의 체크섬을 수행합니다. 체크섬 값이 작업 1: 이전 STA 데이터베이스 덤프에서 받은 값과 일치하는지 확인합니다.

   # cd /path_to_dump_file/
   # cksum dump_file_name.sql.gz
   

작업 7: 이전 STA 데이터베이스 처리 및 로드

이 절차를 따라 STA 1.0.x 또는 STA 2.0.x 데이터베이스의 압축을 풀어 STA 2.1.0 서버에 복원합니다. 압축을 푼 데이터베이스는 압축된 데이터베이스보다 10~15배의 공간을 차지할 수 있습니다.

1. 아직 실행 중인 STA 서비스가 있는 경우 모두 중지합니다.

   # STA stop all 
   

2. 백업 파일의 압축을 풉니다.

   # gunzip dump_file_name.sql.gz
   

3. 다음 단계를 수행하여 더 이상 사용되지 않는 데이터(예: 처리된 SNMP 레코드 및 빈 분석 레코드)가 들어 있는 STA 데이터베이스를 비웁니다.

   시간 예상: STA 1.0.x 및 STA 2.0.x의 경우 압축이 풀린 데이터베이스 스냅샷 크기 1GB당 최대 1분입니다.

   주:

   purgerecs 명령 작업의 영구 레코드는 STA 데이터베이스에 저장됩니다. STA 2.0.x부터는 데이터베이스 비우기도 런타임에 자동으로 발생합니다. 정기적으로 MySQL Event Scheduler는 여러 테이블에서 레코드를 비워 데이터베이스 증가 속도를 줄입니다.

   1. STA 데이터베이스 업데이트 디렉토리로 변경합니다.

      # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates
      

   2. 비우기를 시작합니다.

      # ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/dump_file_name_PURGED.sql
      

      주:

      purgerecs 명령에 대한 도움말을 보려면 다음 명령을 입력하십시오.

      # ./purgerecs -h
      

   예 8-6에서 purgerecs 유틸리티는 /dbdumpfiles에 있는 MySQL 덤프 파일 Dec14_dump.sql을 처리합니다. 출력은 /dbdumpfiles에 Dec14_dump_PURGED.sql이라는 새 파일로 저장됩니다. 진행 상태 점은 200개의 레코드가 처리될 때마다 나타납니다.

   예 8-6 이전 데이터베이스 백업에서 더 이상 사용되지 않는 데이터 비우기

   # cd /Oracle/StorageTek_Tape_Analytics/db/updates
   # ./purgerecs /dbdumpfiles/Dec14_dump.sql /dbdumpfiles/Dec14_dump_PURGED.sql
   ................................................
             STA v1.0.2, Schema 33.02 
   Processed 11,689 lines from '20130711_dump.sql':
   ------------------------------------------------
   snmp_storage_cells........1,614,255
   snmp_media................110,205
   ...
   media_summaries...........254
   transform_logs............0
   ================================================
   Records Processed:........13,143,283
   Records Purged:...........2,857,623
   Records Remaining:........10,285,660
   Elapsed Time:.............00:00:11
   

4. 이 단계는 선택 사항입니다. 데이터베이스 파일 크기를 파악하고 로드 프로세스 시간을 예상합니다.

   시간 예상: STA 1.0.x 및 STA 2.0.x의 경우 압축이 풀린 데이터베이스 스냅샷 크기 1GB당 최대 3~10분입니다.

   # ls -s -h dump_file_name_PURGED.sql
   

5. MySQL 서버를 시작합니다.

   # STA start mysql
   

6. STA 1.0.x 또는 STA 2.0.x 데이터베이스를 로드합니다. 메시지가 표시되면 데이터베이스 루트 사용자 암호를 입력합니다. 상세 정보를 표시하는 –v 옵션(권장되지 않음)을 지정하지 않을 경우 프로세스가 실행될 때 명령 출력이 없습니다.

   주:

   선택 사항인 –v 매개변수(상세 정보 출력용)는 권장되지 않습니다. 이 매개변수를 지정하면 많은 수의 메시지가 터미널 창에 표시되어 큰 데이터베이스의 경우 명령 프로세스 속도가 매우 느려질 수 있습니다.

   # mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /path_to_dump_file/dump_file_name_PURGED.sql;"
   Password: mysql_root_password
   

   여기서 각 항목은 다음과 같습니다.

   • –p—STA 설치 중 설정된 데이터베이스 루트 암호를 물어봅니다.

   • –e—다음 따옴표로 묶인 명령문을 실행합니다.

     • SET SESSION SQL_LOG_BIN=0;—불필요한 바이너리 로깅을 해제하여 로드 속도를 높입니다.

     • SOURCE /path_to_dump_file/dump_file_name_PURGED.sql—덤프 파일을 DB로 로드합니다.

   명령을 성공할 경우 프로세스가 완료되면 명령 프롬프트로 돌아옵니다.

작업 8: 이전 데이터베이스 업그레이드

이 절차를 사용하여 STA 1.0.x 또는 STA 2.0.x 데이터베이스를 새 STA 2.1.0 스키마로 업그레이드합니다.

시간 예상: 압축이 풀린 데이터베이스 스냅샷 크기 1GB당 대략적인 시간입니다.

• STA 1.0.x에서 업그레이드하는 경우—1GB당 최대 5분

• STA 2.0.x에서 업그레이드하는 경우—1GB당 최대 30분

1. 아직 실행 중인 STA 서비스가 있는 경우 모두 중지합니다.

   # STA stop all 
   

2. 업그레이드 필요 조건 확인에서 /tmp의 크기가 업그레이드 작업에 충분하지 않다고 파악한 경우 필요에 따라 /tmp의 크기를 늘립니다.

   크기를 늘릴 수 없는 경우 다음 단계를 사용하여 대체 임시 위치를 사용하도록 MySQL에 대한 환경 변수를 설정합니다.

   1. 대체 임시 위치를 만들고 열기 권한을 지정합니다. 예를 들면 다음과 같습니다.

      # mkdir /dbbackup/tmp
      # chmod 777 /dbbackup/tmp
      

   2. MySQL을 중지합니다.

      # STA stop mysql
      

   3. MySQL 구성 파일을 편집합니다. 예를 들면 다음과 같습니다.

      #  vi /etc/my.cnf
      

   4. 파일의 mysqld 섹션에 tmpdir 변수로 식별되는 대체 임시 위치를 정의하는 라인을 추가합니다. 다음은 이 라인이 추가된 파일의 예입니다.

      [mysqld]
      #----- mysqld MySQL Server Options -------------------------
       
      tmpdir                          = /dbbackup/tmp
      server-id                       = 1
      ...
      

   5. MySQL을 다시 시작합니다.

      # STA start mysql
      

3. 데이터베이스 업데이트 디렉토리로 변경합니다.

   # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates
   

4. 업그레이드 스크립트를 시작하고 메시지가 표시되면 데이터베이스 루트 사용자 암호를 입력합니다. 보안상의 이유로, 암호는 화면에 표시되지 않습니다.

   # ./upgradedb.sh
   

   주:

   시스템 루트 사용자 또는 Oracle 설치 사용자로 이 단계를 수행할 수 있습니다.

   다음은 화면 표시의 예입니다.

   # ./upgradedb.sh
   
   DB Root Password: 
   +-------------------------------------------------------------+
   | STA DATABASE UPGRADE                                        |
   | Upgrading DB schema from 58.00r0 to 59.00r0                 |
   | Started: 2014-12-12 15:14:45                                |
   +-------------------------------------------------------------+
   STA database is 5.15 GB and contains approximately 12,636,002 records.
   Checking if current database v58.00 is a valid upgrade candidate...
   ...DB v58.00 is a valid upgrade candidate...
   +-------------------------------------------------------------+
   ==> You may ABORT using CTRL-C within 7 seconds
   ==> .....6.....5.....4.....3.....2.....1
   ==> CTRL-C disabled!
   +-------------------------------------------------------------+
   Starting upgrade...
   

   프로세스가 완료되면 다음과 비슷한 배너가 표시됩니다.

   주의:

   계속하기 전에 배너가 표시될 때까지 기다리십시오.

   +-------------------------------------------------------------+
   | Started.................2014-12-12 15:14:45                 |
   | Finished................2014-12-12 17:07:11                 |
   | Elapsed Time............01:52:26                            |
   | Starting Version........58.00r0                             |
   | Final Schema Version....59.00r0                             |
   | Schema Release Date.....2014-12-12 11:00:00                 |
   | Records (approximate)...12,636,002                          |
   +-------------------------------------------------------------+
   

5. 작업 8: 이전 데이터베이스 업그레이드에서 /tmp의 크기를 늘렸거나 대체 임시 위치를 만들었다면 정상적인 크기 및 위치로 복원합니다.

6. 모든 STA 서비스를 시작합니다.

   # STA start all
   

7. 이 단계는 선택 사항입니다. STA_FRESH_INSTALL_BACKUP.sql 파일을 삭제하여 STA 데이터베이스 백업 볼륨에 디스크 공간을 확보합니다.

작업 9: 새 STA 버전 구성

이 절차를 따라 라이브러리 및 STA 2.1.0을 구성하면 STA가 라이브러리 작업 모니터링을 시작할 수 있습니다.

라이브러리에서 STA 트랩 수신자 업데이트

2개의 새 트랩 레벨인 13(테스트 트랩) 및 14(상태 트랩)가 STA 2.0.x에 도입되었습니다. 모니터되는 각 라이브러리에 대해 다음 단계를 수행하여 이러한 트랩 레벨이 STA 트랩 수신자 정의에 포함되었는지 확인합니다.

1. 업그레이드 경로에 따라 다음과 같이 진행하십시오.

   • 단일 서버 방식을 사용하여 STA 2.0.x에서 업그레이드하는 경우 STA의 SNMP 설정 구성으로 진행합니다.

   • 단일 서버 방식을 사용하여 STA 1.0.x에서 업그레이드하는 경우 2단계로 이동하여 모니터되는 각 라이브러리에서 기존 STA 트랩 수신자에 새 트랩 레벨을 추가합니다.

   • 두 대의 서버 방식을 사용하는 경우 3단계로 이동하여 모니터되는 각 라이브러리에 새 STA 트랩 수신자를 추가합니다.

2. 단일 서버 방식을 사용하여 STA 1.0.x에서 업그레이드하는 경우 라이브러리 모델에 해당하는 단계를 사용하여 STA 트랩 수신자에 새 트랩 레벨을 추가합니다.

   SL150 이외의 모든 라이브러리 모델의 경우 트랩 수신자를 수정하려면 기존 정의를 삭제한 다음 새 정의를 추가해야 합니다.

   SL150을 제외한 모든 라이브러리 

   1. 라이브러리 CLI에 로그인합니다.

   2. 기존의 모든 트랩 수신자를 표시하고 STA 수신자의 인덱스 번호를 기록해 둡니다.

      snmp listTrapRecipients
      

   3. STA 트랩 수신자를 삭제합니다.

      snmp deleteTrapRecipient id index
      

      여기서 각 항목은 다음과 같습니다.

      • index는 STA 트랩 수신자의 인덱스 번호입니다.

   4. STA 트랩 수신자를 다시 추가하고 트랩 레벨 목록에 새 트랩 레벨을 포함합니다. 자세한 내용은 STA SNMP v3 트랩 수신자 만들기 또는 라이브러리에서 STA SNMP v2c 트랩 수신자 만들기를 참조하십시오.

   SL150 라이브러리 

   1. 브라우저 기반 사용자 인터페이스에 로그인합니다.

   2. SNMP 메뉴에서 SNMP Trap Recipients를 선택합니다.

   3. 목록에서 STA 트랩 수신자를 선택합니다.

   4. Modify Trap Recipient를 선택합니다.

   5. 트랩 레벨 목록에 새 트랩 레벨을 추가한 다음 Save를 누릅니다.

3. 두 대의 서버 업그레이드 방식을 사용하는 경우 각 라이브러리에서 새 STA 2.1.0 서버를 트랩 수신자로 추가합니다. 자세한 내용은 STA SNMP v3 트랩 수신자 만들기 또는 라이브러리에서 STA SNMP v2c 트랩 수신자 만들기를 참조하십시오.

STA의 SNMP 설정 구성

모든 업그레이드에 대해 이 단계를 수행합니다. 이 단계는 STA에서 수행됩니다.

1. STA 관리자인 사용자로 STA에 로그인합니다.

2. 업그레이드 전에 기록한 값을 사용하여 STA SNMP 클라이언트에 대한 구성 설정을 다시 입력합니다. 현재 STA 사용자 및 구성 설정 기록(선택 사항)을 참조하십시오. 이 값은 모니터되는 라이브러리에 구성된 값과 일치해야 합니다. 자세한 내용은 STA에 대한 SNMP 클라이언트 설정 구성을 참조하십시오.

3. STA와 라이브러리 사이의 SNMP 통신을 복원하려면 모니터되는 각 라이브러리에 대한 연결을 테스트합니다. 자세한 내용은 라이브러리 SNMP 연결 테스트를 참조하십시오.

   주:

   이 단계가 성공적으로 완료되면 STA가 모니터되는 각 라이브러리에서 데이터를 받아 처리하기 시작합니다.

   STA가 중지되었거나 라이브러리 연결이 복원되었을 때 처리 중인 교환으로 인해 Exchanges Overview 화면에 완료되지 않은 교환이 표시될 수 있습니다. 완료되지 않은 교환에 대한 자세한 내용은 STA 사용 설명서를 참조하십시오.

4. 각 라이브러리에서 최신 SNMP 라이브러리 구성 데이터를 가져옵니다. 자세한 내용은 수동 데이터 수집 수행을 참조하십시오.

STA 서비스 및 사용자 정보 구성

모든 업그레이드에 대해 이 단계를 수행합니다. 이 단계는 STA 서버에서 수행됩니다.

이전 STA 버전의 설정을 보존하려면 업그레이드 전에 기록한 값을 사용합니다. 현재 STA 사용자 및 구성 설정 기록(선택 사항)을 참조하십시오.

주:

업그레이드가 끝나면 STA가 모든 논리적 그룹을 소유합니다. 논리적 그룹 소유권은 STA 기능에 중요하지 않으며 Operator 또는 Administrator 권한이 있는 모든 STA 사용자는 논리적 그룹을 수정할 수 있습니다.

1. STA 백업 서비스 및 STA 리소스 모니터 서비스 유틸리티를 구성합니다. 자세한 내용은 제 7 장 STA 서비스 구성을 참조하십시오.

2. STA 사용자 이름 및 암호를 만듭니다. 자세한 내용은 STA 사용 설명서를 참조하십시오. 다음을 수행할 수도 있습니다.

   • 사용자에게 STA 2.1.0의 새 암호 요구 사항을 알립니다.

   • 해당하는 경우 사용자에게 사용자 정의 사용자 환경 설정을 다시 입력하도록 지시합니다.

3. STA 전자 메일 서버에 인증이 필요한 경우 전자 메일 계정 사용자 이름 및 암호를 입력해야 합니다. 자세한 내용 STA 사용 설명서을 참조하십시오.

4. 해당하는 경우 사용자 정의 템플리트에 대한 원래 소유권을 복원합니다. 자세한 내용은 STA 사용 설명서를 참조하십시오.

5. 해당하는 경우 개인 실행 보고서 정책에 대한 원래 소유권을 복원합니다. 자세한 내용은 STA 사용 설명서를 참조하십시오.

이전 STA 서버 구성 해제(선택 사항)

이 절차는 두 대의 서버 업그레이드 방식을 사용한 경우에만 적용됩니다. 새 STA 서버가 예상한 대로 작동 중임을 확인한 후 이 절차를 수행할 수 있습니다.

1. 각 라이브러리의 SNMP 구성의 트랩 수신자에서 이전 STA 1.0.x 또는 STA 2.0.x 서버를 구성 해제합니다. 자세한 내용은 STA 사용 설명서를 참조하십시오.

2. 이전 STA 1.0.x 또는 STA 2.0.x 서버를 구성 해제합니다.

실패한 데이터베이스 업그레이드 복구(선택 사항)

주의:

이 절차는 반드시 Oracle 지원 담당자의 지시에 따라서 수행하십시오.

이 절차는 작업 8: 이전 데이터베이스 업그레이드의 데이터베이스 업그레이드가 성공적으로 완료되지 않고 업그레이드를 반복하려는 시도도 실패한 경우에만 수행합니다.

1. 작업 7: 이전 STA 데이터베이스 처리 및 로드, 6단계에서 작업 8: 이전 데이터베이스 업그레이드까지 반복합니다.

   업그레이드가 다시 실패할 경우 데이터베이스가 알 수 없는 상태가 되며 손상되었을 가능성이 있으므로 데이터베이스를 새로 설치된 원래 상태로 복원해야 합니다. 다음 단계를 진행합니다.

2. 손상된 업그레이드된 데이터베이스를 삭제합니다.

   # mysql -uroot -p -e "drop database stadb;"
   

3. STA 데이터베이스 백업 위치로 변경하고 작업 5: 새 STA 데이터베이스 덤프(선택 사항)에서 만든 새 설치 데이터베이스 덤프 파일을 로드합니다.

   예를 들면 다음과 같습니다.

   # cd /dbbackup
   # mysql -uroot -p -e < /home/oracle/STA_FRESH_INSTALL_BACKUP.sql
   

4. 작업 8: 이전 데이터베이스 업그레이드를 수행합니다.

5. STA를 새 설치로 구성합니다. 자세한 내용은 다음 절을 참조하십시오.

   • STA의 라이브러리 연결 구성

   • STA 서비스 구성