[VxVM4.0] 베리타스 볼륨매니저 4.0 변경된 부분

=========================================================================================================================


1.1 rootdg의 제거

----------------
: Veritas Volume Manager의 3.5 이하 버전에서는 rootdg가 사용된다.
  vxconfigd가 boot mode에서 rootdg를 import하고 vxconfigd가 enabled mode로 진입하기를 기다린다.
  rootdg로 인한 문제가 지속적으로 발생함.

   [rootdg를 제거]
 - vxconfigd가 boot mode로 올라올 때에 rootdg를 체크하지 않게 함
 - rootdg에 대한 문제를 사전에 차단 함
 
1.2 vxconfigbackupd 추가 - 자동적으로 disk group에 대한 configration을 백업한다.

--------------------------------------------------------------------------------

 역할: The vxconfigbackupd daemon automatically backs  up  information  about  a  disk  group's new configuration whenever the configuration is changed

 [관련 files]
/etc/init.d/vxvm-recover                     //Startup file for vxconfigbackupd.
/etc/vx/cbr/bk/dgname.dgid/dgid.dginfo         //Location of backup file for  disk  group  information.
/etc/vx/cbr/bk/dgname.dgid/dgid.diskinfo //Location of backup file for disk attributes.
/etc/vx/cbr/bk/dgname.dgid/dgid.binconfig //Location of backup file for  binary  configuration copy.
/etc/vx/cbr/bk/dgname.dgid/dgid.cfgrec         //Location of backup file for configuration  records in vxprint -m format.

1.3 cdsdisk : Cross platform Data Sharing
 sliced, simple, nopriv이외에 cdsdisk type이 Veritas Volume Manager 4.0에서 추가되었다.
 vxdisksetup시에 default로 cdsdisk type으로 설정되어진다.
 cdsdisk는 다른 OS에서 data sharing이 가능하다.
 cdsdisk는 private region과 public region이 slice 7번에 공존한다.


1.3. 설치 방법

--------------------

 Software Package Installation

1. Install Basic VxVM Package
 # pkgadd –d . VRTSvlic VRTSvxvm VRTSvmdoc VRTSvmman


2. Install VEA Package
 # pkgadd –a ../scripts/VRTSobadmin –d . VRTSob VRTSobgui


3. Install remaining VxVM Package
 # pkgadd –d . VRTSalloc VRTSddlpr VRTSvmpro VRTSfspro


참조> Package 경로


1.4. Initializing 방법

-------------------------

VxVM software start하기 전에 vxinstall을 이용하여 Disk Group을 초기화 한다.
Voulme Manager 4.0버전에서는 vxinstall시에 rootdg에 대한 요구가 제거되었다.

# vxinstall

Do you want to use enclosure based names for all disks ?
[y,n,q,?]  (default : n) n

Do you want to setup a system wide default disk group ?
[y,n,q,?]  (default : y) n
 The installation is successfully completed.


1.5. Install License

------------------------

# vxlicinst              // 위의 command를 사용하여 License 입력
# vxlicrep               // 위의 command를 사용하여 License 확인


/ 디렉토리에서 rm * 명령을 실행하면 시스템이 맛가게되는대 이는

아래의 두 심볼릭 link 파일(/bin, /lib)이 삭제되기 때문입니다.

lrwxrwxrwx 1 root root 9 2월 3일 09:55 lib ->  /usr/lib
lrwxrwxrwx 1 root root 9 2월 3일 09:55 bin -> /usr/bin

원본파일은 /usr 디렉토리에 존재하기때문에

아래 순서대로 링크를 재 생성하여 주도록 합니다.



<복구절차>

1) cdrom single boot
   

   stop + a

   ok> boot cdrom -s


2) 부팅디스크의 / 디렉토리 마운트


  #mount /dev/dsk/c0t0d0s0  /a

  #cd /a


3) symbolic link 생성

  #ln -s ./usr/lib lib

  #ln -s ./usr/bin bin

  #cd

  #umount  /a
 

 #reboot

 

1)   자기 시스템 상태의 확인

인스톨 관련 정보를 표시하는 코맨드 CDE와 OpenWindows 환경에서 메뉴로 부터 "Workstation 정보"를 선택하여 GUI상에서 시스템에 관한 기본적인 정보를 확인한다.
/usr/openwin/bin/wainfo 코맨드를 실행 하는 것도 가능하다.

==>  소프트웨어의 설정에 대하여 개별적인 정보를 얻고자 하는 경우에
         다음과 같은 코맨드가 이용 가능하다.

 

   * HOST 이름
# uname -n    : whiteeye
# hostname    : whiteeye
# showrev     : Hostname: whiteeye
# sysdef      : whiteeye node name (NODE)

 

   * OS의 종류, 버젼
# uname -s    : SunOS
# uname -r    : 5.6
# uname -v    : Generic
# showrev     : Release:  5.6
# Kernel version:   SunOS 5.6 Generic August 1998
# sysdef      : 5.6 release (REL)
# SunOS system name (SYS)
# Generic version (VER)

 

   * 파티션 구성
# df -k       : Filesystem kbytes used avail capacity Mounted on
        /dev/dsk/c0t3d0s0 38383 19392 15161 56% /
        ...........

 

   * 패치 정보
