태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
   情  
Front Page
Tag | Location | Media | Guestbook | Admin   
 
'Database'에 해당하는 글(5)
2009.12.07   [DB] DataBase의 모든 Table와 Column을 조회하는 쿼리
2009.04.27   [DB] DB Binary Type vs File Storage
2007.12.15   오라클의 주요 구성요소 (1)
2007.12.15   오라클 데이터베이스와 Instance
2007.12.15   오라클에서 SQL명령이 내부적으로 작동하는 과정 (2)


[DB] DataBase의 모든 Table와 Column을 조회하는 쿼리

선택된 DataBase의 모든 Table와 Column을 처리하는 쿼리입니다.

SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
ORDER BY TABLE_NAME, ORDINAL_POSITION 

NFORMATION_SCHEMA>COLUMNS를 이용하여 시스템 Table의 정보를 손쉽게 조회할 수 있습니다.

결과

image

신고
Tag : MS SQL Server

name    password    homepage
 hidden


[DB] DB Binary Type vs File Storage

DB의 데이터 타입 중에 Binary 형태가 있습니다. 이는 이미지나 파일, 비디오 등의 이진 데이터를 저장할 수 있는 공간을 제공하는데요. 하지만 보통의 경우 이진파일의 경우 파일 서버를 따로 두는 경우가 많습니다. 과연 어느 경우에 DB의 Binary 데이터 형으로 저장해야하고, 어떤 경우에 별도의 저장공간에 데이터를 저장해야할까요?

만약 이진 파일을 어떻게 저장할지 고민된다면, 아래에 제시된 여건을 체크해보세요.

  1. Binary 파일이 읽히는 속도가 중요하다면, DB에 Binary형태로 저장하는 것은 권장되지 않습니다. 예를 들어 Video Streaming Service를 위해 데이터를 저장하는 것이라면, DB에 저장하는 것보다 Streaming에 전념할 수 있는 서버를 따로 두는 것이 옳습니다. DBMS는 애초에 수많은 데이터 Access요청을 빠르게 처리하는 것이 주 임무이기 때문에 Binary 데이터를 전송하는데 온힘을 기울이지 않습니다.
  2. 파일의 크기가 1MB이상의 사이즈라면, File Server를 두는 것이 보다 효율적입니다. 파일의 크기가 커진다는 것은, 파일의 전송이 시작되면 파일전송이 끝마칠 때 까지 DBMS의 자원을 소모한다는 의미입니다. DBMS의 자원은 수많은 데이터 중에서 필요한 데이터를 매우 빠르게 검색하는데 소모되는 것이 바람직하지, 단순한 파일의 연속적인 로드에 DBMS의 자원을 소모하는 것은 옳지 못합니다. 한가지 더, DB의 크기가 커질 수 록 DB가 검색해야할 데이터 크기가 커지므로 대부분의 경우 검색 속도가 저하됩니다.
  3. 보안이 필요한 데이터라면 파일을 DB에 저장하여 DBMS가 제공하는 높은 보안 수준을 적용받을 수 있습니다. 만약, DB에 저장하지 않고 별도의 저장공간(File Storage)에 저장하는 것이라면 별도의 보안 프로세스를 적용해야할 것입니다.
  4. DB에 Binary형으로 저장한다면, DB에 접근하는 방법(ODBC, OleDB 등) 또한 중요합니다. 대형 Video Streaming Service에 ODBC를 사용한다면, Time Out Fail가 발생할 것입니다.
  5. 만약 해당 Binary 데이터의 크기가 크고, 자주 변경된다면 DB에 저장하는 것보다, File Server에 두는 것이 훨신 효과적입니다. 거대한 데이터가 자주 변경된다는 것은 단편화가 많이 발생하게 되는데, DB의 것보다 일반 OS의 단편화 관리가 보다 쉽고 효율적이기 때문입니다.
  6. 트랜젝션이 필요한 경우라면, SQL의 Transaction을 사용하는 것이 손쉬운 방법입니다.

자세한 사항은 다음의 링크를 참조하여, 문서를 읽어보세요.

[To Blob or Not to Blob]

신고
Tag : DB

name    password    homepage
 hidden


오라클의 주요 구성요소

 


** 오라클 데이터베이스의 주요 구성 요소 **

