East's IT

1-6 Oracle Database 10g: "g" Stands for Grid   Cluster

 Oracle's grid infrastructure:
 • Low cost
 • High quality of service
 • Easy to manage

 Oracle Database Server 제품에 구현된 Grid infrastructure
 **1) Automatic Storage Management(ASM)
   2) Real Application Clusters(RAC)
   3) Oracle Streams
 **4) Enterprise Manager Grid Control(관리 인터페이스)
==============================================================================
1-8 << Oracle Database Architecture >>
==============================================================================
 Oracle Database Service는 내부적으로 크게 2 부분으로 구성됩니다.

 • Memory       : Oracle Instance (Process)

 • Storage(HDDs): Oracle Database (Files)
==============================================================================
1-9 Database Service Structures
==============================================================================
 Oracle Service
 ==================================================
 Instance

  • System Global Area (SGA)  : Memory  구조
  ------------------------------------------
  • Background processes      : Process 구조
 ==================================================
 Database files                      : Storage 구조
 ==================================================
 << 현재 실습용 환경에 구성된 서비스 >>

 • orcl service (orcl Database 서버) <-- 개발자에게 알려주셔야 합니다.
  • orcl database
  • orcl instance

(터미널)

$ ps -ef | grep orcl
oracle    7012     1  0 May20 ?        00:00:09 ora_pmon_orcl
oracle    7014     1  0 May20 ?        00:00:03 ora_psp0_orcl
oracle    7016     1  0 May20 ?        00:00:00 ora_mman_orcl
oracle    7018     1  0 May20 ?        00:00:13 ora_dbw0_orcl
oracle    7020     1  0 May20 ?        00:00:09 ora_lgwr_orcl
oracle    7022     1  0 May20 ?        00:01:05 ora_ckpt_orcl
oracle    7024     1  0 May20 ?        00:00:10 ora_smon_orcl
oracle    7026     1  0 May20 ?        00:00:00 ora_reco_orcl
oracle    7028     1  0 May20 ?        00:00:32 ora_cjq0_orcl
oracle    7030     1  0 May20 ?        00:00:24 ora_mmon_orcl
oracle    7032     1  0 May20 ?        00:00:14 ora_mmnl_orcl
oracle    7034     1  0 May20 ?        00:00:00 ora_d000_orcl
oracle    7036     1  0 May20 ?        00:00:00 ora_s000_orcl
oracle    7060     1  0 May20 ?        00:00:00 ora_qmnc_orcl
oracle    7076     1  0 May20 ?        00:00:02 ora_q000_orcl
oracle   17758     1  0 13:32 ?        00:00:00 ora_j000_orcl
oracle   17809 17789  0 13:33 pts/1    00:00:00 grep orcl
oracle   32499     1  0 May20 ?        00:00:00 ora_q002_orcl

$ cd /u01/app/oracle/oradata/orcl/

$ ls
control01.ctl  example01.dbf  redo03.log    temp01.dbf
control02.ctl  redo01.log     sysaux01.dbf  undotbs01.dbf
control03.ctl  redo02.log     system01.dbf  users01.dbf
$
==============================================================================
1-10 Oracle Memory Structures
==============================================================================
 SGA : 교재의 그림에 표시된 메모리 컴포넌트로 구성되며,
       각 컴포넌트에 "기록된 내용 또는 메모리 영역"을
       여러 서버프로세스가 같이 공유하여 사용하게 됩니다.

       (SGA: SYSTEM GLOBAL AREA)

      << 10g 부터는 일부 SGA 컴포넌트의 크기가 자동으로 관리됨 >>

         SGA_TARGET=0    : SGA 자동관리사용않함

         SGA_TARGET>0, 적절한 값 : SGA 자동관리사용함.

       메모리 자동관리는 Workshop II Less 8 에서 자세히 설명합니다.

 메모리에 구성되는 인스턴스의 구성요소 중 System Global Area(SGA)의
 각 컴포넌트의 기능을 이해하기 전에 접속한 세션에서 요청한
 하나의 SQL 문장을 Server Process가 처리하는 과정을 이해해 봅시다.

