2018. 6. 15. 15:50
  • 아카이브 로그 모드 확인
    현재 데이터베이스의 아카이브 적용 여부는 아래의 명령어 실행을 통해 확인 가능함

    ARCHIVE LOG LIST



    위의 예시를 살펴보면 해당 데이터베이스는 아카이브 모드로 운영중이며
    현재, 이전, 다음의 로그 시퀀스 넘버가 무엇인지 알 수 있다

    추가적으로 V$DATABASE VIEW를 통해서도 아카이브 로그 모드 적용 여부를 알 수 있다



    칼럼명
    내용
    name현재 데이터베이스의 SID
    log_mode아카이브 모드 일때는 위와 같으며 노 아카이브 모드 일때는NOARCHIVELOG가 표시됨
  • 아카이브 로그 모드, 노아카이브 모드의 전환
    노아카이브 로그 모드에서 아카이브 로그 모드로 전환하기 위해서는
    데이터베이스를 마운트 한 상태에서 아래의 명령을 실행하면 됨

    ALTER DATABASE ARCHIVELOG;

    반대로 아카이브 모드에서 노아카이브 모드로 전환하려면 동일하게 마운드 상태에서

    ALTER DATABASE NOARCHIVELOG; 

    명령어를 실행하면 됨
    실제 데이터베이스 운영상황에서는 한번 아카이브 로그 모드로 데이터베이스를 전환 또는 설정하면 변경하지 않는다


  • 아카이브 로그 파일 확인
    이전에 생성된 아카이브 로그 파일의 정보는 V$ARCHIVED_LOG 뷰에서 확인 가능
    데이터베이스가 노아카이브 로그 모드이면 당연히 해당 뷰의 컬럼값은 없으며
    데이터베이스 open 이후 로그 스위치가 한번도 발생하지 않았다면 역시 해당 뷰는 확인 할 수 없다
    (실제 운영중인 데이터베이스에서는 그럴일이 없겠지만)






    두번째 v$log 뷰를 조회한 내용과 v$archived_log 뷰를 조회한 것에서 sequence#을 주목하면
    로그스위치 발생 후의 로그 그룹의 시퀀스 넘버가 447인 것과 아카이브 로그 파일의 시퀀스 넘버가 447인것을 알 수 있고
    이는 같은 내용의 REDO로그 데이터가 저장되어 있다는 의미이기도 하다


Posted by 엠 군
2018. 6. 15. 15:49
  • 아카이브 로그 모드와 아카이브 REDO 로그 파일
    아카이브 로그 모드(Archive log mode)는 REDO 데이터를 덮어 쓰기 전에
    REDO 데이터를 아카이브 로그 파일로 복사하여 REDO 데이터를 저장하는 방식임

    데이터베이스를 아카이브 로그 모드로 운영을 하게 되면,
    (거의) 모든 REDO 데이터를 저장 할 수 있고 이는 백업파일을 이용하여 데이터베이스를 복구할 때
    아카이브 로그 파일을 사용하여 아카이브 로그 파일에 데이터가 저장된 시점까지 데이터베이스를 복구 할 수 있음

  • 아카이브 로그 파일의 생성
    데이터베이스를 아카이브 로그 모드로 운영중이면 로그 스위치가 발생 했을 때
    ARCn이라는 백그라운드 프로세스가 새로운 아카이브 리두 로그 파일에 REDO 로그 파일에 기록된
    REDO 데이터를 복사함

  • Log Sequence Number(로그 시퀀스 넘버)
    아카이브 모드로 운영되는 데이터베이스에서는 로그 스위치가 발생 할 때 마다
    계속해서 아카이브 로그 파일을 생성함
    이렇게 지속적으로 변경이 발생하는 REDO 로그 파일과 차례로 생성되는 아카이브 REDO 로그 파일을 식별하기 위해
    로그 시퀀스 넘버라는 일련번호를 REDO 로그 파일과 아카이브 로파일에 부여함(당연히 unique)

    로그 시퀀스 넘버는 로그 스위치가 발생하여 REDO 로그 데이터를 다음 REDO 로그 파일에 쓰기 시작할때 할당되며
    그 값은 과거의 로그 시퀀스 넘버 + 1한 값임(이전 로그 시퀀스 넘버가 3001이었으면 3002같이)
    같은 로그 시퀀스 넘버를 가지는 REDO 로그 파일과 아카이브 로그 파일에 저장된 REDO 데이터의 내용은 동일함

  • REDO 로그 파일의 다중화
    REDO 로그 파일은 장애가 발생 했을 경우 데이터 손실의 최소화(또는 손실 방지)를 위해 필요하며
    REDO 로그 파일의 다중화는 장애가 로그 파일에 문제가 생겨 데이터의 마지막 변경 시점까지의 복구를 할수 없는 일이 발생하지 않도록 하기 위함임

    오라클은 REDO 로그 그룹에 여러 멤버를 할당하여 로그 파일을 다중화 할 수 있음
    REDO 로그 그룹이란 n개 이상의 로그 파일(=멤버)로 구성된 그룹을 의미함

    LGWR은 현재 current 상태의 그룹에 대해 동일한 REDO 데이터를 기록하며 
    이는 같은 내용을 가진 로그 파일이 그룹에 있는 파일 갯수 만큼 여러개가 존재함을 의미
    동일한 그룹에 포함된 각각의 로그 파일을 별도의 디스크로 분산하여 관리하면 디스크 손상에 의한 장애 발생시
    (같은 그룹의) 다른 로그 파일을 이용하여 데이터베이스의 가용성을 높일 수 있음

  • REDO 로그 그룹의 확인
    REDO 로그 그룹에 관한 정보는 V$LOG VIEW를 이용하여 확인


    위의 실행 예를 보면 현재 #3 그룹이 current 상태이며 로그 시퀀스 넘버는 446임을 알 수 있다

    V$LOG 칼럼값의 내용은 아래 표를 참조

    칼럼명
    내용
    group#REDO 로그 그룹의 번호
    statusREDO 로그 그룹의 상태
    sequence#REDO 로그 그룹의 로그 시퀀스 넘버
    membersREDO 로그 그룹에 포함된 멤버수(=파일 갯수)
  • REDO 로그 파일 확인
    REDO 로그 파일에 관련된 정보는 V$LOG 뷰와V$LOGFILE 뷰에서 확인할 수 있으며
    아래의 예시는 로그 파일의 위치(디렉토리)와 이름을 확인 하는 것이다

    REDO 로그 그룹은 총 3개 각 로그 그룹에는 2개의 로그 파일이 있고 경로는 위와 같음을 알 수 있다



    V$LOGFILE 뷰의 내용은 위와 같으며
    status 칼럼은 정상적인 데이터베이스 운영 중에는 null 값이 출력된다
    (만약 장애가 생기게 되면 inactive, recovery등으로 변경됨)

  • 로그 스위치의 실행
    로그 스위치는 현재 current 상태인 로그 파일에 공간이 없어 다른 로그 파일이 REDO 데이터를 써야할 때 생기는 
    이벤트 인데, 오라클 서버가 자동으로 실행하기도 하고 관리자에 의해 수동으로 적용이 가능함

    ALTER SYSTEM SWITCH LOGFILE;


    해당 명령어 실행으로 current 그룹이 #3에서 #2로 변경되었으며 로그 시퀀스 넘버도 변경되었음


