CS 스터디 - 데이터베이스(2)

#1 데이터베이스의 UNDO 연산과 REDO 연산에 대해 설명해주세요 

대부분의 데이터베이스들이 채택하는 버퍼 관리 정책은 수정된 페이지를 언제든지 디스크에 쓸 수 있으며, 트랜잭션이 종료된 시점에 해당 트랜잭션이 수정한 페이지를 
 
DBMS는 데이터를 고정 길이의 페이지로 저장하며, 디스크에서 읽거나 쓸 때에 페이지 단위로 입출력 이뤄짐 
메인 메모리에 유지하는 페이지들을 관리하는 모듈을 페이지 버퍼 관리자 (또는 버퍼 관리자)라고 부르는데 DBMS의 중요 모듈중 하나이며, 버퍼 관리 정책에 따라 트랜잭션의 UNDO 복구와 REDO 복구가 요구되거나 그렇지 않게 된다. 
 
" 수정된 페이지를 언제든지 디스크에 쓸 수 있는가? "

• STEAL : 언제든지 수정된 페이지 디스크에 쓸 수 있음 
  • 아직 완료되지 않은 트랜잭션이 페이지를 수정하고, 수정된 페이지들이 디스크에 출력될 수 있다.
  • 해당 트랜잭션이 정상종료되지 못하게 되면 트랜잭션이 변경한 페이지들을 원상 복구 (변경 전 상태로) 시켜야 한다.
  • UNDO 로깅과 복구가 필연적으로 수반
•  ¬STEAL : 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책
  • UNDO 작업이 메모리 버퍼에 대해서만 이뤄지므로 매우 간단해진다.
  • 대신 계속 버퍼에 수정된 페이지들을 가지고 있어야 하므로, 매우 큰 메모리 버퍼 사이즈가 필요하다. 

* UNDO : 사용자가 수행한 작업을 원래대로 되돌리기 위한 작업,  최신 데이터를 오래된 데이터로 만드는 작업 
 
" 트랜잭션이 종료된 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에도 쓸 것인가? "

• FORCE: 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
  • 이 정책을 따르면 커밋 시 이미 디스크 상 데이터베이스에 반영이 되어 있어 REDO 복구가 필요 없어 보일수도 있으나, 데이터베이스 백업으로부터의 복구 시에는 REDO 복구가 요구된다. 
• ¬FORCE: 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책
  • 이 정책은 커밋 시점에 어떤 작업을 했었다는 로그를 기록

REDO : 오래된 데이터를 최신으로 만들기 위한 작업,  사용자가 했던 작업을 그대로 수행하는 것 
- 커밋한 트랜잭션의 수정은 유지되어야 한다 (ACID 중 Durability)
이미 커밋한 트랜잭션의 수정을 재 반영하는 복구작업을 REDO 라고 한다. 
 
 
 

#2 데이터베이스 View란 무엇이고, 왜 사용해야 할까요? 

view : 가상의 테이블, 데이터는 없고 SQL만 저장되어 있는 object를 의미, view 를 select 하게되면 view가 가지고 있는 SQL 문이 실행되는 것과 같다. 데이터의 논리적 독립성을 제공하며, 필요한 데이터만 뷰로 정의하여 사용하기 때문에 관리 용이, SQL 명령문이 간단해진다. view 에서 수정은 불가하므로, 변경해야 한다면 drop & create로 지우고 다시 생성해야 한다. 원본 테이블의 이름으로 생성이 불가하며, 실무에선 주로 vw_등의 접미사 / 접두사를 통해 뷰라는 것을 명시한다. 

CREATE VIEW 뷰이름 AS SELECT 구문;
DROP VIEW 뷰이름

-- VIEW 사용시 SELECT문 중첩 없이 SQL 간단히 바뀜 
SELECT name From account_view;

 
- 보안 : 스키마 내 특정 테이블의 정보가 필요한데, 보안상 스키마 테이블 보는 권한 허용이 불가하다 이런 경우에 view 생성해서 전체 데이터 공개는 막고 필요한 것만 view에 담아 제공 가능 
- 사용자 편의성 : SQL 간소화 및 복잡한 SQL 편리하게 재 생성 가능 
 
참고글

https://stricky.tistory.com/323

 

#3 SQL injection 공격이란? 

SQL 인젝션 공격이란 악의적인 목적을 가진 임의의 SQL문을 주입, 실행하게 하여 데이터베이스가 비정상적인 동작을 하도록 조작하는 공격을 의미합니다. 이를 막기 위해서 다음과 같은 방법을 사용할 수 있습니다.
 
첫 번째로, 사용자의 입력값에 대한 검증이 필요합니다. 입력 가능한 형식을 지정해두고, 해당 형식이 아니라면 올바르지 않은 입력이라 판단 후 수행하지 않도록 합니다. 아래와 같은 학생 이름 입력 쿼리가 있다고 가정해보자. 

