Database Concepts Chapter 6. Database Administration

데이터베이스 이론 및 실습 정재윤 교수님 수업 (19-1)

 

관리자의 측면에서 Database를 살펴보자

 

핵심 기능

- Concurrency control

- Security

- Backup and Recovery

---

Concurrency Control

1) 기본 컨셉

- 한 사용자의 행동이 다른 사용자의 행동에 영향을 끼치지 않도록 하자!

- The core of concurrency is accessibility.

- 해결 방법(무식)

    >> 한 명이 접속하면 다른 사람은 접속 못하게 하기

    >> 한 명이 DB 변경하면 다른 사람은 읽을 수만 있게 한다. 

 

2) Need for Atomic Transactions

- 하나의 operation 하는데 여러 쪼갤 수 없는 단위의 transaction들을 통해서 이루어짐(Atomic transaction)

- 그 단위를 Logical Units of Work(LUW) 라고도 한다. 

- operation이 DB로 커밋되기 전에 모든 LUW가 성공적으로 작용해야 한다. 

(하나라도 오류가 나면 rollback이 발생, operation 저장 ㄴㄴ)

 

3) Concurrent Processing Example

- A가 abc를 건드리고 B가 qwe를 건드리면 문제없음

- 둘이 같은 걸 update 하면 문제가 발생한다. 그러한 문제의 종류?

 

4) Concurrency Problem

- Dirty reads

>>  A가 작업 중인 레코드가 끝나지 않았는데 B가 해당 레코드를 update 하려고 건드림

- Nonrepeatable reads

>> SQL이 db를 읽고 있음 => 읽고 지나간 부분의 record가 update 돼서(change 돼서) 최종 결과물이 올바르지 못한 경우

- Phanton read

>> SQL이 db를 읽고 있음 => 읽고 지나간 부분에 새로운 record가 생겨서 최종 결과물이 올바르지 못한 경우

- 자 그러면 concurrency problem을 해결하자

 

5) Resource Locking

- 다른 사용자의 권한을 disallow 하자

- implicit(DBMS에서 자동) & explicit(유저가 수동으로 설정) resource locking으로 나뉜다.

- serializable transaction : 각각의 transaction이 일정한 순서를 가지고 순차적으로 실행되는 것, A와 B 누가 실행했는지에 관계없이 동일한 결과가 나와야 한다. 

 

5-2) Two-phased Locking(2PL)

locking의 두 가지 절차

- growing phase : 사용 전에 lock

- shrinking phase : 사용 후에 Lock 해제

 

5-3) Deadlock

locking에서 발생할 수 있는 문제

- A가 abc를 lock

- B가 qwe를 lock

- A가 qwe를 원함

- B가 abc를 원함

- 서로가 원하는 걸 서로가 lock 하고 있음 => 영원히 lock이 안 끝남 (교착 상태라고 표현하기도 함)

- 간단하게 deadlock 푸는 법

>> record의 접근에 순서가 존재하게 만들기, 한 번 작업 시작하면 통째로 lock 하기

 

6) Optimistic Locking vs Permistic Locking

이제 deadlock과 같은 문제를 해결할 건데 이를 위해 locking의 종류를 알아보자.

- Optimistic Locking

>> deadlock 등의 문제가 별로 안 생긴다고 긍정적으로 생각

>> 연산을 일단 다한 다음에 연산 전에 누군가가 건드렸는지 확인

>> 안 건드렸으면 Lock 하고 update

- Pessimistic Locking

>> 쫄보 Locking

>> 시작하기 전에 일단 Lock 하고 작업 끝나면 unlock

>> 안전은 확실한데 대기 시간이 늘어난다. 

이건 왜 있는지 모르겠는데 일단 첨부

7) Consistent Transactions

총정리를 위한 transaction의 성질들 : ACID

- Atomic

>> 모든 database action이 작동하거나 / 모두 안 하거나 둘 중에 하나다.

>> 하나라도 안되면 모두 안됨!

>> A transaction consists of a series of steps. Each step must be successful for the transaction to be saved.

 

- Consistent

>> Statement-level consistency : nonrepeatable read문제가 발생하지 않도록 하는 것?

(Each SQL statement independently processes consistent rows)

(각 SQL 문은 일관된 행을 독립적으로 처리한다.)

>>  Transaction-level consistency

( All rows affected by either of the SQL statements are protected from changes during the entire transaction.)

( SQL 문의 영향을 받는 모든 행은 전체 트랜잭션 중 변경으로부터 보호됩니다.)

 

- Isolation

>> 다중 사용자 환경에서 여러 transaction이 동일한 데이터에서 작동 중일 수 있습니다.

>> 현재 transaction이 완료될 때까지 레코드에서 다른 트랜잭션은 허용되지 않습니다.

 

- Durable

>> database의 모든 기록(log data)들은 저장하자. 나중에 어떤 문제가 생기든 복구할 수 있게

 

---

Security

1) 기본 컨셉

- 인증된 사용자만 접근한다.

- 허용된 접근만 가능하다.

- 누가, 무엇을, 언제 가능한지 권한을 정의하는 것.

- 보통 username과 password로 개인을 식벽한다.

 

2) Granting Permissions

- 개인에게 권한을 주거나 특정 role을 가진 사람들에게 권한을 주거나.

* 하나의 권한을 여러 사람들이 가질 수는 없는 건가? 의문 존재

 

3) Database security guideline

- Firewall 설치

- 최신 OS 업데이트

- DBMS의 기능 필요한 것만 사용하기

- DBMS를 물리적 위험으로부터 지키기

- 비밀번호 관리하기

 

---

Backup and Recovery

1) 기본 컨셉

- 위험을 겪었을 때 회복하자!

- Reprocessing은 비효율적임(시간 비용, brunt-force, human error 발생 가능) (여기서 reprocessing은 sql부터 천천히 다 돌린다는 거 같음)

- Rollback, Rollforward이 짱이여~

 

2) Rollback and Rollforward

- 특정 쿼리를 실행하기 전과 후에 파일을 저장했다고 생각해보자.

- 실행을 했는데, 잘못 실행함, 실행하기 전으로 돌아가고 싶으면 rollback

>> To undo, 저장한 데이터를 before-image

rollback

- 맞게 실행했는데 잘못해서 날아감, 맞게 실행한 것으로 돌아오고 싶으면 rollforward

>> To redo, 저장한 데이터를 after-images 

rollforward

 

추가적인 DBA의 책임(역할)

1. DBA는 사용자가 보고 한 오류 및 기타 문제를 수집하고 기록하는 시스템이 있는지 확인해야 합니다.

2. DBA는 데이터베이스 구성을 제어하는 ​​프로세스를 작성하고 관리해야 합니다.

3. DBA는 적절한 문서가 유지되도록 할 책임이 있습니다.