# showrev -p  : Patch:  101331-03 Obsoletes:  Packages:  SUNWcsu.7
        11.5.0,REV=2.0.18,PATCH=35
        ........

 

   * 로드 되어 있는 모듈
# sysdef      : * Loadable Objects
        strmod/bufmod
        strmod/connld
       ......

 

   * 소프트웨어 패키지 구성
# pkginfo     : system      AXILvplr       Axil platform links
        system      AXILvplu       Axil usr/platform links
        ..............

 

2)   네트워크에 관한 정보는 다음과 같은 코맨드가 이용 가능하다.

   * IP Address, NetMask, Broadcast Address
# ifconfig -a : inet 129.158.153.162 netmask ffffff00 broadcast 120.158.153.255
 

 

3)   하드웨어의 구성 요소에 관한 상세한 정보는 다음과 같은 코맨드가 이용 가능하다.

   * 아키텍처 타입
# prtconf     : System Configuration: Sun Microsystems sun4m
# arch -k     : sun4m

 

   * Workstation 모델
# prtconf  : SUNW,SPARCstation-5
# prtconf -vp : ......
model: 'SUNW,501-2572'
clock-frequency: 0510ff40
name: 'SUNW,SPARCstation-5'
# dmesg       : root nexus = SUNW,SPARCstation-5

 

   * CPU 타입
# dmesg       : cpu0:  SUNW,UltraSPARC (upaid 0 impl 0x10 ver
0x22 clock 143 MHz)
# prtconf -vp :    ....
sparc-version: 00000008
mask_rev: 00000020
device_type: 'cpu'
name: 'FMI,MB86904'
# ok cpu-info : VPU FMI,MB86904 Rev. 2.0: 85Mhz
(EEPROM 코맨드)

 

   * 메모리 용량
# dmesg       : mem = 32768k (0x2000000)
# prtconf     : Memory size: 32 Megabytes

 

   * 시리얼 포트 디바이스
# dmesg       : zs0 at obio0: obio 0x1000000 sparc ipl 12
zs0 is
/obio/zs@0,1000000
# sysdef      : zs, instance #0
zs, instance #1

 

   * 디스크
# dmesg       : sd3 at esp0: target 3 lun 0
sd3 is
/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/
esp@5,8800000/sd@3,0
# sysdef      : sd, instance #2 (driver not attached)
sd, instance #3

 

   * 프레임 버퍼
# prtconf     : cgsix, instance #0
# prtconf -F  :
/iommu@f,e0000000/sbus@f,e0001000/cgsix@2,0
# dmesg       : cgsix0 at sbus0: SNus slot 3 00 SBus level 5 sparc ipl 9
cgsix0 is
/iommu@0,10000000/sbus@0,10001000/cgsix@3,0
cgsix0: screen 1152x900, single buffered, 1M mappable, rev 11
# sysdef      : cgsix, instance #0

 


4)   Root 디바이스와 Swap 디바이스 등의 정보는 /etc/vfstab 화일을 확인 하거나 다음의 코맨드의 이용이 가능 하다.

   * Root 디바이스
# dmesg       : root on
/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/
esp@5,8800000/sd@3,0:a fstype ufs

 

   * Swap 디바이스
# dmesg       : dump on /dev/dsk/c0t3d0s1 size 131532K
# swap -l     : swapfile dev swaplo blocks free
/dev/dsk/c0t3d0s1 32,25 8 263080 209312
# sysdef      : swapfile dev swaplo blocks free
/dev/dsk/c0t3d0s1 32,25 8 263080 209312

 

   * 시스템 보드 구성의 정보
# prtdiag(Sun4d, Sun4u 아키텍처만 가능)

PS. # /usr/platform/sun4u/sbin/prtdiag -v | more 플랫폼 정보를 한번에 확인


출처가 분명하지 않은 퍼옴입니다.

How to Mount or Unmount a USB Mass Storage Device Without vold Running

  1. See How to Prepare to Use USB Mass Storage Devices Without vold Running for information on disabling vold.

  2. Become superuser.

  3. (Optional) Identify the diskette device.

    For example:


    # cd /dev/rdsk
    # devfsadm -C
    # ls -l c*0 | grep usb
    lrwxrwxrwx   1 root  root   55 Mar  5 10:35 c2t0d0s0 ->
    ../../devices/pci@1f,0/usb@c,3/storage@3/disk@0,0:a,raw

    In this example, the diskette device is c2t0d0s0.

  4. Select one of the following to mount or unmount a USB mass storage device.

    1. Mount a USB mass storage device.


      # mount [ -F fstype ] block-device mount-point
      

      This example shows how to mount a device with a UFS file system.


      # mount /dev/dsk/c1t0d0s2 /mnt
      

      This example shows how to mount a device with a PCFS file system.


      # mount -F pcfs /dev/dsk/c1t0d0s0:c /mnt
      

      This example shows how to mount a CD with a read-only HSFS file system.


      # mount -F hsfs -o ro /dev/dsk/c1t0d0s2 /mnt
      
    2. Unmount a USB mass storage device.

      First, be sure no one is using the file system on the device.

      For example:


      # fuser -c -u /mnt
      # umount /mnt
      
    3. Eject the device.


      # eject /dev/[r]dsk/cntndnsn
      

      For example:


      # eject /dev/rdsk/c1t0d0s2 
      


