IT Japan

DBA를 위한 Linux 쉘 스크립팅 입문 본문

카테고리 없음

DBA를 위한 Linux 쉘 스크립팅 입문

swhwang 2016. 3. 23. 00:24
반응형

Linux 환경에서 오라클 데이터베이스를 설치, 운영, 유지보수 하는데 필요한 기본적인 bash 쉘 스크립트를 소개합니다.

게시일: 2005 11

지금으로부터 7년 전, 오라클은 Linux 운영체제를 위한 최초의 상용 데이터베이스를 발표하였습니다. 그 이후로, Oracle, Red Hat, Novell/SUSE 등의 벤더가 서로 협력하며 데이터베이스 및 애플리케이션 성능을 최적화한 Linux 커널을 개발해 왔습니다. 이러한 이유로, Oracle Database 10g for Linux는 운영체제와 긴밀하게 연관된 개선 기능을 포함하고 있습니다. 이제 DBA들에게도 Linux 기반 시스템을 최적의 상태로 관리하기 위한 경험과 지식이 필요하게 되었습니다.

시스템 관리자와 DBA 사이에는 고전적인 역할의 구분이 이루어져 왔습니다. 하지만 실제 상황에서 이러한 구분이 항상 명확한 것은 아닙니다. 많은 IT 조직은 데이터베이스와 운영체제를 동시에 책임지는 직원들을 고용하기도 합니다. 또 오라클 데이터베이스 역시 운영체제의 리소스와 밀접한 연관성을 가지고 있으며, 주어진 환경과 긴밀한 통합을 이루도록 설계되어 있습니다.

또 많은 시스템 관리자와 DBA들은 자신들이 담당하는 업무를 자동화하기를 원하고 있습니다. 소프트웨어의 설치, 시스템 리소스의 모니터링, 시스템의 관리와 같은 반복적이고 오류 가능성이 높은 작업들은 자동화된 프로세스를 통해 처리하는 것이 훨씬 효율적입니다.

이러한 작업을 자동화하는 방법의 하나로 쉘 스크립팅을 활용할 수 있습니다. 시스템이 시작되고 셧다운 되는 과정에서 다양한 스크립트가 호출됩니다. 오라클 및 써드 파티 벤더가 제공하는 유틸리티들 역시 쉘 스크립트를 통해 호출됩니다. 쉘 스크립트는 쉽고 빠르게 개발할 수 있다는 장점 때문에 애플리케이션 프로토타입 개발을 위한 도구로 오랜 기간 활용되어 왔습니다. 시스템 관리자들은 쉘 스크립팅이 제공하는 기능들을 이용하여, 주어진 환경에 맞춤화된 솔루션을 개발하고 있습니다.

본 문서에서는, Linux 플랫폼에서 오라클 데이터베이스를 설치, 운영, 유지보수 하는데 필요한 기본적인 “bash” 쉘 스크립트를 소개합니다. 본 문서는 Linux 스크립트에 처음 입문하는 사용자, 또는 Linux를 처음 접하는 DBA를 대상으로 작성되었으므로, 경험이 많은 Linux 시스템 관리자들에게는 크게 도움이 되지 않을 수도 있음을 참고하시기 바랍니다.

쉘 스크립트란 무엇인가?

쉘 스크립트란 일련의 명령을 포함하는 텍스트 파일입니다. 사용자가 이 파일을 실행하면, 파일에 포함된 명령이 순서대로 실행되게 됩니다. (shell)이란 Linux 커널과의 커뮤니케이션을 위해 사용하는 커맨드라인 사용자 인터페이스를 지칭하는 용어로, C (csh), Korn (ksh), Bourne (sh), Bourne-Again (bash) 등이 널리 사용되고 있습니다. 쉘은 파일 또는 터미널로부터 입력된 라인을 읽어 해독 과정을 거친 후 커맨드를 실행하는 역할을 담당하며, 이러한 점에서 쉘 역시 커맨드의 일종으로 볼 수 있습니다. Bourne-Again (bash) 쉘은 위에서 언급된 쉘들의 기능을 대부분 포함하고 있으며, 본 문서에서도 bash 쉘을 이용하여 스크립트 작성 방법을 설명하게 될 것입니다.

스크립트 파일의 첫 번째 라인에는 스크립트를 실행할 때 어떤 쉘을 사용할 것인지 정의하게 됩니다. 그 예가 다음과 같습니다:

#!/bin/bash

       

쉘 스크립트를 사용하는 이유는 무엇인가?