사용자 삽입 이미지

1. Oracle Server : 오라클 서버는, SQL문 처리 및, DB복구, 성능 향상, 유지 관리 등 다양한 역할을 한다. 크게 Oracle Instance와 Oracle Database로 구성된다

2. Oracle Instance : Instance는 SGA(System Global Area : 오라클을 이루는 메모리 구조 중 하나)와 Background Process(보이지 않게 뒤에서 오라클을 유지하는데 도움을 주거나, 성능 및 신뢰도 향상에 기여하는 프로세스)로 구성된다. (Instance = SGA + Background Process)
 
(Instance는 오라클 DB를 액세스하는 수단으로서 한번에 하나씩 DB를 열어 사용한다고 한다.)

3. Oracle DataBase : 쉽게 말해 하드디스크 상에 존재하는 데이터베이스 정보와, 이를 유지하는데 필요한 파일(복구 파일, 환경 파일, 인증 관련 파일)을 말한다.

4. 기타 키 파일 : Parameter + Password file + Archived log files

5. 사용자 프로세스 : SQL Plus나 제작된 기타 응용 프로그램 등을 말한다. SQL쿼리를 입력받고, 그 결과를 사용자에게 보여주는 역할을 한다.

6. 서버 프로세스 : 사용자 프로세스와 Oracle Server사이에서 존재하며 사용자 프로세스의 요구를 받으면, Instance와 통신하며 사용자 대신 SQL문을 실행하고, 결과를 사용자에게 반환한다. 서버프로세스는 사용자프로세스 수만큼 생성되거나, 또는 공유될 수 있다. 서버 프로세스는 Oracle Server에서 생성된다.

7. 기타 프로세스 : 언젠가 알게 될 기타 프로세스 들..


Oracle Server에 접속하는 세가지 방법

1. Oracle Instance가 존재하는 System에서 DB 액세스 프로그램(또는 기타 응용 프로그램)을 이용하는 방법(프로세스간 통신을 사용한다)

2. Server-Clinet 환경에서의 접속 : 서버에 Oracle이 작동 중일 때 클라이언트에서 사용자프로세스를 이용하여 접속하는 방법

3. 3Tier System에서의 접속(Client-Server-DB) : Server-Client 사이에 하나의 단계가 추가된 상태
   - Client에서 브라우져나, 기타 사용자프로세스를 이용하여 Data 요구

   - Server(보통 Web Server)에서 사용자 요구를 받아 해석하며, DB접속이 필요할시 DB Server에 접속

      하여 데이터를 요청하고 결과를 생성한뒤 Client에 결과를 반환한다.

   - DB Server : DB를 실제 운용 관리하는 서버


세션이란 : 두 호스트간에 Data를 교환키 위한 논리적 연결
   - 사용자가 Oracle Server에 접속하는 때부터 종료할때까지 유지 된다.

   - 세션을 시작하기 위해서는 Oracle 서버에 접속할 수 있는 환경에 있어야한다.


전용 서버 : 사용자 프로세스와 서버프로세스 간에 일대일 대응하는 접속

공유 서버 : 여러 사용자 프로세스가 서버프로세스를 공유하는 접속


by thankee from tistory.com

신고
Tag : 오라클, 오라클 구조
Commented by Favicon of http://shakrock.tistory.com BlogIcon 대지곰탱 at 2008.07.08 09:07 신고  r x
IT 업계에서 일하시나봐요? ㅎㅎ 저도 IT 에 종사하고 있습니다.

이런 반가울때가~ ㅎㅎ
날씨가 덥네요~ 건강조심하시고요~ 담에 또 뵈요~ ㅎㅎ

name    password    homepage
 hidden


오라클 데이터베이스와 Instance

오라클 데이터 베이스


사용자 삽입 이미지

 

1. 데이터 파일 : 실제 데이터가 포함되어 있다.

2. 리두 로그 파일 : 데이터를 복구할 수 있도록 DB변경 사항이 기록되어 있다. SGA의 Redo log buffer의 내용이 LGWR(백그라운드 프로세스 중 하나)에 의해 기록된다.

3. 제어 파일(Control files) : 뮤결성 유지 관리 확인에 필요한 정보

 