Posted by 엠 군
2018. 6. 15. 15:49
  • REDO log 파일
    온라인 REDO 로그 파일이라고도 하며 이는 데이터 파일에 대한 변경 사항을 기록하는 파일이다.
    예를 들어 특정 테이블에 데이터를 insert하여 추가하거나 delete문을 사용하여 row값을 지우는 등의 작업을 수행할때
    모든 변경 사항을 기록함

    § REDO log 파일에 기록되는 시점
    데이터 파일에 대한 모든 변경 사항은 트랜잭션이 커밋된 시점에 리두 로그 파일에 기록됨
    오라클은 커밋된 트랜잭션의 리두 데이터가 리두 로그 파일에 기록되는 것을 보장함
    따라서 장애가 발생하여 데이터 변경 사항이 데이터 파일에 기록되지 않았을지라도 리두로그 파일에
    변경 사항이 기록되어 있으므로 리두 로그 파일만 존재한다면 데이터가 유실되는 일은 막을 수 있음
    만약 리두 로그 파일이 손상되면 손상 이전의 시점까지만 복구가 가능함

  • REDO 로그 버퍼와 LGWR
    리두 로그 버퍼는데이터 변경 사항 발생 시 생성된 리두데이터를 임시 보관하는 메모리 영역임
    리두 데이터는 일단 SGA 영역의 리 두로그 버퍼에 저장되었다가 특정 시점에 백그라운드 프로세스인 LGWR에 의해
    REDO 로그 파일에 기록됨
    정보를 한꺼번에 내려씀으로 인해 불필요한 디스크 I/O를 줄일 수 있고 이는 성능향상으로 이어짐
    리두 로그 버퍼에 할당된 메모리 영역의 크기는 initial parameter인 LOG_BUFFER로 지정 할 수 있음
    1. LGWR이 리두 데이터를 내려 쓰는 시점
      1. commit
      2. every 3 second
      3. DBWn 프로세스가 redo 데이터 쓰기를 요청할 떄(=데이터 파일에 변경된 블록을 기록 할때)
      4. REDO 로그 버퍼의 용량이 부족한 경우
      5. 기록해야할 REDO 로그 데이터가 REDO 로그 버퍼 전체 크기의 1/3에 도달 했을때

    2. REDO 로그 버퍼와 변경 처리의 정지
      오라클은 리두로그 버퍼가 가득 차게 되면 데이터 변경 처리를 정지 시킴(=DB Hang)
      관리자는 이와 같은 상황이 일어나지 않도록 아래와 같이 유의해야함
      1. REDO 로그 파일은 속도가 빠른 디스크에 위치 시킴
      2. REDO 로그 버퍼의 사이즈를 여유있게 둔다(공간의 낭비가 생기진 않아야함)

  • REDO 로그 파일의 순환 기록
    데이터베이스에는 반드시 두개 이상의 REDO 로그 파일이 할당 되어 야 함
    LGWR은 할당된 REDO 로그 파일을 순환해가며 REDO 데이터들을 기록함

    § 로그 파일의 상태
    로그 파일의 상태는 v$log view의 status 컬럼을 확인하면 알수 있으며 상세 내용은 아래와 같음

    status 칼럼값
    설 명
    CURRENTLGWR이 해당 REDO 로그 파일(그룹)에 REDO 값을 내려씀
    ACTIVE인스턴스에 장애가 발생하면 해당 REDO 로그 그룹에 기록된 변경 이력이 필요해짐
    INACTIVE현재 사용하지 않는 REDO 로그 파일(그룹) 인스턴스 장애가 발생해도 해당 그룹에 기록된 내용은 필요 없음
  • 순환 기록의 동작

    로그 파일이 3개 있다는 가정을 하고 위 그림을 순서대로 설명하면, 
    ① 현재 LGWR 프로세스는 REDO log 파일 #1에 REDO 데이터를 쓰고 있으며 파일의 상태는 current
    ② #1 파일에 데이터가 가득차서 더이상 LGWR 프로세스가 #1에 REDO 데이터를 쓰지 못하게 되면
        log switch라는 이벤트가 발생하며 LGWR 프로세스는 #2에 REDO 데이터를 쓰게 됨
        이때 #2에 있던 데이터들은 덮어쓰게 되며 #2에 있던 데이터를 유지하기 위해서는 아카이브가 필요함
    ③ #2에도 데이터가 가득차게되어 더 이상 공간이 없게 되면 2번과 같이 로그스위치가 발생하며 
    ④ #3에 REDO 데이터를 쓰기 시작함 #3도 동일하게 1번부터의 과정을 순환, 반복함

 