==============================================================================
<< SGA의 각 Components 를 이해하기 위해 사전 지식(1-10) >>
==============================================================================
1] User Process, Server Process : Session (1-12)
    (Server Process가 사용하는 메모리: Program Global Area,PGA)
==============================================================================
2] SQL 문장의 처리과정(By Server Process)
==============================================================================
1) SQL*Plus(User Process in Client-Side)로 orcl Database Server에 접속합니다.

2) Database Server의 운영체제 메모리에
   특정 Server Process가 생성되어 할당(by Listener)됩니다.

   --> 세션이 구성됩니다.

3) User가 SQL*Plus(User Process)에서 SQL 문을 작성한 뒤 네트워크를 통해

4) User Process(Clinet)에서 orcl database Server상의 Server Process로

  전달됩니다.
==============================================================================
5) Database Server 상의 Server Process는 전달 받은 SQL 문을
   다음의 과정을 거쳐서 처리
==============================================================================
  (1) Parsing: 아래의 여러 검사를 수행한 뒤, 검사를 만족하는 경우
               문장을 실행할 수 있도록 분석(실행계획 작성)하여
               "Parsed-Code"라는 실행형태의 코드를 작성합니다.

               - 문장의 문법을 검사,
               - 문장에 명시된 Table이름, Column명, 사용할 수 있는 Index정보
                 저장공간 정보 등등
               - 구문을 요청한 접속사용자의 권한
==============================================================================
  (2) Executing:

   - 분석된 Parsed-Code를 실행하여 디스크 상의 Data를
                   Oracle block단위로 찾아서 메모리에 Load합니다.

     DML 또는 DDL 문장의 경우에는 메모리에 Load된 Oracle Block의
     복사본에서 수정할 행을 찾아 다음의 작업을 진행합니다.

                 - Undo Data를 구성하여 디스크의 특정영역에 저장합니다.
                 - 변경전의 행의 데이터와 DML/DDL문장에 의해 변경한 후의
                   데이터를 기반으로 redo log entry를 작성하여
     Redo Log Buffer에 기록합니다.
                 - 메모리에 Load된 Oracle Block을 수정합니다.
                 - 사용자의 User Process에게 작업완료 메세지를 전달합니다.
==============================================================================
  (3) Fetching : SELECT 문장의 경우에는 Load된 Oracle Block의 복사본에서
                 조건을 만족하는 행을 찾아 원하는 Record를 추출하여 결과로서
                 메모리에 누적한 뒤,
   이를 네트워크를 통해 User Process에게 전달합니다.

 ============================================================== 
 문장별로 위의 단계를 간단히 정리하면 다음과 같습니다.

 - SELECT 문: Parsing --> Executing --> Fetching 을 모두 수행함
 ============================================================== 
 - DML(DDL) : Parsing --> Executing 과정만 수행함
 ============================================================== 
==============================================================================

 만약 서로 다른 Server Process들이 동일한 SQL문장을 처리해야 할 때,
 맨 처음으로  SQL문을 처리하는 Server Process가 각 처리 단계별로
 작성된 내용들을 지우지 않고 메모리에 남겨놓는다면,
 두번째 문장을 처리하는 Server Process는 작성된 내용이나
 메모리 존재하는 데이터들을 그냥 사용하면 처리가 빠를 수 있겠네요.
           

 위의 각 단계를 이해하면 SGA를 구성하는 각 컴포넌트의 기능을
 이해할 수 있습니다.

(1) Shared Pool :
    - 최종적으로 분석된 Parsed-Code, 실행계획, 문장이 Hash값을 handle로
      할당받은 Memory Address에 기억(Memorize)됨.
    - 여러 검사를 위해 필요한 Dictionary 상의 System Definition들이 기억됨
    - LRU(at Least Recently Used) 알고리즘을 이용하여 메모리 공간이 관리됨

  LRU-List : MRU-END --.....-- LRU-END

(2) Database Buffer Cache
    - Disk상의 Data가 Oracle Block단위로 기억되는 영역
    - LRU 알고리즘을 이용하여 메모리 공간이 관리됨

