JJJ

import java.util.Scanner;

public class Main {
	public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int n = sc.nextInt();		
		for(int i = 1 ; i <= 9 ; i ++) {
			System.out.println(n + " * " + i + " = " + (n * i));
		}
	}
}

import java.util.Scanner;

public class Main {
	public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int m = sc.nextInt();
		int d = sc.nextInt();
		int totaldays = 0;
		int yo = 0;
		
		int[] dayArr = {0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
		String[] yoArr = {"SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT"};
		
		for(int i = 1 ; i < m ; i++) {
			totaldays += dayArr[i];
		}
		totaldays += d;	
		yo = totaldays % 7;
		System.out.println(yoArr[yo]);		
	}
}

import java.util.Scanner;
public class Main {
	public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int a = sc.nextInt();
		int b = sc.nextInt();
		System.out.println(a+b);
	}
}

HTTP 요청 종류 (서버→ 클라이언트 데이터 전달 방식)

1. 정적 콘텐츠

- css, js, 이미지 등

2. 뷰 템플릿

3. HTTP 응답 메시지

- HTTP API를 제공하는 경우 json 등의 데이터만 HTTP body에 담아서 전달

1. 정적 콘텐츠

- 해당 파일을 변경 없이 그대로 제공

- /static, /public, /resources, /META-INF/resources

- 정적 리소스 경로 : src/main/resources/static

ex) http://localhost:8080/basic/hello.html => src/main/resources/static/basic/hello.html

2. 뷰 템플릿

- 뷰 템플릿 경로 : src/main/resources/templates

- @ResponseBody가 없으면 뷰 리졸버를 실행해서, 반환 String값으로 뷰를 찾고 렌더링

- @ResponseBody가 있으면 뷰 리졸버를 실행하지 않고, 반환 String값을 HTTP body에 넣어서 전달

- Thymeleaf => 스프링 부트가 ThymeleafViewResolver를 빈으로 등록하고, application.properties도 기본으로 설정

spring.thymeleaf.prefix=classpath:/templates/
spring.thymeleaf.suffix=.html

=> 논리뷰명 : hello → 물리뷰명 templates/hello.html

3. HTTP 응답 메시지

- HTTP API 제공하는 경우 HTML대신 데이터를 전달함

- HTTP body에 json과 같은 형식의 데이터를 넣어서 전달함

response.getWirter().write("ok");

ResponseEntity

- HttpEntity를 상속 받음

@GetMapping("/response")
public ResponseEntity<String> responseEntityTest() {
	return new ResponseEntity<>("ok", HttpStatus.OK);
}

@ResponseBody

@ResponseStatus("HttpStatus.OK")
@ReponseBody
@GetMapping("/response")
public HelloData responseBodyTest() {
	HelloData helloData = new HelloData();
    helloData.setUserName = "AAA";
    helloData.setAge = "20";
    return helloData;
}

@RestController

- @Controller대신 @RestController를 붙이면 @ResponseBody가 전체 메서드에 적용됨

- REST API를 만들 때 사용하는 컨트롤러

REDO, UNDO가 궁금해서 먼저 살펴봅니다.

9.1 REDO, UNDO를 왜 알아야 합니까?

- 트랜젝션에서는 ACID라는 특성이 있음

- 이 구성을 위해서는 REDO, UNDO는 꼭 알아야 함

Atomicity : 원자성 : 수행 중인 트랜잭션에서 데이터를 일부만 변경하고 나머지는 수행되지 않을 채 커밋 불가

Consistency : 일관성 : 트랜잭션에 의해 데이터 간의 일관성이 어긋나면 안 됨

Isolation : 고립성 : 트랜잭션끼리는 고립되고 독립되어야 함

Durability : 지속성 : 트랜잭션은 장애가 발생해도 데이터는 반드시 복구되어야 함

=> 장비가 꺼져도 커밋한 데이터는 반드시 복구 가능