Posted by 엠 군
2018. 6. 8. 15:51
  • 데이터 파일과 블록
    오라클은 데이터를 읽고 쓰는 작업을 데이터 블록(이하 블록)이라고 불리는 고정된 크기의 영역 단위로 수행
    따라서 테이블, 인덱스 등 모든 객체들은 블록 단위로 분할된 상태에서 데이터 파일에 저장됨

    블록의 크기는 2kb, 4kb, 8kb, 16kb, 32kb 중 하나를 지정할 수 있으며 기본값은 8kb임
    데이터베이스 블록의 기본 크기는 데이터베이스를 생성할때 지정 할 수 있으며 이는 standard block size라고 함
    standard block size는 데이터베이스 생성 이후에는 변경 할 수 없음

    오라클 9i 이후 버전에서는 standard block size와 다른 블록 크기로 테이블 스페이스를 생성 할 수있음
    (이는 nonstandard block size라고 함)

  • 데이터베이스  버퍼 캐시(buffer cache)
    데이터베이스 버퍼 캐시는 데이터를 효율적으로 읽고 쓰기 위해 SGA 안에 마련된 메모리 공간임
    데이터베이스 버퍼 캐시에 할당되는 메모리 영역의 크기는 initial parameter 인 DB_CACHE_SIZE로 지정함
    데이터베이스 버퍼 캐시의 크기를 크게 설정하는 것만으로도 성능 개선을 기대 할 수 있음
    1. for CACHE
      데이터 파일에서 읽어온 블록을 메모리 상에 임시 보간 하는 것으로 읽기 성능을 개선하는 cache의 역할을 함
      같은 블럭에서 여러번 같은 데이터를 읽어 오는 것을 가정 할 때,
      버퍼 캐시를 이용한다면 디스크 I/O를 줄일 수 있고 이는 성능 개선으로 이어짐
      버퍼 캐시의 크기는 한정적이르모 오라클은 버퍼 캐시에 보관되는 블럭을 LRU 알고리즘으로 관리함
      (LRU 알고리즘이란 마지막으로 사용한 후 가장 오래된 데이터를 관리하기 위한 알고리즘임)

    2. for BUFFER
      버퍼 캐시는 캐시의 역할 뿐 아니라 블록을 기록하는 횟수를 줄여 성능 개선을 꾀하는 버퍼로써의 역할도 지님
      오라클은 변경된 블록을 즉시 데이터 파일에 기록하지 않고 우선 데이터베이스 버퍼 캐시에 보관함
      deferred write라고 하여 체크포인트(checkpoint)라는 이벤트가 발생하면 백그라운드 프로세스인 DBWn이 데이터 파일에 한번에 내려씀
      블록의 변경 횟수만큼 디스크에 직접 기록하지 않으므로 디스크 I/O를 줄이고 성능 개선으로 이어짐

    3. 데이터베이스 버퍼 캐시 확인
      아래의 쿼리를 통해 확인 할 수 있음



      더불어, SGA의 상세 정보는 V$SGASTAT VIEW에서 확인 할 수 있음

  • § nonstandard block size
    오라클 9i 이후 버전에서는 스탠다드 블록사이즈와 다른 크기의 블록 사이즈를 지정 할 수 있으며
    비표준 블록크기를 지정하면 테이블 영역에 서로 다른 블록 크기로 데이터를 저장 할 수 있게됨
    단, 블록 사이즈에 맞게 initial parameter인 DB_nK_CACHE_SIZE를 설정하여 비표준 블록 사이즈에 맞는
    데이터베이스 버퍼 캐시를 구성해줘야 함


