■ AES 암호화 기법 MySQL에서 제공하는 암호화 기법은 여러가지가 있습니다. https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html 그중에 키를 이용한 AES 암호화 기법이 있습니다. 이것에 대해 한번 알아보겠습니다. 이 암호화 기법은 AES 암호 알고리즘(Advanced Encryption Standard)이라고 합니다. 다음을 참고하시면 자세한 내용을 확인해 보실 수 있습니다. https://namu.wiki/w/AES ■ 암호화 설정 암호화 방식은 서버 변수로 설정을 합니다. 이 설정 방법에 따라 강력한 암호화를 설정할 수 있습니다. 대신 그만큼 성능이 낮아지는것은 참고하셔야 합니다. 서버변수중 block_encryption_mod..
■ SHOW ENGINE 명령어 사용법 SHOW ENGINE engine_name {STATUS | MUTEX} SHOW ENGINE은 스토리지 엔진에 대한 운영 정보를 표시합니다. PROCESS 권한이 필요합니다. 이 문장에는 다음과 같은 다양한 방법이 있습니다. SHOW ENGINE INNODB STATUS SHOW ENGINE INNODB MUTEX SHOW ENGINE PERFORMANCE_SCHEMA STATUS SHOW ENGINE INNODB STATUS 표시는 InnoDB 스토리지 엔진의 상태에 대한 표준 InnoDB 모니터의 광범위한 정보를 표시합니다. InnoDB 모니터 바로가기 SHOW ENGINE INNODB MUTEX는 InnoDB 뮤텍스 및 rw-lock 통계를 표시합니다. SH..
■ Prepared 명령(Prepared Statement) • PREPARE Statement • EXECUTE Statement • DEALLOCATE PREPARE Statement MySQL 5.7은 server-side prepared statements을 지원합니다. 이 지원은 효율적인 클라이언트 / 서버 바이너리 프로토콜을 활용합니다. 매개 변수 값에 자리 표시 자와 함께 prepared statements을 사용하면 다음과 같은 이점이 있습니다. + 실행될 때마다 명령문을 구문 분석하기위한 오버 헤드가 줄어 듭니다. 일반적으로 데이터베이스 응용 프로그램은 쿼리 및 삭제 WHERE, 업데이트 SET 및 삽입 VALUES와 같은 절의 리터럴 또는 변수값만 변경하여 대량의 거의 동일한 명령문을 ..
머리말 DB2의 세계로 막 진입한 DBA나 앞으로 DBA가 될 사람들에게는 새로운 데이터베이스를 위한 디자인과 퍼포먼스를 선택하기란 매우 어렵다. 이 글에서, DBA에게 있어 중요한 두 가지 영역에 대해 살펴보기로 한다. 바로 테이블 공간과 버퍼 풀이다. 테이블 공간과 버퍼 풀을 어떻게 디자인 하는냐, 또 어떻게 튜닝하느냐에 따라 DB2 Server의 성능에 큰 영향을 줄 수 있기 때문에 테이블 공간과 버퍼 풀의 디자인과 튜닝에 초점을 맞추어 설명하도록 한다. 예제는 DB2 version 8.1, Enterprise Server Edition을 기준으로 한다. 예제 대부분은 이전 버전에도 적용된다. version 8.1에만 적용될 경우 별도로 알려주겠다. Section 1에서는 DB2가 테이블 공간 Ty..
■ KILL 명령어 KILL [CONNECTION | QUERY] processlist_id mysqld에 대한 각 연결은 별도의 스레드에서 실행됩니다. KILL processlist_id 문으로 스레드를 강제 종료 할 수 있습니다. 스레드 프로세스 목록 식별자는 INFORMATION_SCHEMA PROCESSLIST 테이블의 ID 컬럼, SHOW PROCESSLIST 출력의 ID컬럼 및 성능 스키마 스레드 테이블의 PROCESSLIST_ID 컬럼에서 확인할 수 있습니다. 현재 스레드의 값은 CONNECTION_ID () 함수에 의해 리턴됩니다. KILL은 선택적 CONNECTION 또는 QUERY 수정자를 허용합니다. + KILL CONNECTION은 수정자가 없는 KILL과 같습니다. 연결이 실행중인..
■ Flush 명령문 FLUSH [NO_WRITE_TO_BINLOG | LOCAL] { flush_option [, flush_option] ... | tables_option } flush_option: { BINARY LOGS | DES_KEY_FILE | ENGINE LOGS | ERROR LOGS | GENERAL LOGS | HOSTS | LOGS | PRIVILEGES | OPTIMIZER_COSTS | QUERY CACHE | RELAY LOGS [FOR CHANNEL channel] | SLOW LOGS | STATUS | USER_RESOURCES } tables_option: { TABLES | TABLES tbl_name [, tbl_name] ... | TABLES WITH READ..
애플리케이션의 동시성이 높은 테이블과 연결된 인덱스에서 높은 인덱스 리프 블록 경합을 볼 수 있습니다. 이것은 일반적으로 응용 프로그램이 많은 INSERT 및 DELETE를 수행 할 때 발생합니다. 그 이유는 인덱스에 새 행을 삽입하는 동안 인덱스 블록이 분할되기 때문입니다. 트랜잭션은 블록 분할을 수행하는 세션이 작업을 완료할 때까지 모드 4에서 TX 잠금을 기다려야합니다. ■ 이유 애플리케이션에서 많이 액세스되는 테이블의 인덱스입니다. 단조 증가하여 삽입 된 값이있는 테이블 열의 인덱스입니다. 대량으로 삭제된 테이블 ■ 인덱스 리프 블록 경합 감지 핫 인덱스를 찾는 방법에는 여러 가지가 있습니다. • AWR 보고서에서 높은 "enq : TX – 인덱스 경합"시스템 대기 확인 • 동시에 AWR 보고서의..