vi 편집기 단축키


출처 : https://kldp.org/node/102947


http://www.viemu.com 제공의 내용을 번역한 것

데이터베이스 객체의 종류

●  데이터베이스 객체의 종류


 데이터베이스 객체

 설명

 TABLE

 데이터를 담고 있는 객체 

 VIEW

 하나 이상의 테이블을 연결해서 마치 테이블인 것처럼 사용하는 객체 

 INDEX

 테이블에 있는 데이터를 빠르게 찾기 위한 객체 

 SYNONYM

 데이터베이스 객체에 대한 별칭을 부여한 객체 

 SEQUENCE

 일련번호 채번을 할 때 사용하는 객체

 FUNCTION

 특정 연산을 하고 값을 반환하는 객체

 PROCEDURE

 함수와 비슷하지만 값을 반환하지는 않는 객체 

 PACKAGE

 용도에 맞게 함수나 프로시저를 하나로 묶어놓은 객체



●  TABLE


- 데이터를 넣고 수정하고 삭제하는, 데이터를 담고 있는 가장 기본적인 객체. ROW (행)과 COLUMN (열)으로 구성된 2차원 형태(표)의 객체로 우리가 자주쓰는 엑셀과 비슷한 구조라고 보면 이해가 쉽습니다.


- TABLE 생성은 CREATE문으로 생성할 수 있는데, 기본 구문은 아래와 같습니다.


CREATE TABLE [스키마.]테이블명 (

컬럼1    컬럼1_데이터타입    [NULL, NOT NULL],

컬럼2    컬럼2_데이터타입    [NULL, NOT NULL],

...

) [TABLESPACE 테이블스페이스명];


스키마명은 생략이 가능하며, 생략하게되면 현재 자신이 로그인한 스키마 이름으로 생성됩니다.

TABLESPACE 구문도 생략이 가능한데, 해당 사용자의 디폴트 TABLESPACE에 생성됩니다.

'ORACLE > Oracle DBMS' 카테고리의 다른 글

DBMS 기본 데이터 타입  (0) 2018.11.02
데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10

Table 또는 인덱스의 사이즈를 확인 하는 쿼리

개별 단위로 테이블 사이즈가 알고 싶을때 조회 하는 쿼리


select owner,segment_name,segment_type,sum(bytes)/1024/1024 as MB

from dba_segments

where OWNER='APP_USER'

GROUP BY owner,segment_name,segment_type;

'ORACLE > Admin' 카테고리의 다른 글

Table 또는 인덱스의 사이즈를 확인 하는 쿼리  (0) 2018.11.01
ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18
Listener password  (0) 2018.10.14
Oracle 8i Startup, shutdown  (0) 2018.04.09
ASM  (0) 2018.03.12

CURSOR_SHARING

CURSOR_SHARING


어플리케이션이 리터럴SQL을 사용해서 만들어졌거나 패키지 어플리케이션이 바인드 변수를 사용하지 않는 경우, 이런 상황에서 성은이 나빠진다면 CURSOR_SHARING 파라미터를 이용해서 어플리케이션을 크게 변경하지 않고 튜닝하는 것이 가능합니다.


CURSOR_SHARING 파라미터는 EXACT, FORCE, SIMILAR 라는 값을 가지고 있고, FORCE 또는 SIMILAR로 설정한 경우, 사용자가 리터럴 SQL을 수행하여도 오라클이 리터럴값을 바인드 변수로 치환합니다.


실제 수행구문

SQL> select count(col1) from test where col2 = 10;


오라클이 Parse 한 SQL문

SQL> select count(col1) from test where col2 = :"SYS_B_0" ;


● FORCE 

 - 리터럴 값에 상관없이 한 개의 공유 커서를 공유합니다. 바인드 피크와 같이 특이한 값에 최적화될 위험이 있습니다.

 - Shared Pool 사용량을 줄이는 효과 및 경합을 줄이는 효과가 큽니다.


● SIMILAR

 - 실행 계획이 확실히 같을 때에만 한 개의 공유 커서를 공유합니다. 최적의 실행 계획이 같지 않을 가능성이 있는 경우에는 동일 문장에 여러 개의 공유 커서를 만듭니다.

 - 옵티마이저 통계를 수집한 경우 범위 조건을 지정하거나, 히스토그램을 수집했을때의 '=' 조건 등은 리터럴값에 따라 최적인 실행 계획이 달라질수 있으므로 다른 리터럴 값마다 자식 커서를 생성합니다.

 - 옵티마이저 통계가 없고 다이나믹 샘플링도 꺼져있다면, 내부 기본값에 의해 실행 계획이 결정되므로 같은 공유 커서를 사용합니다. 컬럼 통계가 최소값과 최대값만 있을 경우 (히스토그램 없음), '=' 조건은 선택도가 항상 1/NDV가 되기 때문에 같은 공유 커서를 사용합니다.