Posted by 엠 군
2018. 6. 8. 15:50
  • 데이터 파일과 테이블스페이스의 관계
    데이터베이스의 데이터(테이블, 인덱스 및 기타 오브젝트 등)는 데이터 파일에 보관 되어 있음
    데이터 파일은 파일 시스템상에 생성되는 일반적인 파일이므로 OS상에서 확인 가능
    (단, ASM 환경에서는 일반적인 파일시스템과 동일하게 확인 할 수는 없음)


    위의 그림을 설명하면 실제로 데이터베이스 내부에 물리적으로 존재하는 것은 데이터 파일과 데이터를 저장하는 최소 공간인 OS 블럭이 있고
    한 개 이상의 데이터 파일을 그룹으로 묶은 후 명명한 테이블스페이스라는 논리적 저장공간이 존재함
    테이블 스페이스는 오라클이 정의한 논리적인 저장 공간이므로 OS 상에서 실제로 확인할 수 없음(존재 하지 않으므로)
    데이터베이스 내에서 오브젝트(객체, 테이블이나 인덱스등)를 생성할때 데이터 파일을 지정하는것이 아니라 테이블 스페이스를 지정함

  • 테이블 스페이스의 종류

    종류
    설명
    Permanent Tablespace테이블이나 인덱스 등 데이터베이스에서 활용하기 위한 객체들을 저장하기 위한 테이블 스페이스
    UNDO TablespaceUNDO 정보만을 저장하기 위한 테이블 스페이스. 사용자가 생성한 테이블이나 인덱스등의 객체 저장이 불가능
    Temporary TablespaceSQL 처리(정렬, sort)시 사용하는 임시 작업용 테이블 스페이스. 사용자가 생성한 테이블이나 인덱스등의 객체 저장이 불가능

     

    1. Permanent Tablespace
      Permanent Tablespace는 오라클 동작에 필수인 Permanent Tablespace와 사용자의 데이터를 보관하기 위한 Permanent Tablespace가 있음
      1. for System
        SYSTEM Tablespace와 SYSAUX Tablespace는 오라클이 동작하는데 필수적인 테이블 스페이스임
        시스템 테이블스페이스에는 data dictionary가 저장되어 있으며 SYSAUX 테이블 스페이스에는 AWR Repository 등 필수적인 관리 정보가 저장됨
        두 테이블 스페이스 모두 사용자의 객체들을 저장할 수 있기는 하나, 운영의 효율성을 고려하여 사용자의 데이터는 저장하지 않는다.
      2. for User
        위의 두개의 테이블 스페이스를 제외한 나머지 테이블 스페이스는 사용자의 데이터를 저장하기 위한 테이블 스페이스임
        DBCA를 사용하여 데이터베이스를 생성하면 기본적으로 USERS 테이블 스페이스가 생성됨

    2. UNDO Tablespace
      UNDO 테이블 스페이스는 UNDO segment를 저장하기 위한 전용 테이블 스페이스
      따라서 사용자가 생성한 객체(인덱스, 테이블 등)는 저장 할 수 없음
      DBCA를 사용하여 데이터베이스를 생성하면 기본적으로 UNDOTS1이라는 이름의 테이블 스페이스가 생성됨

      § UNDO Segment
      UNDO 세그먼트는 변경 전 데이터(=last commit 데이터)를 보관하는 영역임. UNDO Segment의 키워드는 Rollback  
      트랙잭션이 시작되면 해당 트랜잭션에 자동으로 특정 UNDO 세그먼트가 할당되며
      해당 트랜잭션에서 변경된 데이터의 변경 전 데이터는 각 트랜잭션에 할당된 UNDO 세그먼트에 보관됨
      여기에 보관된 데이터는 트랜잭션의 롤백이나 read consistency를 위해 변경 전 데이터가 필요할 때 사용됨

    3. Temporary Tablespace
      임시 세그먼트라 불리는 작업용 디스크 영역을 보관하기 위한 특별한 테이블 스페이스
      UNDO 테이블 스페이스와 같이 사용자의 객체를 저장하여 사용 할 수 없으며
      DBCA를 사용하여 데이터베이스를 생성하면 기본적으로 TEMP라는 이름으로 생성됨
      임시 테이블 스페이스에는 임시 파일이라는 특수한 데이터 파일로 구성되는데 여기에는 오브젝트들을 보관 할수 없으므로
      다른 테이블 스페이스와 같이 백업이 필요하지 않음

      § Temporary Segment
      임시 세그먼트는 처리에 필요한 일시적인 작업 영역을 메모리상에 확보 할 수 없을 때 할당되는 작업용 디스크 공간임
      예를 들어, SQL을 처리 후 출력하는 과정에서 정렬(=sort, order by절 이용 같은)처리에 필요한 데이터 양이 적을 때는
      PGA의 SQL Work area(sorting 영역)에서 처리하지만 필요한 공간의 크기가 SQL Work area의 크기를 넘어버리게 되면
      임시 세그먼트를 할당함. 할당 후 해제하는 것은 오라클이 자동으로 수행(어느 프로세스가 하더라?)

  • 데이터 파일과 테이블 스페이스의 확인
    1. 테이블 스페이스의 확인: DBA_TABLESPACES라는 VIEW에서 확인 가능
      아래 그림과 같이 쿼리를 사용하여 내용을 확인 가능함



    2. 데이터 파일 확인: DBA_DATA_FILES라는 VIEW에서확인 가능
      아래 그림과 같이 쿼리를 사용하여 내용을 확인 할 수 있음



      ※ ASM 환경에서는 같은 쿼리를 사용해도 다른 결과가 나옴



    3. 임시 테이블 스페이스 확인
      아래의 쿼리를 사용하여 확인할 수 있으며 위와 같이 ASM 환경에서는 다른 결과가 표시됨



      ※ ASM 환경