(3) Redo Log Buffer
    - Server Process가 DML/DDL operation 중에 생성된 redo entry를
      발생순서대로 기억

    - redo entry: LGWR 에 의해서 redo log file에 저장되어
                  복구가 필요할 때 사용됨
==============================================================================

위의 구성 Components 이외에도 선택적으로 다음의 추가적인 Component가 있습니다.

(4) Large pool: 병렬처리와 관련된 메세지버퍼 또는  워킹 버퍼

(5) Java Pool : Oracle Database Server 내에
  Java로 작성된 소스코드 및 컴파일된 Class파일을
  저장해 놓고 PL/SQL subprogram등에서 호출해서 사용 시
                Java Class 파일이 메모리에 Load되는 영역

==============================================================================
PGA : 각 Server Process 및 background Process가 자신의 작업을 수행하면서
      개별적으로 서버로 부터 할당받아 사용하는 메모리 영역이며, 9i 부터는
      자동으로 관리됩니다.
==============================================================================

==============================================================================
10-12 Process Structures
==============================================================================
Client [1] User process: 사용자가 Oracle server에 접속요청을 할 때 사용자의
     시스템 상에서 기동됩니다.

     (사용자 시스템의 메모리에 구성됨)
==============================================================================
Server [2] Server process: Oracle Instance에 접속하여
       사용자가 세션을 구성할 때 시작됩니다.
       (Database Server의 메모리)

 [3] Background processes: Oracle Instance가 시작될 때 기동됩니다.
       (Database Server의 메모리)
=============================================================================
10-13 Oracle Instance Management
=============================================================================
1) Database Writer(DBWn) :
=============================================================================
    database buffer cache로 부터 DML 문에 의해 수정된 Dirty 상태의 buffer를
    해당 disk 상의 datafile 내의 Oracle block에 저장합니다.
    이 작업을 통해 database buffer cache에서 새로운 블록을 기억하기 위하여
    지울 수 있는 기존 버퍼를 확보하는 백그라운드 프로세스 입니다.
   ==========================================================================
   10-14 Server Process and Database Buffer Cache and DBWn
         (그림 참조)

   SQL문장을 처리하면서, Server Process는 처리해야 하는 Data를
   Oracle Block단위로 Database Buffer Cache로 Load 합니다.
   =================================================================
   이 때, Database Buffer Cache상의 각 buffer들은 다음의 상태
   중 하나의 상태에 있게됩니다.
   =================================================================
    - Free or unused : 사용되지 않은 빈 buffer로
                       Database Service 기동 직후에 주로 존재합니다.
   =================================================================
    - Pinned : Server Process가 SQL 처리 중에 사용중인 buffer
   =================================================================
    - Clean  : Server Process가 SQL 처리를 완료한 버퍼로
               디스크 상의 내용과 동일하여,
               필요한 경우에 지울 수 있는 buffer.
   =================================================================
    - Dirty  : Server Process가 SQL 처리를 완료한 버퍼로
               DML 문장에 의해 수정이 되어
               디스크 상의 내용과 다른 상태의 buffer.
          
               이런 Dirty Buffer가 DBWn에 의해 디스크 상에 저장이되면,
               Clean 상태의 Buffer가 됩니다.
   ==========================================================================

2) LogWriter(LGWR)
    DML/DDL을 처리하는 Server process가 Redo Log Buffer에
    작성해서 기억시킨 Redo entries를 redo log file에 저장하여
    Redo log buffer를 비웁니다.
 =====================================================
 (참고)  LGWR이 리두로그파일에 redo log buffer에 있는
         리두엔트리를 기록하는 시점.
 =====================================================
         - commit시 마다
         - 리두로그버퍼의 1/3이상 찼을 때
         - 1메가 이상의 리두가 redo log buffer에 있을 때
         - 3초마다
         - DBWn가 dirty buffer를 저장하려고 할때
           그 dirty buffer에 해당하는 Redo entry가
           리두로그 버퍼에 있을 때 (DBWn이 LGWR을 호출함)
 =====================================================

3) Checkpoint Process(CKPT)
    Datafile과 Redolog file들에 저장된 내용간의 Sync 정보를
    check 해서 그 정보를 Controlfile과 Datafile header에 저장하는
    백그라운 프로세스