참조 : http://docs.sun.com/app/docs/doc/817-3814/6mjcp0qrg?a=view
Tip 1) 어떤 특정한 파일을 사용하고 있는 프로세스들에 대한 정보를 알고 싶을 때,

$ lsof (expected file name with path)

을 실행하면 된다.

$ lsof /etc/passwd

를 실행하면, /etc/passwd를 억세스하고 있는 프로세스들을 점검할 수 있으며, 이 파일을 가지고 장난치는 프로세스들도 발견할 수 있다.

Tip 2) 어떤 파일 시스템 내에, 그렇게 큰 크기의 파일들을 찾을 수 없는데도 불구하고, Available Space가 0을 향해서 치닫고 있을 수도 있다. 아마도, unlink된 파일에 대고 계속해서 써 대고 있을 가능성이 크다. lsof는

$ lsof (expected directory - root of mounted partition)

의 형식으로 해당 디렉토리 내, 혹은 partition 내에 있는 모든 파일들에 대해 억세스하고 있는 프로세스들을 열거해 줄 수 있다. 역시 장난 치는 프로세스를 발견할 수 있을 것이다.

Tip 3) 긴급히 어떤 파일 시스템을 unmount해야 할 때, 여러분은 해당 파일 시스템에 있는 파일들을 사용하는 프로세스들 덕분에 unmount를 하지 못하고 마냥 기다리기만 했던 일을 겪어 봤을 것이다. lsof는 파일 시스템 내에 있는 파일들에 대해서 억세스하고 있는 프로세스들을 다 찾아줄 수 있다.

$ lsof (expected file system name)

이것을 이용해서 즉시 unmount를 하는 스크립트도 간단히 만들 수 있을 것이다.

Tip 4) lsof는 모든 네트워크 Socket들을 찾아낼 수 있다.

$ lsof -i

를 실행하면, 현재 사용되고 있는 모든 Socket들을 볼 수 있을 것이다.

Tip 5) Tip 4)를 잘 이용하면, 어떤 네트워크 Connection에 대해서 그 목적지 나 어디서 부터 맺어진 연결인지를 쉽게 알아낼 수 있다. 만약, 여러분의 서버 에서 돌아가고 있는 프로세스들 중에서, security.kaist.ac.kr로 연결을 하고 있는 프로세스를 잡아낼 수 있으며, 구체적으로 어떤 서비스(혹은 포트)에 연 결하고 있는가도 지정하여 알아낼 수 있다.

$ lsof -i@security.kaist.ac.kr $ lsof -iTCP(|UDP)@security.kaist.ac.kr:smtp

물론 여러개의 -i옵션을 이용해서 다양한 호스트로의 연결을 잡아낼 수 있다.

Tip 6) Tip 5)를 응용해서 netstat과 물려서 이용하는 예도 있다.


$ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 security.kaist.ac:1019 fool.bbaga.co.kr:login ESTABLISHED

자, 누군가가 fool.bbaga.co.kr의 login 서비스로 커넥트하고 있는 것이 발견 됐다. 이 프로세스를 Tip 5)를 이용해서 찾아보도록 하자.

$ lsof -iTCP@fool.bbaga.co.kr:login
COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
rlogin 25023 godslord 3u inet 0x10144168 0t184 TCP security.kaist.ac.kr:1019-)fool.bbaga.co.kr:login
...

Tip 7) lsof로, 어떤 특정한 프로그램의 프로세스들이 억세스하고 있는 모든 파일들을 볼 수 있다. -c 옵션으로 이것을 간단하게 해결할 수 있다.
$ lsof -c httpd

httpd 데몬을 통해서 억세스 되고 있는 모든 파일들을 열람할 수 있다.

Tip 8) lsof를 이용하여, rcp나 ftp를 이용한 파일 전송 과정을 모니터링 할 수도 있다. 먼저 대상이 되는 프로세스를 ps 등을 이용해서 찾아낸다. 그런 다음,

$ lsof -p (PID)

를 하면 당연히 해당 프로세스가 열고 있는 파일들을 열람할 수 있게 된다. 조금 더 자세히하고 싶다면, ftp는 일반적으로 9,10이나 10,11번을 각각 Socket과 Local Data File에 할당하고, rcp는 3,4번을 할당한다. 이를 이용 하면,

$ lsof -p (PID) -ad9,10 -r

이런 식으로 되며, 어떤 뜻인지는 위의 옵션 설명을 보고 해석해 보기 바란다.

Tip 9) lsof로는 어떤 유저가 열고 있는 모든 파일들을 열거해 볼 수도 있다.

$ lsof -u(loginname) 혹은 $ lsof -u(UID)

-u 옵션에는 인자를 ","로 구분하여 여러 인자를 한 꺼번에 넘길 수 있다.

$ lsof -ugodslord,sakai,astroby

즉, godslord, sakai, astroby의 유저들이 열고 있는 모든 파일들을 열거한다. -u 옵션을 사용하면서, 특정한 유저에 대한 정보는 보고 싶지 않을 때는, Login Name이나 UID의 앞에 "^"를 붙여 주면 된다.

$ lsof -u ^root 혹은 $ lsof -u ^0

이렇게 되면, root에 대해서는 체크를 하지 않는다.

Tip 10) lsof를 이용해서, 로그인 추적도 가능하다. 다음의 예제는 Solaris 2.x 에서의 경우이다.