DBA 경험이 어느 정도 있는 사용자라면 쉘 스크립팅이 갖는 가치에 대해 이미 잘 알고 있을 것입니다. 하지만 UNIX 시스템의 경험이 없는 사용자에게, 암호처럼 얽힌 쉘 커맨드는 무척 어지럽고 성가시게 보일 수도 있습니다. 또 한편으로, Oracle 10g가 데이터베이스 외부의 운영체제 레벨에서 데이터를 처리하기 위한 안정적인 플랫폼을 함께 제공하고 있기도 합니다.

하지만 쉘 스크립트를 사용해야 할 이유는 여러 곳에서 찾아볼 수 있습니다. 그 몇 가지 예가 아래와 같습니다:

  • 이미 구현된 스크립트를 관리해야 하는 경우.
  • 오라클 소프트웨어를 설치하기 전에 수행되는 시스템 셋업 작업을 자동화하고자 하는 경우: 예를 들어, OS의 초기 상태를 점검하고 소프트웨어 설치 이전에 필요한 조치사항을 리포트하는 스크립트를 작성할 수 있습니다. 또 오라클 데이터베이스에 필요한 OS 사용자/그룹을 생성하고 환경 변수를 설정해 줄 수도 있습니다.
  • 스크립트 대신 오라클 데이터베이스를 이용하여 스케줄 기반의 작업을 실행할 수도 있습니다. 하지만 데이터베이스가실행 중이지 않은상태에서 실행되어야 할 작업이 있을 수도 있습니다. 데이터베이스(또는 리스너, 데이터베이스 관련 프로세스 등)를 시작하거나 중단하는 스크립트를 작성할 수도 있습니다. 이러한 작업은 데이터베이스 내부적으로는 처리가 불가능한 것들입니다.
  • 데이터베이스의 상태를 모니터링하기 위한 메커니즘이 필요한 경우(: 데이터베이스가 쿼리를 처리할 수 있는 상태인지 확인해야 하는 경우): 예를 들어 오라클과 직접적으로 연관되지 않은 프로세스와 리소스를 모니터링하는 스크립트를 작성하여 시스템의 상황을 보다 폭넓게 확인할 수 있습니다.
  • 백업의 자동화: Oracle Recovery Manager(RMAN)는 백업 스크립트의 개발을 위한 플랫폼 중립적인 유틸리티입니다. 쉘 스크립트에서 Oracle Recovery Manager를 호출하고 백업 및 복구 작업을 위해 활용할 수 있습니다.
  • 다양한 데이터베이스 제품을 동시에 지원해야 하는 환경: 여러 종류의 데이터베이스를 동시에 운영할 필요가 있을 수 있습니다. 단일 데이터베이스 제품으로 모든 요구사항을 만족하기 어려울 수도 있고, 특정 제품에 관련한 보안 관련 이슈가 제기될 수도 있습니다. 이러한 상황이라면, 특정 데이터베이스에 종속되지 않은 쉘 스크립팅을 활용하여 요구사항을 해결하는 것이 바람직할 것입니다.

쉘 스크립트의 적용이 바람직하지 않은 경우

오라클 데이터베이스에는 고전적인 RDBMS의 한계를 뛰어넘는 다양한 기능이 포함되어 있습니다. 다른 소프트웨어와 마찬가지로, 오라클 데이터베이스는 운영체제에서 제공되는 리소스를 사용합니다. 하지만 주변 환경을 인지하고 변경하는 능력은 다른 소프트웨어의 수준을 훨씬 뛰어넘습니다. SQL과 오라클의 고정 뷰(fixed view)를 이용하면 데이터베이스 내부로부터 시스템 전체를 조망하는 것이 가능합니다. 이에 반해, 쉘 스크립트는 데이터베이스 외부에서 바라본 시스템 뷰를 제공합니다. 쉘 스크립팅이 만병통치약이 될 수 없는 이유가 여기에 있습니다.