위 세가지를 오라클 데이터베이스라(물리적구조라고도 함)고 한다.

다음 세가지는 기타 키파일을 말한다.

 

1. 매개편수 파일(Parameter file) :  Oracle Instance의 특성 정의에 관한 정보(예 각종 매개변수)

2. 암호 파일(Password file) : 사용자 인증을 위한 정보

3. 아카이브된 로그 파일(Archived log files) : 리두 로그 파일의 오프라인 복사본으로서 리두 로그 파일이 담겨진 디스크에 문제가 생겨도 복구할 수 있도록 하기 위해 존재한다.

 

 

오라클 메모리 구조

사용자 삽입 이미지

오라클의 메모리 구조는 크게 SGA와 PGA로 구분된다.
(메모리를 말하는것이지 프로세스를 말하는것이 아니다. 대개 SGA는 하나 PGA는 여럿이며 여러 PGA가 SGA를 공유한다.)


1. SGA(System Global Area) : 인스턴스 시작시 생성된다.

  - SGA_MAX_SIZE에 의해 최대 크기가 조정되며, 크기는 동적이다(커지거나 작아지거나 한다).

  - SGA는 인스턴스를 종료하지 않고 구성을 변경할 수 있다(9i이후 부터)

  - 할당단위는 그래뉼이다. (그래뉼 : 연속적인 가상 메모리 할당 단위. 예상 SGA가 128MB이하이면
     4MB, 크면 16MB)

  - SGA구성요소는 그래뉼 단위로 커지거나작아진다.
  - SGA구성 최소 단위는 세개의 그래뉼이다. (Database Buffer cache, Shared cache, 그외 고정SGA)

  - 공유 풀(Shared Pool) : - Library cache + Data dict cache로 구성.

      > Library cache : 최근에 사용한 SQL문, PL/SQL문에 대한 정보가 저장된다.
         *LRU(Least Recently Used)알고리즘으로 관리

         *SQL(또는 PL/SQL), parse tree, QEP(Quary Execution Plan : 실행 계획)의 형태로 저장됨.

         *SQL : 실제 SQL문장이 저장되어 사용자 프로세스에서 요구된 SQL문과 비교한다.(대소문자,
                  띄어쓰기 구분하며 비교한다) SQL문이 똑같은 경우 parse-tree와 QEP실행이 실행된다.

         *QEP : 실행 계획으로서 해당 데이터를 찾아가는 최적의 방법.

         *Parse-tree : 해당 SQL문의 실행의 주체(C language에서 컴파일후 생성되는 목적모듈이라고
                        생각하면 된다. 즉 parsing(분석)후 생성된 것이 parse-tree로서 실행이 주체가 된다.)

         *SQL문이 넘어오면 가장 먼져 Library cache에서 전에 실행된적이 있는지 확인한다. 만약

          이전에 실행된 것으로 확인되면, 해당 parsing과정을 건너뛰고 이미 존재하는 해당 parse-tree

          와 QEP를 실행한다. 즉 Library cache는 Parsing과정을 생략할 수 있도록함으로서 속도향상에

          기여한다.

      > Data Dictionary Cache : 가장 최근의 데이터 정의 모음 및 각종 통계 정보가 저장된다.
          * 테이블, 인덱스, 열, 사용자, 권한, DB파일, 기타 통계정보 포함

          * 자주 참조되는 정보를 메모리상에 존재하게 함으로서 물리적 IO를 최소화 함으로서

             속도 향상에 기여한다.
          * 구문분석단계(Parsing) 동안에 이곳에서 각종 정보를 찾아, 권한 확인, 해당 정보 확인

            따위의 작업을 한다.(계정 확인, 데이터 파일이름, 세그먼트이름, 테이블 설명, 권한,...)

      > SHARED_POOL_SIZE 매개변수로 크기 조정(Library cache와 Data dictionary cache의 세부

          크기조정은 오라클이 알아서 한다. SHARED_POOL_SIZE의 크기가 작으면 오버해드가

          늘어난다. 크기가 크면 속도가 향상된다.) SGA_MAX_SIZE를 초과하게 설정할수 없다.

      > Shared Pool은 여러 프로세스들이 공유한다. 또한 인스턴스마다 개별로 존재하지 않는다.

  - 데이터베이스 버퍼 캐시(Database Buffer Cache) : 데이터 파일에서 읽어들인 복사본 저장

      > DB_BLOCK_SIZE에 지정된 블록크기 단위로 데이터가 전송된다.
        (기본 8k, 2의 1승부터 6승인 64k 중 하나 선택 가능)

      > System data(Dictionary table), User data(일반 table), Undo block(롤백용 블록)로 구성

      > 하드디스크에 직접 조회하지 않고 메모리에 두고 사용함으로서 속도 향상(물리적 IO감소)

      > LRU알고리즘을 통해 관리
      > 모든 DB작업은 이곳에서 이뤄지며, 이곳에 없는 데이터는 하드디스크에서 이곳으로 읽어온다)

      > 데이터베이스 버퍼 캐시는 크기가 동적이다.

      > 세가지 서브 캐시로 나눌수 있다.

         * DB_CACHE_SIZE 크기의 Default Buffer Cache. 항상 존재하며 0이 될수 없다.

         * DB_KEEP_CACHE_SIZE 크기의 Keep Buffer Cache. 재사용될 메모리 블록이 저장되는 곳.

         * DB_RECYCLE_CACHE_SIZE 크기의 Recycle Buffer Cache. 거의 재사용되지 않는 메모리 블록.

         * 서브 캐시들의 크기 역시 DB_BLOCK_SIZE에서 정해진 크기로 관리된다.

         * 재사용될 정보의 메모리 구역과 그렇지 않은 메모리구역을 나누어 둠으로서 LRU알고리즘에

           의해 공간확보시 재사용될 메모리 구역의 데이터가 삭제되는것을 막는다.

  - Redo Log Buffer : 복구 목적으로 데이터베이스 블록의 모든 변경사항이 기록되는 메모리 공간

      > 기록된 사항은 리두 항목이라고 하며, 변경사항을 재구성, 재실행 할 정보가 포함된다.
      > LOG_BUFFER로 크기가 정해진다.

      > LGWR 백그라운드 프로세스에 의해 리두 로그 파일에 기록된다.

      > 약 1MB의 작은 크기를 가지고 있다

      > 버퍼가 가득 차버리는 것을 막기 위해 지속적으로 Redo Buffer의 내용을 Redo Log File에

         기록하는데 하드디스크와 메모리의 속도차를 가만해 Redo Log Buffer을 3등분하고,

         각 등분이 가득 찰때마다 그 등분의 내용을 하드디스크의 Redo Log File에 기록하게 된다.

         (순환형 버퍼라고 칭하기도 하는데 그 이유는 지속적으로 1,2,3,1,2,3,1,2,3순서로 순환하며

         덮어 쓰기 때문이다.)

                      