Posted by 엠 군
2018. 6. 8. 12:52

1.개요

CSScan 유틸리티는 DB의 data를 Migration 할 때 As was DB와 To be DB의 Character set이 서로 다를 때

As was DB의 data character set을 To be DB의 data character set으로 변경하여 주는 유틸리티입니다.

data를 Migration 하는 경우 말고 업그레이드 시에도 활용이 가능합니다. (당연히요)

(제가 아는 한에서는) 이 유틸리티는 11g까지 지원합니다.

 

2.실행 

## csminst 스크립트를 실행시킵니다.
 
SYS>@?/rdbms/admin/csminst.sql
User created.
 
Grant succeeded.
 
(중략)
 
Grant succeeded.
 
Grant succeeded.
 
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
## 스크립트 실행 후 sqlplus 접속이 끊기므로 실행 완료 후 재접속 해줍니다.
 
[oracle@oracle54 ~]$ sqlplus / as sysdba
 
SQL*Plus: Release 11.2.0.4.0 Production on Tue Apr 17 08:16:06 2018
 
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
 
 
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
## csmig 계정을 잠금 해제합니다.
 
SYS>alter user csmig identified by csmig account unlock;
 
User altered.
 
## OS 레벨에서 csscan 유틸리티를 실행시킵니다.
                   
[oracle@oracle54 ~]$ csscan system/dlrlwk (system 계정을 사용합니다.)
 
Character Set Scanner v2.2 : Release 11.2.0.4.0 - Production on Tue Apr 17 08:17:22 2018
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
## 변경할 캐릭터 셋의 레벨을 설정합니다. 1번을 선택 할경우에는 아래의 scan process를 늘려줍니다.
지금의 실습은 user level입니다.
 
(1)Full database, (2)User, (3)Table, (4)Column: 1 > 2
 
## 현재의 캐릭터 셋을 확인합니다.
 
Current database character set is KO16MSWIN949.
 
## 변경할 캐릭터 셋 이름을 입력합니다.
 
Enter new database character set name: > AL32UTF8
 
## fetch 버퍼 용량을 선택해줍니다. 엔터키를 누르면 기본값을 선택합니다.(상황에 알맞게 사용)
 
Enter array fetch buffer size: 1024000 >
 
## scan process 숫자를 설정합니다. 환경이 좋고 많은 리소스가 필요하면 넉넉히 입력합니다
(저의 실습 환경은 좋지 않아서 최대값이 1입니다.)
 
Enter number of scan processes to utilize(1..): 1 > 1
 
## User Schema 이름을 입력합니다.
Enter user name to scan: > SCOTT
 
## 작업이 시작됩니다.
Enumerating tables to scan...
 
. process 1 scanning SCOTT.MIGDEPT2[AAAV3UAAEAAAAIYAAA]
. process 1 scanning SCOTT.DEPT[AAAVRCAAEAAAACAAAA]
. process 1 scanning SCOTT.MIGDEPT[AAAV3TAAEAAAAIQAAA]
. process 1 scanning SCOTT.DEPT2[AAAVznAAEAAAAMwAAA]
. process 1 scanning SCOTT.EMP[AAAVREAAEAAAACQAAA]
. process 1 scanning SCOTT.AUDIT_DEPT[AAAVpAAAEAAAAIIAAA]
. process 1 scanning SCOTT.INFO[AAAVxNAAEAAAAIgAAA]
 