=> 어중간한 데이터 변경 불가

=> 트랜잭션 단위로 변경/롤백되어야 함

=> 다른 트랜잭션과 동시에 실행하든 단독으로 실행하든 결과는 같아야 함

9.2 지속성 구현

- 커밋한 데이터는 지킨다.

- 데이터에 변경이 일어나면 이를 디스크에 기록하면 되는데, 디스크 I/O는 시간이 많이 걸린다.

- 대량이 데이터를 변경하면 커밋을 하는데 시간이 너무 많이 걸림 => 상용 DBMS에서는 변경 로그를 사용하여 성능과 지속성을 구현함

- 오라클은 REDO로그를 사용하여 성능, 지속성 확보 : REDO로그에 데이터는 한꺼번에 기록하여 I/O의 횟수가 줄어들고, 시퀀셜 액세스를 해서 I/O소요 시간을 줄임

=> REDO 없이 변경내용을 실제 디스크의 변경점에 직접 기록하지 않고, 여러 변경점들을 REDO로그에만 기록해서 I/O횟수, 시간 줄임

9.3 REDO와 UNDO의 개념

Q) 정보가 손상되면, 과거로 돌아가야 하는데, 과거로 돌아가기 위해서 필요한 정보는? 

A) 정보가 손상된 시점에서 최신 상태까지 복구하기 위한 정보가 필요함

=> 1) 변경 정보

=> 2) 어떤 시점의 데이터 상태

- 두 정보를 알면, 어떤 과거의 시점으로부터 어떤 변경이 일어났는지 알 수 있음

REDO : 누가 무엇을 한 정보 = 변경 정보, REDO로그를 이용해서 과거의 데이터를 최신 데이터 쪽으로 흐르게 할 수 있음(롤 포워드)

UNDO : UNDO로그를 사용해서 변경을 취소할 수 있음(롤백)

=> UNDO로 과거의 어떤 시점으로 돌아간 뒤, REDO로 최신의 데이터로 변경함

9.4 REDO 구조

- 데이터의 변경은 버퍼 캐시에서 일어나고, 그때 REDO로그가 생성됨(커밋이 일어나기 전에)

EX.

1) UPDATE문

2) 서버 프로세스가 REDO, UNDO를 로그 버퍼에 기록 + 캐시에 있는 블록의 데이터 변경

3) UNDATE완료 통보

- 오라클은 REDO로그를 커밋이 발생하기 전에 디스크에 기록함

- 공유 메모리에 REDO로그 버퍼가 있음

- REDO로그를 디스크에 REDO로그 파일로 기록하는 일은 LGWR라는 백그라운드 프로세스가 수행함

- REDO로그 파일은 개수가 한정되어있고, 크기 제한도 있어서 계속 보관을 불가능해서, 아카이브 REDO로그 파일이라는 오랫동안 REDO로그를 보관하기 위한 파일이 존재

- REDO로그 파일은 REDO로그의 일시적인 보관소이고, 아카이브 REDO로그 파일이 오랜 시간 보관할 수 있는 본격적인 보관소

1) 서버 프로세스가 공유 메모리 상의 REDO 로그 버퍼에 REDO로그 기록 (커밋 전)

2) LGWR은 서버 프로세스가 커밋하면 혹은, 자발적으로 REDO로그를 REDO로그 버퍼에서 REDO로그 파일에 기록하고 기록이 끝났다고 서버 프로세스에 통보

3) 서버 프로세스는 커밋이 끝난 것을 클라이언트에 통보

4) ARCH가 REDO로그 파일을 아카이브 REDO로그 파일에 옮김

- REDO로그 파일은 중요한 파일이므로 반드시 다중화해야 함, 일반적으로 REDO로그 그룹을 여러 개 세트로 만들고, 그룹 안에 새로운 REDO로그 파일을 추가

- LGWR은 여러 개의 서버 프로세스의 REDO로그를 한꺼번에 기록하므로 높은 처리량을 구현