$ lsof -i@security.kaist.ac.kr
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
in.rlogin 8112 root 0u inet 0x60d7c7e8 0t2 TCP fool.bbaga.co.kr:login-)security.kaist.ac.kr:1018 (ESTABLISHED)
in.rlogin 8112 root 1u inet 0x60d7c7e8 0t2 TCP fool.bbaga.co.kr:login-)security.kaist.ac.kr:1018 (ESTABLISHED)
in.rlogin 8112 root 2u inet 0x60d7c7e8 0t2 TCP fool.bbaga.co.kr:login-)security.kaist.ac.kr:1018 (ESTABLISHED)

security.kaist.ac.kr에서부터 fool.bbaga.co.kr로 로긴한 프로세스가 있다. 이 프로세스의 ID는 8112번이다.

$ lsof -p 8112
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
....
in.rlogin 8112 root 4u VCHR 23,0 0t0 136785 /devices/pseudo/clone@0:ptmx-)logindmux-)ptm
in.rlogin 8112 root 5u VCHR 4,0 0t0 136939 /devices/pseudo/clone@0:logindmux-)logindmux
in.rlogin 8112 root 6u VCHR 4,1 0t0 136939 /devices/pseudo/clone@0:logindmux-)logindmux
...

물론 다른 내용도 많겠지만 위의 내용, 특히 맨 첫 라인에 주목해 보자. 이 프로세스는 DEVICE 항목에서 보듯이, 23, 0의 Device를 사용하고 있으며, 이는 곧, /dev/pts/0을 의미한다.

$ lsof /dev/pts/0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tcsh 8114 godslord 15u VCHR 24,0 0t35381 136786 /dev/pts/../../devices/pseudo/pts@0:0
...

즉, 이 유저는 /dev/ptr/0에서 tcsh 프로세스를 가지고 로긴한 사실을 알 수 있다.
Platform마다 다르지만 비슷한 방법으로 로긴을 추적해 낼 수 있다.

사용법은

lsof –i :1004 이런 식입니다.

1004는 포트번호 입니다.

RAID 각 레벨(level)에 관한 설명
 
RAID 0
RAID-0는 전형적인 Parity가 없는 striped disk drive들의 non-redundant group으로 정의된다. RAID-0 array는 보통 I/O intensive application을 위한 large stripes로 구성되는데, 종종 data intensive application의 single-user를 위한 synchronized spindle drive들을 이용한 sector-stripe으로 구성할 수도있다.
RAID-0는 redundancy를 지원하지 않기 때문에 만일 Array내의 하나의 drive가 장애를 일으키면, Array 전체가 장애를 일으키게 된다. 그러나 RAID-0는 모든 Array type중 가장 빠르고 data저장 효율이 높다.
RAID 1
Disk Mirroring이라 불리는 RAID-1은 data를 중복 저장하도록 디스크드라이브들을 쌍로 구성한 것으로 서버쪽으로는 하나의 드라이브로 인식된다. RAID-1은 striping은 사용되지 않는 반면, 여러개의 RAID-1 array들이 서로 striped되어 mirrored drives pair들로 구성된 하나의 대용량 array로 구성 시킬 수 있으며, 이를 "Dual-level array" 또는 RAID-10이라 부른다.
Write는 Mirrored Pair인 두개의 Drive에 동시에 저장되어 각 Drive가 동일한 정보를 저장하게 된다. 그러나 각 Drive는 Simultaneous Read Operation을 수행할 수 있다. 따라서, 각 Drive의 Read Performance는 두배로 되고 Write Performance는 변화가 없게 된다. RAID-1은 Redundant를 가진 Array중에서는 최고의 Performance를 보이며, 특히 Multi-user Environment에서 유용하다.
RAID 3
RAID-3는 RAID-2처럼 Sector-striped data를 Drive Group에 걸쳐 저장하지만, Group내의 하나의 Drive는 Parity Information만을 저장하도록 지정된다. RAID-3는 Error Detection을 위해서는 각 sector에 embbed된 ECC에 의존한다.
Hard Drive가 장애를 일으킬 경우, Data 복구는 남아있는 Drive상에 기록된Information의 Exclusive OR(XOR)연산을 통하여 이루어진다.
Records는 전형적으로 모든 Drive에 걸쳐 있기때문에, Data Intensive 환경에 적합하다. 각 I/O은 Array내의 모든 Drive들을 액세스하기 때문에, RAID-3 Array는 I/O을 Overlap시킬 수가 없고 따라서, RAID-3는 long record의 Single-user, Single-tasking 환경에 적합하다. 그러므로 Short record에서의 성능 저하를 피하기 위해서는, RAID-3는 Synchronized-spindle drives가 필요하다.
RAID 5
종종 Rotating Parity Array라 불리는 RAID-5는 RAID-4에서 하나의 전용Parity Drive를 설정함으로써, Parity Update가 한 Drive에서 이루어지므로 생기는 Write Bottleneck을 피하기 위하여 만들어진 RAID Array이다.
RAID-5는 RAID-4처럼 large-stripe이 사용되어 multiple I/O operation이 overlap되도록 하고 있다. 그러나, RAID-4와는 다르게, 각 Drive들이 일련의 서로다른 stripes들에 대한 parity를 돌아가면서 저장하게 된다.
따라서, 전용 parity Drive가 없기 때문에 모든 drive들이 데이타를 저장할 수 있고, Read operation이 모든 drive에 걸쳐 overlap될 수 있다.Write Operation은 전형적으로 single data drive를 액세스하며 그 record에 대한 parity drive를 액세스한다.
따라서, RAID-4와는 달리 서로 다른 records들이 해당 parity들을 서로 다른 drive들에 저장하기 때문에, Write Operation도 overlap이 가능하다. RAID-5는 RAID-1이 모든 데이타를 redundant copy하는 것과는 달리, parity information만을 저장하기 때문에 RAID-1에 비하여 Storage Efficiency를 높일 수 있다. 결과적으로 RAID-5 Array는 어떤 수의 Drive도 연결이 가능하고, 각 Drive들은 Parity information 저장 부분만을 제외하고는 모두 data storage로 활용될 수 있다. 즉, RAID-5는 RAID-1보다 저장 장치를 효율적으로 극대화 시킬 수 있다. 그러나 performance에서는 손실을 감수 하여야 한다.
Data가 RAID-5 Array에 쓰여질 때, Parity information 또한 Update되어야 하는데, 이는 Write Operation에 의하여 어떤 data bit들이 바뀌었는지를 찾아내어 이에 해당하는 parity bits들을 바꾸므로서 Update된다.
이는 overwritten될 old data를 먼저 읽고, 이 것이 새로 overwrite될 새로운 데이타와 XOR 연산을 하므로써 수행된다. 이 것은 바뀐 모든 bit의 position에서 1이 되는 bit mask를 만들게 되고, 이 bit mask가 parity drive로 부터읽어 들인 old parity information과 XOR연산을 수행한다. 이 결과, Parity information내에 있는 해당 bit를 변화 시킨다. 이렇게 하여 Update된 Parity는 Parity Drive에 write back된다.
그러므로, write-request하는 모든 Application에 대하여 RAID-5 Array는 두개 의 Read, 두개의 Write와 두개의 XOR operation을 수행하여야 만이 원래의 write가 완료된다.
RAID-1에서의 redundant data에 비하여, Parity를 저장하는 RAID-5는 위와 같이 보다 많은 연산을 행하게 되며, write operation 중에 parity information을 재생하는데 추가적으로 시간이 소요된다. 이러한 이유 때문에 RAID-5는 RAID-1에 비하여 write performance가 약 3/5~1/3 수준밖에 되지 않는다. 이때문에, RAID-5 Array는 결코 Software적으로 사용되지 않으며, 아울러 디지탈 비디오 캡쳐와 같이 write performance가 중요한 Application에는 사용되지 않는다.
 
