이 장에는 다양한 STA 서비스 관리에 대한 자세한 내용이 포함되어 있습니다. 처음으로 이런 서비스를 구성하는 경우 STA 설치 및 구성 설명서를 참조하십시오.
이 장은 다음 절로 구성됩니다.
STA 서비스 데몬인 staservd는 STA 백업 및 STA 리소스 모니터 서비스를 관리하고 실행하는 지속적으로 실행 중인 Linux 서비스입니다. STA 백업 및 STA 리소스 모니터 서비스 모두 STA 서비스 데몬 내 별도의 실행 스레드로 실행됩니다.
STA 서비스 데몬은 STA 서버가 부트되면 시작되며(STA start all 명령 사용) 서버가 종료되면 종료됩니다. 다음 명령을 사용하여 STA 서비스 데몬의 상태를 시작, 중지 및 확인할 수도 있습니다.
STA 서비스 데몬을 시작하려면 다음을 수행합니다.
# STA start staservd
Starting staservd Service...
staservd service was successfully started
STA 서비스 데몬을 중지하려면 다음을 수행합니다.
# STA stop staservd
Stopping the staservd Service...
Successfully stopped staservd service
STA 서비스 데몬의 상태를 확인하려면 다음을 수행합니다.
# STA status staservd
staservd service is running
STA 명령에 대한 자세한 내용은 제 1 장 서버 관리를 참조하십시오.
주:
STA 설치 후 STA 서비스 데몬은 STA 백업 및 STA 리소스 모니터 서비스를 시작하지만 해당 서비스는 구성될 때까지 활성화되지 않습니다. 이러한 서비스를 구성하려면 STA 설치 및 구성 설명서를 참조하십시오.STA 백업 서비스는 STA 서비스 데몬 내에서 실행 중인 여러 서비스 중 하나입니다. 이 서비스는 STA 데이터베이스 및 키 구성 디렉토리의 자동 전체 백업을 수행하고, 이러한 파일을 STA 서버의 지정된 위치로 쓰거나 압축된 형식으로 원격 서버에 씁니다. Oracle은 원격 백업 서버를 구성할 것을 권장합니다.
계속하기 전에 STA 서비스 데몬이 실행 중인지 확인하십시오. STA 서비스 데몬을 참조하십시오.
STA 백업 서비스는 /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin에 있는 관리 유틸리티인 staservadm을 사용하여 구성됩니다. STA 백업 서비스를 구성하려면 STA 설치 및 구성 설명서를 참조하십시오.
구성되면 STA 백업 서비스는 다음 프로세스를 24시간마다 한 번씩 수행합니다.
다음 파일 유형의 고속 덤프(핫 백업이라고도 함)를 시작합니다.
MySQL 데이터베이스 덤프 파일
MySQL 이진 로그 파일
STA 서비스 데몬 및 STA WebLogic 구성 파일
STA 서비스 데몬 및 STA 백업 서비스 관리 로그
덤프 파일을 지정된 백업 호스트로 전송합니다.
전날의 전체 덤프 파일을 STA 서버에서 삭제합니다.
현재 일의 덤프 파일 복사본을 STA 서버의 /sta_db_backup/local 디렉토리에 씁니다.
현재 환경 설정의 상태를 표시합니다.
# ./staservadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Backup Service Settings: Configured [yes] File Transfer –S [SCP] Full Backup –T [11:00] Sleep Interval –i [350 sec] Backup Hostname –s [stabaksvr] Backup Username –u [stabck] Backup Password –p [*******] Backup Directory –d [/home/stabck/STAbackups] Database Username –U [stadba] Database Password –P [*********]
Configured 필드가 [no]인 경우 백업 서비스는 유휴 모드로 실행 중이며 어떠한 백업도 수행하고 있지 않습니다. 적절한 구성 설정을 제공해야 합니다. 자세한 내용은 STA 설치 및 구성 설명서를 참조하십시오.
현재 환경 설정을 지웁니다.
# ./staservadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Backup Service Settings: Configured [no] File Transfer –S [SCP] Full Backup –T [00:00] Sleep Interval –i [300 sec] Backup Hostname –s [] Backup Username –u [] Backup Password –p [] Backup Directory –d [] Database Username –U [] Database Password –P []
백업 서비스가 더 이상 구성되지 않으며 유휴 상태로 돌아갑니다. 이제 새 설정을 제공할 수 있습니다. 자세한 내용은 STA 설치 및 구성 설명서를 참조하십시오.
파일이 대상 서버로 성공적으로 전송되었는지 확인하려면 다음과 같이 하십시오.
STA 서버에서 로그를 확인합니다.
대상 백업 서버로 로그온하고 백업 디렉토리의 컨텐츠를 나열합니다.
STA 서버에 시스템 루트 사용자로 로그온합니다.
STA 데이터베이스 백업 로그 디렉토리로 변경합니다.
# cd /sta_logs/db/backups
staservd.log.0 파일에서 "INFO: done. Database dump completed." 문자열을 검색합니다. 이 파일은 백업 서비스 구성 유틸리티의 작업을 등록합니다.
# grep "INFO: done. Database dump completed" staservd.log.0
INFO: done. Database dump completed, file located at /dbbackup/local/20130721_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130722_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130723_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130724_133755.stafullbackup.sql
대상 백업 서버로 로그온합니다.
데이터베이스 백업 로그 디렉토리의 파일을 나열합니다.
이 예에서는 /backups/tbivb01 디렉토리가 STA 서버 "tbivb01"에서 백업 파일을 수신하도록 이전에 설정되었습니다.
# ls –1 /backups/tbivb01
0.stadb-bin.000023.gz 0.stadb-bin.000024.gz 0.stadb-bin.000026.gz 0.stadb-bin.000027.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000025.gz 20130723_133755.stadb-bin.000026.gz 20130723_133755.stafullbackup.sql.gz
/sta_db_backup/local 디렉토리의 파일을 나열하여 최신 백업 파일의 복사본이 STA 서버에 로컬로 저장되었는지 확인합니다. 예를 들면 다음과 같이 하십시오.
# ls –l /dbbackup/local
20130721_133755.conf.zip 20130721_133755.fmwconfig.zip 20130721_133755.stafullbackup.zip
나열된 파일의 이름은 YYYYMMDD_HHMMSS.filename.zip 형식입니다.
제 3 장 암호 관리를 참조하십시오.
STA 리소스 모니터 서비스는 데이터베이스 테이블스페이스 및 디스크 볼륨 공간, 로깅 볼륨 디스크 공간 및 물리적 메모리 사용을 포함하여 STA 서버 리소스를 모니터하고 보고합니다.
각 리소스에 대한 HWM(상위 워터마크) 사용을 설정할 수 있습니다. 상위 워터마크는 경보가 발생하는 임계값입니다. 임계값에 도달하거나 이를 초과하면 표준 일간 리소스 보고서에 경보가 기록되고 하나 이상의 지정된 수신자에게 선택적으로 전자 메일이 전달됩니다.
예를 들어 데이터베이스 테이블스페이스 HWM을 60%로 설정하는 경우 STA 리소스 모니터가 STA 응용 프로그램에서 최대 허용 가능 데이터베이스 테이블스페이스의 60% 이상을 사용했음을 감지하면 테이블스페이스 경보가 설정되고 지정된 수신자에게 전자 메일이 전송됩니다. 또한, Nag 모드가 설정된 경우 리소스 모니터는 시스템을 스캔할 때마다 계속해서 경보 전자 메일을 전송합니다.
STA 리소스 모니터 서비스는 /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin에 있는 해당 관리 유틸리티인 staresmonadm을 사용하여 구성됩니다. STA 리소스 모니터 서비스를 구성하려면 STA 설치 및 구성 설명서를 참조하십시오.
다음 명령을 입력하여 환경 설정의 현재 상태를 질의합니다.
# ./staresmonadm –Q
Configured 필드가 "no"인 경우 리소스 모니터 서비스는 리소스를 모니터하거나 보고서를 전송하지 않는 "idle" 모드로 실행 중입니다. 서버를 구성해야 합니다. 자세한 내용은 STA 설치 및 구성 설명서를 참조하십시오.
구성된 STA 리소스 모니터 서비스의 출력 예:
# ./staresmonadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Resource Monitor Service Settings: Configured [yes] Send Reports –T [13:00] Sleep Interval –i [600 sec] Alert Nagging –n [on] DB Username –U [sta_dba] DB Password –P [*********] DB Tablespace hwm –t [65%] DB Backup hwm (/dbbackup) –b [65%] DB Data hwm (/dbdata) –d [65%] Log Volume hwm (/var/log/tbi) –l [65%] Root Volume hwm (/) –z [70%] Tmp Volume hwm (/tmp) –x [80%] System Memory hwm –m [75%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [john.doe@company.com] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
다음 명령을 입력하여 현재 환경 설정을 지웁니다.
# ./staresmonadm –C
리소스 모니터 서비스가 더 이상 구성되지 않으며 유휴 상태로 돌아갑니다. 이제 새 설정을 제공할 수 있습니다. 자세한 내용은 STA 설치 및 구성 설명서를 참조하십시오. 예를 들면 다음과 같이 하십시오.
# ./staresmonadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Resource Monitor Service Settings: Configured [no] Send Reports –T [00:00] Sleep Interval –i [300 sec] Alert Nagging –n [off] DB Username –U [] DB Password –P [] DB Tablespace hwm –t [–1%] DB Backup hwm (/dbbackup) –b [–1%] DB Data hwm (/dbdata) –d [–1%] Log Volume hwm (/var/log/tbi) –l [–1%] Root Volume hwm (/) –z [–1%] Tmp Volume hwm (/tmp) –x [–1%] System Memory hwm –m [–1%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
제 3 장 암호 관리를 참조하십시오.
리소스 모니터 보고서는 STA 리소스 모니터 서비스 관리 유틸리티인 staresmonadm을 사용하여 구성됩니다. STA 리소스 모니터 서비스를 구성하려면 STA 설치 및 구성 설명서를 참조하십시오.
리소스 모니터는 다음과 같은 서로 다른 두 가지 보고서를 생성할 수 있습니다.
리소스 모니터 표준 보고서는 하루에 한 번 staresmonadm –T 옵션에서 지정한 시간 쯤에 전송됩니다. 시간을 설정하지 않는 경우 자정 이후 첫번째 스캔 시 보고서가 전송됩니다. 이 보고서는 이 서비스를 구성할 때 지정한 전자 메일 수신자에게 전송됩니다.
보고서는 다음 서버 리소스에 대한 데이터를 제공합니다. 이러한 리소스가 상위 워터마크 임계값을 초과하는 경우 보고서에 경보가 표시됩니다.
데이터베이스 테이블스페이스 및 볼륨
로깅, 백업 및 루트 볼륨
임시 디렉토리
시스템 메모리 사용
주:
보고된 값은 마운트 지점을 기준으로 합니다. 모니터된 여러 항목이 동일한 마운트 지점을 공유하는 경우 이러한 항목에 대해 보고된 값은 동일합니다.STA RESOURCE MONITOR STANDARD REPORT System: tbivb03 Scanned: 2013-10-24 11:30:14 Database Tablespace HWM : 60.00% Used : <0.1% MB Used : 13 MB Free : 75763 MB Total : 75776 Location : /dbdata/mysql Database Volume HWM : 60.00% Used : 6.80% MB Used : 6855 MB Free : 93939 MB Total : 100794 Directory : /dbdata/mysql ...
staresmonadm 경보 Nag 모드(–n) 옵션이 "on"으로 설정된 경우 매 스캔 후 리소스 고갈 경보 보고서가 전송됩니다. Nag 모드가 해제된 경우 표준 보고서에만 경보가 표시됩니다.
각 스캔 간 간격은 일시 정지 간격(–i) 속성에서 결정하며 보고서는 이 서비스를 구성할 때 지정한 전자 메일 수신자에게 전송됩니다. 살펴본 문제를 해결하는 데 도움이 되도록 보고서 내에 권장 사항이 제공됩니다.
STA RESOURCE DEPLETION REPORT
System: server01
Scanned: 2013-10-24 11:34:47
************************************************************
* A L E R T S *
************************************************************
==================================================
ALERT – Low System Physical Memory
==================================================
Physical memory usage has exceeded threshold value!
HWM [1.00%]
Used [48.24%] (!)
MB Used [7757]
MB Free [8324]
MB Total [16080]
Hostname [server01]
Recommendations:
1) Shutdown unneeded processes.
2) Under Linux, try releasing unused caches using commands:
# free –m
# sync
# /sbin/sysctl –q vm.drop_caches=3
# free –m
3) Install additional memory.
STA 서비스는 실행 스크립트, 서버 및 클라이언트 응용 프로그램을 포함하는 Java jar 파일, 구성 파일, 덤프 파일, 로깅 파일 및 누적 데이터 파일로 구성됩니다. 이 절에서는 각 항목의 용도 및 위치에 대해 설명합니다.
STA 서비스 데몬 시작 및 종료 스크립트 staservd 및 시스템 실행 레벨 심볼릭 링크는 다음 디렉토리에 있습니다. 이 스크립트 및 연관된 심볼릭 링크는 STA 설치 프로그램에 의해 만들어집니다.
/etc/init.d/staservd—기본 시작 및 종료 스크립트
/etc/rc0.d/K04staservd—시스템 종료에 대한 심볼릭 링크
/etc/rc1.d/K04staservd—시스템 종료에 대한 심볼릭 링크
/etc/rc2.d/S96staservd—시스템 시작에 대한 심볼릭 링크
/etc/rc3.d/S96staservd—시스템 시작에 대한 심볼릭 링크
/etc/rc4.d/S96staservd—시스템 시작에 대한 심볼릭 링크
/etc/rc5.d/S96staservd—시스템 시작에 대한 심볼릭 링크
/etc/rc6.d/K04staservd—시스템 종료에 대한 심볼릭 링크
STA 백업 서비스 관리 유틸리티인 staservadm은 oracle.tbi.serveradm.jar 파일에 포함되어 있는 이름이 ServerAdm인 Java 클라이언트 응용 프로그램을 호출하는 Perl 스크립트입니다. 자세한 내용은 STA 백업 서비스를 참조하십시오.
STA 리소스 모니터 관리 유틸리티인 staresmonadm은 oracle.tbi.resmonadm.jar 파일에 포함된 이름이 StaResMonAdm인 Java 클라이언트 응용 프로그램을 호출하는 Perl 스크립트입니다. StaResMonAdm은 STA 서비스 데몬과 통신하여 런타임 환경 설정을 설정하고 재설정하는 RMI 클라이언트입니다. 자세한 내용은 STA 리소스 모니터 서비스를 참조하십시오.
테이블 2-1에는 실행 프로그램 및 해당 위치가 나와 있습니다.
| 프로그램 |
위치 |
|---|---|
|
STA 서비스 프로그램 Jar 파일 |
$STAHOME/common/lib/oracle.tbi.server.jar |
|
STA 백업 서비스 관리 유틸리티 Java 응용 프로그램 Jar 파일 |
$STAHOME/common/lib/oracle.tbi.serveradm.jar |
|
STA 백업 서비스 관리 유틸리티 사용자 스크립트 파일, staservadm |
$STAHOME/common/bin/staservadm |
|
STA ResMon 관리 유틸리티 Java 응용 프로그램 Jar 파일 |
$STAHOME/common/lib/oracle.tbi.resmonadm.jar |
|
STA ResMon 관리 유틸리티 Java 사용자 스크립트 파일, staresmonadm |
$STAHOME/common/bin/staresmonadm |
각 항목에 대한 설명은 다음과 같습니다.
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
STA 데이터베이스 백업에는 다음 유형의 파일이 포함됩니다.
STA 서비스 데몬 서버, STAServer 및 해당 백업 서비스 구성 유틸리티 ServerAdm의 작업을 기록합니다. 관리 로그는 각각 크기가 최대 1.0MB인 최대 10개의 로그 파일로 구성된 모음입니다. 로그 파일 이름은 *.log.N 형식이며 여기서 N은 로그 번호입니다(staservd.log.0, staservadm.log.0, staservd.log.1 등).
로그는 staservd.log.9가 채워지면 로그 파일#1이 재사용되는 식으로 순환됩니다. 활성 로그 파일은 항상 #0 (staservd.log.0)입니다. 로그 #0이 채워지면 로그 #1로 이름이 바뀌고 새 로그 #0이 시작됩니다. 기본적으로 STAServer 및 ServerAdm 로그는 다음 디렉토리에 저장됩니다.
/STA_logs/db/backups
STA_logs의 기본 위치는 /var/log/tbi입니다.
로그 위치 및 내부 형식(단순 ASCII 텍스트 또는 XML 마크업 중 하나)은 다음 위치에 있는 로깅 등록 정보 파일 staservd.log.props 및 staservadm.log.props에 의해 제어됩니다.
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
각 항목에 대한 설명은 다음과 같습니다.
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
MySQL 데이터베이스 덤프 파일은 데이터베이스 스키마 및 데이터 컨텐츠의 적시 스냅샷입니다. STA 백업 서비스는 다음 작업을 수행합니다.
이 절에서 논의한 파일 유형에 대해 24시간마다 한 번 수행되는 고속 덤프(핫 백업이라고도 함)를 시작합니다.
최신 덤프 파일을 지정된 백업 호스트로 전송합니다.
전날 전체 덤프 파일을 로컬 백업 디렉토리에서 삭제합니다.
현재 일의 덤프 파일 복사본을 로컬 백업 디렉토리에 씁니다.
STA 백업 서비스는 기본적으로 해당 로컬 덤프 파일 및 증분 binlog 파일을 YYYYMMDD_HHMMSS.filename.sql 형식으로 /sta_db_backup/local 디렉토리에 저장합니다.
용어 증분 덤프는 데이터베이스를 변경하는 모든 트랜잭션을 기록하는 MySQL 이진 로그(binlog)를 가리킵니다. STA 백업 서비스는 binlog를 기본 데이터베이스 덤프를 따르는 증분 백업으로 처리합니다.
STA 증분 덤프는 마지막 전체 덤프 이후 생성된 모든 이진 로그로 구성됩니다. binlog를 재생하여 데이터베이스를 로그에 기록된 마지막 트랜잭션 상태로 복원할 수 있습니다. 복원은 최신 덤프 파일을 로드한 후 최신 데이터베이스 덤프 이후 생성된 모든 MySQL binlog를 순서대로 재생하는 작업으로 구성됩니다.
binlog 백업은 가장 최근의 전체 덤프 이후 생성된 모든 binlog 목록 작성 후 각각의 해당 로그(현재 열려 있는 로그 제외)를 백업 서버에 전송하는 것으로 구성됩니다.
백업 이진 로그 이름 지정 형식은 YYYYMMDD_HHMMSS.stadb–bin.log_sequence_number입니다.
MySQL 이진 로그 위치는 MySQL 설정 파일 /etc/my.cnf에 정의됩니다. 현재는 다음으로 설정되어 있습니다.
/STA_logs/db
백업 binlog 파일의 로컬 복사본은 다음 위치에 있습니다.
/sta_db_backup/local
최신 항목을 제외하고 백업 서버에 성공적으로 전송된 모든 binlog는 MySQL 명령 PURGE BINARY LOGS BEFORE NOW()를 사용하여 비워집니다. 따라서 현재 binlog 및 현재 일의 전체 백업 파일은 서버에 보존됩니다.
주의:
binlog 파일을 수동으로 삭제하지 마십시오.STA 응용 프로그램 데이터베이스를 복구하는 데 필요한 파일 이외에 STA 백업 서비스는 STA WebLogic 구성 파일 및 고유 STA 서비스 데몬 구성 파일도 백업합니다. 백업은 각 구성 디렉토리의 모든 파일 및 디렉토리에 대한 순환 백업입니다.
구성 파일 백업은 전체 STA 데이터베이스 덤프가 수행될 때 24시간마다 한 번씩 수행됩니다. 백업 파일 이름 형식은 YYYYMMDD_HHMMSS.filename.zip.gz입니다.
이러한 백업의 소스 및 대상 위치는 테이블 2-2에 나와 있습니다.
| 소스 위치 | 로컬 복사본 | 원격 복사본 |
|---|---|---|
|
$STAHOME/common/conf/* |
$BACKUPS/YYYYMMDD_HHMMSS.conf.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.conf.zip.gz |
|
$WLHOME/config/fmconfig/* |
$BACKUPS/YYYYMMDD_HHMMSS.fmconfig.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.fmconfig.zip.gz |
각 항목에 대한 설명은 다음과 같습니다.
$STAHOME = /Oracle_storage_home/StorageTek_Tape_Analytics
$WLHOME = /Oracle_storage_home/Middleware/user_projects/domains/TBI
$BACKUPS =/dbdata/mysql/backups
$RHOST = 백업 서버 IP 주소 또는 이름
$RDIR = 백업 서버의 디렉토리
모니터링 작업과 관련된 파일에는 다음 두 종류가 있습니다.
STA 서비스 데몬 및 리소스 모니터 관리 유틸리티인 staresmonadm의 작업을 기록합니다. 이러한 로그는 각각 크기가 최대 1.0MB인 최대 10개의 로그 파일로 구성된 모음입니다. 로그 파일 이름은 *.log.N 형식이며 여기서 N은 로그 번호입니다(staservd.log.0, staservadm.log.0, staservd.log.1 등).
로그는 staservd.log.9가 채워지면 로그 파일#1이 재사용되는 식으로 순환됩니다. 활성 로그 파일은 항상 #0 (staservd.log.0)입니다. 로그 #0이 채워지면 로그 #1로 이름이 바뀌고 새 로그 #0이 시작됩니다. 기본적으로 STA 서비스, STA ResMon 및 STA ResMonAdm 로그는 모두 다음 위치에 있습니다.
/STA_logs/db/backups
로그 위치 및 내부 형식(단순 ASCII 텍스트 또는 XML 마크업 중 하나)은 다음 위치에 있는 로깅 등록 정보 파일 staservd.log.props 및 staresmonadm.log.props에 의해 제어됩니다.
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
각 항목에 대한 설명은 다음과 같습니다.
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
기본적으로 ResMon은 시스템을 스캔할 때마다 수집한 값을 다음 위치에 있는 CSV(콤마로 구분된 값) 파일에 씁니다.
/STA_logs/db/staresmon.csv
Excel 및 MySQL과 같은 프로그램은 이 데이터 파일을 로드하여 시간 기반 값으로 다양한 분석 및 그래프 기능을 수행할 수 있습니다(예: 리소스 고갈 추세 분석).
주:
ResMon CSV 파일은 STA 백업 서비스에서 비우거나 롤링하거나 백업하지 않습니다.staresmon.csv의 각 레코드는 시스템의 스캔을 나타냅니다. 21열 레코드의 형식은 테이블 2-3에 나와 있습니다.
| 열 |
머리글 |
설명 |
형식 |
|---|---|---|---|
|
1 |
TIMESTAMP |
스캔 날짜 및 시간 |
"YYYY–MM–DD HH:MM:SS" |
|
2 |
TS_MB_MAX |
최대 테이블스페이스 |
123 |
|
3 |
TS_MB_USED |
사용된 전체 데이터베이스 공간 |
123 |
|
4 |
TS_MB_AVAIL |
남아 있는 데이터베이스 공간 |
123 |
|
5 |
TS_PCT_USED |
최대값의 백분율인 사용된 데이터베이스 테이블스페이스 |
12.34% |
|
6 |
TS_PCT_HWM |
최대값의 백분율인 데이터베이스 테이블스페이스 상위 워터마크 |
12.34% |
|
7 |
DBVOL_MB_MAX |
데이터베이스가 포함되어 있는 볼륨의 최대 사용 가능 공간 |
123 |
|
8 |
DBVOL_MB_USED |
사용된 전체 데이터베이스 디스크 볼륨 공간 |
123 |
|
9 |
DBVOL_MB_AVAIL |
남아 있는 데이터베이스 볼륨 디스크 공간 |
123 |
|
10 |
DBVOL_PCT_USED |
최대값의 백분율인 사용된 데이터베이스 볼륨 디스크 공간 |
12.34% |
|
11 |
DBVOL_PCT_HWM |
최대값의 백분율인 데이터베이스 볼륨 상위 워터마크 |
12.34% |
|
12 |
LOGVOL_MB_MAX |
로그가 포함되어 있는 볼륨의 최대 사용 가능한 공간 |
123 |
|
13 |
LOGVOL_MB_USED |
사용된 전체 로깅 디스크 볼륨 공간 |
123 |
|
14 |
LOGVOL_MB_AVAIL |
남아 있는 로깅 볼륨 디스크 공간 |
123 |
|
15 |
LOGVOL_PCT_USED |
최대값의 백분율인 사용된 로깅 볼륨 디스크 공간 |
12.34% |
|
16 |
LOGVOL_PCT_HWM |
최대값의 백분율인 로깅 볼륨 상위 워터마크 |
12.34% |
|
17 |
MEM_MB_MAX |
설치된 최대 물리적 RAM |
123 |
|
18 |
MEM_MB_USED |
사용된 전체 물리적 메모리 |
123 |
|
19 |
MEM_MB_AVAIL |
남아 있는 물리적 메모리 공간 |
123 |
|
20 |
MEM_PCT_USED |
최대값의 백분율인 사용된 물리적 메모리 공간 |
12.34% |
|
21 |
MEM_PCT_HWM |
최대값의 백분율인 물리적 메모리 상위 워터마크 |
12.34% |
STA 서비스 데몬, 백업 서비스, 백업 서비스 관리 유틸리티 및 STA 리소스 모니터 유틸리티 로깅은 다음 로깅 구성 파일에 의해 제어됩니다.
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
여기서 $STA_HOME은 STA 설치 중 지정된 STA 홈 위치입니다. 자세한 내용은 STA 설치 및 구성 설명서를 참조하십시오.
로깅 파일 컨텐츠 및 형식은 이 파일의 Java 로그 관리 등록 정보에 의해 제어됩니다. 테이블 2-4에는 이러한 등록 정보가 요약되어 있습니다. 자세한 내용은 다음 사이트에서 Oracle Java SE 설명서를 참조하십시오.
http://docs.oracle.com/en/java/
| 등록 정보 | 설명 |
STA 설정 |
|---|---|---|
|
java.util.logging.FileHandler.append |
파일 처리기가 기존 파일에 추가되어야 하는지 여부를 지정합니다. 기본값은 false입니다. |
true |
|
java.util.logging.FileHandler.count |
순환할 출력 파일 수를 지정합니다. 기본값은 1입니다. |
10 |
|
java.util.logging.FileHandler.formatter |
Formatter 클래스 이름을 지정합니다. 기본값은 java.util.logging.XMLFormatter입니다. |
사람이 읽을 수 있도록 Java.util.logging.SimpleFormatter를 사용합니다. java.util.logging.XMLFormatter는 주석 처리되었으며 사용 가능합니다. |
|
java.util.logging.FileHandler.level |
처리기에 대한 기본 레벨을 지정합니다. 기본값은 Level. ALL입니다. |
CONFIG |
|
java.util.logging.FileHandler.limit |
파일 하나에 쓸 최대 바이트 수를 대략적으로 지정합니다. 0을 입력하면 제한 없음을 나타냅니다. 기본값은 제한 없음입니다. |
500000(0.5 MB) |
|
java.util.logging.FileHandler.pattern |
출력 파일 이름 패턴을 지정합니다. 기본값은 "%h/java%u.log"입니다. |
/STA_logs/db/backups/staservd.log.%g /STA_logs/db/backups/staservadm.log.%g 여기서 STA_logs는 Linux 설치 중 설정된 로그 위치입니다. 자세한 내용은 STA 설치 및 구성 설명서를 참조하십시오. |
로그 레벨은 이 파일의 STA 로깅 등록 정보에 의해 제어됩니다. 이 등록 정보는 테이블 2-5에 요약되어 있습니다.
STA 데이터베이스 복원 절차는 최신 전체 데이터베이스 덤프를 로드한 후 해당 덤프 바로 뒤에 발생한 모든 이진 로그를 재생하는 작업으로 구성됩니다.
백업 서버 디렉토리에는 서로 다른 백업 파일 세트가 있습니다. 예를 들면 다음과 같이 하십시오.
# cd /data/stabackups
# ls –1
20130721_133755.conf.zip.gz 20130721_133755.fmwconfig.zip.gz 20130721_133755.stadb-bin.000024.gz 20130721_133755.stafullbackup.sql.gz 20130722_133755.conf.zip.gz 20130722_133755.fmwconfig.zip.gz 20130722_133755.stadb-bin.000024.gz 20130722_133755.stafullbackup.sql.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000021.gz 20130723_133755.stadb-bin.000022.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.stadb-bin.000024.gz 20130723_133755.stafullbackup.sql.gz
파일 이름 시간 기록 형식은 YYYYMMDD_HHMMSS입니다. 동일한 날짜 태그가 있는 모든 이진 로그는 전체 덤프가 로드된 후 데이터베이스에 재생됩니다.
다음 관리 작업이 여기에서 논의됩니다.
다음 절차를 사용하여 백업 파일을 STA 서버로 복사합니다.
특정일의 파일 전체 세트를 STA 서버로 복사합니다.
Oracle은 모든 파일을 /tmp 디렉토리에 복사할 것을 권장합니다. 예를 들어 STA가 sta.server.com 서버에 설치되어 있고 현재 백업 서버에 로그온되어 있다고 가정합니다.
# scp 20130723*.* sta.server.com:/tmp/.
Password:
STA 서버에 루트로 로그인합니다.
*.gz 파일의 압축을 풉니다. 예를 들면 다음과 같이 하십시오.
# cd /tmp
# gunzip 20130723*.*.gz
다음 절차를 사용하여 구성 디렉토리 파일을 복원합니다.
모든 STA 프로세스를 중지합니다. 그런 다음 MySQL 서버만 다시 시작합니다.
# STA stop all
# STA start mysql
STAServer 및 STA 서비스 데몬 구성 디렉토리의 압축을 풉니다.
zip 파일은 기존 파일을 복원하거나 덮어쓸 수 있도록 전체 디렉토리 경로를 포함하여 만들어집니다. unzip 명령에서는 –d 옵션을 지정하여 복원 경로의 루트를 배치할 위치를 지정할 수 있습니다. 추가 옵션을 사용하면 선택적 교체와 같이 더 많은 동작을 제어할 수 있습니다.
클린 복원의 경우 기존 구성 디렉토리를 완전히 교체해야 합니다. 원본을 먼저 백업하십시오. 예를 들면 다음과 같이 하십시오.
# cd $WLSHOME
# zip –vr fmwconfig.orig.zip fmwconfig
# rm –rf fmwconfig
# cd /tmp
# unzip –X –d/ 20130723_133755.fmwconfig.zip
# cd $STAHOME/common
# zip –vr conf.orig.zip conf
# rm –rf conf
# cd /tmp
# unzip –X –d/ 20130723_133755.conf.zip
각 항목에 대한 설명은 다음과 같습니다.
$WLSHOME =/Oracle_storage_home/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
다음 명령을 MySQL 루트 사용자로 수행합니다.
데이터베이스를 다시 로드하려면 다음을 수행합니다.
남은 stadb 데이터베이스가 있으면 제거합니다. 예를 들면 다음과 같이 하십시오.
# mysql –uroot –p –e 'drop database stadb;'
Password:
최신 전체 덤프를 로드합니다. 이렇게 하면 스키마를 만들고 모든 데이터를 설치하게 됩니다. 예를 들면 다음과 같이 하십시오.
# mysql –uroot –p –e 'source 20130723_133755.stafullbackup.sql;'
Password:
binlog를 재생하려면 다음을 수행합니다.
각 증분 덤프(binlog)를 최신에서 가장 오래된 순으로 실행합니다.
MySQL 서버에서 실행할 이진 로그가 둘 이상인 경우 가장 안전한 방법은 서버에 대한 단일 연결 및 모든 이진 로그 컨텐츠를 실행할 단일 MySQL 프로세스를 사용하여 모두 처리하는 것입니다.
예를 들면 다음과 같이 하십시오.
# mysqlbinlog 20130723_133755.sta-binlog.000021 \
> 20130723_133755.sta-binlog.000022 \
> 20130723_133755.sta-binlog.000023 \
> 20130723_133755.sta-binlog.000024 |mysql –u root –p
다른 방법은 모든 로그를 단일 파일로 통합한 다음 해당 파일을 처리하는 것입니다.
# mysqlbinlog 20130723_133755.sta-binlog.000021 > /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000022 >> /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000023 >> /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000024 >> /tmp/recoversta.sql
# mysql –u root –p –e 'source /tmp/recoversta.sql'
주:
명령줄에 암호를 제공하지 않으면 MySQL은 계속하기 전에 사용자에게 프롬프트를 표시합니다.아래 예에 나와 있는 것처럼 이진 로그를 처리하면 서버에 대한 다중 연결이 생성될 수 있습니다. 첫번째 로그 파일에 CREATE TEMPORARY TABLE 문이 있고 두번째 로그에 해당 임시 테이블을 사용하는 문이 포함되어 있는 경우 다중 연결로 인해 문제가 발생될 수 있습니다. 첫번째 MySQL 프로세스가 종료되면 서버는 임시 테이블을 삭제합니다. 두번째 MySQL 프로세스가 해당 테이블을 사용하려고 시도하면 서버는 "unknown table"을 보고합니다.
# mysqlbinlog binlog.000001 |mysql –u root –p #<=== DANGER!!
# mysqlbinlog binlog.000002 |mysql –u root –p #<=== DANGER!!
Linux 시스템 루트 사용자로 다음 명령을 입력합니다.
# STA start all
다른 복원 방법은 적시 복원으로, 이 방법에서는 특정 시작 시점에서 특정 종료 시점까지 이진 로그를 재생할 수 있습니다.
예를 들어 이진 로그의 내용을 검토한 후 잘못된 작업으로 인해 로그 항목 #6817916 바로 뒤에 몇 개의 테이블이 삭제된다는 사실을 발견합니다. 전날 수행된 전체 덤프에서 데이터베이스를 복원한 후 STA 서비스를 하나라도 다시 시작하기 전에 이 절차에 나와 있는 명령을 사용하여 초기 로그 항목 번호 "176"에서 항목 번호 "6817916"까지 최신 이진 로그를 재생할 수 있습니다.
다음 절차를 사용하여 로그 번호 범위에서 STA 데이터베이스를 복원합니다.
모든 STA 프로세스가 종료되고 MySQL 서버만 실행 중이어야 합니다.
# STA stop all
# STA start mysql
MySQL 루트 사용자로 유효한 작업을 추출합니다. 예를 들면 다음과 같이 하십시오.
# mysqlbinlog ––start–position=176 ––stop–position=6817916
/var/log/tbi/db/stadb–bin.000007 > ./recover.sql
데이터베이스에 적용합니다. 예를 들면 다음과 같이 하십시오.
# mysql –uroot –p –e 'source ./recover.sql'
Password:
Linux 시스템 루트 사용자로 STA 응용 프로그램 및 STA 서비스 데몬을 다시 시작합니다.
# STA start all
적시 또는 증분 복구 작업에 대한 자세한 내용은 다음 사이트에서 MySQL 설명서를 참조하십시오.