사용자 삽입 이미지

2.PGA(Program Global Area) : 서버 프로세스 시작시 생성(서버프로세스에 할당되는 메모리 공간)

  - Cursor : SQL문으로 조회한 데이터 결과값은 작을수도 있고 엄청나게 클수도 있다. 이렇게 크기를

                예측할 수 없는 결과값을 한번에 사용자 프로세스에게 넘겨주지 않고 커서를 이용하여,

                커서가 가리키는 데이터를 사용자 프로세스가 준비되었을때 한줄 씩 반환한다.




by thankee from tistory.com

신고
Tag : Database, Instance, Session, 오라클, 오라클 구조

name    password    homepage
 hidden


오라클에서 SQL명령이 내부적으로 작동하는 과정

SQL문이 내부적으로 처리되는 과정

사용자 삽입 이미지

    1. 사용자가 사용자 프로세스(SQL PLUS나 기타 응용프로그램)을 이용 SQL명령을 내림

    2. 서버프로세스에 SQL문 도착

    3. 서버프로세스는 이전에 한번 실행된적 있는지 Library cache에서 찾아본다.

        (한 문자씩 하나하나 비교한다. 즉 대소문자, 띄어쓰기에 따라 다른문장으로 인식 한다.)

    4-1. 이전에 실행된적 있다면, Library cache에서 parse-tree와 QEP를 이용하여 해당 SQL문을

           실행한다.(Parsing과정 생략)

    4-2. 이전에 실행된적 없고 처음 실행되는 것이라면 서버프로세스는 parsing(구문분석)과정을

           시작한다.

    5. 일단 Data dictionary cache의 데이터 정의, 통계정보를 이용하여 해당 SQL문이 적절한지

        (권한은 있는 사용자 인가, 테이블이 존재하는가, 속성이 존재하는가 등등) 확인하고,

        해당 데이터로 가는 최적의 방법인 QEP를 만든다.

    6, 7. parse-tree와 QEP를 만들고 그것을 Library cache에 다음을 대비하여 저장한다.

    8. parse-tree와 QEP를 이용하여 해당 SQL문을 실행하고 그 결과를 PGA에 가져온 후

       사용자프로세스에 반환한다.

    * 모든 SQL문장은 Data Buffer Cache에서 실행되고, Data Buffer Cache에 없는 데이터가 있더라도

      하드디스크의 데이터베이스에서 해당 데이터를 읽어서 Data Buffer Cache에 올린 후 작업을

      재개한다.