=============================================================================
<< 사전 지식 >>
=============================================================================
 파일의 Sync정보에 대하여
    DBWn는 datafile에, LGWR는 redo log file에 저장을 수행합니다.
    이런 각 파일의 저장작업에 대하여
     "여기까지 저장을 완료했습니다" 를 나타내는 정보로
     checkpoint 프로세스가 다음과 같은 내용을 이용하여
     컨트롤 파일에 기록해 놓습니다.
=============================================================================
 1. System Change Number(SCN) - Commit이 발생될 때마다 1씩 증가

 -- 현재 시스템의 SCN 확인

 (Terminal)

 $ sqlplus / as sysdba      /* SYS 스키마로 접속 */

 SQL> select current_scn from v$database ;

 CURRENT_SCN
 -----------
      639104

 SQL> select current_scn from v$database ;

 CURRENT_SCN
 -----------
      639106

=============================================================================
 2. Redo Byte Address (RBA)
       - Redo Entry 각각을 구별하기 위해 Redo Entry에 기록되는 정보
       - Redo Log File 기록된 Redo Entry들 중에
  복구를 시작할 리두로그 Entry의 위치 정보를 제공함.
=============================================================================
<< Checkpoint가 수행하는 작업의 중요성 >>
=============================================================================
 만약, 100개의 서로 다른 session에 의해서 100개의
 서로 다른 data block에 변경(DML)작업이 발생되었다고 가정합시다.

 이 때, Database Buffer cache상에는 수정된 Dirty 상태의 buffer가
 모두 100개가 존재합니다.(8192byte * 100 = 819200) (Undo는 제외합니다)

 또한, Redo log buffer에는 100개의 redo entry가 기억되어 있습니다.

(가정 상황)
    - Dirty 상태의 data buffer 중 DBWn에 의해 30개가 저장되고
      아직 저장이 안된 70개의 버퍼가 database buffer존재

    - Redo Log file에는 100개의 redo entry가 모두 저장됨

      왜, 8192 바이트 중 20바이트의 행하나를 수정한 경우라도,
      Datablock은 8129바이트를 저장해야 하지만
      변경전/후 값으로 구성된 redo entry(매우작은 정보)만을
      저장하면 되므로 저장이 빠르게 수행됩니다.

      또한 Redo는 매우 자주 저장됩니다.

    - 이 상황에서 서버의 메모리(즉, instance)가 깨졌다고 가정합시다.
      (--> 이런 상태를 instance failure가 발생했다고 함).

    이 때, 파일은 정상적이지만, 메모리가 깨지기 전에 작업된 내용
    (예에서 70개의 Dirtybuffer)이 메모리로부터 디스크로
    저장이 안된 상태입니다.

   이런 경우, 데이터베이스는 재기동하면서
   Controlfile에 기록된 Datafile들과 Redolog 파일의 Redo entry
   정보들을 이용하여 자동으로 복구를 수행함.

   예를 가지고 쉽게 설명하면

   Datafile에는 수정된 100 개의 30개의 Dirty buffer가 저장되었고,
   Redo Log File에 기록된 리두 100 개 중에서
   1번리두부터 30번 리두에 해당하는 데이터블록의 내용은 저장되었기
   때문에 재실행할 필요가 없고, 31번째 리두부터 100째리두를 재실행 후
   복원된 dirty buffer를 파일에 저장하면 데이터베이스를
   복구할 수 있습니다.

   이러한 파일간의 Sync 정보를
   책임지고 Controlfile과 Datafile Header에 저장하는
   백그라운드 프로세스가 "CKPT"입니다.

   그리고 위와 같은 instance failure 상황에서
   데이터베이스 서비스를 정상적으로  Open시키키 위하여
   기동하는 중에 필요한 복구(이를 Instance 복구라 함)를
   수행하는 백그라운드 프로세스가 SMON 입니다.
=============================================================================
4) System Monitor(SMON) : 인스턴스 복구를 수행하는 프로세스
=============================================================================
5) Process Monitor(PMON) :
    특정 user session이 비정상적으로 종료 시,
    Database Server의 메모리상에서 해당 세션의
    리소스 및 작업내역을 clearn-up 하는 백그라운드 프로세스