먼저, 운영체제 환경의 대부분을 데이터베이스 내부에서 모니터링하거나 변경하는 것이 가능하다는 사실을 인지할 필요가 있습니다. 오라클의 고정 뷰(fixed view, v$ 접두어를 가진 뷰)를 이용하면 서버(v$instance) 또는 데이터베이스가 실행중인 플랫폼(v$database)의 정보를 확인할 수 있습니다. 데이터베이스에 관련된 파일의 위치 및 속성도 같은 방법으로 확인이 가능합니다. 데이터파일(v$datafile, dba_data_files), temp 파일(v$tempfile, dba_temp_files), 리두 로그(v$logfile), 아카이브 로그(v$archived_log), 컨트롤 파일(v$controlfile) 등의 위치와 기타 속성을 데이터베이스로부터 직접 쿼리할 수도 있습니다. Flash Recovery Area($recovery_file_dest)에 대한 정보, 또는 init.ora 매개변수(db_recovery_file_dest, db_recovery_file_dest_size), 프로세스(v$process), 메모리(v$sga, v$sgastat) 등에 관련한 정보 역시 쉽게 확인이 가능합니다. 그 밖에도 다양한 PL/SQL 패키지가 제공되며, 하부 OS에 대한 액세스를 지원하는 Java/C 데이터베이스 오브젝트의 개발이 가능합니다.

데이터베이스 액세스가 빈번하게 요구되는 작업이라면, 스크립팅이 최선의 대안이 되기 어려울 것입니다. 뒷부분에서 설명하겠지만, SQL*Plus를 이용하여 스크립트에서 데이터베이스에 액세스하는 것이 가능합니다. 하지만 다른 언어를 이용하여 문제를 해결하는 것이 더 쉬울 가능성이 높습니다.

아래 표는 데이터베이스 내부로부터 접근 가능한 정보의 목록을 요약하고 있습니다:

서버/OS 정보

서버 정보의 확인

쿼리

설명

인스턴스가 실행 중인 서버의 이름

select host_name
from v$instance;

bash에서 같은 정보를 얻기 위해 사용할 수 있는 명령이 아래와 같음:

hostname

or

uname –n

운영 체제 플랫폼

select platform_name from v$database –-(10g)

아래 명령을 사용하여 같은 정보를 확인할 수 있음

uname –s

파일 정보

오라클 파일의 위치

쿼리

설명

컨트롤 파일

select name
from v$controlfile;

데이터베이스 컨트롤 파일의 위치. init.ora 파일의 control_files 매개변수에도 같은 정보가 정의되어 있음.

데이터파일

select file_name
from Dba_data_files;

데이터베이스 데이터파일의 위치

Temp 파일

select file_name
from Dba_temp_files;

데이터베이스 임시 파일의 위치

로그 파일

select member
from v$logfile;

리두 로그의 위치

아카이브 로그

select name
from v$archived_log

아카이브 리두 로그의 위치. init.ora 파일의 log_archive_dest_n 매개변수에도 같은 정보가 정의되어 있음. 데이터베이스가 아카이브 모드로 설정되지 않은 경우에는 쿼리 결과가 반환되지 않음.

Flash recovery area

select name
from v$recovery_file_dest

Oracle 10g에서 Flash Recovery Area를 위해 사용하는 디렉토리의 위치. init.ora 파일의 db_recovery_file_dest 매개변수에도 같은 정보가 정의되어 있음.

기타 매개변수에 정의된 파일 시스템 접근 위치

select *
from v$parameter

where value like '%/%'

or

value like '%/%';

쿼리 결과는 오라클 데이터베이스 버전에 따라 크게 달라질 수 있음. 반환되는 매개변수 값이 아래와 같음:

spfile
standby_archive_dest
utl_file_dir
background_dump_dest user_dump_dest
core_dump_dest
audit_file_dest
dg_broker_config_file1
dg_broker_config_file2

파일시스템 관련 경로 정보 표시

select directory_path from dba_directories

표준 데이터베이스 기능으로 포함되지 않은 파일에 액세스하기 위해 Oracle UTL_FILE_DIR 매개변수와 DIRECTORY 데이터베이스 오브젝트를 사용할 수 있음.

프로세스 정보

프로세서/프로세스

쿼리

설명

세션 프로세스

select p.spid, s.username, s.program

from v$process p, v$session s

where p.addr=s.paddr order by 2, 3, 1

spid ps –ef 실행 결과를 조합하여, 특정 프로세스의 OS 정보와 데이터베이스 정보를 비교할 수 있음.

parallelism 관련 프로세스

select slave_name, status
from v$PQ_SLAVE

Parallelism을 이용하여 로드, 쿼리, 오브젝트 생성, 복구, 복제 등의 데이터베이스 작업 성능을 개선할 수 있음. parallel_threads_per_cpu 매개변수는 인스턴스의 디폴트 “degree of parallelism”을 정의하는데 사용됨.

메모리 정보

메모리

쿼리

설명

Program Global Area

select * from V$PGASTAT

pga_aggregate_target 매개변수는 서버 연결을 위해 사용되는 메모리 사이즈의 설정을 위해 사용됨.