Level 0
Level 1
Level 5
Level 0 + 1
장점
- DISK I/O가 분산이 된다.
- RAID level중 가장 빠르다.
- DATA 저장 효율이 높다.
- 안정적이다.
- redundant해서 Fault Tolerance를 보장한다.
- simultaneous-read가 되기 때문에 기존의 방법에 2배정도 읽기 효과를 준다.
- Write-bottleneck 현상을 줄일 수 있다.
- 안정적이다.
- disk I/O를 줄일 수 있다.
- hot-swap, hot-fix, hot-spare, hot-plug등이 가능하다.
- Level 0과 Level 1의 장점을 가진다.
 
단점
- Fault Tolerance가 보장되지 않는다.
- 안정적이?못하다.
- redundant가 없다.
- 비용이 비싸다.
- Striping이 되지를 않기 때문에 disk I/O bottleneck 현상에 대해 효율적이지 못하다.
- level 1에 비해서 읽기 성능이 떨어진다.
- level 0에 비해 저장효율이 떨어진다.
- 비용이 비싸다.
- disk 저장 효율성이 그리 높지 않다.

그럼 오라클 데이터베이스의 생김새를 알아보겠습니다. 오라클 데이터베이스가 어떤 구조를 하고 있는지를 잘 이해하는 것은 정말 중요한 일입니다. 왜냐구요 ?? 예를 들어, 자동차의 구조를 잘 이해하면 고장이 났을 때 쉽게 고칠 수 있습니다. 데이터베이스도 마찬가지입니다. 구조를 잘 이해하면 데이터베이스에 문제가 발생했을 때 쉽게 고칠 수 있기 때문입니다.
아래는 오라클 데이터베이스의 구조에 대한 설명입니다.

먼저, 오라클 데이터베이스는 세 가지 영역의 물리적 구성요소로 이루어져 있습니다.
첫 번째는 프로세스 영역입니다
  이 영역은 백그라운드 프로세스(DBWR, LGWR, PMON, SMON, CKPT)와 사용자 프로세스 그리고 서버 프로세스로 구성되어 있습니다
두 번째는 메모리 영역입니다.
  공유풀 영역(SHARED POOL), 데이터 버퍼캐쉬(DATA BUFFER CACHE) 영역, 로그 버퍼(LOGO BUFFER) 영역 그리고 라지풀(LARGE POOL) 영역으로 구성되어 있습니다.
마지막은 파일 영역입니다.
 
컨트롤 파일(CONTROL FILES), 파라메터 파일(PARAMETER FILES), 데이터 파일(DATA FILES) 그리고 리두로그 파일(REDO-LOG FILES)로 구성되어 있습니다.
 
