데이터베이스 관리과 관련된 내용을 담고있다.
티베로 인스턴스는 서버를 구성하는 두 가지 중 하나
두가지 : 데이터베이스와 티베로 인스턴스
서버가 설치된 곳에는 두 가지 존재
인스턴스 : 데이터베이스를 관리하기 위해 존재하는 일꾼들
티베로 인스턴스를 사용하기 위해서는 데이터베이스 드라이버를 가지고 있어야하고 프로세스에 접속해야한다. 접속은 4단계로 이루어지며 워커 스레드와 사용자간의 db세션이 만들어진다. 최대 세션의 개수는 워커스레드의 수. 워커스레드 10개 -> 워커 프로세스 1개. 각각 db세션을 통해 sql을 보내고 스레드가 응답을 보낸다. 리스너는 접속을 중계하는 역할을 한다. 접속 이후에는 스레드와 클라이언트의 일대일 대응.
백그라운드 프로세스
매니저
리스너처럼 특정 포트...
스페션 포트는 리스너포트 +1에 해당하는 숫자의 포트를 사용한다.
티베로 쉐어드 메모리(TSM)
티베로 인스턴스 시작시 만들어지고 버퍼드 캐시 쉐어드 캐시
메모리 공간에서 여러 처리를 한다.
티베로 종료 시에는 처리하던 데이터들을 다시 파일에 쓰는 작업을 한다.
메모리에서 데이터를 처리함으로써 성능에 기여한다. 메모리 공간에 대한 내용 했었다.
파라미터 파일
인스턴스가 어떻게 동작해야할지 워커 프로세스에 포함되는 워커 스레드의 개수, 혹은 쉐어드 메모리의 크기 등을 정의해서 파라미터 파일에 써놓고 tbboot
-> 그걸 보고 인스턴스가 동작한다.
처음에 인스턴스를 시작할 때 지시하는 역할이다. 인스턴스는 시작 시 파라미터 파일의 내용만 기억하기 때문에 이미 시작된 이후에 파라미터 파일을 수정해도 인스턴스에 해당 내용이 적용되지 않는다. 다시 입력을 하려면 티베로 서버가 죽었다가 살아났을 때 ...
그런데 어떤 종료의 파라미터는 지시해서 값을 변경할 수 있는 파라미터도 있다.
정적 파라미터
인스턴스 동작 중 동적으로 바꿀 수 없다.
동적 파라미터
티베로에 접속해서 파라미터를 통해 값을 변경 가능하다.
티베로 참조 안내서 1장 참고
300여 가지의 파라미터 속성(동적/정적) 확인 가능
control Files
여러 파일들에 대한 리스트 정보가 담겨있다.
컨트롤 파일에서 읽어와서 보여주는 정보
컨트롤 파일을 tbsql에서 출력해보면 현재 사용하는 컨트롤 파일이 무엇인지, 컨트롤 파일 경로는 어디에 있는지 표시된다.
디스크립션을 보여달라는 명령
딕셔너리 뷰의 컬럼명, 타입 등을 보여준다.
DB_CREATE_DATE DATE // 데이터베이스 생성시점
CF_CREATE_DATE DATE // 컨트롤 파일 생성시점
컨트롤파일에 문제가 생겨서 (Ex 기존 파일에 문제 발생) 새로 다시 만든다면 최초 생성 시간과 컨트롤 파일의 생성시간이 달라지게 된다.
!!!!!!
컬럼의 폭 조절
컬럼별 폭 조절 혹은 기본 글자 수 설정
유틸리티 안내서 참조 1.7.1절
글자수 조절
전체 폭 조절
유틸리티 안내서 참조 1.8.18절
COL NAME FORMAT a6
COL DB_CREATE_DATE FORMAT a15
COL CF_CREATE_DATE FORMAT a15
SET LIN 100
/
앞서 실행한 sql다시 실행
이게 바로 컨트롤 파일에서 정보를 가져와서 보여주는 것이다.
SELECT STATUS, NAME FROM V$CONTROLFILE;
redo로그 파일 관리
리두 로그 파일 구성요소 : 리두로그 멤버 / 리두로그 그룹
멤버는 그룹 내에 여러 개 존재 가능
리두 로그 파일 관리
로그 그룹 추가
멤버가 바로 로그 파일에 해당.
리두로그 버퍼의 내용을 티베로가 두 개의 파일에 똑같이 쓴다. -> 가용성 확보를 위해
그래서 서로 다른 저장 장치에 저장되어있어야 한다. 저장 장치가 수명을 다 해서 망가졌을 때 한개의 디스크만 망가지는 것이 일반적. 디스크의 파일들이 망가지겠지만 다른 디스크는 멀쩡할 것. 서로 다른 디스크에 위치하는 여러 파일들을 사용하는 이유.
로그 그룹 삭제
리두 로그 파일 정보 조회
온라인 리두 로그 파일
일반적으로 업무 성격에 따라(리두로그 발생량) 크기 갯수는 알맞게 설정한다. 보통 500m- 1G 정도, 갯수는 10개 이상으로 설정
리두 로그 버퍼에 있는 것들을 리두로그 파일에 계속 쓴다.
메모리에 있는 리두로그 버퍼?에 있다가 쓰여지는 것
시간이 흐를 수록 로그파일 그룹은 가득 찬다. -> 로그 스위치 -> 가득차면 로그스위치
그러면서 온라인 리두 로그 파일에는 최근 리두 로그만 존재할 것이다.
리두로그 파일은 데이터 변경(DML)이력정보이다. 이 이력정보를 이용해서 복구 가능
리두로그 다중화
아카이브 리두로그 파일
current가 끝난 파일을 자동으로 올린다. (해당 모드일 때)
지시된 경로에 만들어진다. 경로는 파라미터 파일
cat $TB_HOME/config/$TB_SID.tip
sql에서 직접 조회
SELECT LOG_MODE FROM V$DATABASE;
그런데 아카이브 모드는 바꿀 수 있다. (동적 파라미터)
아카이브 모드가 되어 온라인 아카이브 리두 로그가 저장된다면
아카이브 로그도 조회 및 확인이 필요하다.
테이블 스페이스
데이터파일은 데이터파일과 연결되어있다.
데이터 파일은 독립적으로 존재하지 않고 테이블 스페이스를 만들 때 데이터 파일이 같이 만들어진다. 테이블 스페이스에 종속되어있기 때문에 테이블 스페이스 삭제 시에 데이터 파일도 함께 삭제된다.
용도 : 데이터를 저장
데이터파일은 물리적 공간
테이블 스페이스는 여러 데이터파일로 이루어진 논리적 공간
테이블 스페이스와 데이터 파일은 1:N의 관계
테이블 스페이스 개요
테이블 스페이스 유형
테이블 스페이스 관리
테이블 스페이스는 논리적 공간으로서 데이터 파일로부터 공간을 얻는 존재. 데이터 파일의 크기가 테이블 스페이스의 크기가 되는 것이다.
필요 시 오프라인 상태로 만들고 복구 작업을 수행할 수 있다.
테이블 스페이스는 저장 공간이고, 이를 테이블 또는 인덱스가 사용한다. 오프라인 상태가 되면 테이블 스페이스를 테이블이나 인덱스가 사용할 수 없게 된다.
티베로 관리 안내서 3.2절
티베로 sql참조 안내서 7.41절 참고
딕셔너리 뷰(모니터링, 참조 시 사용) - 티베로 참조 안내서
테이블 스페이스의 식별 번호
물리 저장구조 논리 저장구조
테이블 스페이스
기본 시스템에서 사용하는, 최소 티베로 설치 시 만들어지는 테이블 스페이스들
SySTEM, UNDO, SYSSUB, USR, TEMP
확인하는 방법 ?
DESC DBA_TABLESPACES
SELECT TABLE_NAME FROM DESC DBA_TABLESPACES
이외에 사용자 지정 테이블 스페이스를 사용하기 위해서는
테이블 스페이스부터 만들어야 한다.
테이블 스페이스 쿼리를 이용해서 만드는 테이블 스페이스
테이블 생성 시 특정 테이블 스페이스를 지정해야한다.
테이블 스페이스 공간 관리
데이터 파일과 연결되어있기 때문에 ...
세그먼트는 하나의 익스텐트로 시작한다.
익스텐트는 데이터 파일의 일부 공간이다.
데이터 파일의 일정 공간을 가져다 쓰는 것.
그러다가 필요하면 (데이터 파일로부터)익스텐트를 더 가져온다.
그렇다면 세그먼트가 대체 뭐길래 공가능ㄹ 떼어다가 사용하는가
데이터를 저장할 때 사용하는 객체인 테이블. 테이블이 사용하는 것이 바로 세그먼트이다. 테이블이 만들어질 때 세그먼트가 자동으로 만들어지고, 세그먼트와 테이블은 연결된다. 이용자는 sql문을 작성 시 테이블만 작성하지만 테이블 자체는 어떤 공간을 가지고 있는 녀석이 아니다. 테이블은 데이터를 저장하는 객체지만 그 자체가 공간을 제공하는 것은 아니다. 공간을 제공하는 것은 바로 세그먼트인 것이다.
최초에 테이블이 없는 상태에서 테이블을 계속 만든다. 계속 만들다보면 공간이 없어서 에러가 발생할 것이다. 데이터를 집어넣지 않는 빈 테이블만 만들어도 공간이 가득 찰 수 있는 것이다. 이유 : 세그먼트는 익스텐트 하나를 가지고 시작하기 때문에 공간이 점유된다.
테이블을 계속 만들면 데이터파일의 공간을 계속 차지하게 될 것이다. 이것이 데이터 세그먼트, 데이터 파일간의 관계.
세그먼트의 익스텐트는 블럭의 집합이다.
익스텐트를 자세히 보면 일련의 블럭들로 이루어져있음을 알 수 있다.
세그먼트 공간에 어떤 떄에 접근하는가? 테이블에 연결된 쿼리를 실행할 때.
쿼리가 실행되면 테이블에 연결된 세그먼트의 블럭(결국 데이터 파일에 있음)들을 가져와서 메모리에 올리고, (모든 쿼리의 대상이 되는 데이터는 파일에서 메모리에 올라와야 한다. 메모리에는 블럭단위로 올라오고, 세그먼트에 있는 블럭들이 모두 메모리에 올라와야하는 것이다.? 사용 끝지점(HWM)까지의 블럭이 ㅔㅁ모리에 모두 올라와야 한다.)
세그먼트 생성
테이블이 만들어지고, 테이블 타입의 스키마 객체 (테이블) 생성, 그리고 동일한 이름의 세그먼트가 만들어져서 연결이 된다.
컬럼을 프라이머리 키로 정의하면 유니크 인덱스가 만들어지고 인덱스 객체가 만들어진다. 인덱스 객체 때문에 세그마ㅓㄴ트가 만들어져서 연결된다. lob 오브젝트 객체와 연결되는 lob 세그먼트 가 만들어져서 연결된다.....
undo테이블 스페이스
테이블 스페이스는 저장공간.
undologfile을 저장한다.
undo log file 역할
트랜잭션 롤백. 모든 트랜잭션에서는 undo데이터가 발생한다. 트랜잭션은 데이터 변경의 묶음이다.undo란? 되돌리는 것. 데이터 변경했는데 왜 되돌릴 수 있는 데이터가 만들어지느냐? 언제든지 롤백을 할 수 있기 때문이다. 롤백 명령을 수행할 수 있게 해주기 위해서는 undo 데이터가 있어야한다. 그래서 데이터 변경 시 동시에 데이터를 되돌리는 데이터가 만들어지는 것이다.
트랜잭션 복구라는 것은 명시적으로 롤백 명령을 내려서 데이터를 되돌리는 것이 아니라 에러때문에 데이터가 되돌려지는 것을 의미한다.
Ex: 데이터 수정 후 연결선(물리적)이 가위로 잘렸다. 다음 명령을 받을 수 없다. 서버가 커밋을 계속 기다리게 된다.
읽기 일관성 : 데이터에 접근하는데에 일관성 있게 보여준다. 데이터를 읽을 때 시차가 발생한다. 1번째와 1000번 째 데이터를 읽을 때 중간에 생긴 데이터 변경 때문에 (다른 세션에서도 데이터 사용가능하기 때문에) 다른 데이터를 보게 될 수 있다. 어떤 시점에서 봐도 같은 데이터를 읽는 것을 보장하는 것.
플래시백 : 데이터를 순식간에 되돌리는 것. 10분 전 테이블 데이터를 조회할 수 있도록 해준다. undo데이터를 이용해 되돌려서 당시 데이터를 보여주는 것이다.
UNDO_RETENTION
커밋 이후 undo데이터의 보존 기간을 설정하는 파라미터. 기본값은 커밋 시점으로부터 900초이다. 커밋 이전까지는 undo데이터를 충분히 사용할 수 있다.(계속 유지 되기 때문에. ) 기본적으로 커밋 이후에는 undo데이터를 사용할 수 없다. 그러나 900초 동안은 사용할 수 있다. 900초는 기본값이기 때문에 파라미터를 변경해서 시간을 늘릴 수 있다. 늘릴 경우에는 undo데이터 저장을 위한 공간이 더 필요하게 된다.
undo extent 의 상태
더 공부해야할 부분 : 뷰 딕셔너리는 뭐냐? 이 부분은 대체 뭘 한거냐?
아마 테이블 스페이스와 연결되는 데이터 파일 확인 방법인 것 같긴 한데?
테이블 스페이스에서 뷰 딕셔너리를 이용해 조회해보길 바란다.
테이블 스페이스와 연결되는 데이터파일을 확인하는 두 가지 방법
SELECT NAME FROM V$TABLESPACE;
COL FILE_NAME FORa50
COL TABLESPACE_NAME FORa20
SELECT FILE_NAME, TABLESPACE_NAME FROM DBA_DATA_FILES;
두 개를 조인해서 보지 않아도 DBA_DATA_FILE파일 하나로 이름을 알수 있다.
DESC DBA_TABLESPACES
먼저 컬럼 확인을 하고, 연결된 컬럼들의 타입과 스탵이터스 확인 가능
SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;
SELECT NAME FROM VDATAFILE;
DESC VDATAFILE
테이블 스페이스
디스크립션 두 개
데이터파일 번호와 이름 알 수 있음. 테이블 스페이스 번호 ... 알 수 있음
두 개를 연결하면 테이블 스페이스 이름과 데이터파일 이름을 조인해서 알아낼 수 있음(연결고리 : TS#)
두개를 조인하는 쿼리 작성.
데이터 파일의 이름 변경과 디렉토리 변경
티ㅔㅂ로 설치 시 사용자 계정이 자동으로 생성된다. 이외에 업무에 필요한 사용자 계정을 추가해서 사용 시 ?
사용자 계정 조회
딕셔너리 이름이 DBA_USERS임
DESC DBA_USERS;
SELECT USERNAME FROM DBA_USERS;
사용자계정
패스워드를 통해 인증한다.
유저 생성 시 패스워드를 만들게 된다. 단방향 암호화로 저장된다. 원래 패스워드를 되돌릴 수는 없다. 조회를 해도 본래 패스워드를 짐작할 수 없다.
COL USERNAME FOR a10
SLELCT USERNAME, PASSWORD, ACCOUN_STATUS FROM DBA_USERS;
따라서 패스워드를 잃어버렷을 때는 재정의 해야한다.
하나의 사용자 계정은 하나의 스키마를 가진다. 스키마는 객체 관리를 위한 용도로 사용된다. 테이블을 만든다고 할 때 그 유저의 스키마에 속해있게된다. 여러 객체들은 특정 유저의 스키마에 속해서 존재하게 된다.
사용자 생성 문법
CREATE USER tibero
IDENTIFIED BY tmax
DEFAULT TABLESPACE MY_SPACE
단, 권한이 있는 유저(sys유저)가 사용자를 생성할 수 있다.
사용자 생성 후 connect권한을 부여하지 않으면 db에 접속할 수 없다. 만들어진 유저에게는 아무런 권한이 없다. sys유저가 권한을 부여해줘야한다. 모든 작업은 권한이 필요하다.
만약 유저를 생성할 때 default tablespace를 지정하지 않으면 유저가 객체를 만들때 (ex: 테이블) 어떤 테이블 스페이스를 사용한다는 것을 지정하게 되어있다. 지정하지 않는다면 유저의 default tablespace를 사용한다.
DBA_USERS에서 유저 별 어떤 테이블 스페이스가 지정되어있는지 확인할 수 있다. 그 외 여러 사용자 관련 정보 확인 가능
사용자 정보 변경
비밀번호 변경 가능.. 여러가지 가능
프로파일
프로파일은 패스워드 관리 정책
프로파일은 변경. 삭제, 그리고 유저에게 부여도 가능하다.
프로파일 적용
CREATE PROFILE prof LIMIT
failed_login_attempts 3; // 로그인 시도 횟수는 3회
CREATE USER tibero IDENTIFIED BY abcd PROFILE prof; // 티베로 유저에게 prof 프로파일 부여
ALTER USER tibero PROFILE prof;
sys유저가 확인 후 해제
CONN SYS/TIBERO // sys유저로 접속
SELECT ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME='TIBERO';
ALTER USER TIBERO ACCOUNT UNLOCK;
CONN TIBERO/TMAX // tibero 유저로 접속
권한이란?
특권 부여 예
SELECT ON EMPLOYEE
이라는 권한 ==> SELECT권한 을 스미스에게 부여. 기본적으로 SELECT는 본인이 소유한 객체에만 허용된다. 스미스 스키마에는 EMPLOYEE테이블 객체가 없지만 권한을 부여받음WITH GRANT OPTION
... 읽어봐라권한 회수(REVOKE)
롤
권한을 모아둔 집합.
롤은 일종의 권한을 모아둔 바구니
권한의 집합을 만든다 -> 유저에게 부여한다.
롤 취소 가능
티베로 설치 시 미리 정의된 롤이 있다.
권한을 담고있는 바구니
롤 조회
명령어가 다르다.
사용자 생성 및 권한 부여
유저가 만들어지면 유저 이름에 해당되는 스키마가 만들어진다.
피터 유저가 테이블을 생성하면 테이블객체가 만들어지는데 이는 피터 스키마에 속하게 된다.
스키마 객체 종류
이들은 데이터베이스 내의 어떤 스키마에 반드시 속하게 된다.
a테이블이 데이터베이스에 있다고만 이야기하면 안된다. 테이터베이스 내에 수많은 스키마가 존재하고, a테이블이 어떤 스키마에 속했는지도 알아야하기 때문이다. 테이블, 뷰, 프로시저 등 여러 이름이 동일한 객체가 존재할 수 있다. 따라서 어떤 객체를 언급할 때는 피터.a테이블
형식으로 스키마와 함께 언급해주어야 한다. 만약 스키마를 생략할 때는 현재 로그인한 유저의 스키마
에 있는 객체로 인식하게 된다.
스키마 객체의 이름
sql예약어 리스트