INSERT INTO student.name VALUES ~

만약 이곳에 사용자로부터 입력받은 값이 'NAME'); DROP TABLE student;-- 라면?NAME이라는 값의 학생이름이 들어가고, 뒤에 DROP TABLE 부분이 수행되어 버린다. = DROP TABLE 명령어가 수행되면서 테이블이 날아간다. 또한 --는 뒷 부분을 주석으로 만들어버려서 뒤의 내용도 수행 X. 
 
따라서 사용자의 입력값을 그대로 쿼리로 사용하지 않고, 특수 문자, 데이터 베이스 예약어(UNION) 등을 필터링함으로써 방지 
두 번째로, prepared statement를 사용하는 방법입니다. prepared statement란 미리 SQL 구문을 컴파일해두고, 변수 부분만 변화를 주어 수행하는 방식입니다. 실행되는 SQL 문을 숨길 수 있어 보안상의 이점이 있습니다.

SELECT s.score from Student s where s.name = ?

 
세 번째로, DB에 대한 에러 메시지를 노출하지 않는 것입니다. 데이터베이스의 테이블 명, 컬럼 명 등을 노출되지 않도록 숨김으로써 사전에 데이터베이스를 보호할 수 있습니다.
 

#4 SQL Injection 에서 왜 Preapred Statement 사용하는게 보안 상 이점을 가지나요? (꼬리 질문)

prepared statement란 미리 SQL 구문을 컴파일해두고, 변수 부분만 변화를 주어 수행하는 방식입니다.
웹 상에서의 쿼리는 parse - bind - execute - fetch 순서대로 수행됩니다. 
 
일반적인 statement 사용하여 쿼리를 수행하면, 매번 parse ~ fetch를 수행합니다. 
하지만 preapred statement 사용하여 쿼리를 수행하면 parse는 1번만 수행되고(미리 컴파일이 다 되어있음), bind 단계에서 각 바인딩 변수만 대입하여 사용합니다. 이 때 binding 변수는 SQL 문법이 아닌 인터프리터 또는 컴파일 언어로 처리되어 수행되므로, 공격 의도가 있는 쿼리를 대입하여도 단순 문자열로 치환되므로 의미있는 쿼리로 동작하지 않습니다. 따라서, 보안적인 이점을 가집니다. 
 
ㄴ 참고 

https://webstone.tistory.com/50

SQL Injection 공격 대응방안:Prepared Statement를 사용하는 이유

 

 
 

# 5 장애로 인해 데이터베이스가 재시작되어야 한다면 어떤 단계를 걸쳐 복구가 이뤄지나요? 

• 마지막 체크 포인트 시점부터 최근 로그(End Of Log)까지 로그를 탐색하며 어디서부터 시스템이 복구를 시작해야 하고, 어느 트랜잭션을 복구해야 하는지 분석
• 복구 시작해야 하는 시점부터 장애 발생 직전 시점까지 REDO가 필요한 모든 단계 복구, 실패한 로그 조차 REDO 를 수행한다. 이 과정이 끝나면 장애 발생 시점 상태와 동일해진다.
• 이후 UNDO 복구 수행을 통해 최신 시점 -> 과거로 역방향 탐색하며 복구가 필요한 로그에 대해 UNDO 복구를 수행한다. 

참고로 UNDO가 필요한지, REDO가 필요한지 판단하는 것은 로그의 LSN이라는 식별자를 통해 알 수 있다. 데이터베이스의 모든 페이지는 page LSN을 가지고 있는데,  이 식별자는 페이지가 갱신될 때마다 해당 로그의 LSN으로 갱신된다. 
 
 

# 6 CAP 이론에 대해 설명해주세요 

분산 데이터베이스 환경에서 사용되는 이론, Consistency, Availability, Partition Tolerance의 이니셜들이다. 
 
C : 모든 시스템의 데이터는 항상 같은 데이터를 가질 것 
A : 분산 시스템에 대한 모든 요청은 항상 응답을 반환할 것 
P : 장애 상황에서도 시스템의 작동은 계속 될 것 
참고로, 적절한 응답 시간 내 세 가지 속성을 모두 만족시키는 분산 시스템을 구성할 수는 없으며, 분산환경에서 P가 필수인 만큼 CP / AP로 나뉘어진다.
하나가 죽더라도 정상적으로 요청을 처리해 일관성을 희생하고 가용성을 높이던지(AP), 잠시 요청 처리를 중단하고 재실행될 때까지 기다려 가용성 희생하고 일관성을 지키던지(CP)
절대적이지는 않다. 최근 틀렸다는 지적도 존재하여 새로운 이론도 나옴. 참고로 몽고디비와 레디스는 CP, 아파치 카산드라의 경우 AP..
 
 