시스템글로벌 영역
사용자가 실행한 SQL문에 의해 검색 또는 변경되는 테이블 데이터를 임시로 저장하는 메모 리 영역 시스템글로벌 영역(SYSTEM GLOBAL AREA)이라고 합니다.
SGA 영역은 오라클 데이터베이스에서 가장 중요한 영역이며 데이터베이스의 크기를 결정하는 척도이고 전체 실행속도를 향상시키기 위한 튜닝의 대상이 되기도 합니다. 그리고, 데이터베이스에 접속하는 모든 사용자들이 공유하는 영역이며 기본적으로 오라클 데이터베이스 서버는 하나의 SGA 영역으로 구성되어 있습니다.
공유 풀 영역(Shared Pool Area)
  SQL*PLUS, 애플리케이션 프로그램 등에서 데이터베이스에 접속하면 하나의 사용자 프로세스와 하나의 서버 프로세스가 할당되고 사용자는 SQL문을 실행하게 됩니다. 그리고, 서버 프로세스는 SQL문의 문법(Syntax)을 확인하고 사용된 테이블이 데이터베이스 내에 존재하는지를 확인한 다음 SQL문의 실행 가능한 실행코드와 실행에 필요한 실행 계획(Explain Plan)을 수립하고 그 내용을 저장하는 곳이 공유 풀(Shared Pool) 영역입니다. 공유 풀 영역은 2가지 영역으로 구성되어 있는데 라이브러리 캐쉬(Library Cache) 영역에는 실행코드와 실행계획이 저장되고 자료사전 캐쉬(Data Dictionary Cache) 영역에는 사용자가 읽게 되는 자료사전 테이블과 뷰 정보가 저장됩니다.
데이터 버퍼캐쉬 영역(Data Buffer Cache Area)
  서버 프로세스는 사용자가 실행한 SQL문에 정의된 테이블이 존재하는 데이터 파일로부터 테이블을 읽어서 데이터베이스 버퍼 캐쉬(Buffer Cache) 영역에 저장합니다. 예를 들어, 윈도우 운영체제의 탐색기 화면에서 어떤 파일을 참조하기 위해 더블-클릭을 하면 파일의 데이터는 메모리의 버퍼영역에 로드되고 다시 편집 프로그램에 의해 화면에 출력됩니다. 이때 사용되는 메모리 버퍼 영역과 원리가 유사합니다.
로그버퍼 영역(Log Buffer Area)
  사용자가 실행한 DML문을 커밋(Commit)하면 화면에 '커밋이 성공적이다'라는 메시지를 보여줍니다.(또는 롤백을 실행하면 '롤백되었읍니다') 이때 커밋했던 모든 작업내용을 메모리의 로그 버퍼(Log Buffer) 영역에 저장하게 됩니다. 모든 작업내역을 리두로그 버퍼에 저장하는 이유는 갑작스런 시스템의 다운 또는 데이터베이스의 다운 시 처리하고 있던 모든 작업내용을 복구하기 위해서 입니다.
예를 들어, 윈도우 운영체제 시스템을 사용하다 시스템의 전원이 갑자기 꺼졌을 때 수행중인 작업이 존재했다면 다시 전원을 켰면 "복구모드"로 전환되어 복구작업을 수행합니다. 이러한 복구작업을 수행하기 위해서 운영체제는 항상 디스크의 일부공간에 작업내역을 백업해두었다가 복구 시 사용하게 되는데 이러한 원리와 같은 개념입니다.
라지 풀 영역(Large Pool Area)
  오라클 8.x 버전부터 백업과 복구작업을 실행할 때 복구관리자(Recovery Manager)라는 툴을 사용할 수 있고 또한, 사용자가 데이터베이스에 접속하는 방법 중에 공유서버(Shared Server) 프로세스라는 환경이 있는데 이러한 환경을 구성할 때 라지 풀 영역을 사용합니다
 
  파일영역
데이터베이스의 마지막 구조인 파일영역에는 데이터베이스가 생성되면서 만들어졌던 자료사던 테이블과 뷰 그리고 사용자가 직접 생성한 테이블, 인덱스, 뷰, 시퀀스, 시노늄 등이 저장되어 있습니다. 또한, 데이터베이스의 모든 상태정보가 저장되어 있습니다. 파일영역을 "데이터베이스"라고 부르기도 합니다. 그럼, 보다 자세히 알아보도록 합시다.
컨트롤 파일(Control Files)
  데이터베이스를 시작(STARTUP)할 때 항상 참조되는 파일이 컨트롤 파일입니다. 왜냐하면, 컨트롤 파일은 데이터베이스에서 사용하게 될 모든 파일들의 절대경로와 파일크기 등의 정보를 저장하고 있기 때문에 파일들의 이상유무를 확인하기 위해서 참조하게 됩니다.(차후에 "백업과 복구"에서 자세히 소개됩니다.) 그리고 새로운 데이터 파일이 추가되면 해당 파일의 디렉토리 정보와 파일의 상태를 컨트롤 파일에 저장합니다.