- 커밋할 때 블록을 디스크가 아닌 REDO로그에 기록해서 빠른 커밋 구현

- 장비 장애가 발생해서 DBWR이 데이터를 기록할 틈에 없었더라고, REDO로그와 데이터 파일에 있는 과거 데이터로 데이터 복구(롤 포워드)가 가능

작성 중...

3.1 캐시가 필요한 이유

- 오라클은 디스크에서 데이터를 읽고 씀

- 디스크는 속도가 느리기 때문에 오라클은 캐시를 활용해서 가능하면 느린 디스크 대신, 빠른 메모리에서 처리하려 함

3.2 캐시란?

- 빈번하게 사용하는 데이터를 매번 디스크에서 가져오지 않고, 캐시라고 하는 메모리 상의 공간에 두고 빠르게 접근할 수 있음

- 캐시에 hit에 하지 않으면, 디스크에서 데이터 처리를 해야 하므로, SQL의 속도가 느려짐

1) SELECT요청

2) 서버 프로세스는 SELECT에 필요한 데이터가 캐시에 있는지 확인

3) 있으면, 캐시에서 가져와서 결과 반환 / 없으면, 디스크에서 읽고 캐시에 넣은 뒤에 결과를 반환

3.3 데이터는 블록 단위로 관리

- 오라클은 '블록'이라는 단위로 데이터를 관리하며, I/O의 단위도 블록이고, 버퍼 캐시도 블록 단위

- 한 개의 블록에는 여러 건의 데이터가 있는데, 그중 하나만 읽으려고 해도 블록 전체를 가져오고 캐시에 보관됨

- 블록의 크기는 2KB, 4KB, 6KB, 8KB, 16KB, 32KB 중 하나인데 주로 8KB

3.4 캐시와 인덱스

- 인덱스도 블록으로 구성됨, 인덱스를 한 블록에 보관할 수 없으면, 여러 개의 블록으로 구성함

- 인덱스도 캐싱되어 빠르게 접근할 수 있음

3.5 프로세스는 캐시를 공유

- 기본적으로 프로세스는 독립적으로 수행되고, 자원도 독자적으로 사용함

- 프로세스마다 캐시를 가지게 되면, 낭비가 심하고, 다른 프로세스에서 확인이 불가능함

- 오라클의 캐시는 모든 프로세스가 확인이 가능함

- OS의 공유 메모리(SGA)라는 특수한 메모리를 사용하면, 특정 프로세스가 기록한 데이터를 다른 프로세스도 확인이 가능함 (공유하지 않는 메모리 : PGA)

- DBMS에서는 여러 개의 프로세스가 실행되므로,  공유 메모리는 필수적

- 공유 메모리는 누구든지 접근이 가능하므로 Lock이 필요함 > 성능 문제 발생 가능

- 공유 메모리에는 버퍼 캐시 말고 공유 풀, 로그 버퍼 같은 영역도 있음

3.6 공유 메모리 설정

- 오라클 설정 파일 : sqfileXXXX.ora > DB_CACHE_SIZE : 오라클 버퍼 캐시의 크기

- 버퍼 캐시의 크기를 DBMS 성능과 직결되므로, 잘 설정해야 함

=> 오라클 설치 시 적절 크기를 알 수 없을 때 크게 정해 놓고, 나중에 통계를 기반으로 조정

=> 버퍼 캐시 어드바이저(V$_CACHE_ADVICE) : 버퍼 캐시 크기마다 물리 읽기 수를 예측

=> 버퍼 캐시 히트율 : 버퍼 캐시 내에서 요청받은 블록을 꺼내온 빈도

=> 자동 공유 메모리 관리 : SGA크기만 정해두면, 버퍼 캐시 크기를 설정할 필요 없이, 부하의 정도에 따라 오라클이 자동을 조절, DB_CACHE_SIZE를 지정하면 하한으로 동작함(최소한의 버퍼 캐시 보장)