=============================================================================
6) Archiver(ARCn) :
   선택적으로 구성하여 사용되며
   별도의 설정으로 Database를 Archivelog mode로 설정한 경우에
   Archived Redo Log를 생성하는 백그라운드 프로세스.
=============================================================================

=============================================================================
(참고) Archived Redo Logfile의 필요성 및 개념
=============================================================================
 Redo log file 용도 : DML을 처리하는 Server Process들이
        Redo Log Buffer에 생성한 Redo Entris가
        발생순으로 LGWR에 의하여 저장된 파일.

 Redo Log File의 사용방식
 ===============================================================
  최소 2개 이상의 Redo Logfile이 "순환적으로 사용"됨.
 --> 같은 파일이 계속 재사용되면서 오래된 Redo Log들을
     사라집니다.

    redo file1    redo file2    redo file3
 ==========================================================
 - log switch : LGWR가 사용하는 redo log file을 바꾸는 동작
 ==========================================================
        - Redo Log Sequecne Number (LSN)

          --> log switch가 발생될 때 마다 1씩 증가하는 값.
 ==========================================================
 아래의 상황을 가정하여 생각하면 쉽게 이해할 수 있습니다.
=============================================================================
 (가정)

 2010년 12월에 전체 datafile들을 백업(복사)해 놓음.

 2010년 12월부터 서비스 개시하여
 DML 작업으로 redo 로그 파일에 DML 작업의
 리두엔트리가 파일에 저장되면서 매달별로 로그스위치가 발생
 되어 현재 2011년 7월이라고 가정합시다.

  redo file1            redo file2           redo file3

 2010 12월리두(지워짐) 2011년1월리두(지워짐) 2011년2월리두(지워짐)
 2011  3월리두(지워짐) 2011년4월리두(지워짐) 2011년5월리두
 2011  6월리두         2011년7월리두(현재사용)      

 Archive redo log file : LGWR이 사용이 끝난
    redo log file의 논리적인 복사본.

=============================================================================
1-15 Physical Database Structure
=============================================================================
• Data files : 테이블을 통해 INSERT 문으로 처리된 데이터가 저장된 파일
        (Header가 있음)

• Online redo log files : DML/DDL 수행 시에 작성된
     Redo Log Entry가 저장된 파일

• Control files : Datafile과 Redologfile의 위치및 이름,
    파일들의 Sync정보, 데이터베이스이름 등
    데이터베이스의 제어 정보가 저장된 파일

• Parameter file : Instance 기동시에 설정해야 하는 파라미터들이 기록된 파일

• Password file  : SYSDBA 또는 SYSOPER의 패스워드가 저장된 파일

• Backup files   : Datafile이 손상된 경우, 복구를 위해 준비한 복사본

• Archive log files : 사용이 끝난 Online Redo log파일의 논리적인 복사본
 
• Alert log      : 데이터베이스가 운영되면서 발생된 Oracle 프로그램 로그

• trace files
 
  (1) Background process가 장애 시에 기록되는 trace파일

  (2) Server Process가 SQL 문장을 수행하면서
      사용한 CPU 및 메모리 사용량 및 발생시킨  DISK IO
      그리고 실행계획을 기록하는 trace파일로 SQL 문장 튜닝시에도 사용됩니다.
=============================================================================
1-16 Datafile 저장공간이 사용되는 방식(용어에 대한 정리)
=============================================================================
• Tablespace : 논리적으로 서로 관련된 데이터들이
               저장된 파일들을 묶어놓은 단위
               Datafile을 생성 시에 같이 정의됨.

  (기능) 데이터를 저장해 놓은 물리적인 파일(실제 파일)들과
         논리적인 저장단위를 서로 분리시키는 역할을 함.

         파일이 실제 OS 상의 어느 경로에 존재하던지
         관리자가 설정만 해 놓으면 SQL을 처리하는
         서버프로세스는 Tablespace에 관련된 datafile정보를
         이용하여 사용자의 SQL문에 의해 요청되는 데이터
         처리작업을 수행함.