오라클 데이터베이스가 시작되기 위해서는 최소한 하나의 컨트롤 파일이 존재해야 하는데 유니버셜 인스톨러에 의해 설치하면 3개의 컨트롤 파일이 기본적으로 생성됩니다. 이중에 하나는 원본이고 나머지는 복사 본 파일입니다. 컨트롤 파일은 오라클 데이터베이스가 존재하기 위해 꼭 필요한 파일이기 때문에 원본 컨트롤 파일에 문제가 발생하면(컨트롤 파일이 사용자에 의해 삭제되거나 컨트롤 파일이 존재하는 디스크가 깨지는 사태) 복사 본 컨트롤 파일로 대체해서 사용하기 위해서 입니다.
파라메터 파일(Parameter File)
  앞에서 배웠던 SGA 영역를 생각해 보십시오. SGA 영역은 시스템 메모리 영역으로부터 데이터베이스가 전용으로 사용하기 위해 할당받게 되는 영역입니다. 그렇다면, 시스템으로부터 얼마만큼의 메모리 크기를 할당받게 될까요 ? 그 의문의 해답을 가진 파일이 파라메터 파일입니다. 또한, 파라메터 파일은 컨트롤 파일의 경로, 데이터베이스의 환경설정 등 관련된 모든 정보를 포함하고 있습니다.
이 파일은 데이터베이스의 튜닝 시에도 사용되는 매우 중요한 파일 중의 하나입니다. 운용체제에 따라 약간의 차이는 있지만 기본적으로 데이터베이스를 설치하면 다음 그림과 같이 INIT<DB명>.ORA 또는 INIT.ORA 라는 파일 이름으로 존재합니다.
데이터 파일(Data Files)
  사용자들이 실행한 SQL문에 의해 변경되는 모든 데이터는 논리적으로는 테이블과 인덱스에 저장되지만 실제로는 운영체제 상에 존재하는 데이터 파일에 저장됩니다. 예를 들어, SQL*PLUS 툴에서 사용자가 생성한 테이블을 SQL*PLUS 내에서 SELECT, UPDATE, INSERT, DELETE 하면 데이터가 저장되고 변경됩니다. 하지만, SQL*PLUS 툴을 종료한 후 운영체제 상에서 사용자가 생성한 테이블을 조회하려면 어떻게 해야 할까요 ?? 운영체제 상에서는 확인 할 방법이 전혀 없습니다.
즉, SQL*PLUS 툴 내에서 만 테이블이라는 논리적인 구조를 눈으로 직접 확인할 수 있고 운영체제에서는 파일을 통해 사용자의 테이블이 존재한다는 것을 확인할 수밖에 없는 것입니다. 이러한 파일을 데이터 파일이라고 합니다.
리두로그 파일(Redo-Log Files)
  사용자가 실행한 SQL문을 커밋(Commit)하면 화면에 '커밋이 성공적이다'라는 메시지를 보여줍니다. 이때 커밋했던 모든 작업내용은 리두로그 파일에 백업됩니다. 이렇게 리두로그 파일에 저장하는 이유는 갑작스런 시스템의 다운 또는 데이터베이스의 다운 시 처리하고 있던 모든 작업에 대해 복구작업을 수행하기 위해서 입니다.
 
  백그라운드 프로세스
오라클 데이터베이스의 현재 상태를 모니터링하거나, 사용자가 실행한 SQL문의 작업을 처리해주는 프로세스를 백그라운드 프로세스라고 합니다. 백그라운드 프로세스에는 데이터베이스가 시작될 때 꼭 필요한 DBWR(Database Writer), LGWR(Log Writer), SMON(System Monitor), PMON(Process Monitor), CKPT(CheckPoint)가 있습니다. 만약, 5개의 백그라운드 프로세스 중 하나라도 존재하지 않는다면 데이터베이스는 더 이상 사용할 수 없습니다. 그리고, 이 5개의 프로세스를 필수 백그라운드 프로세스라고 합니다.
DBWR 프로세스
  데이터베이스 기록기(DBWR)는 사용자가 실행한 SQL문에 의해 데이터의 변경내역(입력, 수정, 삭제)을 테이블에 저장하는 작업을 수행합니다. 예를 들어, 사용자가 UPDATE문을 실행하고 커밋(Commit)문을 실행할 때 테이블에 데이터를 저장하는 작업을 데이터베이스 기록기 프로세스가 처리합니다. 데이터베이스 기록기(DBWR)와 로그 기록기(LGWR)는 데이터베이스를 시작하면 자동으로 생성되고 종료하면 없어지는 백그라운드 프로세스입니다.
LGWR 프로세스
  사용자가 실행한 SQL문을 커밋(Commit)하면 화면에 '커밋이 성공적이다'라는 메시지를 보여줍니다. 이때 커밋했던 모든 작업내용을 리두로그 파일에 백업 하게되는데 이러한 작업을 로그 기록기(LGWR)가 처리해 줍니다. 모든 작업내역을 리두로그 파일에 저장하는 이유는 갑작스런 시스템의 다운 또는 데이터베이스의 다운 시 처리하고 있던 모든 작업내용을 다시 복구하기 위해서 입니다.
PMON 프로세스
  사용자들이 데이터베이스에 접속하면 한번의 접속 요구마다 사용자 프로세스가 하나씩 생성됩니다. 프로세스 모니터(PMON)는 이러한 사용자 프로세스들의 상태를 감시합니다. 만약 어떤 사용자 프로세스에 오류가 발생하거나(예를 들어, SQL*PLUS에서 SQL문을 실행하는 중에 윈도우를 닫게 된다면) 또는 사용자 프로세스가 비정상적으로 종료된 경우 모든 작업을 자동적으로 롤백(Rollback) 시켜줍니다.