3.7 공유 메모리는 어떤 식으로 보이는가?

- ps 명령어를 사용하여 각 프로세스가 사용하는 메모리의 크기를 확인할 수 있음

- VSZ : 각 프로세스의 가상 메모리 크기

- RSS : 각 프로세스가 실제로 사용하는 메모리 크기

세마포어

- OS가 제공하는 자원을 관리하기 위한 장치

- 자원의 수에 비해 사용하고자 하는 프로세스의 수가 많을 경우 순서대로 자원을 사용할 수 있도록 프로세스 제어를 수행

- 오라클을 기동할 때 세마포어가 부족하다는 의미의 메시지가 나타나면 늘리는 것을 검토

- 아무도 사용하지 않는 세마포어가 OS에 남아 있는 경우도 있으므로 정리(ipsc명령, ipcrm명령)

# /sbin/sysctl -a | grep sem

kernel.sem = 250 32000 100 123

3.8 버퍼 캐시를 정리하는 LRU 알고리즘

- 버퍼 캐시는 자주 사용하는 데이터를 더 빠르게 가져오기 위해 사용

- 그 크기를 한정되어 있으므로, 누군가 관리하고 정리를 해줘야 함

- LRU(Least Recently User) 알고리즘은 단순히 말해서 최근에 사용하지 않은 데이터부터 캐시에서 제거하는 알고리즘

- 오라클도 버퍼 캐시 관리를 위해서 LRU알고리즘을 사용

- 오라클은 큰 테이블이라고 판단하면 버퍼 캐시로 데이터 블록을 적재하지 않음

- 풀 스캔한 데이터는 일반적으로 버퍼 캐시에 적재되지 않는 다고 생각하면 됨

3.9 OS와 스토리지

- 스토리지 캐시 : 스토리지에서 데이터를 읽어오는 것을 빠르게, 기록하는 것도 빨라짐 (원래 디스크에 기록해야 하는 데이터를 캐시에 기록하는 것만으로 OS관점에서 I/O를 종료할 수 있음)

CPU - 메인 메모리 - | - 스토리지 캐시 - 디스크

3.9.1 OS의 버퍼 캐시와 가상 메모리의 차이

- OS에는 버퍼 캐시와 가상 메모리가 있음

- OS의 버퍼 캐시는 오라클의 버퍼 캐시와 유사한 기능

- OS버퍼 캐시 : 메인 메모리의 일부를 버퍼 캐시로 사용하고, 자주 사용하는 파일 데이터를 둠

- 가상 메모리 : 실제로 가진 물리 메모리보다 더 많은 메모리를 사용, 최근에 사용하지 않은 데이터를 프로세스 모르게 디스크에 보관(page out) 해두고, 나중에 요청이 들어오면 디스크에서 가져옴(page in)  메모리가 실제 메모리보다 많은 것처럼 보임 (SWAP : 가상 메모리를 위한 디스크)

- 가상 메모리와 버퍼 캐시의 동작은 상반되어 있음, 버퍼 캐시는 디스크에 빠르게 접근하기 위해 메모리의 일정 부분을 할당하여 사용하고, 이에 비해 속도가 느리더라도 사용할 수 있는 메모리의 크기를 늘리기 위해서 디스크를 사용하는 것이 가상 메모리

2.1 오라클의 역할

- 여러 클라이언트의 데이터를 디스크에 보관하고, 클라이언트의 요청에 따라 데이터를 돌려주는 역할을 함

2.2 데이터베이스의 데이터는 모두의 것

- 오라클은 각종 프로그램으로부터 요청을 받아서 데이터는 처리함

- 요청을 받아서 처리하는 입장인 오라클에는 여러 가지의 프로세스들이 있음

- 데이터베이스에는 여러 프로세스와 사용자들이 접근하기 때문에 정합성을 고려해야 함