• Segments(세그먼트) : 테이블이나 인덱스가 공간을 사용하는 단위

• Extents (확장영역) : Segment에 대한 공간 할당 단위.
                       (Segment가 확장됩니다)
                       - 전제: 연속된 Oracle Blocks

• Blocks (블록) : SQL 처리를 위해 발생되는
                  최소 IO 단위(db_block_size)
==============================================================================

운영체제 기본적인 정보 확인 명령어
 uname CMD
  # uname -a
  # cat /etc/release
 date CMD
  # rdate time.bora.net
  # date +%m%d
 cal CMD
디렉토리 이동 관련 명령어
 pwd CMD
  PS1 변수
 cd CMD
  PATH
  - 절대경로(Absolute PATH) # cd /dir1
  - 상대경로(Relatvie PATH) # cd dir1
파일의 종류
 일반 파일
 디렉토리 파일
 링크 파일
  하드링크(Hard Link)      # ln file1 file2
  심볼릭링크(Symbolic Link)# ln -s file1 file2
 디바이스 파일
  블럭디바이스(Block Device)
  캐릭터디바이스(Character Device)
man & passwd CMD
 man CMD
  # man ls
  # man -k calendar
  # man -l passwd
  # man -s 1B ls
 passwd CMD
  # passwd [USER]
--------------------------------------------------------
디렉토리 관리 명령어
 ls CMD
  # ls -l dir1
  # ls -ld dir1
  OPTIONS: -a, -l, -d, -t, -r, -F, -R, -h, -i

  # ls -altr
 mkdir CMD
  # mkdir -p dir1/dir2/dir3
 rmdir CMD
  # rm -r dir1
파일 관리 명령어
 touch CMD
 cp CMD
  # cp file1 file2
  # cp file1 dir1
  # cp -r dir1 dir2
  OPTIONS: -i, -r, -p
 mv CMD
  # mv file1 file2
  # mv file1 dir1
  # mv dir1 dir2
  OPTIONS: -i
 rm CMD
  # rm -rf dir1
  # \rm -r dir1
파일 내용 확인 명령어
 cat CMD
  # cat -n file1
  # cat file1 file2 > file3
 more CMD
  # CMD | more

  # ps -ef | more
  # pkginfo | more
  # patchadd -p | more
 head CMD
  # alias pps='ps -ef | head -1 ; ps -ef | grep $1'
 tail CMD
  # tail -f /var/adm/sulog
  # tail -f /var/adm/messages
  # tail -f /var/adm/messages | grep DHCP
기타 관리용 명령어
 wc CMD
  Data Gathering

 su CMD
  # su user01
  # su - user01
--------------------------------------------------------
 id CMD
  UID/EUID, GID/EGID
 groups CMD

 last CMD
 who CMD
 w CMD
  while [ 1 ]
  do
   CMD
   sleep 2
  done
사용자와 통신할 때 사용하는 명령어
 mailx CMD
  # mailx -s "OK: solarisXXX" root@paran.com < report.txt
 talk CMD
 wall CMD
  # wall -a /etc/hosts
파일 속성 정보 변경 명령어
 chown CMD
  # chown -R user01 dir1
 chgrp CMD
 chmod CMD
  퍼미션 변경 방법
  - Symbolic Mode(EX: chmod u+x file1)
  - Octal Mode   (EX: chmod 755 file1)

  파일 & 디렉토리 퍼미션 의미

  umask CMD
   (관리자) /etc/profile
   (사용자) $HOME/.profile
  특수 퍼미션
   SetUID/SetGID/Sticky Bits 의미
   SetUID/SetGID/Sticky Bits 설정
   SetUID/SetGID/Sticky Bits 관리
자주 사용되지 않지만 유용한 명령어
 diff/cmp CMD
  # diff file1 file2
  # dircmp dir1 dir2
--------------------------------------------------------
 sort CMD
  # df -k -F ufs
  # du -sk /etc
  # cd /etc ; du -sk * | sort -nr | more

  # sort -u file1
  # sort file1 | uniq -d
  # sort file1 | uniq -u
 file CMD
  # cd /etc ; file *