Creating Database Scan Summary Report...
 
Creating Individual Exception Report...
 
## 작업이 완료 되었습니다.
Scanner terminated successfully.

3.작업확인

## 작업을 실행한 디렉토리에서 아래와 같이 검색합니다.
  
[oracle@oracle54 ~]$ ls -al scan*
-rw-r--r--. 1 oracle oinstall 1437 Apr 17 08:21 scan.err
-rw-r--r--. 1 oracle oinstall 1223 Apr 17 08:21 scan.out
-rw-r--r--. 1 oracle oinstall 7617 Apr 17 08:21 scan.txt
 
## Scan.* 파일의 내용은 아래와 같습니다.
 - scan.out: scanning 과정을 저장 한 파일 입니다.
 - scan.txt: scan 관련 내용의 종합 보고서 입니다.
 - scan.err: 캐릭터셋 변경시 손실되는 데이터에 대한 정보 입니다
 
 
## scan.txt 파일을 살펴 보겠습니다.
  
[oracle@oracle54 ~]$ vi scan.txt
 
Database Scan Summary Report
 
Time Started  : 2018-04-17 08:21:12
Time Completed: 2018-04-17 08:21:34
 
Process ID         Time Started       Time Completed
---------- -------------------- --------------------
         1  2018-04-17 08:21:30  2018-04-17 08:21:32
---------- -------------------- --------------------
 
[Database Size]
 
Tablespace                           Used            Free           Total       Expansion
------------------------- --------------- --------------- --------------- ---------------
SYSTEM                            765.06M           4.94M         770.00M            .00K
SYSAUX                            709.25M          40.75M         750.00M            .00K
UNDOTBS1                           15.25M       2,004.75M       2,020.00M            .00K
TEMP                                 .00K            .00K            .00K            .00K
USERS                           4,201.25M         211.25M       4,412.50M            .00K
EXAMPLE                           310.19M          36.06M         346.25M            .00K
------------------------- --------------- --------------- --------------- ---------------
Total                           6,001.00M       2,297.75M       8,298.75M            .00K
 
[Database Scan Parameters]
 
Parameter                      Value
------------------------------ ------------------------------------------------
CSSCAN Version                 v2.1
Instance Name                  orcl
Database Version               11.2.0.4.0
Scan type                      User tables
User name                      SCOTT
Scan CHAR data?                YES
Database character set         KO16MSWIN949
FROMCHAR                       KO16MSWIN949
TOCHAR                         AL32UTF8
Scan NCHAR data?               NO
Array fetch buffer size        1024000
Number of processes            1
Capture convertible data?      NO
------------------------------ ------------------------------------------------
  


Posted by 엠 군
2018. 6. 8. 12:50

top는 리눅스 상의 유틸리티로 루트 권한에서 사용이 가능하며 

시스템 리소스를 보여주는 유틸리티입니다.

이 페이지에서 소개할 htop 유틸리티는 기본적으로 top 유틸리티와는 동일한 유틸리티이지만

가시성 및 편의성이 좋은 UI를 가지고 있음에도 불구하고 리소스를 많이 사용하지 않는 다는 장점이 있습니다.

OEL이나 Redhat 리눅스 상에서는 설치 방법이 Ubuntu 같은 debian 계열과는 조금 달라서 아래의 내용을 참고하셔서 활용하시기 바랍니다.

본 안내문은 OEL 6.x, RHEL 6.x 버전까지 유효합니다. 그 이상의 버전에서는 최하단 추가글을 확인하시기 바랍니다.

 

  1. 설치 프로그램 다운로드
    루트 계정에서 아래의 링크를 통해 다운로드 받습니다.  wget 명령어를 사용합니다.

    --2018-04-25 20:35:57--  http://hisham.hm/htop/releases/1.0.3/htop-1.0.3.tar.gz
    Resolving hisham.hm... 69.163.217.231
    Connecting to hisham.hm|69.163.217.231|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 399306 (390K) [application/x-tar]
    Saving to: ??htop-1.0.3.tar.gz??
     
    100%[============================================================>] 399,306      202K/s   in 1.9s   
     
    2018-04-25 20:35:59 (202 KB/s) - ??htop-1.0.3.tar.gz?? saved [399306/399306]
  2. 다운로드 받은 파일의 압축을 해제하고 해당 디렉토리로 이동합니다.

    [root@oracle54 ~]# tar zxf htop-1.0.3.tar.gz
    [root@oracle54 ~]# cd htop-1.0.3
      
      
  3. 다음과 같이 설치 명령어를 실행합니다.

    [root@oracle54 htop-1.0.3]# ./configure; make; make install
    checking for gcc... gcc
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables...
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc accepts -g... yes
    checking for gcc option to accept ISO C89... none needed
    checking how to run the C preprocessor... gcc -E
    checking for grep that handles long lines and -e... /bin/grep
    (중략)
    test -z "/usr/local/share/pixmaps" || /bin/mkdir -p "/usr/local/share/pixmaps"
     /usr/bin/install -c -m 644 htop.png '/usr/local/share/pixmaps'
    make[2]: Leaving directory `/root/htop-1.0.3'
    make[1]: Leaving directory `/root/htop-1.0.3'
  4. 설치 완료 후 유틸리티를 실행시킵니다. (커맨드 라인에서 htop 입력)

         

 

 상단의 CPU%, MEM%를 마우스로 클릭하면 오름차순, 내림차순 정렬이 가능하므로 상황에 맞게 사용하면 됩니다.

 세부 명령어는 하단을 참조하면 됩니다.