- 엑셀은 사용자별로 엑셀 파일을 가지고 데이터를 관리하지만, 데이터베이스는 다수의 사용자와 애플리케이션이 데이터를 공유하므로, Lock이라는 개념이 있음

2.3 오라클이 여러 개의 프로세스로 구성된 이유

- 다중 처리를 하려고

- 현 사용자가 작업하는 동안 다른 사용자가 가만히 있을 순 없음

- 빠른 CPU와 메모리가 느린 디스크의 동작을 기다리고 있는 것은 매우 비효율적임

- 오라클은 서로 다른 역할의 여러 개의 프로세스를 실행해서 병렬 처리함

2.4 서버 프로세스, 백그라운드 프로세스

1) 서버 프로세스 : SQL 처리, 클라이언트에게 서비스를 직접 제공

2) 백그라운드 프로세스 : 서버 프로세스를 지원, 지원 스태프 역할

 - DBWR : 데이터를 디스트에 기록

 - LGWR : 데이터 변경 이력인 로그를 디스크에 기록

 - PMON : 프로세스 감시, 장애 발견시 정리

 - ARCH : 로그 데이터를 아카이브(장기보관을 위해 별도 파일로 보관)

2.5 각 프로세스의 역할

1. SQL수신

2. SQL파싱 (어떤 테이블에 어떻게 접근)

3. 데이터 읽기

4. 데이터 기록

5. SQL 결과 회신

6. 로그 기록 (데이터 변경 로그를 디스크에 기록)

7. 각종 정리 (문제 프로세스 재기동, Lock해제 등)

8. 로그 보관 (아카이브)

- 서버 프로세스는 SQL문을 처리하고 결과를 돌려주는 일에만 집중하고 , 이 외의 일을 백그라운드 프로세스가 함

1.1 필수 키워드

DBMS의 목적

1. 병렬 처리와 높은 처리량

2. 응답시간 중요

3. commit데이터는 보호

1.2 오라클과 디스크

- 오라클은 데이터는 디스크에서 읽어오고, 디스크에 기록함

- 디스크는 아래와 같이 생김

- 디스크의 원판이 돌아가고, 뾰족한 헤드가 움직여서 데이터를 읽고 기록함

1.3 디스크의 동작

- 디스크는 빠른 속도로 회전함, 빠르게 돌지만, 메모리의 속도에 비하면 매우 매우 느린 속도임

- 디스크에 데이터를 읽고 쓰려면 두가지 동작이 필요 1) 탐색, 2) 회전대기

1) 탐색 : 헤드를 필요한 데이터가 있는 쪽으로 이동

2) 회전 대기 : 디스크의 회전해서 원하는 데이터가 올 때까지 기다림

- 오라클은 디스크를 이용하므로, 처리시간 단축을 위해서는 디스크 I/O가 제일 중요함

1.3.1 I/O시간을 줄이는 방법

- 시퀀셜 액세스 : 시작점에서부터 마지막까지 중간 부분을 빠뜨리지 않고 전부 읽기/쓰기, 테이블 풀 스캔

- 인덱스 : ROWID를 가지고 있음, ROWID는 디스크 상의 실제 테이블의 레코드를 찾기 위한 논리적 주소

1.3.2 인덱스 사용

- 인덱스를 조사 > ROWID를 얻음 > 디스크에서 데이터를 얻음

- 인덱스는 Tree구조로 되어 있음

1.3.3 랜덤 액세스

- 인덱스를 사용하면 ROWID를 활용해서 디스트에서 필요한 부분만 읽어오면 충분하므로, 시퀀셜 액세스를 하지 않고, 랜덤 액세스함

- 랜덤 액세스를 하면 매번, 탐색+회전 대기를 거쳐야 하는 비효율적인 부분이 있음

=> 인덱스를 사용하여 데이터를 조회할 때에는 큰 테이블에서 아주 적은 데이터만 조회할 때 사용해야 함(전체 데이터의 5%~20%), 많은 데이터를 하나하나 인덱스를 사용해서 랜덤 액세스를 하는 것은 오히려 더 느려지고, 그냥 풀 스캔이 더 빠름