'CURSOR_SHARING=SIMILAR'일 때는 경우에 따라 Shared Pool 사용량을 줄이는 효과가 거의 없으며 경합도 줄이지 못하는 경우가 있습니다. SIMILAR를 사용할 때는 테스트를 하고 V$SQLAREA.VERSION_COUNT를 조사하여 값이 적은지에 대한 여부 (커서의 공유되고 있는지)를 확인해야 합니다.


SQL> select sql_text, version_count from v$sqlarea

   2  where sql_text like 'select /* TEST%';


SQL_TEST                                                VERSION_COUNT

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

select count(col1) from test where col2 = :"SYS_B_0" ;              5  


VERSION_COUNT = 5 는  같은 SQL문의 자식 커서가 5개 있다는 뜻

'ORACLE > Tunning' 카테고리의 다른 글

CURSOR_SHARING  (0) 2018.10.31
CBO 와 바인드 변수, 바인드 피크  (0) 2018.05.17
Hint 정리  (0) 2017.12.18
CBO와 히스토그램 정리  (0) 2017.12.07
옵티마이저 기본기능  (0) 2017.11.14

IBM의 RedHat 인수를 보고

IT 기업의 생태계가 빠르게 변화하고 있다고 느낍니다.


HP-UX는 HP가 서버 시장은 손에서 내려놓은듯한 움직임을 보이고 있었죠. HP는 주력이었던 OA시장과 3D프린트 분야로 치고 나가고 있기 때문에, 서버 시장에서의 영향력은 많이 줄어든게 사실입니다.

 

IBM의 AIX는 이미 유닉스 시장의 90% 이상 차지한 OS이고 유닉스 시장에서 독보적인 위치를 차지 하게 되었죠.

그럼에도 IBM은 AIX의 판매량이 계속 감소하고 있었고, 그렇다고 DB2가 잘나가는것도 아니고, 이래전래 타개책을 생각했던것 같습니다. IBM에 부족한것은 하드웨어가 아닌 소프트웨어 였고, 이제는 대세가 되어 버린 리눅스를 기본 탑재나 다양한 방법 활용으로 활로를 찾는것 같습니다.

리눅스를 이용한 클라우드 서버 개발이라던가... IBM X86 서버에 기본으로 레드햇을 탑재 해서 팔거나, 아니면 레드햇을 커스텀 해주는 서비스 등을 생각 해볼수 있을것 같습니다.


애초에 방향성을 다르게 시작한 두 기업이기에


- HP는 전문인 OA에 주력, PC 및 서버 사업은 감소


- 컴퓨터 전문 기업인 IBM은 하드웨어와 서버에 여전히 주력


이런 느낌인것 같습니다.


기존에도 기업에서는 비용이 많이 드는 전산제품에 단가를 낮추기 위해 중요하지 않은 서버들을 리눅스로 대체 하는 경우가 많았습니다. 오픈소스인 리눅스가 빠르게 발전하고, 안정성이 유닉스만큼 좋아졌고, 쉽게 구하거나 설치가 용이해서 지금은 중급 장비에도 많이 선택하고 있습니다.


기업 입장에서는 무엇보다 유지보수의 여부가 생명이기 때문에, 하청주고 책임 떠넘기기를 하기 위해서는 공식 기술지원팀이 있는 레드햇이 가장 좋은 선택일수 있었다고 봅니다.

장애나면 어떻게 책임 질거야? 라는 질문에 CentOS나 기타 다른 리눅스는 답이 없는 상황이라...

국내에 리눅스를 혼자 커널 커스텀하고, 용도에 맞게 변형 시킬수 있고, 장애가 나왔을때 근본부터 찾을수 있는 리눅스 엔지니어는 거의 없다고 봐도 무방하기 때문에 유지보수 측면에서 약점이 있는 제품이었고, 레드햇과 오라클 리눅스만이 기술지원팀을 운영하며, 연간 라이센스 비용을 받고 있었죠.


IBM이 물론 겉으로 보기에는 리눅스 시장의 적극적인 진출을 위해 레드햇을 인수 한걸로 볼수도 있지만,

서버 시장이 갈수록 소비자나 기업이 서버를 구매하지 않게 되고, 모든 전산 시스템이 클라우드 시스템으로 넘어가게 되면, 서버 시장 구조 자체가 완전히 바뀔것이기 때문에 IBM 입장에서도 미래에 대비하는것 일수도 있겠습니다.

리눅스 기반의 클라우스 서비스를 개발이 목적일 수도 있구요.


오라클도 DB를 개별적으로 운영하는 단계에서 클라우드로 넘기고 있습니다. 블록체인을 활용하고 어쩌고 하면서 다들 다음 단계로 나아가고 있습니다.


IT시장은 변화가 빠른 만큼 미래를 잘 대비해야 한다고 생각합니다.

'잡담' 카테고리의 다른 글

IBM의 RedHat 인수를 보고  (0) 2018.10.29

티스토리 툴바