OEL 7.x, RHEL 7.x 이상 버전에서 설치 방법

-진행 과정은 크게 다를바가 없으나 버전 및 몇가지 차이가 있으니 확인이 필요합니다.

--2018-05-02 15:06:42--  http://hisham.hm/htop/releases/2.0.2/htop-2.0.2.tar.gz
Resolving hisham.hm (hisham.hm)... 69.163.217.231
Connecting to hisham.hm (hisham.hm)|69.163.217.231|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 476364 (465K) [application/x-tar]
Saving to: ??htop-2.0.2.tar.gz??
 
100%[=============================================================>] 476,364     37.6KB/s   in 11s   
 
2018-05-02 15:06:59 (40.9 KB/s) - ??htop-2.0.2.tar.gz?? saved [476364/476364]
 
[root@oracle54 ~]# tar xvfvz htop-2.0.2.tar.gz
[root@oracle54 ~]# cd htop-2.0.2
[root@oracle54 htop-2.0.2]# yum -y install ncurses-devel 
## 이 구문이 추가로 진행되어야 설치가 가능(중간에 설치 오류가 날 수 있고 오류가 나면 반복 실행하면 됨)
(중략)
Complete!
[root@oracle54 htop-2.0.2]# ./configure; make; make install
(중략)
make[2]: Leaving directory `/root/htop-2.0.2'
make[1]: Leaving directory `/root/htop-2.0.2'
  
  

설치 완료 후 htop입력 하여 사용하면 됩니다.

Posted by 엠 군
2018. 6. 8. 09:46

※ 요약 정리

  • 클라이언트 어플리케이션
    클라이언트 어플리케이션은 오라클 서버에 SQL을 실행하고 그 결과를 회신 받는 어플리케이션의 총칭
    SQL*Plus가 대표적인 제품이며 그외에도 SQL Developer, TOAD, Orange 등의 tool이 있음

  • 서버프로세스와 세션



    - 서버프로세스는 클라이언트 어플리케이션에서 실행된 쿼리(sql 문장)를 받아
      처리를 수행하는 프로세스임
      위 그림을 설명하면
    1. 클라이언트(원격) 에서 오라클 서버로 접속을 원하면
    2. Listener에 접속 요청을 하게되고 Listener에서 이 요청을 받아 오라클 서버와 통신을 연결해줌
      클라이언트와 Listener와의 연결은 Connect라고 하며
    3. connect 이후 클라이언트와 오라클 서버가 통신을 수립하면
      session이 수립된것이며 이렇게 최초 1회에 한해 Listener를 통해 1번, 2번 과정을 거치며 클라이언트와 오라클 서버가 통신
    4. 한번 session이 연결되면 클라이언트와 오라클 서버와의 session에는 Listener 없이도 session이 성립됨
    5. 위의 환경은 dedicated server 환경으로 클라이언트와 서버프로세스가 1:1의 관계를 가짐

  • Listener
    리스너는 클라이언트 어플리케이션에서 네크워크를 통해 송신된 인스턴스로의 접속 요청을 접수하는 프로세스
    리스너를 통해 접속하는 형태를 원격접속(=remote)이라고 함
    동일한 장비 안에서 데이터베이스에 접속 할 경우에는 리스너가 필요하지 않으며 이러한 형태는 로컬 접속(=local)이라함
    로컬 접속만 사용하는 서버에서는 리스너를 가동하지 않아도 됨

  • v$session
    클라이언트와 오라클 서버간 수립된 세션에 대한 정보가 담겨있는 뷰

    § v$session 컬럼 목록과 내용

    컬럼명
    내 용
    sid세션 식별자(당연히 unique)
    serial#세션의 시리얼 번호, 각 세션은 sid와 serial# 두개의 값으로 식별함
    program오라클에 접속한 프로그램. 일반 세션에는 클라이언트 어플리케이션 이름이 표시됨
    username세션에 접속하고 있는 계정명. DBSNMP나 SYSMAN 계정의 세션은 EMDC관리도구에서 접속한 것을 의미함
    type세션의 종류. USER는 일반적인 세션을 의미하고, BACKGROUND는 백그라운드 포르세스가 접속한 세션을 의미함


    § v$session 뷰 확인


    위 화면을 통해 현재 세션의 세부 정보 확인이 가능하다

  • 세션과 프로세스의 관계 (v$process와 v$session)
    dedicated server 환경에서는 한개의 세션마다 한개의 서버프로세스가 기동하는데 
    v$process와 v$session 두 개의 뷰를 조인한 쿼리를 통해 상태를 확인 할 수 있음

    § v$process와 v$session의 조인 쿼리 


    해당 쿼리를 통해 system 계정으로 접속하고 있는 세션은 PID=32, SPID=3955의 서버프로세스에 대응하고 있음을 알 수 있음
     