1.4 데이터 보증을 위한 디스크

- 데이터는 오라클의 프로세스가 비정상 종요되어도 무사해야 함 (commit 한 데이터는 보호)

- 오라클은 데이터 변경 후 commit 하면 데이터를 디스크에 기록함

DML, DDL, DCL 문법에 관련된 책이 아니고, 오라클이 컴퓨터에서 어떻게 동작하는지 쉽게 설명해주는 책입니다. 

특히, 디스크와 오라클간의 관계에 대해서 잘 설명합니다. 

내가 DBA도 아닌데 이런 책을 왜 봐야 하나 생각할 수 있는데, SM 업무를 하다 보면 SQL 외에도, 인덱스의 구조, 오라클 프로세서들의 역할, DBMS가 디스크를 어떻게 사용하는지, 버퍼 캐시는 어떻게 쓰는지, REDO/UNDO, 백업/복원과 같은 내용을 알아야 합니다. (DBA가 DB관련 업무를 다 해주는게 아니라면....)

이 책에서는 깊고 어려운 내용 까지는 아니지만, 시스템 운영자로서 알면 좋은 내용들을 알아볼 수 있습니다.

목 차

CHAPTER 1 I/O와 디스크의 관계 1
1.1 오라클을 이해하기 위한 필수 키워드 2
1.2 오라클과 디스크(하드디스크) 3
1.3 디스크의 동작 4
1.4 데이터를 보증하기 위한 디스크 12
1.5 요약 14

CHAPTER 2 오라클의 여러 프로세스 17
2.1 오라클의 역할 이미지 18
2.2 데이터베이스의 데이터는 모두의 것 20
2.3 오라클이 여러 개의 프로세스로 구성된 이유 25
2.4 서버 프로세스와 백그라운드 프로세스의 역할 27
2.5 각 프로세스가 수행하는 처리 29
2.6 요약 32

CHAPTER 3 캐시와 공유 메모리 37
3.1 어째서 캐시가 필요한 것인가? 38
3.2 그래서 캐시란 대체 무엇인가? 39
3.3 데이터는 블록 단위로 관리 41
3.4 캐시를 사용해서 인덱스 검색을 효율적으로 43
3.5 프로세스는 캐시를 공유 45
3.6 공유 메모리에 필요한 설정 48
3.7 공유 메모리는 어떤 식으로 보이는가? 50
3.8 버퍼 캐시를 정리하는 LRU 알고리즘 52
3.9 오라클뿐만이 아닌 OS나 스토리지에 대해서도 생각하자 54
3.10 요약 58

CHAPTER 4 SQL문 분석과 공유 풀 61
4.1 SQL문의 분석과 공유 풀을 왜 배워야 하는가? 62
4.2 SQL문과 일반적인 프로그래밍 언어의 차이 62
4.3 서버 프로세스와 분석 63
4.4 실행 계획이 최적이라는 것을 판단하기 위해서는? 66
4.5 공유 풀의 동작과 구조 71
4.6 수치로 알아보는 분석과 공유 풀의 정보 74
4.7 요약 76

CHAPTER 5 오라클의 기동과 정지 79
5.1 기동과 정지를 왜 배워야 하는가? 80
5.2 오라클의 기동/정지의 개요 80
5.3 업무의 시작에 해당하는 오라클의 기동 81
5.4 인스턴스, 데이터베이스, 그리고 주요 파일의 구성 82
5.5 기동 처리의 흐름과 내부 동작 85
5.6 업무 종료에 해당하는 오라클의 정지 91
5.7 데이터베이스를 수동으로 생성하기 93
5.8 요약 95