# 7 MySQL의 트랜잭션 격리수준에 대해 설명해주세요. 

 
MySQL은 Repeatable READ라는 트랜잭션 격리수준을 기본 옵션으로 사용하고 있습니다. 트랜잭션이 시작되기 전 커밋된 내역에 대해서만 조회하고, 다른 사용자는 트랜잭션 영역 수정이 불가능합니다. 단, 새로운 레코드 삽입은 허용하기 때문에 없던 데이터가 새롭게 나타나는 Phantom Read 문제가 있습니다. 
* 트랜잭션 격리수준 ? : 동시에 여러 트랜잭션이 처리 될 때, 다른 트랜잭션에 변경한 데이터를 볼 수 있도록 허용할지 말지, 그 격리 수준을 결정하는 것
 
READ UNCOMMITTED
= 어떤 트랜잭션의 변경 내용이 Commit, Rollback 상관없이  다른 트랜잭션에게 보인다. 
-> 데이터의 일관성을 유지하는 것이 불가능함
-> DirtyRead 문제 ( 아직 실행이 끝나지 않은 다른 트랜잭션에 의한 변경사항을 보게 됨 ) 
 
READ COMMITTED
-> 커밋이 이루어진 트랜잭션만 조회 가능, 오라클의 기본 격리수준 
-> non repeatable read 문제 (한 트랜잭션 내에서 같은 쿼리 두 번 수행시 그 사이 다른 트랜잭션이 수정해버리면 동일 쿼리에 대한 결과가 다르게 나오는, 일관성이 깨진 현상) 
 
REPEATABLE READ
-> 트랜잭션이 시작되기 전 커밋된 내용에 대해서만 조회, 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 불가능, mysql 
- Phantom Read 문제 ( 트랜잭션 도중 수정은 불가능하지만 새로운 레코드 삽입은 가능하므로 처음엔 없던 데이터가 나중에 다시 생기는 현상)
 
SERIALIZABLE
-> 완벽한 읽기 일관성 모드, 트랜잭션에 해당되는 데이터 수정 / 입력 작업이 모두 제한된다.
 
 

#8 HashMap, HashTable 차이가 무엇인가요? 

HashMap		HashTable
안전하지 않음	thread - safe	안전
허용	key에 null값 허용?	허용하지 않음
제공하지 않음	not-fail Enumeration 제공 여부	반복자 생성 후 hashtable 수정시(새로운 데이터 넣거나 기존꺼 삭제하거나) 바로 예외 던져줌
사용	보조해시 함수 사용 여부	사용 X

* hashmap의 경우 not-fail enumeration 제공하지 않아서 반복문 중간에 자료 하나 remove 해도 예외가 발생하지 않는다. (버그 발견 못할 확률이 존재, 인텔리제이에서는 suspicious 하다고 알려주긴 한다.)
* 보조 해시 함수 : key의 해시값을 변형하여 해시 충돌 가능성 줄이는 것 
* 두 자료구조 모두 Map의 형태를 따른다. (key - value 구성)
 
추가 참고

https://github.com/wjdrbs96/Today-I-Learn/blob/master/Java/Collection/Map/Java%20HashMap%20동작원리.md

 

# 9 Object 클래스에서 객체를 처리하기 위해 제공하는 메소드는 어떤 것들이 있나요? 

protected Object clone() // 객체의 복사본을 만들어 리턴
public boolean equals(Object obj)
protected void finalize() // gc에 의해 호출되는 메소드, 사용하지 말기 
public Class<?> getClass()

public int hashCode() // 객체에 대한 해시 코드 값 리턴.

public String toString() // 객체를 문자열로 표현하는 값 리턴. 
// 실제 구현되어있는 메소드는 getClass().getName() + '@' + Integer.toHexString(hashCode())

 
 
 

# 10 hashCode 메소드 오버라이딩 시 따라야 하는 규칙에는 무엇이 있나요? 

• 자바 어플리케이션이 수행되는 동안 어떤 객체에 대해 이 메소드가 호출될 때에는 항상 동일한 int 값 리턴해줘야 함 / 대신 자바 프로그램 실행할 때마다 같은 값일 필요는 없음.
• equals() 메소드 통해 비교한 값이 true라면, hashCode() 메소드 호출시에도 동일한 int값이 나와야 한다
• equals() 메소드가 false를 리턴했다고 해서 hashCode() 호출한 int 값이 무조건 달라야 할 필요는 없으나, 서로 다른 int 값을 제공하는 것이 성능상 도움이 된다. 

* 따라서 직접 작성하기 보다는 intelliJ, Eclipse 등의 개발툴에서 자동 생성해주는 기능 사용하는 것이 좀 더 권장.. 
 
 
 
 

https://d2.naver.com/helloworld/407507
https://stricky.tistory.com/323
https://webstone.tistory.com/50