검색 관련 명령어
 grep CMD
  # grep OPTIONS PATTERN file1
  OPTIONS: -c, -n, -l, -v, -i, -w
  PATTERN: *  .  ^root  root$  [abc] [a-c] [^a]
  [참고] egrep, fgrep
 find CMD
  # find / -name core -type f
  # find / -user user01 -group class1
  # find / -mtime [-7|7|+7]
  # find / -perm [-755|755]
  # find / -size [-300c|300c|+300c]
  # find / -name core -type f -exec rm {} \;
압축 & 아카이빙
 압축(Compress)
  compress/uncompress CMD
  gzip/gunzip CMD
 아카이빙(Archiving)
  tar CMD
   (/test1 -> /test2)
   # cd /test1
   # tar cvf - . | (cd /test2 | tar xvfp -)
------------------------------------------------------------------------
  cpio CMD
 압축 + 아카이빙(Compress & Archving)
  zip CMD
  jar CMD
Visual Editor
 (vi) $HOME/.exrc(set nu)
 (vim)$HOME/.vimrc(syn on)
Korn Shell 특징
 Redirection
  ------------------
  fd
  ------------------
  0 stdin
  1 stdout
  2 stderr
  ------------------

  Redirection stdin (EX: mailx -s WARN root < report.txt)
  Redirection stdout(EX: ls -l > file.txt)
  Redirection stderr(EX: CMD > file.log 2>&1)
 Pipe
  CMD | more
  CMD | grep inetd

  CMD > file.log
  CMD | tee file.log
 ksh function
  # set -o
  # set -o vi
  # set +o vi

  # set -o noclobber
  # set -o vi
  # set -o ignoreeof
 Variable
  변수의 종류
  - 지역 변수
  - 환경 변수
  - 특수 변수

  변수 선언 방법

  export 의미?

  시스템 환경변수(set/env)
   EDITOR/VISUAL
   PS1/PS2
   PATH/MANPATH/LD_LIBRARY_PATH
   HOME/PWD/LOGNAME
   DISPLAY
------------------------------------------------------------
 Metacharacter
  ''  ""  ``  \  ;
 History
  (ksh) $HOME/.sh_history
  (bash)$HOME/.bash_history

  r, r vi
 Alias
  # alias cp='cp -i'
  # alias
  # unalias cp
 환경파일
  /etc/profile
  $HOME/.profile
  $HOME/.kshrc

 쉘별 환경 파일
  sh  ) /etc/profile, ~/.profile
  ksh ) /etc/profile, ~/.profile, ~/.kshrc
  bash) /etc/profile, ~/.bash_profile, ~/.bashrc
  csh ) /etc/.login, ~/.cshrc, ~/.login
 /etc/skel
  (주) /etc/profile
  (부) /etc/skel
Process Admin
 Process Information
  /proc/PID(pCMD: ps, pfiles, pstack, pmap, ...)
  PID, PPID, UID/EUID, TTY
 Process Admin I
  프로세스 실행
   fg) # ls
   bg) # ls &
  프로세스 확인
   # ps -ef | grep inetd
   OPTIONS: -l, -f
                                 -e, -a, -U, -t
------------------------------------------------------------
  프로세스 종료
   # kill -[1|2|9|15] PID PID
   [참고] pgrep, pkill
 Process Admin II
  잡 실행
   fg) # ls
   bg) # ls &
  잡 확인
   # jobs
  잡 종료
   # kill %1
   <CTRL + Z>, stop %1
 Process Monitoring
  # ps -ef | grep inetd
  # prstat
원격접속 & 파일전송
 System V
  telnet CMD
   원격접속 에러메세지
  ftp CMD
   /etc/ftpd/ftpusers
   /etc/shells
  [참고] auto_ftp.sh, telnet.sh
------------------------------------------------------------
 BSD
  rlogin CMD
  rsh CMD
  rcp CMD
 Secure
  ssh CMD
  sftp CMD
  scp CMD
ACL(Access Control List)
 getfacl CMD
 setfacl CMD
------------------------------------------------------------