http://www.facebook.com/events/117466691700212/
모노레일 에스프레소 부평점에서 오픈 기념 이벤트를 진행 중이에요~
위의 링크로 가셔서 모노레일 에스프레소 부평점 페이지에 좋아요 하시고,
응원의 댓글 남기시면
500원 할인 쿠폰 문자로 쏴드린데용~~^^
맛있는 음료 저렴한 가격에 드셔보세요~
아래의 좋은 정보를 주신,
http://cafe.naver.com/toadsoft/906
감사합니다.^^
아래 내용을 담기 해서 가져오고 싶었으나,
네이버 카페로만 담기가 가능하니까....
부득이하게 copy 해 왔습니다.
==================================================================
안녕하세요.
이번에도 제가 주로 사용하는 Rebuild Table를 Toad를 이용해 컬럼 위치를 변경하는 방법에 대해 간단히 설명드리겠습니다.
프로젝트를 하다보면, 처음에 만들었던 테이블에서 덕지덕지 컬럼이 추가되는데, 가끔 보기 안좋을때가 있어 위치를 바꾸고 싶을 때가 있어 다른 분께 도움이 될까해서 작성해 봅니다.
그림에서는 제 정보가 담겨 있는 부분은 지웠습니다. ^^ 이해해 주세요~또한 그림에서 빨강색으로 박스표시 되어 있는 부분을 강조한 부분입니다.
① 우선 Toad 를 실행후 Schema Browser를 그림과 같이 단축 아이콘을 이용해 쉽게 열어 봅시다.
만약 메뉴를 이용한다면 Database -> Schema Browser 를 이용하시면 됩니다.
② 이 화면은 Schema Browser의 화면입니다.
컬럼 위치를 변경할 부분을 빨강색 박스로 표시했듯이, CCODEMST 테이블의 USEYN <-> REMARK 컬럼 위치를 변경하려고 합니다.
그리고, 좌측 테이블 리스트에서 CCODEMST 테이블을 선택 후 오른쪽 마우스를 클릭합니다.
③ CCODEMST 테이블에서 오른쪽 마우스를 클릭하면 다음과 같이 메뉴가 나오며, 밑에 부분에 있는 Rebuild Table를 선택합니다.
④ 이 화면에서는 여러가지 Rebuild Table 작업을 할 수 있지만, 저는 컬럼 위치 변경하는 예제를 통해 설명드리기 때문에 다른 부분은
전부 Pass 하겠습니다. 탭 메뉴에서 보면 Columns 항목 으로 이동해 봅시다.
그리고 USEYN 항목을 마우스로 클릭해 위로 한칸 옮겨봅시다!
⑤ USEYN, REMARK 항목이 생각한대로 맞게 되었다면 탭 메뉴에서 SQL을 선택합니다.
SQL항목으로 가면 자동으로 스크립트를 생성합니다.
⑥ SQL 탭을 선택하면 잠시 로딩 후 ▶ 버튼 이 활성화 됩니다. 이 버튼을 클립합시다~ gogo~
참고로 화면 내용을 보면 기존 테이블은 CCODEMST_X로 한다라고 되어 있네요~ ^^
⑦ 스크립트의 실행후 ERROR가 발생했는지 보실수 있습니다.
화면에 보면 에러가 하나도 없죠!! ㅋㅋ
그리고 확인버튼 클릭!
⑧ 자~ 스크립트를 실행한 결과입니다.
CODEMST, CCODEMST_X 테이블이 생성이 된걸 확인 하실 수 있습니다.
⑨ CCODEMST 테이블에서 USEYN, REMARK의 위치가 변경 되신걸 확인 하실 수 있죠!?
마지막으로 CCODEMST 테이블이 맞게 되었다면 CCODEMST_X 테이블을 삭제(DROP) 하셔도 됩니다.
이제 더이상의 의미는 없으니까요~
=========================================================================
다시한번 좋은 글 감사합니다.^^
다른분 블로그에서 가져다가 쓰네..ㅋㅋ
(http://www.cyworld.com/vbman/2877958)
두고 자주 봐야겠다..;;
5.3 Storage 하부구조 Oracle Block
Data Block은 Logical Block, Oracle Block 또는 page라는 용어로 불린다. Oracle Block의 크기는 OS Block 의 N배수로 이루어지며 SGA의 Database Buffer에 I/O가 일어나는 기본단위가 된다. 파라미터 파일(init.ora)의 DB_BLOCK_SIZE 값으로 확인 가능하며 Database가 생성될 때 지정된 Oracle Block의 크기는 변경이 불가능 하다. Oracle 9i 부터는 테이블스페이스 별로 Block의 사이즈를 지정할수 있는 다중 블록사이즈를 지원하는데 DB_BLOCK_SIZE값은 Create 문에서 BLOCKSIZE절을 설정하지 않은 경우 기본값으로 지정된다.
왼쪽 그림은 일반적인 블록의 구조를 나타낸다. Block Header는 Block 위치나 Segment Type 같은 일반적인 블록 정보를 가진다. Table Dictionary에는 클러스터에있는 테이블에 관한 정보가 저장된다. Row Dictionary 에는 Block에 포함된 Row 정보를 저장한다. Row Data 영역에는 테이블이나 인덱스 데이터가 저장되어 있고 Free Space는 Insert나 Update문에 의해 추가적인 데이터가 저장될 수 있는 공간이다. 블록과 관련된 주요 저장 파라미터 중에 PCTFREE와 PCTUSED가 있는데 테이블 생성문에서 칼럼정의 바로 다음에 위치하는 것들이다.
∘ PCTFREE : 블럭에 이미 존재하고 있는 로에 update가 가능하도록 Free영역으로 남겨두는 비율을 지정한다. VARCHAR2 칼럼의 경우 데이터가 가변적이므로 update문 실행 시 추가적인 공간을 필요로 하게 된다. 블록의 Free Space가 PCTFREE에 도달하게 되면 블록이 가득찬 것으로 인식하고 insert문에 의해 추가적인 row의 저장을 불가능해진다. delete문에 의해서 블럭의 free space가 PCTFREE 값 아래로 떨어지면 free list에서 옮겨지고 다시 insert가 가능해진다. 기본값은 10 이며 0~99 범위의 값을 줄수가 있고 99면 최소 하나의 ROW만 입력가능하게 된다. PCTREEE 값이 작으면 많은 수의 Row을 해당 블록에 담을 수 있는 반면 DATA가 UPDATE될 때 FREE SPACE를 위해 BLCOK REOGRANIZE 발생으로 관리비용이 증가 한다. 긴 컬럼을 갖고있는 큰 row의 경우 Row Chaining 이나 Row Migration이 발생할 확률이 높아진다. Chained 또는 Migrated Row를 읽을 때 1개 이상의 데이터 블럭을 스캔해야 하기 때문에 I/O 속도가 저하된다.
∘ PCTUSED : 블럭의 Free Space 퍼센트가 PCTFREE에 도달하게 되면 사용된 Space가 PCTUSED 아래로 떨어지기 전까지 해당 Block에 Row를 insert 할 수 없다. 자동세그먼트 관리 모드인 경우 오류없이 지정한 값은 무시된다. 기본 값은 40이고 인덱스가 저장되는 공간에 대해서는 지정할 수 없다. 이 값이 높으면 블록의 재활용성은 높아지지만 Free List와 Dirty List 간의 빈번한 스위칭이 발생하여 오버헤드가 발생될 수 있고 너무 낮으면 블록의 재활용 율이 낮아진다. PCTUSED와 PCTFREE의 합은 100 이하로 주어져야만 하며 적적한 값은 90이다. UPDATE 시 Row Size가 증가되는 일이 많은 테이블의 경우 PCTFREE = 20, PCTUSED = 40 이 적당하다. INSERT, DELETE가 자주 발생하지만 UPDATE시 ROW SIZE가 증가 되지 않는 테이블의 경우 PCTFREE = 5, PCTUSED = 60 정도가 적절하며 TABLE은 매우 크지만 대부분 READ ONLY TRANSACTION 일 때는 PCTFREE = 5, PCTUSED = 90 정도로 설정해도 된다.
∘ INITRANS : 어느 한 시점에 블록에 변경을 일으키는 트랜잭션이 있을 경우 이에 대한 정보를 저장하기위한 공간을 트랜잭션 슬롯 이라고 한다. INITRANS는 데이터블록 이나 인덱스블록에 생성되는 트랜잭션 슬롯의 초기 개수를 지정한다. 데이터 세그먼트는 기본값이 1 인덱스 세그먼트는 기본값이 2다.
∘ MAXTRANS : 인덱스 또는 데이터 블록에 생성되는 트랜잭션 슬롯의 최대 개수로 기본값은 255 다.
5.4 Storage 하부구조 Extent
5.4.1 Extent 개요
Segment에 할당된 일정한 수의 연속된 Oracle Block들을 말한다. 일정한 수라는 의미는 사용자가 create table 문에서 storate option 중 initial 값을 10K로 지정 했고 DB_BLOCK_SIZE가 2K 일 경우 5Block인 된다. 즉, 5개의 Oracle Block 이 하나의 Extent로 구성된다. Database안의 각 Segment가 생성될 때 최소 한 개의 Extent를 가지게 되는데 이를 initial extent 라 한다. 예를 들어 table을 생성 시키면 initial extent 만큼 빈 공간이 할당되며 data가 저장되어 extent가 다 차면 새로운 next extent 만큼 공간이 할당 된다. extent가 할당 되었다는 의미는 테이블스페이스의 여유 공간 일부를 세그먼트에 해당하는 테이블이 추가로 점유했다는 뜻이다. 일반적으로 data가 저장되어있는 object를 dorp하기 전 까지는 할당된 extent는 반납되지 않는다. rollback segments의 경우 free extents를 포함하고 있으며 적정크기 보다 큰 경우 자동으로 해제된다. DBA는 다음과 같은 SQL문장을 이용하여 사용하지 않는 extent를 반납할 수 있다.
SQL>ALTER TABLE table_name DEALLOCATE UNUSED;
5.4.2 DMT vs LMT
∘ DMT(Dictionary Managed TableSpace)
오라클 8.0.5 이전 에서는 TableSpace에서 Extent 할당을 관리하는 방법이 데이터딕셔너리를 이용하는 방법만 존재 했다. 새로운 Extent의 할당이 필요한 시점에 오라클은 Data Dictionary Table에 질의를 하여 어느 extent가 할당 가능한지 파악 하기위해 비용이 높은 Recursive 연산을 수행해야만 하기 때문에 자원에 대한 많은 경합이 발생하였다. 또한 Entent 관리를 통한 효율적인 운용을 위해서는 테이블(segment)에 대해서 PCTFREE, PCTUSED, PCTINCREASE, FREELIST와 같은 저장 파라미터를 DBA가 일일이 관리해 주어야만 했다. 오라클 8.1.5 버전 부터는 Locally Managed Tablespace 라는 새로운 Extent관리 방법이 추가 되었으나 하위버전의 DB를 마이그래이션 한 경우 기존방식대로 DMT 방식을 사용해야만 했다. Oracle 8.1.6 (Oracle 8i release 2)에 와서야 DMT Tablsespace를 LMT 방식으로 전환 시킬 수 있게 되었으나 SYSTEM 테이블스페이스나 오프라인 상태의 테이블스페이스, Temporary Tablespace는 변경할 수 없는 제약 사항이 존재 했다. 테이블스페이스 전환을 위해서는 DBMS_SPACE_ADMIN 패키지의 TABLESPACE_MIGRATE_TO_LOCAL 프로시저를 사용 한다. DBMS_SPACE_ADMIN 패키지는 Locally Managed Tablespace를 관리하는 각종 프로시저를 제공한다. 다음은 레거시버전의 오라클에서 사용되던 테이블 스페이스 생성 스크립트이다.
SQL>CREATE TABLESPACE "ITEST" LOGGING
DATAFILE 'E:\ORADATA\TEST\ITEST.ORA' SIZE 1000M REUSE
EXTENT MANAGEMENT DICTIONARY
DEFAULT STORAGE ( INITIAL 1024K NEXT 1024K MINEXTENTS 1
MAXEXTENTS 2147483645 PCTINCREASE 50 ) MINIMUM EXTENT 0K;
∘ LMT(Locally Managed TableSpace)
Oracle 8.1.5 버전부터 도입되었고 Oracle 9i부터 DMT방식 대신 Extent 관리의 Default가 되었다. Locally Managed Tablespace는 자체 extent에 대한 관리를 각각의 데이터 파일에 비트맵 형식으로 저장하여 관리하는 테이블스페이스로 데이터 파일을 구성하는 블럭이 비어 있는지 사용 중인지에 대한 정보를 관리한다. 비트맵의 각각의 비트는, 하나의 블럭 또는 블럭의 그룹에 해당하는 정보를 나타낸다. 익스텐트가 할당되거나 비워지거나 재사용될 때 오라클에서는 블럭의 새로운 상태를 나타내기 위해 비트맵의 값을 변경한다. LMT의 장점으로는 가용공간에 대한 정보를 데이터 딕셔너리에 저장하지 않으므로 데이터 딕셔너리에 대한 경합을 줄이게 된다. 또 Extent에 대한 local management를 통해, 인접한 가용 공간의 정보를 자동으로 관리하게 되므로 extent에 대한 coalesce 작업을 수행하는 등의 내부 작업이 줄어든다. 9.2부터는 SYSTEM 테이블스페이스를 포함한 모든 테이블스페이스를 LMT 방식으로 생성할 수 있다. CREATE TABLESPACE 문의 EXTENT MANAGEMENT 절
[EXTENT MANAGEMENT
{DICTIONARY | LOCAL
{AUTOALLOCATE | UNIFORM [SIZE integer [K|M] }}]
DICTIONARY : 테이블스페이스에 대해 Dictionary Table를 사용하여 공간 정보를 관리함.
LOCAL : 테이블스페이스가에 대해 비트맵을 사용하여 Locally Managed 방식.
AUTOALLOCATE : 테이블스페이스에 대한 익스텐트 관리를 시스템에서 관리하며 DBA는
익스텐트의 크기를 수동으로 지정할 수 없음.
UNIFORM : 테이블스페이스가 동일한 크기의 익스텐트로 구성되도록 지정함.
크기는 기본적으로 바이트 단위로 지정하며 익스텐트 크기를 KB 또는 MB 단위로 지정하기
위해서는 K 또는 M을 사용함. 이 옵션을 사용하게 되면, DEFAULT Storage 절
MINIMUM EXTENT 또는 TEMPORARY 옵션을 사용할 수 없다.
예) 테이블스페이스 생성
SQL>CREATE TABLESPACE "TEST"
NOLOGGING
DATAFILE 'D:\ORACLE\ORADATA\TEST\TEST1.ORA' SIZE 2000M
REUSE, ''E:\ORACLE\ORADATA\TEST\TEST2.ORA'' SIZE 1000M
REUSE EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
5.5 Storage 하부구조 Segment
5.5.1 세그먼트 개요
테이블 이나 인덱스 등의 객체가 일정시점에 할당한 모든 저장공간(Extent)들을 말한다. 세그먼트는 하나 이상의 익스텐트(Extent)로 구성되며 테이블 세그먼트, 인덱스 세그먼트, 롤백 세그먼트, 템포러리 세그먼트 등이 있다. 각 세그먼트에 저장되는 데이터나 용도에 따라 다른 특성을 가지므로 DBA의 적적한 관리가 필요하다. Oracle 9i 버전부터 세그먼트 내의 영역 관리를 자동으로 처리해주는 ASSM (Automatic Segment Space Management) 기능이 도입되었다.
ASSM은 각 데이터 블록내의 사용량 관리를 위해 FREESISTS 를 사용하는 대신 비트맵 FREELIST를 사용함으로써 세그먼트내의 영역관리를 투명하게 만들어 준다. 또 가변적인 크기를 가진 행을 포함한 세그먼트의 데이터 블록 사용 효율을 높이는 등의 개선이 있었다. ASSM을 사용하는 테이블스페이를 만들기 위해서는 CREATE TABLESPACE 문에 SEGMENT SPACE MANAGEMENT AUTO 절을 이용하면 된다.
5.5.2 Data Segment
USER가 INSERT 문으로 입력하는 데이터를 저장하는 공간으로 테이블에 해당한다. 실질적인 데이터가 영구적으로 저장되는 공간으로 입력, 수정, 삭제, 조회 작업이 빈번하게 이루어진다. 테이블에 관련된 extent가 자주 발생하지 않도록 하는 것이 성능향상에 주안점이다. 또한 I/O의 효율을 높이기 위해서 row migration이나 row chain의 발생이 적어지도록 조회위주의 테이블인지 빈번하게 트랜젝션이 일어나는 테이블인지를 고려하여 Storage 옵션을 지정해야 한다. extent가 자주 발생되지 않도록 하기 위해서는 initial과 next storage 파라미터를 적절히 지정해야 한다.
SQL>select owner, segment_name, initial_extent, next_extent,
max_extents, pct_increase, entents
from dba_segment
where owner not in ('SYS', 'SYSTEM') and segment_type = 'TABLE';
예를 들어 조회 결과 extents가 3이고, initial_extent 10240b, next_extent 10240b, pct_increase 50 이라고 가정했을 때 현재 이 세그먼트(테이블) 점유하고 있는 공간의 크기는 다음과 같다.
table data = 10240 +10240 * 1.5 +10240 * 1.5* 1.5
pct_increase 값이 0이 아닌 경우 계산이 복잡한걸 알 수 있다. 똑 extents 값이 크다는 것은 빈번하게 segment가 확장을 한다는 의미가 되므로 Storage값을 크게해서 확장주기를 늘려주거나 연속적인 데이터 배열을 위해서 테이블의 Export/Import를 고려해 볼 필요도 있다. 한 row의 길이가 평균 5Kbyte 이고 하루에 200건 정도의 데이터가 입력되는 테이블이 있고 2개월에 한번 extent가 발생하도록 하면 한달을 20일 정도로 가정하면 table의 storage 파라미터 값중 initial, next 값을 4Mbyte (5Kbyte * 200건 * 40일)로 주고 pctincrease 값을 0으로 주면된다. 또 Insert나 Update가 자주 발생하는 경우 pctfree 값을 20 정도로 하며 varchar2 Type의 칼럼이 많은 경우 pctfree를 조금 더 크게 하는 것이 좋다.
5.5.2 Index Segment
책에서 필요한 부분을 빨리 찾는 방법은 목차나 색인을 페이지를 보고 해당하는 페이지를 펼치는 것이다. 책에서 색인에 해당하는 데이터베이스 객체가 Index Object이다. 검색 성능을 높이기 위한 용도로 각 Row의 Rowid를 저장하고 있다. 이렇게 인덱스를 저장하고 있는 공간을 Index Segment라고 한다. 대부분 Data Segment와 유사하지만 row data의 delete가 이루어져도 해당하는 영역은 빈 공간으로 남게 된다. 따라서 입력과 수정이 많은 테이블에 너무 많은 인덱스를 작성하면 여러 가지 문제가 발생하게 되고 정기적으로 Drop과 Create를 해줄 필요가 있다.
∘ 빈번한 확장이 이루어지는 객체 조회 (extents 확인)
SQL>select a.owner||'.'||a.segment_name "objname",
decode(a.segment_type, 'TABLE', 'TABLE', 'INDEX', 'INDEX On ' || b.table_name) "basetable",
a.extents, a.tablespace_name, c.file_name
from dba_segments a, dba_indexes b, dba_data_files c
where a.tablespace_name = c.tablespace_name
and a.segment_name in (b.index_name, b.table_name)
and a.extents > 0 and a.owner = 'SCOTT'
order by a.segment_name;
∘ delete로 인한 인덱스 세그먼트의 빈공간 확인 (인덱스 분석 후)
SQL>select name, lf_rows, del_lf_rows,
(del_lf_rows/lf_rows)*100 "Delete Space %"
from index_stats
where name = 'EMP_IDX';
5.5.3 Rollback Segment (Undo Segment)
Commit되지 않은 트랜젝션의 Rollback 데이터를 저장하고 있는 공간이다. 변경된 데이타에 대응되는 Filename and Block ID, 트랜잭션이 작동전에 존재하고 있었던 데이터가 저장된다. 롤백 엔트리를 동일 트랜잭션과 연결하여서, 만약 트랜잭션 복구가 필요하면 쉽게 찾는다. 어느 유저가 생성하였는지 상관하지 않고, SYS유저의 소유가 된다. 유저가 트랜젝션을 Commit 해서 롤백데이타가 지워지고 더 이상 공간이 필요치 않을 경우 확장된 공간이 축소된다. 롤백할 데이터의 읽기 일관성 (Read Consistency)을 위해 여러 유저가 공유하게 된며 비정상적인 인스턴스의 종료 후 복구 시 불완전한 트랜잭션의 롤백을 위해서 사용되기도 한다. Oracle 9i 이후버전 부터는 Rollback Segement라는 용어 대신 Undo Segment라는 용어를 사용한다. Undo 세그먼트는 관리 방식에 있어서 9i 이후 버전에서 자동 관리 모드와 수동 관리 모드를 선택 할 수 있는 기능이 추가 되었고, 트랜잭션 처리를 위한 알고리즘이 개선되었다. Undo 세그먼트는 생성, 할당 및 튜닝을 오라클 서버가 관리하므로 DBA는 더 이상 몇 개의 Rollback 세그먼트를 생성 할 것인지, 크기는 어떻게 할 것인지, 트랜잭션에 따라 어떻게 할당할 것인지를 결정하지 않아도 된다.
오라클 버전이 8i 이전 이거나 segment관리가 수동인 경우 대용량 트랜젝션을 위한 전용RBS를 추가로 작성해야 하는데 작성해 놓기만 하면 오라클이 알아서 사용한다. RBS는 여러 유저가 공유하므로 유저들끼리 충돌하지 않도록 여러개를 작성 하는것이 좋다. (RBS권장수 = 동시접속 유저 수 / 4)
∘ RBS확인
SQL>Select segment_name, segment_type, extents, tablespace_name
From dba_segments
Where segment_type = 'ROLLBACK';
∘ RBS활용 예
- 자료집계 등 장시간 대량의 데이터를 입력하는 작업 중 오류발생
ORA-01555: 너무 이전 스냅샷:롤백 세그먼트 12 수에 "RBS" 이름으로 된 것이 너무 작습니다.
- 임시 테이블은 NOLOGGING 모드로 생성한다.
- 롤백세그먼트를 생성해주고
CREATE PUBLIC ROLLBACK SEGMENT "BIGRBS" TABLESPACE "RBS"
STORAGE ( INITIAL 20480K NEXT 20480K);
- 온라인 상태로 만들어 준다.
ALTER ROLLBACK SEGMENT "BIGRBS" ONLINE;
- 현재 세션에서 해당 RBS를 사용하도록 지정
set transaction use rollback segment bigrbs;
- 대량의 데이터 입출력
- 파라미터 파일의 rollback_segment 파라미터에 추가
5.5.4 Temporary Segment
일반유저가 SQL문을 수행할 때 오라클은 Sort나 집계 비교 등 데이터 처리를 위한 중간 작업 공간을 사용한다. 이 롤백세그먼트와 같이 작업이 완료되면 크기가 축소되는 특성상 조각화가 많이 발생된다. Temporary Segment는 유저별로 세팅 할 수 있으며 기본값이 지정되지 않은 경우 system 테이블스페이스를 사용하게 된다. 예를 들어 SCOTT 유저의 Temporary영역을 확인하거나 지정하려면 다음처럼 하면 된다.
SQL>select username, temporary_tablespace from dba_users
where username = 'SCOTT';
SQL>alter user scott temporary tablespace temp;
5.5.5 자동 세그먼트 공간 관리 (Automatic Segment Space Management)
데이터베이스 공간 관리는 DBA의 중요한 역할 가운데 하나이며, 데이터베이스가 중단되지 않고
서비스를 제공 할 수 있도록 공간 사용에 대한 계획 수립과 관찰에 많은 시간을 할애하게 된다.
Oracle 9i부터 도입된 자동 공간 관리 기능은 테이블이나 인덱스가 차지하는 여유공간(free space)에 대한 관리를 단순하게 하는 기능으로 저장 공간 활용율을 높이고 성능개선과 안정성에 도움을 준다. Oracle 9i 전 버전에서는 FREELISTS라고 불리는 데이터 구조체를 통해 객체가 점유하고 있는 공간 내에서 새로운 row에 대한 insert가 가능한 공간을 관리 해 왔다. DBA는 FREELIST 와 FREELIST GROUP의 개수를 객체 생성시 지정 할 수 있었다. 이때 PCTUSED 값은 FREELIST에 특정 블럭을 속하게 하거나 속하지 않게 하는 기준 역할을 수행했다. 한편 새로운 자동 세그먼트 관리 기능에서는 객체 내의 공간 관리를 명시적으로 지정하지 않고도 효과적으로 활용될 수 있는 기능을 제공하고 있으며 객체에 할당된 블록들의 공간 활용 정도를 bitmap을 사용하여 관리하게 하고 있다. bitmap의 상태는 주어진 블록에 얼마나 많은 공간이 가용한지를 나타낸다. (예: 75% 이상, 50% - 70%, 25%-50%, 25% 미만) 또한 블록이 초기화 되어 있는지 여부도 나타내 준다. 이 기능은 FREELISTS, FREELIST GROUP, PRCUSED 같은 저장 파라미터들을 수작업으로 조정할 필요성을 없애면서 DBA의 작업을 줄여주었다. 동시에 데이터베이스 입장에서는 특정 블럭이 얼마나 사용되고 있는지 여부를 좀더 정확히 파악 할 수 있게 됨으로써 공간 활용성을 높일 수 있게 되었다. 특히 매 row의 크기가 매우 다양한 경우 많은 효과를 얻을 수 있다. 또한 이 기능은 DML 처리의 성능 개선에도 도움을 주게 되는데 이것은 여유 공간에 대한 정보를 lookup 하기 위한 대기 시간을 bitmap을 사용함으로써 현격하게 감소시킬 수
있기 때문이다.
5.6 BigFile Tablespace
데이터베이스의 추세가 점점 더 대용량화되어 가면서 VLDB(Very Liarg DataBase)에 대한 요구들도 증가하고 있다. 오라클 10g에서는 이러한 VLDB의 요구에 맞추어 대용량 파일을 지원하는 테이블스페이스가 소개되었다. 주요 특징으로 최대 파일 크기는 4TB ~ 128Tb까지 지원한다. 하나의 datafile 만 가질 수 있다는 점을 제외하고는 기존의 datafile operation과 동일하다.
5.7 Storage Parameter
Storage Parameter는 데이터가 저장되는 객체인 Table과 Index의 최적화를 위해 사용되어진다. 테이블을 작성할 때 추가적인 옵션 지정 없이 기본 값들을 활용 할 수 있으며, 테이블스페이스에 할당된 값을 상속 할 수도 있다. 오라클이 업그레이드 되면서 자체적으로 관리되는 영역도 많아지고 있다. 자동세그먼트 관리 모드인 경우 PCTUSED, FREELIST, FREELIST GROUP, NEXT_EXTENTS 같은 값들은 무시된다. 데이터가 많아지고 유저수도 늘어나면서 시스템의 속도는 느려 지는데 한정된 CPU나 메모리를 여러 유저가 나누어서 사용하기 때문이다. 특히 I/O에 소요되는 오버헤드가 많다. Storage Parameter는 데이터를 디스크에 연속적으로 저장시키는 내용과 밀접한 관련이 있으므로 테이블이나 인덱스를 작성할 때 데이터의 특성에 맞게 지정해 준다면 보다 효율적이겠다. storage 파라미터 값을 각 개별 오브젝트에 지정하거나 디폴트값으로 테이블스페이스에 지정한다.
INITIAL : 테이블이나 인덱스가 작성될 때 최초로 할당되는 크기이다. 다르게 말하면 Segment 생성에 처음 할당되는 extent 크기로 디폴트는 5개의 데이터 블록이다.
NEXT : 데이터량이 늘어나서 세그먼트에 공간이 더 필요하게 될 때 확장되는 크기를 말한다.
PCTINCREASE : NEXT만큼 확장할 때 NEXT 값에 추가로 확장될 비율을 뜻한다. 정확하게는 NEXT * (1 - PCTINCREASE/100) 크기만큼 씩 확장된다. 롤백 세그먼트는 0으로 고정되어 있으며 기본 값은 50이지만 0으로 세팅하기를 권장한다.
MINEXTENTS : 객체가 작성될 때 초기에 확장되는 개수를 세팅함
MAXEXTENTS : Segment 에 할당될 수 있는 전체 Extent 의 수. 디폴트 99개.
OPTIMAL : 롤백세그먼트에만 적용. 디폴트는 NULL.
FREELISTS : 테이블에 데이터가 입력될 때 메모리 상에서 빈 블록을 필요로 한다. 이 속성은 메모리 상에 빈 블록을 미리 확보해 놓는 수이다. 다음은 FreeList를 확인하는 방법이다.
SQL>select class, count from v$sysstat where class = 'free List‘;
∘ Storage Parameter 확인
DBA_TABLESPACES, DBA_DATA_FILES, DBA_SEGMENTS,
DBA_EXTENTS, DBA_FREE_SPACE
SQL>SELECT segment_name, tablespace_name, extents, blocks
FROM dba_segments WHERE OWNER='SCOTT';
SQL>desc dba_tablespaces;
-->8i (8.1.7) 버전에서 조회되는 칼럼들
TABLESPACE_NAME, INITIAL_EXTENT, NEXT_EXTENT, MIN_EXTENTS,
MAX_EXTENTS, PCT_INCREASE, MIN_EXTLEN, STATUS, CONTENTS,
LOGGING, EXTENT_MANAGEMENT, ALLOCATION_TYPE, PLUGGED_IN
-->9i 버전에서 추가된 칼럼들
ALLOCATION_TYPE, PLUGGED_IN, SEGMENT_SPACE_MANAGEMENT
-->10g 버전에서 추가된 칼럼들
DEF_TAB_COMPRESSION, RETENTION, BIGFILE
-->11g 버전에서 추가된 칼럼들
PREDICATE_EVALUATION, ENCRYPTED, COMPRESS_FOR


PREV