DML작업이 진행될 경우 내부적인 처리 과정(Insert, Update, Delete, Select)

일단 DML문의 기본적인 Parsing과정은 위와 같다. Data Buffer Cache에서 실행될때 그 과정이

DML문마다 약간의 차이가 있는데 그것은 다음과 같다.

   - Select문 : Select문의 해당 컬럼내용을 해당 테이블에서 읽어와 결과를 반환한다.

   - Update문 : Update문은 RollBack과정을 고려한 몇 가지 작업을 진행한다.

                      아래 그림과 같이 설명하겠다.

 

사용자 삽입 이미지

        1. 100을 200으로 변경한다고 할 때, 변경전 값을 Undo Block에 복사한다.(Roll back 용도)
            Undo Block는 Data Buffer Cache의 일부분 중 하나이다.

        2. 변경되기 전 값(100), 변경되기 후 값(200), 변경된곳의 주소를 Redo log buffer에 저장

        3. 마지막으로 Data Buffer Cache의 데이터를 실제로 변경하게 된다.

    - Delete문 : Update와 거의 같다.다만 3번 과정에서는 실제 데이터를 삭제하며

                     2번 Redo Log Buffer에는 변경 후 값을 비워 둔다.

    - Insert문 : Update문과 거의 같다. 다만 1번의 Undo Block에 값을 복사하는 작업이 없고,

                    Redo Log Buffer에는 변경전 값을 비어두게 된다.


   * Undo Block의 값은 하드디스크에 저장된 Data File의 Undo Segment에 저장이 된다.(Roll Back용)

   * Redo Log Buffer의 내용은 하드디스크의 Redo Log File에 저장이 된다.

   * Commit시에는 Redo Log Buffer의 내용을 해당 트랜젝션 번호와 함께 하드디스크의

     Redo Log File에 저장하며, commit된 트랜젝션 번호를 따로 저장해둔다.



by thankee from tistory.com

신고
Tag : DB동작원리, DB처리과정, 오라클
Commented by Favicon of http://imsosorrybutiloveu.tistory.com BlogIcon 되면한다 at 2008.03.04 14:37 신고  r x
오 알기 쉽게 정리하셨네요 고맙습니다^^
Commented by Favicon of http://up730.tistory.com BlogIcon 롱티* at 2009.10.12 18:23 신고  r x
ㅇㅇ 이해가 쉽네요

name    password    homepage
 hidden


 Category
분류 전체보기 (95)
Netwrok & Security (6)
Web Development (61)
Database (5)
Framework (6)
Others (17)
About (0)
 TAGS
ajax WCF XML c#.net 영국 학원 특수문자 data tier class id 차이 exception MS SQL Server SourceSafe2005 ASP.NET RFC 4180 smarty linux php LiveMail 리눅스 Blog API 영국 인턴쉽 UpdateProgress 오라클 구조 ebnf ATRIX 오라클 DTD id name 차이 ASP maxRecievedMessageSize mantis bug tracker Silverlight application error #401 mantis 자바스크립트 It's me SourceSafe Internet 영국 홈스테이 web tier PHP 강좌 ie6 자바스크립트 버그
 Calendar
«   2017/10   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
 Visitor Statistics
Total : 248,436
Today : 10
Yesterday : 73
rss
 

티스토리 툴바