vmstat, top 등의 Linux 유틸리티를 사용하여 메모리 사용 현황을 모니터할 수 있음.

System Global Area

select * from v$sga

 

 

SGA_MAX_SIZE, SGA_TARGET 매개변수는 Oracle Database 10g의 다이내믹 메모리 할당 기능을 설정하는 용도로 사용됨. 또 다른 매개변수를 이용하면 특정 목적을 위해 메모리를 수동으로 할당할 수 있음.

메모리 할당 내역을 모니터하기 위해 다양한 Linux 유틸리티를 활용할 수 있음.

BASH 스크립트

스크립트는 (사용자의 개입이 없는) 자동화된 프로세스의 일부로써, 또는 (사용자의 입력을 요구하는) 인터액티브한 작업의 일부로써 실행될 수 있습니다. 파일의 실행 권한을 갖고 있다면, 커맨드라인에서 파일 이름을 입력하여 직접 실행하는 것도 가능합니다. 파일의 실행 권한은 없는 대신 읽기 권한을 갖고 있는 경우에도 sh명령을 이용하여 스크립트를 실행할 수 있습니다.

스크립트가 사용자의 입력 없이 실행되도록 프로그래밍된 경우, 다양한 호출 방법을 이용할 수 있습니다. 스크립트를 백그라운드에서 실행하여, 세션이 끊어진 경우에도 계속 실행되도록 하려는 경우는 아래와 같이 커맨드를 입력합니다:

nohup /path_to_dir/myscript_here.sh &

이 옵션은 오랜 실행시간을 갖는 스크립트를 실행할 때 유용하게 활용됩니다. at 커맨드는 정해진 시간에 스크립트를 실행하는 명령, cron은 스케줄 기반으로 스크립트를 실행하기 위한 명령입니다.

지금부터 스크립트의 출력 전환, 루프, 조건부 로직, 변수 할당 등에 관련한 기초적인 내용을 설명하겠습니다.

print_args.sh. 매개변수(argument)는 커맨드의 오른쪽에 위치하여 스크립트에 함께 전달되는 문자열을 의미합니다. 첫 번째 매개변수에 접근하기 위해서는 $1 변수가 사용됩니다. $0 변수는 스크립트의 이름을 저장하는 용도로 사용됩니다. $# 변수는 스크립트에서 사용되는 매개변수의 수를 의미합니다. 스크립트에서 전달되는 매개변수를 일괄적으로 확인하기 위해서는 while 루프와 shift 커맨드를 사용하는 것이 일반적입니다. 이 커맨드를 이용하면 매개변수 리스트에 존재하는 모든 매개변수를 순서대로 확인하는 것이 가능합니다.