Posted by 엠 군
2018. 6. 7. 15:45

※ 요약정리

  • ORACLE_HOME : 오라클 소프트웨어를 설치할 디렉토리
  • ORACLE_BASE : 오라클에 관한 여러가지 파일을 배치하는 거점 디렉토리, 일반적으로 ORACLE_BASE>ORACLE_HOME
    ex) /app/oracle > /app/oracle/product/11.2.4/db_1 
  • ORACLE_HOME 하위 중요 디렉토리
    1. ~/database : Windows 환경에서 parameter file, password file 등이 위치함
    2. ~/dbs : Unix,Linux 환경에서 parameter file, password file 등이 위치함
    3. ~/network/admin : 네트워크 접속 관련 설정파일(sqlnet.ora / listener.ora / tnsnames.ora file 등)이 위치함
    4. ~/bin : netca, dbca, sqlplus 등 오라클 관련 프로그램등이 위치함. 보통 환경변수(.profile)에 PATH를 지정하여 사용
    5. ~/sqlplus : sqlplus 관련 파일이 위치함(~/amdin/glogin.sql이 sqlplus 환경 설정 파일임)
    6. ~/rdbms/admin: 오라클 관련 sql(=스크립트) 파일이 위치함
    7. ~inventory: 설치도구들에 대한 정보 또는 ORACLE_HOME에 관련된 정보

  • global database name : 네트워크 내에서 데이터베이스를 특정하기 위한 명칭, DB_NAME과 DB_DOMAIN으로 구성함 데이터베이스의 DB_DOMAIN을 다르게 설정하면 같은 DB_NAME을 가진 데이터베이스를 식별할수 있음
  • SID(system identifier) : 인스턴스의 식별자, 일반적으로 SID=DB_NAME이며 한 대의 서버에 여러개의 인스턴스를 사용할때는 인스턴스마다 다른 SID를 지정 

  • 데이터베이스와 인스턴스

         

       - 데이터베이스는 데이터를 저장하는 데이터파일과 컨트롤 파일, 리두로그 파일, 아카이브 파일등 각종 관련 파일들의 집합이며

         인트턴스는 위 그림의 SGA 라는 메모리 영역과 (백그라운드) 프로세스등으로 구성됨

 

  • 데이터베이스

    파일 종류
    저장되는 데이터
    파 일 크 기
    비 고
    data file (*.dbf)테이블 
    데이터 
    인덱스
    UNDO 데이터 
    temp(임시) 데이터
    저장되는 데이터의 크기에 따라 파일의 크기가 다름반드시 한 개 이상의 데이터 파일이 존재
    Redo log file(*.log)데이터베이스의 변경 사항일반적으로 수십~수백MB 정도이며 
    데이터의 변경 사항이 많을 경우 파일 사이즈가 큼
    두개 이상의 redo 파일이 존재
    Control file(*.ctl)데이터 파일이나 redo 로그 파일의 위치 정보, 
    각 파일의 최종 변경 시간 등 데이터베이스의 구조정보
    n KB~ n MB반드시 한 개 이상의 컨트롤 파일이 존재 
    중요한 파일이므로 두개 이상 다중화가 필요
  • 인스턴스
    인스턴스는 SGA라는 메모리 영역과 백그라운드 프로세스들로 구성됨

    1. SGA
      Shared pool, Database buffer cache, Redo log buffer, large pool, java pool 등으로 구성
      인스턴스를 구동하면 초기화 파라미터에 설정된 값에 따라 메모리 공간을 확보
    2. 백그라운드 프로세스
      SMON, PMON, DBWR,LGWn,CKPT 같은 필수 프로세스와 ARCn, LMON, FBDA,MMON,Mnnn 등 optional한 프로세스들로 이루어짐
      데이터베이스를 지속적으로 수행하는데 필요한 일상적인 유지 업무를 담당

  • SHOW SGA 출력
    SGA의 정보는 해당 오라클 인스턴스에 접속 후 show sga라고 입력하면 확인 가능
    표시항목과 의미는 아래와 같음

    표시항목
    설 명
    Total System Global Area전체 SGA의 크기
    Fixed SizeSGA의 관리 정보가 저장된 고정 영역의 크기
    Variable SizeShared pool, Large pool, Stream pool을 합친 크기
    Database Buffers데이터베이스 버퍼캐시의 크기
    Redo BuffersRedo로그 버퍼의 크기

    사용 예)

 

Posted by 엠 군