CHAPTER 6 커넥션과 서버 프로세스의 생성 97
6.1 애플리케이션에서의 접속을 왜 배워야 하는가? 98
6.2 오라클의 접속 동작 99
6.3 접속 동작의 확인 106
6.4 정지나 리스너의 상태 확인 110
6.5 성능을 개선하기 위해서는? 111
6.6 요약 113

CHAPTER 7 오라클의 데이터 구조 115
7.1 오라클의 데이터 구조를 왜 배워야 하는가? 116
7.2 가변 길이 데이터를 관리할 프로그램을 만들기 위해서는? 117
7.3 오라클의 데이터 구조 120
7.4 데이터 구조에는 어떤 것들이 있는가? 123
7.5 실제 흐름을 따라 각 동작을 확인 128
7.6 프로세스에서 본 데이터 구조 130
7.7 요약 132

CHAPTER 8 오라클의 대기와 Lock 135
8.1 대기와 오라클의 Lock을 왜 배워야 하는가? 136
8.2 데이터베이스에 Lock이 필요한 이유 136
8.3 대기와 Lock 대기 139
8.4 Latch의 구조 147
8.5 요약 150

CHAPTER 9 REDO와 UNDO의 동작 153
9.1 REDO와 UNDO를 왜 배워야 하는가? 154
9.2 지속성을 구현하기 위해서는 156
9.3 REDO와 UNDO의 개념 158
9.4 REDO의 구조 160
9.4.1 REDO의 요약 163
9.5 UNDO의 구조 163
9.6 여러 상황에서 REDO와 UNDO의 동작 165
9.7 요약 171

CHAPTER 10 백업/복구의 구조와 동작 175
10.1 백업/복구를 왜 배워야 하는가? 176
10.2 백업/복구에 필요한 지식의 복습 177
10.3 백업의 종류와 특징 179
10.4 데이터베이스 손상의 예 181
10.5 기본적인 복구의 종류와 동작 183
10.6 기본적인 복구의 흐름(데이터베이스 전체의 복구) 188
10.7 그 외의 복구 192
10.8 요약 196

CHAPTER 11 백그라운드 프로세스의 동작과 역할 199
11.1 백그라운드 프로세스를 왜 배워야 하는가? 200
11.2 백그라운드 프로세스와 서버 프로세스의 관계 200
11.3 DBWR의 동작과 역할 205
11.4 LGWR의 동작과 역할 209
11.5 SMON의 동작과 역할 210
11.6 PMON의 동작과 역할 211
11.7 LREG의 동작과 역할 211
11.8 ARCH의 동작과 역할 212
11.9 그 외의 백그라운드 프로세스 214
11.10 요약 216

CHAPTER 12 오라클 아키텍처와 동작에 관한 Q&A 217
12.1 지금까지의 복습 218
12.2 오라클의 동작에 관한 질문 222
12.3 모니터링/운영에 관한 질문 223
12.4 해답과 해설 오라클의 동작에 관한 질문 224
12.5 해답과 해설 모니터링/운영에 관한 질문 233
12.6 요약 235

APPENDIX 유스케이스로 배우는 오라클 239
A.1 A 씨에게 준비된 과제 240
A.2 오라클의 기동 240
A.3 리스너를 통한 접속 242
A.4 데이터 파일의 추가 245
A.5 백업하기 247
A.6 OS 명령어를 사용한 데이터 파일 삭제 253
A.7 현재 상태의 백업 255
A.8 복원 258
A.9 복구 260
A.10 데이터 파일의 제거 263
A.11 오라클의 정지 265

컬럼 사이즈를 변경하기 위해 ALTER TABLE - ALTER COLUMN을 했는데, 오류가 발생

SYSCAT.TABDEP 조회하면 해당 테이블이 어떤 VIEW, MQT에서 사용중인지 확인 할 수 있음

원인 : MQT에서 해당 테이블을 참조하고 있어서 그럼

처리방법 : MQT DDL을 백업해두고, MQT삭제 > ALTER > MQT생성 및 REFRESH