SMON 프로세스
  시스템 모니터(SMON)는 백그라운드 프로세스와 데이터베이스 메모리 영역의 상태를 감시하며 데이터베이스가 다운된 후 다시 시작될 때 자동적인 복구작업을 수행해 줍니다.
CKPT 프로세스
  체크포인트(CKPT)는 LGWR 프로세스에 의해 활동하며 사용자가 COMMIT문을 실행할 때마다 오라클 서버가 관리하는 시스템 변경번호(SYSTEM CHANGE NUMBER) 및 데이터베이스의 상태정보를 컨트롤 파일과 데이터 파일에 저장하는 작업을 하게됩니다. 또한, CKPT 프로세스가 발생하면 연속적으로 DBWR 프로세스가 작업을 수행하게 됩니다.
기타 백그라운드 프로세스
  5개의 필수 백그라운드 프로세스뿐만 아니라 경우에 따라서 사용할 수 있는 ARCH(Arch Iver), RECO(Recoverer), LCKn(Lock) 등의 기타 백그라운드 프로세스도 있습니다. ARCH 프로세스는 데이터베이스를 복구모드로 운영할 때 사용하며 RECO 프로세스는 분산 DB환경에서 서로 공유되는 객체 간의 동기화를 설정할 때 사용됩니다. 또한, LCKn프로세스는 병렬서버환경(Oralce Parallel Server)에서 테이블의 잠금과 관련된 백그라운드 프로세스입니다.

AutoFS 
-----------------------------------------------------

 autofs 란 ?


클라이언트가 서버에서 공유한 자원을 사용하려고 할 때
mount 란 명령을 사용하지 않아도 자동적으로 mount 하는 방법

NFS에 의해 공유된 파일시스템은 automount를 이용하여 마운트 할 수 있다.

----------------------------------------------------------------------------

# /etc/init.d/autofs [start or stop]

# cd /net/hostA/usr/share/man

hostA의 /usr/share/man을 hostB의 /net디렉토리에 mount.

root가 아닌 일반 user에서도 접근 가능. 자동 mount 제공.


1) Autofs Map

autofs를 관리하는 파일과 디렉토리들. mount list를 /etc/vfstab이 아닌 autofs의 map 파   일에 정의된 내용 참조.

[Map 유형]

master : autofs file system 설정에 사용되는 다른 map(direct, indirect)들이 list 포함.

direct : 완전 경로명을 가진 mount point list들로 client상의 mount point를 정확히 지시.

indirect : 상대경로명을 표현하는 mount point list. client상의 mount point 설정을 위한             상대 경로 이용.


- Master Map : /etc/auto_master 파일

# cat /etc/auto_master

  /net          -hosts               -nosuid,nobrowse

  /-            auto_direct

  /home        auto_home           -nobrowse

  /xfn          -xfn

[mount_point] [map_name]          [map_option]

  map_name : direct or indirect map의 이름으로 마운트하는 정보를 위한 지시어들.

<special map>

-hosts : NFS Server에 의해 공유된 모든 리소스에 접근.

          /net/host_name 아래로 마운트 접근.

-xfn : 네임서비스를 통해 사용 가능한 리소스에 접근.

        /xfn 아래로 mount.

<direct map entry>

/etc/auto_direct에 정의되어 있는 파일의 완전경로명을 automount 프로그램에게 알려주는   pointer.

<indirect map entry>

/net, /home, /xfn은 indirect map을 위한 mount point 정의.

/etc/auto_master로부터 mount point 초기 경로 읽음.


- Direct Map : /etc/auto_direct 파일

# cat /etc/auto_direct

  /export/home/man  -ro,soft  hostA:/usr/share/man

(nfs로 공유된 hostA의 /usr/share/man을 hostB[Client]의 /export/home/man으로 mount    한다. 읽기 전용. nfs가 응답 안 할시 error 리턴.)


- Indirect Map : /etc/auto_home 파일

# cat /etc/auto_home

  (사용자가 어느 시스템에 있던 네트워크를 통해 홈디렉토리를 일관성있게 보이도록 함.)

  +auto_home (automounter에게 NIS or NIS+ database를 보도록 지시.)

  vian  host5:/export/home/vian

  clare host6:/export/home/clare


- automount 명령어

# automount

  -t duration : automount된 시스템의 유지 시간. default=600초

  -v : automount의 실행과정 보여줌.


2) AutoFS Management


- Direct Map 설정

# vi /etc/auto_master

  /-   auto_direct   (direct map 추가)

# vi /etc/auto_direct    (파일 생성)

  /usr/share/man   -ro   hostA:/usr/share/man    (entry 추가)

# automount -v   (변경 사항 적용)


- Indirect Map 설정

# vi /etc/auto_master   (패치디렉토리와 map 추가)

  /service       auto_patch    (파일 생성)

# vi /etc/patch

  patch    hostA:/export/patch   (패치디렉토리와 서버 경로 추가)

# automount -v (변경 사항 적용)

출처 : Tong - forestcamp님의 [솔라리스]통

+ Recent posts