본문 바로가기

db

[오라클]플래쉬백(Flashback)을 통한 데이터 복구 -1 (ROW LEVEL FLASHBACK, Flashback Verision Query) 우선, 다음과 같이 연습할 테이블을 간단히 만듭니다. [실행화면] 그리고 나서 자료를 넣습니다. 저는 두개의 로우(ROW)를 입력했습니다. [실행화면] 커밋(commit)을 해준후 테이블을 확인합니다. 일본 국가에 속해있는 'ando'의 나이를 수정해 보겠습니다. [실행화면] 그리고 커밋을 해준후, 다시 테이블을 확인해서 업데이트가 이상없이 되었는지 확인해 봅니다. 자, 여기서부터가 플래쉬백을 통한 복구 과정입니다. 저는 방금 수정했던 'ando'의 나이를 이전 데이터로 돌리고 싶어합니다. 하지만 아무것도 모르고 단지 바뀌었다는 사실만을 알고 있습니다. 플래쉬백 버전 쿼리(Flashback Version Query)를 통해서 다음과 같이 변경이력을 탐색합니다. [실행화면] 보시게 되면 아래로부터가 변경된.. 더보기
[오라클] 아카이브 로그 모드(Archive log mode)로 전환하기 이제 슬슬 백업관련해서 복습을 해봅니다. SQL을 그럭저럭 마쳐가지고. 아카이브에 대해서는 알고 계시리라 생각하고 이번글을 적습니다. 데이터베이스가 구성이 되면 디폴트로 노아카이브 모드로 구성이 되는데요, 노아카이브 모드란 아카이브 로그 파일을 생성하지 않는 시스템 모드 입니다. 리두 로그 파일을 따로 기록하지 않습니다. 반면에, 리두로그 스위치가 일어날때 아카이버(Achiver)-ARCH 백그라운드 프로세스-가 디스크나 정해진 경로에 따로 리두 로그 파일을 기록하는데요, 이를 아카이브 모드라 합니다. 아카이브 모드를 사용하기 위해서는 파라미터(Parameter) 파일에 관련 파라미터를 설정해주어야 하는데요. 우선 다음을 데이터 베이스가 오픈된 상태에서 다음을 적용시켜줍니다. 아카이브 로그 파일이 생성될.. 더보기
[오라클] 오라클의 기동상태(시작과 종료) 1. 오라클의 기동 오라클은 4단계의 레벨을 거쳐 시스템이 시작됩니다. 다음로 4단계로 차례대로 실행됩니다. 1. SHUTDOWN : 오라클 인스턴스(Instance)가 정지된 상태로 데이터 베이스에 대해서 접근(Access) 할 수 없습니다. 2. NOMOUNT : 초기화 파라미터 파일을 읽고 인스턴스 구성(SGA, 백그라운드 프로세스 등), alertSID.log 및 추적파일을 엽니다. 3. MOUNT : Control 파일을 읽고 난뒤 리두 로그 파일과 데이터 파일을 확인합니다. 4. OPEN : 데이터 파일과 리두 로그 파일이 제대로 확인된 상태이며, 이때부터 정상적인 접근이 가능합니다. 보통 우리가 sql에서 startup 명령어를 통해서 DB를 기동시킬때는 위와 같은 순서로 기동됩니다. 기동상.. 더보기
[오라클] 아카이브 로그(Archive Log) 데이터베이스 복구를 위한 방법 중 하나인 아카이브 로그 입니다. 리두 로그 파일과 더불어 중요한 복구 방법인데요. 리두 로그 파일을 따로 저장하느냐 안하느냐에 따라 노아카이브 로그 모드와 아카이브 로그 모드로 불리웁니다. 이중 아카이브 로그 모드가 리두 로그 파일을 별도로 저장하는 모드인데요. 즉, 리두로그 파일의 복사본을 만듭니다. 이때 설정된 경로에 따라 리두로그 파일을 복사하는 것을 Archiver 즉, ARCH 백그라운드 프로세스라 부릅니다. 노아카이브 로그 모드와 아카이브 모드의 차이점은 무엇일까요? 우선 아카이브 로그의 유무가 되겠구요. 그로인한 디스크의 I/O의 증가, 감소와 관련이 있겠습니다. (당연히 아카이브 로그를 디스크에 쓸려면 I/O가 발생하겠죠?) 그리고 노아카이브 로드 모드는 데.. 더보기
[오라클] 리두 로그 파일(Redo Log File) -2 리두 로그 파일 -1 에 이은 두번째 글입니다. 다음의 보시는 그림은 LGWR 이 디스크에 리두로그 파일을 쓸때의 모습입니다. LGWR는 두개의 디스크에 리두로그 파일을 기록하는데요. 위에 보시듯 각 동일한 그룹을 각각의 디스크에 나눕니다. 그리고 멤버는 나뉘어진 그룹에 각각 담기구요. 앞 글에서 각 그룹의 멤버는 동일한 로그 기록을 저장한다고 했죠? LGWR는 리두로그 파일을 디크스에 쓸때 두 디스크 동시에 멤버로서 기록함으로써 에러시에 한쪽이 문제가 있어도 다른 한쪽의 디스크가 복구를 가능케 합니다. 그리고 각 그룹의 멤버가 용량이 다 차서 더 이상 리두로그 파일을 기록할 수 없을때 다음 리두로그 그룹으로 리두로그 파일을 기록하게 됩니다. 이때 리두로그 그룹간의 이동을 로그 스위치(Log Switch.. 더보기
[오라클] 리두 로그 파일(Redo Log File) -1 데이터베이스 시스템인 오라클에서 복구시 사용되는 것들이 있는데요. 그중에 하나가 리두로그 파일입니다. 리두로그 파일은 데이터베이스, 즉 오라클 에러 발생시에 데이터 복구를 위한 로그파일인데요. 이 리두로그 파일은 DML 작업시에 기록이 되게 됩니다. DML 작업시에 시스템에 변경되는 작업의 내용을 기록하는 것이죠. 이것을 통해서 문제가 생기면 이 파일을 이용해서 작업순서에 맞게 복구를 하게 되는 겁니다. 먼저, DML 작업으로 생성되는 리두로그는 SGA에 위치하게 되는데 SGA는 System Global Area로서 오라클 데이터 서버가 구동을 하게 되면 해당 인스턴스 내에서 생기게 되는 메모리 영역입니다. 이 메모리 영역안에 리두로그가 구성이 되는 것이구요. 그리고 메모리 안의 그 영역을 리두로그 버퍼.. 더보기
[SQL] CROSS JOIN 또다른 이름 카타시안 프로덕트(Cartesian Product) 이글에서는 CROSS JOIN, 크로스 조인에 대해서 알아볼까 합니다. 타이틀에서 명시했듯이 카타시안 프로덕트라고 하는 이름도 있는데요. 원래 존재하던 SQL 키워드인 카타시안 프로덕트가 SQL이 표준화가 진행되면서 ANSI 표준으로 바뀌었는데 그 이름이 CROSS JOIN 이 된것입니다. 이런 이야기는 앞에서 이야기 했구요. 개념적인 것을 먼저 살펴 보도록 할게요. '모든 경우를 고려한다!' 이것이 바로 크로스 조인의 핵심입니다. 사실 크로스 조인은 개념적인 조인이라고도 하는데요. 이유는 실제 프로젝트에서 이 크로스 조인이 쓰이는 경우는 없기 때문이죠. 그래서 조인이 아니다라고도 한답니다. 위의 말처럼 모든 경우를 고려하기 때문에 우리가 적던 ON절이나 USING절을 배제한체 조인조건을 적지 않습니다... 더보기
[SQL] OUTER JOIN, 외부조인(LEFT, RIGHT, FULL) INNER JOIN, 내부조인에 이은 외부조인 입니다. 내부조인을 접한후에 외부조인을 접하면 개념이 이해가 안갈데가 더 많은데요. 요렇게 생각해보는건 어떨까요? 내부조인 결과+@ 제가 이렇게 한건 결국 외부조인은 내부조인처럼 조인조건을 만족하는 결과에다가(내부조인의 결과와 같습니다.) 내가 조인을 건 어느 테이블의 데이터를 더 보겠다는 겁니다. 그러니 외부조인을 이용해서 데이터를 조회했을 경우에 어느 한쪽 테이블의 값이 null이고 다른 테이블의 데이터는 값이 나오게 되는거죠. 일단 이렇게 알고나서 구문형식을 보도록 할게요. SELECT 테미블명.컬럼명1, 테미블명.컬럼명2, 테미블명.컬럼명3, .. FROM 테이블 명1 (LEFT, RIGHT, FULL) OUTER JOIN 테이블명2 ON 조인조건; .. 더보기
[SQL] INNER JOIN, 내부조인에 대해서 알아보자! (Equi INNER JOIN) 사용하게될 테이블들의 컬럼명입니다. desc조회를 했어요. 1. employees 테이블입니다. 2. departments 테이블입니다. 우선 타이틀에 두개의 조인타입에 대해서 적어 놧는데요. 동일한 타입의 JOIN 입니다. 다만 INNER JOIN 할때 명시해 놓은 조인조건의 결과, 로우가 조인에 참여한 테이블의 조회조건에 상응하는 로우수가 같기때문에 동등하단 의미로 Equi라는 것이 붙은 것입니다. 똑같으니 염려 마세요. 내부조인이라고 불리우는 INNER JOIN 외에도 OUNTER JOIN, CROSS JOIN, NATURAL JOIN이 존재합니다. 우선 여기선 INNER JOIN에 대해서 알아볼건데요. 문법은 다음과 같습니다. SELECT 테이블명.컬럼명1, 테이블명.컬럼명2, ... FROM 테.. 더보기
[SQL] JOIN 조인에 대해서 알아보자! 우리가 여태껏 SQL 문을 써오면서 썻던 hr 스키마 계정에서 항상 employees 테이블에 있는 department_id를 활용을 했었는데요. 그때 아이디로만 활용을 했을뿐 부서명을 알지 못했는데요. 우선 employees 테이블을 조회하여 확인해 보겠습니다. 보세요. 부서명과 관련된 컬럼이 없죠? 그리고 다른 것도 한번 보세요. 하고 있는일, 과업(JOB_ID) 부분도 조회해보면 ID만 알수 있을뿐 이름을 알 수 없습니다. 그럼 이러한 정보는 어디에 있을까요? employees 테이블과 같이 다른 테이블에 그 정보들이 존재합니다. 여기서 테이블에 대해서 설명하고자 한다면 성격이나 데이터 타입이 비슷한 것을 세트로 묶어 놓은 것이라 이야기 할수 있는데요. 우리가 요구한 각 정보들은 department.. 더보기

티스토리툴바