while [ $# -ne 0  ]

do

        echo $1

        shift

done

스크립트가 파일 이름을 매개변수로 받고 (또는 파일 이름의 입력을 요구하고) 뒷부분에서 해당 파일을 읽는 작업을 수행하는 경우, 먼저 파일의 접근 및 읽기가 가능한지 확인하는 과정을 넣어 주어야 합니다. 예를 들어, 백업된 컨트롤 파일 중 하나를 선택하는 과정을 포함하는 복구용 스크립트의 경우, 아래와 같은 확인 과정이 필요합니다.

if [ ! -r $1 ]; then # not exists and is readable

                       echo "File $1 does not exist or is not readable."

               exit;

fi     

실제로 파일에 대해 테스트를 수행하기 위한 코드가 아래와 같습니다.

       

if [ ! -r $1 ];

대괄호([]) 안의 컨텐트가 TRUE인 것으로 평가되는 경우, if fi 사이에 정의된 커맨드가 실행되게 됩니다. 실제 테스트할 내용은 대괄호 안에 정의됩니다. 느낌표는 NOT의 의미를 갖습니다. -r 옵션은 파일이 읽기 가능한지를 점검합니다. 위 스크립트에서는 스크립트와 함께 전달된 첫 번째 매개변수를 테스트하고 있습니다. 다른 테스트 옵션( -d )을 사용하면, 입력된 항목이 디렉토리인지 확인할 수 있습니다 (is_a_directory.sh 참고).

do_continue.sh. 다음은 여러 가지 목적으로 사용자 입력을 읽어 들이는 일련의 커맨드로 구성된 스크립트입니다. 데이터의 손실 또는 예기치 않은 에러가 발생할 수 있는 프로세스를 실행하기 전에, 다음 단계의 커맨드를 정말로 실행할 것인지 사용자의 확인을 거치는 절차가 필요할 수 있습니다. 아래 예제에서는 사용자가 정말로 계속하기를 원하는지 묻는 프롬프트를 띄운 후, 커맨드라인으로부터 doContinue라는 이름의 변수를 읽어 들이고, 사용자가 입력한 값을 평가하고 있습니다. 사용자가 “y” 이외의 다른 값을 입력한 경우, 스크립트를 종료한다는 메시지를 사용자에게 띄운 후 스크립트의 나머지 부분을 실행하지 않고 바로 종료 처리합니다.

doContinue=n

echo -n "Do you really want to continue? (y/n) "

read doContinue

 

if [ "$doContinue" != "y" ]; then

      echo "Quitting..."

      exit

fi

적절한 권한과 환경을 갖춘 사용자만이 스크립트를 실행할 수 있도록 하는 것은 매우 중요합니다. 이 경우 스크립트를 실행하는 사용자가 누구인지 확인하는 과정이 필요하게 됩니다. 커맨드를 역인용부호(‘) 문자로 둘러싸면, 커맨드의 실행 결과가 스크립트로 반환되도록 할 수 있습니다. 아래 예제는 whoami 명령을 사용하여 현재 로그온한 사용자를 반환하고, date 커맨드를 이용하여 날짜를 확인하고 있습니다.

       

echo "You are logged in as 'whoami'";

 

if [ ‘whoami‘ != "oracle" ]; then

  echo "Must be logged on as oracle to run this script."

  exit

fi

 

echo "Running script at ‘date‘"

오라클 데이터베이스와 연동하도록 작성된 스크립트에서는 데이터베이스 암호와 같은 민감한 정보가 사용될 수 있습니다. stty –echo 커맨드는 스크린 echo를 비활성화하여 읽기 작업 과정에서 입력된 정보가 스크린 상에 표시되지 않도록 합니다. 암호 정보를 읽어 들여 변수(아래 예제의 pw)에 저장하고 난 뒤에는 다시 stty echo 명령을 사용하여 디스플레이를 활성화합니다.

       

stty -echo   

        echo -n "Enter the database system password:  "

        read pw

stty echo

Oracle 스크립트

파일 중 일부는 오라클 설치환경에 지정된 위치에 존재합니다. 오라클 인벤토리는 /etc/oraInst.loc 파일을 통해 확인할 수 있습니다. /etc/oratab 파일은 서버에 설치된 데이터베이스(또는 다른 오라클 프로그램)을 확인할 때 유용합니다.

get_inv_location.sh. 이 스크립트는 앞의 예제에 비해 덜 직관적입니다. 스크립트를 단계별로 나누어서 그 내용을 이해해 보기로 하겠습니다.

먼저 인벤토리 경로를 확인하기 위해서, (파일의 컨텐트를 출력하는) cat 커맨드의 실행 결과를 (주어진 패턴과 일치하는 라인을 출력하는 유틸리티인) grep으로 파이프(pipe) 처리합니다. 예제에서는 inventory_loc이라는 문자열을 포함하는 라인을 검색하고 있습니다.

cat /etc/oraInst.loc | grep inventory_loc

오라클이 2회 이상 설치되어 두 개 이상의 인벤토리 경로가 존재하는 경우, “#기호로 주석 처리된 라인을 제외하도록 설정할 수 있습니다. –v 옵션은 주어진 패턴을 포함하는 라인을 제외하도록 합니다.

       

cat /etc/oraInst.loc |grep -v "#"|grep inventory_loc

위 커맨드의 실행 결과 예가 아래와 같습니다:

inventory_loc=/u01/oraInventory

“>” 리다이렉션을 사용하면 표준 출력을 파일로 재설정할 수 있습니다. 파일이 존재하지 않는 경우에는 생성됩니다. 또 파일이 이미 존재하는 경우에는 덮어쓰기 처리됩니다.

       

cat /etc/oraInst.loc|grep -v "#"|grep inventory_loc > tmp

인벤토리 위치를 확인했다면, 이제 등호(=) 기호 앞의 데이터를 제거할 차례입니다. 이번에는 cat 커맨드의 실행 결과를 (가변 길이의 필드를 분할하는 용도로 자주 사용되는 패턴-스캐닝 언어인) awk를 이용하여 여러 개의 토큰(token)으로 분할합니다. –F 옵션은 awk가 등호 기호를 구분기호(delimeter)로 사용하도록 설정하는데 이용됩니다. 그런 다음 두 번째 토큰($2), 다시 말해 등호 기호 오른쪽의 전체 문자열을 출력합니다. 결과적으로 인벤토리 경로(/u01/oraInventory)가 얻어집니다.

cat tmp | awk -F= '{print $2}'

원하는 결과가 얻어졌다면 임시 파일은 삭제 처리합니다.

rm tmp

list_oracle_homes.sh. 데이터베이스의 ORACLE_HOME 경로를 확인하고자 하는 경우에는 여러 가지 방법이 활용 가능합니다. 데이터베이스 사용자로 로그인하여 echo 명령으로 $ORACLE_HOME 변수를 출력하는 것이 그 한 예입니다. 또는 /etc/oratab 파일의 내용을 검색하여 주어진 인스턴스와 연관된 이름을 가져올 수도 있습니다. 이 파일의 데이터베이스 엔트리는 아래와 같은 형식을 갖습니다.

       

$ORACLE_SID:$ORACLE_HOME:<N|Y>:

TESTDB ORACLE_SID로 갖는 ORACLE_HOME 엔트리 중 하나를 출력하기 위한 명령이 아래와 같습니다:

cat /etc/oratab | awk -F: '{if ($1=="TESTDB") print $2 }'

그렇다면 /etc/orainst 파일에 존재하는 모든 ORACLE_HOME 엔트리에 대해서 동일한 작업을 반복해 주어야 하는 경우에는 어떻게 해야 할까요? 아래 코드를 이용하면 리스트를 대상으로 한 반복 작업이 가능합니다.

dblist='cat /etc/oratab | grep -v "#" | awk -F: '{print $2 }''

 

for ohome in $dblist ; do

  echo $ohome

done

dblist 변수는 어레이로 사용되고 있으며, 모든 ORACLE_HOME 경로가 이 변수에 저장됩니다. 코드의 반복 처리를 위해서 for 루프가 정의되었고, 각각의 엔트리는ohome 변수에 저장된 후 표준 출력으로 echo 처리됩니다.

search_log.sh. 오라클 소프트웨어에서 관리되는 여러 가지 로그 파일을 모니터하기를 원하는 경우를 생각해 봅시다. 데이터베이스 경고 로그(database alert log)에는 데이터베이스 운영 과정에서 매우 중요한 메시지가 기록됩니다. 또 제품이 설치/삭제되거나 패치가 적용되는 경우에도 별도의 로그 파일이 생성됩니다. 아래 스크립트는 매개변수로 전달된 파일에 대해 검색 작업을 수행하고, “ORA-“라는 문자열이 포함된 모든 라인을 지정된 수신자에게 이메일로 전달합니다.

       

cat $1 | grep ORA- > alert.err

 

if [ 'cat alert.err|wc -l' -gt 0 ]

then

        mail -s "$0 $1 Errors" administrator@yourcompany.com < alert.err

fi     

위 코드는 alert.err 파일에 존재하는 단어의 수를 계산하고 있습니다. 단어 수(wc) 0보다 큰(-gt) 경우, if 블록의 컨텐트가 실행되고 mail (또는 send mail도 사용 가능합니다) 명령을 이용하여 메시지가 전달됩니다. 메시지의 제목에는 실행되는 스크립트($0), 검색되는 로그의 이름($1), 메시지 본분에서 검색 조건(ORA-)과 일치하는 라인의 수 등이 포함됩니다.

ORACLE_HOME, ORACLE_BASE, ORACLE_SID 등의 환경변수를 이용하면 Linux 환경에 저장된 오라클 리소스의 위치를 쉽게 확인할 수 있습니다. Oracle E-Business Suite 11i 애플리케이션 인스턴스를 관리하는 경우라면, APPL_TOP, TWO_TASK, CONTEXT_NAME, CONTEXT_FILE 등의 환경변수를 추가로 활용할 수 있습니다. 주어진 환경에서 사용 가능한 환경변수의 전체 목록을 확인하려면, 아래 명령을 실행하여 결과로 저장된 파일(myenv.txt)을 확인합니다:

env > myenv.txt

환경 변수를 여러 가지 방법으로 조합하면, 검색하고자 하는 파일의 위치를 쉽게 확인할 수 있습니다. 예를 들어 경고 로그(alert log)의 위치는 아래와 같이 정의됩니다.

       

$ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log

본 문서에서 소개된 기본적인 방법을 잘 활용하여, 경고 로그(또는 다른 파일)를 주기적으로 검색하고, 새로 발견된 에러를 이메일로 전송하는 스크립트를 작성하고 스케줄링할 수 있습니다. 그런 다음 로그 컨텐트를 다른 파일에 저장하여, 가장 최근에 발생한 에러 메시지만을 이메일을 통해 전송할 수 있습니다.

Oracle Recovery Manager Scripts. Oracle Recovery Manager(RMAN)는 데이터베이스 백업 및 복구 관리를 위한 유틸리티입니다. RMAN을 이용하여 작성한 백업 스크립트는 플랫폼과 무관하게 동작하기 때문에, 이기종 플랫폼 환경의 관리 업무를 극적으로 단순화할 수 있습니다. RMAN은 하부 운영체제에 의해 호출된 후 스크립트를 전달하는 방식으로 동작합니다. 예를 들어 콜드 백업을 위한 스크립트(cold.sh)는 다음과 같은 내용으로 작성됩니다:

       

#!/bin/bash

rman target / <<EOF

shutdown immediate;

startup mount;

backup spfile;

backup database;

alter database open;

delete noprompt obsolete;

quit;

EOF    

첫 번째 라인은 스크립트가 bash 쉘을 사용함을 정의하고 있습니다. 두 번째 라인은 Oracle Recovery Manager를 호출하고 ($ORACLE_SID 환경변수에 정의된) 타겟 데이터베이스에 OS 사용자 계정으로 로그인함을 의미합니다. 두 번째 라인 마지막의<<EOF는 이후 실행되는 커맨드가 RMAN에 의해 처리됨을 의미합니다. 그리고 마지막 라인의 EOF RMAN에 전달되는 커맨드의 마지막 부분임을 정의하고 있습니다. 마지막 라인이 처리된 후 RMAN은 데이터베이스를 셧다운하고 다시 시작하여 데이터베이스를 마운트한 후, 서버 매개변수 파일과 데이터베이스 컨텐트의 백업 작업을 수행합니다. 백업이 완료되면 데이터베이스가 오픈됩니다. 미리 정의된 보존정책의 기준보다 오래된 백업 파일은 자동 삭제됩니다. 백업 스크립트 작성에 관련한 자세한 정보는 RMAN 제품문서를 참고하시기 바랍니다.

야간 백업은 스케줄 기반으로 자동 실행되도록 설정하는 것이 일반적입니다. 위의 스크립트를 호출한 후 표준 출력을 지정된 이메일 주소로 전달하는 방법이 아래와 같습니다:

sh cold.sh | mail -s"Backup `date`" administrator@yourcompany.com

쉘 스크립트를 통해 다른 오라클 유틸리티를 실행하는 것도 물론 가능합니다. tnsping는 오라클 연결 식별자(Oracle connection identifier)가 리스너(listener)에 연결할 수 있는지 확인하는 유틸리티입니다. 데이터베이스 연결 문제를 점검하기 위해 이 유틸리티를 실행하는 예가 아래와 같습니다:

tnsping ptch04 |grep TNS-

데이터베이스 export/import (또는 data pump) 유틸리티 또한 스크립트에서 자주 활용되곤 합니다.

Database Installation. 데이터베이스 셋업 과정에서 수반되는 작업의 대부분을 자동화하는 것도 가능합니다. Linux 운영체제에 Oracle 10g를 설치하기 전에, 여러 가지 테스트를 실행하여 패키지의 최소요구버전과 커널 매개변수 설정을 검증하는 작업이 필요합니다. 패키지의 버전은 rpm 커맨드와 –q 옵션을 사용하여 확인할 수 있습니다.

       

rpm -q compat-libstdc++

(“virtual” 또는 “pseudo” 파일시스템으로 구분되는) /proc 파일시스템을 이용하면 시스템의 다양한 설정을 확인할 수 있습니다. /proc 파일시스템에서는 실제 파일이 저장되지 않으며, 그 대신 런타임 시스템 정보가 파일의 형태로 조회될 수 있습니다. 예를 들어 /proc/meminfo는 시스템의 메모리 정보를 포함하고 있으며, “grep MemTotal /proc/meminfo명령을 통해 시스템의 전체 메모리 크기를 조회하는 것이 가능합니다. 여기에 앞에서 설명한 awk를 적용하면, 킬로바이트 단위로 표시된 메모리 크기 정보를 추출해 낼 수 있습니다:

grep MemTotal /proc/meminfo | awk '{print $2}'

위와 같은 커맨드는 조회 결과에 따라 (시스템 업데이트 등의) 다른 작업이 요구되는 스크립트에서 유용하게 활용됩니다. 샘플 스크립트 중 10gchecks_kernel.sh 10gchecks.sh는 현재 버전 및 설정과 오라클의 권장 버전/설정을 비교하고 있습니다.

데이터베이스 모니터링. ps 커맨드를 이용하면 현재 프로세스 상태를 조회하고, 데이터베이스, 리스너, 스크립트 등의 프로세스가 실행 중인지 확인할 수 있습니다. 현재 서버에서 실행 중인 모든 데이터베이스의 목록을 확인하기 위한 스크립트가 아래와 같습니다:

       

echo "'ps -ef | grep smon|grep -v grep|awk '{print $8}'| awk -F \"_\"

'{print$3}'`"

위 스크립트는 한 눈에 이해하기에는 다소 복잡한 감이 있습니다. 첫 번째로 사용된 명령인 ps, 현재 서버에서 실행 중인 모든 프로세스의 목록을 출력합니다 (-ef 옵션은 모든 프로세스의 완전한 목록을 출력하도록 지정하고 있습니다). 다음으로 grep SMON(Oracle System Monitor 백그라운드 프로세스)의 목록만을 추출하기 위해 사용됩니다. 또 스크립트에서 실행한 grep 커맨드에 연관된 프로세스도 목록에서 제외시킬 필요가 있습니다. 다음으로 awk를 사용하여 리스트의 (시스템 프로세스 네임 정보- ora_smon_<oracle_sid>-에 해당하는) 8번째 컬럼을 추출해 냅니다. awk의 마지막 인스턴스는 “_” 기호를 검색 대상 구분문자로 사용하여,SMON 프로세스를 소유한 데이터베이스 네임을 출력합니다. 이때 “_” 기호를 큰 따옴표 안에 묶고 백슬래시(\) 기호를 앞에 붙여 주어야만 문자를 그대로 처리할 수 있습니다.

exec_sql.sh. 앞에서 설명한 것처럼, 사용자가 sqlplus에 접근할 수 있는 경우라면 쉘 스크립트에서 데이터베이스를 조회하는 것도 가능합니다. 아래 예제는 현재 데이터베이스와 세션 연결을 맺고 있는 머신의 리스트를 반환하고 있습니다:

       

#!/bin/bash

 

output='sqlplus -s "/ as sysdba" <<EOF

       set heading off feedback off verify off

       select distinct machine from v\\$session;

       exit

EOF

'

 

echo $output  

이 스크립트는 다른 프로그램으로 커맨드를 입력한다는 점에서 앞의 RMAN 스크립트와 유사합니다. 로컬 운영체제 레벨에서 인증된 연결은 sysdba 계정으로 데이터베이스에 접속합니다. 메시지 출력을 단순화하기 위해, 이 스크립트에서는 SQL*Plus heading, feedback, verify 옵션을 비활성화하고 있습니다. 그리고 마지막으로 쿼리의 실행이 완료되면 SQL*Plus의 실행을 종료합니다.

뷰 네임의 “$” 기호 앞에 붙은 더블 백슬래시(\\)는 문자열 처리를 위한 에스케이프 구문(escape sequence)입니다. 첫 번째 백슬래시는 두 번째 슬래시를 에스케이프 처리하고, 두 번째 백슬래시는 “$” 기호를 에스케이프 처리하고 있습니다. (깔끔하지는 못하지만 기능적으로는 완벽한 방법입니다.).

앞에서 설명한 것처럼 데이터베이스에 빈번한 액세스를 요구하는 코드가 필요하다면, 쉘 스크립팅은 결코 최선의 대안이 될 수 없습니다. 이러한 경우라면 스크립트를 PL/SQL, (쉘 스크립팅과 매우 유사한 문법을 사용하는) Perl, Python, Java 또는 그 밖의 언어로 작성하는 방법을 먼저 고려해 보시기 바랍니다.

결론

쉘 스크립팅은 반복적이고 오류의 가능성이 높은 관리 업무를 자동화하기 위한 매우 효과적인 도구로 활용됩니다. 본 문서에서 제공된 예제들은 매우 다양한 형태로 활용 가능하지만, 실제 환경에서 바로 활용하기에는 설명이 부족한 감이 있습니다. 시스템마다 고려해야 할 사항이 다르고 특이한 구성이 존재하기 마련입니다. 관리자는 각 시스템 환경의 요구사항을 만족하는 독자적인 솔루션을 개발할 수 있어야 합니다.



반응형
Comments