DATA 전문가로 가는 길

[MySQL/MariaDB] 대용량 페이징 처리 활용 방안(Pagination, 커버링 인덱스)

EstenPark — Tue, 21 Jul 2020 14:17:21 +0900

대용량 테이블에서 페이징 처리 시 맨 뒤쪽으로 갈수록 느려지는 현상을 보실 수 있습니다. 그러한 이유는 어느 순간까지는 인덱스를 활용해서 결과를 출력 가능 하지만, MySQL/MariaDB에서는 filesort가 발생하면서 성능 저하가 발생합니다.

옵티마이저는 정렬을 위해 인덱스 사용이 가능한지 확인하고, 가능하다면 'Filesort' 과정 없이 인덱스 순으로 결과를 반환하게 됩니다. 인덱스를 사용할 수 없다면 WHERE 조건에 일치하는 레코드를 검색해 정렬 버퍼에 저장하면서 정렬 처리(Filesort)를 합니다. Order by, Group By를 처리할 때 인덱스를 처리하지 못할 경우에는 filesort 알고리즘을 통해 정렬하게 됩니다.

Data -> Sort Buffer -> Temp File -> Result File -> Read Random Buffer

1. 테스트 환경

OS : CentOS 7.5(CPU : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz(4 core), Memory : 32GB)
DB : MariaDB 10.3.8
Parameter :
innodb_buffer_pool_size =15G
sort_buffer_size = 1048576
innodb_sort_buffer_size = 1048576
max_length_for_sort_data = 1024
read_rnd_buffer_size = 8388608

Table 및 인덱스 정보 :
EST_USER_CONN_LOGIN 전체 건수 : 2000546

EST_USER_CONN_LOGIN Primary Key
  - USER_CONN_HIST_SEQ_NO, type=int(9), auto_increment
EST_USER_CONN_LOGIN_IX02 인덱스 (결합 인덱스)
  - USER_LOGIN_DTTM, type=datetime
  - USER_LOGIN_RST_TP_CODE, type=varchar

2. 일반적인 페이징 쿼리

약 200만 건 테이블에서 뒤쪽에 있는 데이터를 추출하려고 할 때 상당히 오래 걸리는 것을 보실 수 있습니다. 그 이유는 인덱스를 제대로 사용하지 못하고, 데이터 블록을 정렬해서 가져오기 때문입니다.

SELECT    A.USER_LOGIN_DTTM, A.USER_ID, A.USER_NM
FROM      EST_USER_CONN_LOGIN A
ORDER BY  A.USER_LOGIN_DTTM
LIMIT     0, 10    /* 앞쪽 데이터를 엑세스 할 경우 속도 영향 없습니다. */
;

수행 시간 : 2ms

SELECT    A.USER_LOGIN_DTTM, A.USER_ID, A.USER_NM
FROM      EST_USER_CONN_LOGIN A
ORDER BY  A.USER_LOGIN_DTTM
LIMIT     2000536, 10 /* 맨 뒤쪽 데이터를 엑세스 할 경우 속도 지연 현상이 발생 합니다.*/
;

수행 시간 : 1m 44s

ANALYZE   FORMAT=JSON 결과
{
  "query_block": {
    "select_id": 1,
    "r_loops": 1,
    "r_total_time_ms": 3347.9,
    "read_sorted_file": {
      "r_rows": 2e6,
      "filesort": {                       ->> Filesort 발생!!
        "sort_key": "A.USER_LOGIN_DTTM",
        "r_loops": 1,
        "r_total_time_ms": 2968.6,
        "r_limit": 2000546,
        "r_used_priority_queue": false,
        "r_output_rows": 2000546,
        "r_sort_passes": 84,
        "r_buffer_size": "1023Kb",
        "table": {
          "table_name": "A",
          "access_type": "ALL",
          "r_loops": 1,
          "rows": 1950976,
          "r_rows": 2e6,
          "r_total_time_ms": 693.89,
          "filtered": 100,
          "r_filtered": 100
        }
      }
    }
  }
}

3. 튜닝한 페이징 쿼리(Covering Index)

Covering Index(커버링 인덱스)를 활용해서 대용량 데이터를 처리하는 방법으로 성능을 높일 수 있습니다.
커버링 인덱스는 데이터를 인덱스에서만 추출할 수 있는 인덱스를 의미하며, B-Tree 스캔만으로 원하는 데이터를 가져올 수 있습니다.(데이터 블록 사용 안 함)

SELECT    B.USER_LOGIN_DTTM, B.USER_ID, B.USER_NM
FROM      (
          SELECT    A.USER_CONN_HIST_SEQ_NO
          FROM      EST_USER_CONN_LOGIN A
          ORDER BY  A.USER_LOGIN_DTTM
          LIMIT     2000536, 10
          ) A
          STRAIGHT_JOIN EST_USER_CONN_LOGIN B ON (A.USER_CONN_HIST_SEQ_NO = B.USER_CONN_HIST_SEQ_NO)
          ;

수행 시간 : 389ms

ANALYZE   FORMAT=JSON 결과
{
  "query_block": {
    "select_id": 1,
    "r_loops": 1,
    "r_total_time_ms": 0.067,
    "table": {
      "table_name": "",
      "access_type": "ALL",
      "r_loops": 1,
      "rows": 10,
      "r_rows": 10,
      "r_total_time_ms": 0.0026,
      "filtered": 100,
      "r_filtered": 100,
      "materialized": {
        "query_block": {
          "select_id": 2,
          "r_loops": 1,
          "r_total_time_ms": 0.0261,
          "table": {
            "table_name": "A",
            "access_type": "index",
            "key": "EST_USER_CONN_LOGIN_IX02",
            "key_length": "10",
            "used_key_parts": ["USER_LOGIN_DTTM", "USER_LOGIN_RST_TP_CODE"],
            "r_loops": 1,
            "rows": 1950976,
            "r_rows": 10,
            "r_total_time_ms": 0.0157,
            "filtered": 100,
            "r_filtered": 100,
            "using_index": true
          }
        }
      }
    },
    "table": {
      "table_name": "B",
      "access_type": "eq_ref",
      "possible_keys": ["PRIMARY"],
      "key": "PRIMARY",
      "key_length": "4",
      "used_key_parts": ["USER_CONN_HIST_SEQ_NO"],
      "ref": ["A.USER_CONN_HIST_SEQ_NO"],
      "r_loops": 10,
      "rows": 1,
      "r_rows": 1,
      "r_total_time_ms": 0.0201,
      "filtered": 100,
      "r_filtered": 100
    }
  }
}

Covering Index를 사용하기 전에는 100000건부터 10건을 가져올 때 "Filesort"가 발생했지만, Covering Index를 활용하게 되면 "Using Index"를 확인할 수 있습니다.

가장 마지막에 존재하는 데이터를 가져올 때 1m 44s에서 389ms로 단축된 것을 보실 수 있습니다. 결과적으로 Primary Key를 가져와서 인덱스 접근만으로 데이터를 가져올 수 있게 한 것이 큰 효과를 보게 되었습니다.

4. 데이터 범위

아래 내용은 화면 기획자, 개발 담당자와 긴밀한 협업이 필요한 내용입니다. 데이터 모델링을 할 때 데이터의 범위를 미리 생각해서 인덱스를 활용하는 방법입니다. 전체를 대상으로 데이터를 가져오는 경우는 많이 적기 때문에 화면을 통해서 제어를 한다면 전체 데이터 200만 건을 모두 확인할 필요 없이 적절한 범위 내에서 데이터를 가져올 수 있습니다. 조회 조건에서 기간을 3개월만 조회 가능하도록 정의하면 아래처럼 WHERE 조건절에 범위를 줄일 수 있습니다. 커버링 인텍스를 활용한다고 해도 데이터 양이 늘어날수록 조금씩 느려지게 되는데 아래와 같이 범위를 정하게 되면 동일한 속도를 유지할 수 있습니다.

최종적으로는 55ms로 줄이게 되었습니다.

SELECT    B.USER_LOGIN_DTTM, B.USER_ID, B.USER_NM
FROM      (
          SELECT    A.USER_CONN_HIST_SEQ_NO
          FROM      EST_USER_CONN_LOGIN A
          WHERE     A.USER_LOGIN_DTTM BETWEEN STR_TO_DATE( CONCAT('20200201', '00:00'), '%Y%m%d%H:%i')   /* 조회 조건 활용 */
                                      AND STR_TO_DATE(CONCAT('20200430', '23:59'),'%Y%m%d%H:%i')
          ORDER BY  A.USER_LOGIN_DTTM
          LIMIT     200000, 10
          ) A
          STRAIGHT_JOIN EST_USER_CONN_LOGIN B ON (A.USER_CONN_HIST_SEQ_NO = B.USER_CONN_HIST_SEQ_NO)
          ;

수행 시간 : 55ms

5. ROW_COUNT( ), FOUND_ROWS( ) 적절한 활용

목록을 보여주는 화면의 경우 현재 건수/전체 건수와 같이 표현하는 경우가 많은데 그럴 때 전체 조회건수를 동작하기 위해서 같은 쿼리를 COUNT(*) 함수를 활용해서 실행하게 되면 비효율이 발생할 수 있습니다.
그러한 부분을 개선해주기 위해서 ROW_COUNT( ), FOUND_ROWS( ) 적절히 사용해도 좋습니다..

FOUND_ROWS() 함수는 SELECT 수행 후 결과를 리턴 받으며,
ROW_COUNT() 함수는 DML(Delete, Update, Insert) 문장을 수행 시 결과를 리턴합니다.

6. 결론

MySQL/MariaDB에서 대용량 데이터를 페이징 할 때는 커버링 인덱스를 적극적으로 활용하고, 화면 기획 담당자, 개발 담당자 협업을 통해서 조건에 대한 범위를 줄이고자 노력한다면 데이터가 늘어나도 동일한 속도를 유지할 수 있습니다. 전체 건수를 활용할 때는 ROW_COUNT( ), FOUND_ROW( ) 활용해보는 것도 좋습니다.

7. 참고

[MySQL/MariaDB] 불필요한 Table Access와 인덱스 컬럼 변형에 대한 튜닝 사례

EstenPark — Fri, 10 Jul 2020 10:42:23 +0900

MySQL/MariaDB에서는 UPDATE 실행 계획을 볼 수 없습니다. 그래서 UPDATE 문법을 SELECT 문법으로 변경해서 실행 계획을 확인해야 합니다. 주기적으로 수행(매 10초)하는 쿼리라서 최대한 Sending data를 줄이지 않으면 성능에 문제가 발생할 수 있었습니다. 개발자가 작성한 쿼리를 튜닝한 사례입니다.

아래는 EST_DB_SVC_CPS 테이블의 인덱스 정보입니다.

Primary Key : EST_NO, EST_SVC_NO
Non Unique Index : CONN_TEST_TASK_UPDT_DTTM

1. 원본 쿼리

1.1. 실행 계획 해석
실행계획을 보면 "EST_DB_SVC_CPS" 테이블을 Table Full Scan 하고 있습니다.(type=ALL)
처음 조인하는 테이블에서 다음 읽어야 할 테이블의 Primary Key, Unique Key 컬럼을 사용해서 두 번째 테이블에서 출력되는 레코드가 1건으로 판단합니다.(type=eq_ref)

1.2. 성능 문제점
EST_DB_SVC_CPS 테이블을 두번 액세스 하는 비효율이 발생했습니다.
"DATE_ADD(SQ2.CONN_TEST_TASK_UPDT_DTTM , INTERVAL + 180 SECOND )"인덱스 컬럼을 변경하면서 적절하게 인덱스를 사용할 수 없었습니다.

/* UPDATE 원본 쿼리 */
UPDATE    EST_DB_SVC_CPS A
SET       A.CONN_TEST_TASK_GRP_NO = NULL
WHERE     EXISTS
            (SELECT    'O'
             FROM      (SELECT    SQ2.EST_NO, SQ2.EST_SVC_NO
                        FROM      EST_DB_SVC_CPS SQ2
                        WHERE     SQ2.CONN_TEST_TASK_GRP_NO IS NOT NULL
                        AND       DATE_ADD(SQ2.CONN_TEST_TASK_UPDT_DTTM , INTERVAL + 180 SECOND ) < CURRENT_TIMESTAMP() ) SQ1 
             WHERE     SQ1.EST_NO = A.EST_NO
             AND       SQ1.EST_SVC_NO = A.EST_SVC_NO);

/* 튜닝을 위해서 SELECT로 변경한 원본 쿼리 */
EXPLAIN   EXTENDED 
SELECT    A.CONN_TEST_TASK_GRP_NO
FROM      EST_DB_SVC_CPS A
WHERE     EXISTS
            (SELECT    'O'
             FROM      (SELECT    SQ2.EST_NO, SQ2.EST_SVC_NO
                        FROM      EST_DB_SVC_CPS SQ2
                        WHERE     SQ2.CONN_TEST_TASK_GRP_NO IS NOT NULL
                        AND       DATE_ADD(SQ2.CONN_TEST_TASK_UPDT_DTTM , INTERVAL + 180 SECOND ) < CURRENT_TIMESTAMP() ) SQ1 
             WHERE     SQ1.EST_NO = A.EST_NO
             AND       SQ1.EST_SVC_NO = A.EST_SVC_NO);
          
id|select_type|table|type  |possible_keys                    |key    |key_len|ref                                |ROWS  |filtered|Extra      |
--|-----------|-----|------|---------------------------------|-------|-------|-----------------------------------|------|--------|-----------|
 1|PRIMARY    |A    |ALL   |PRIMARY,EST_DB_SVC_CPS_FK01      |       |       |                                   | 12041|     100|           |
 1|PRIMARY    |SQ2  |eq_ref|PRIMARY,EST_DB_SVC_CPS_FK01      |PRIMARY|8      |ESTDB.A.EST_NO,ESTDB.A.EST_SVC_NO  |   1  |     100|Using where|

MariaDB [ESTDB]> show profile for query 4;
+------------------------+----------+
| Status                 | Duration |
+------------------------+----------+
| Starting               | 0.000050 |
| Checking permissions   | 0.000014 |
| Opening tables         | 0.000012 |
| After opening tables   | 0.000013 |
| System lock            | 0.000004 |
| Table lock             | 0.000005 |
| Init                   | 0.000046 |
| Optimizing             | 0.000030 |
| Statistics             | 0.000027 |
| Preparing              | 0.000017 |
| Executing              | 0.000012 |
| Sending data           | 0.081115 |   ->> 해당 항목을 줄이는 게 튜닝 목표
| End of update loop     | 0.000014 |
| Query end              | 0.000004 |
| Commit                 | 0.000006 |
| Closing tables         | 0.000003 |
| Removing tmp table     | 0.000005 |
| Closing tables         | 0.000004 |
| Unlocking tables       | 0.000003 |
| Closing tables         | 0.000018 |
| Starting cleanup       | 0.000003 |
| Freeing items          | 0.000027 |
| Updating status        | 0.000015 |
| Reset for next command | 0.000011 |
+------------------------+----------+
24 rows in set (0.000 sec)

2. 쿼리 튜닝

불필요한 테이블 엑세스를 줄이고, 인덱스 컬럼 부분을 변형하지 않고, 대입되는 컬럼을 상수 부분에 적용합니다.

EXPLAIN   EXTENDED
SELECT    A.CONN_TEST_TASK_GRP_NO
FROM      EST_DB_SVC_CPS A
WHERE     A.CONN_TEST_TASK_UPDT_DTTM < DATE_ADD(CURRENT_TIMESTAMP() , INTERVAL - 180 SECOND )
AND       A.CONN_TEST_TASK_GRP_NO IS NOT NULL

id|select_type|table|type |possible_keys            |key                      |key_len|ref|rows|filtered|Extra                             |
--|-----------|-----|-----|-------------------------|-------------------------|-------|---|----|--------|----------------------------------|
 1|SIMPLE     |A    |range|EST_DB_SVC_CPS_IX01|EST_DB_SVC_CPS_IX01            |5      |   | 450|     100|Using index condition; Using where|
 
MariaDB [ESTDB]> show profile for query 7;
+------------------------+----------+
| Status                 | Duration |
+------------------------+----------+
| Starting               | 0.000036 |
| Checking permissions   | 0.000005 |
| Opening tables         | 0.000011 |
| After opening tables   | 0.000004 |
| System lock            | 0.000004 |
| Table lock             | 0.000005 |
| Init                   | 0.000012 |
| Optimizing             | 0.000009 |
| Statistics             | 0.000008 |
| Preparing              | 0.000010 |
| Executing              | 0.000003 |
| Sending data           | 0.017332 |  ->> 튜닝 전(0.081115), 튜닝 후 (0.017332)
| End of update loop     | 0.000005 |
| Query end              | 0.000003 |
| Commit                 | 0.000004 |
| Closing tables         | 0.000003 |
| Unlocking tables       | 0.000003 |
| Closing tables         | 0.000005 |
| Starting cleanup       | 0.000003 |
| Freeing items          | 0.000005 |
| Updating status        | 0.000122 |
| Reset for next command | 0.000019 |
+------------------------+----------+
22 rows in set (0.000 sec)

/* 최종 UPDATE 튜닝 쿼리 */
UPDATE    EST_DB_SVC_CPS A
SET       A.CONN_TEST_TASK_GRP_NO = NULL
WHERE     A.CONN_TEST_TASK_UPDT_DTTM < DATE_ADD(CURRENT_TIMESTAMP() , INTERVAL - 180 SECOND )
AND       A.CONN_TEST_TASK_GRP_NO IS NOT NULL
;

3. 결과

보통 날짜 데이터에 대해서 쿼리를 작성 할 때 컬럼을 변경해서 대입하는 경우가 상당히 많습니다. 그렇게 작성하는 것보다 인덱스 컬럼은 최대한 변경하지 않은 상태에서 상수 값을 대입하면 인덱스를 적절하게 사용 가능합니다.

그리고 테이블을 여러 번 액세스 해야 하는 경우가 아니라면, 테이블을 한 번만 액세스 해서 성능을 최적화하는 것이 좋습니다.

[Admin] MySQL/MariaDB 대용량 데이터 마이그레이션 성능 비교(CTAS, mysqldump, INTO OUTFILE~LOAD DATA LOCAL INFILE)

EstenPark — Thu, 9 Jul 2020 12:23:58 +0900

MySQL/MariaDB에서 대용량 데이터를 이관하기 위해서 다양한 방법이 존재합니다. 저는 그중에서 전통적인 방식 CTAS와 mysqldump 유틸리티 그리고 INTO OUTFILE LOAD DATA LOCAL INFILE입니다. 대용량 데이터를 빠르게 이관할 때 유용하게 사용 가능합니다. 다만, 서비스를 운영하는 시점에 적용하는 게 아니라 점검 시간이나 다운타임이 발생할 때 가능합니다.

1. 테스트 환경

OS : CentOS 7.5(CPU : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz(4 core), Memory : 32GB)

DB : MariaDB 10.3.8

Parameter :

innodb_buffer_pool_size =15G
innodb_flush_log_at_trx_commit=0
sync_binlog=0
tx_isolation=READ-COMMITTED

innodb_flush_log_at_trx_commit는 장애 시 commit이 완료된 트랜잭션이 유실되는 것을 방지하기 위해 필요한 파라미터인데 성능을 높이기 위해서는 0으로 설정하여 매 트랜잭션 commit마다 InnoDB log를 디스크로 sync하지 않도록 해줍니다.
sync_binlog를 0으로 세팅하면 binary log flush를 OS가 알아서 하게 하므로 성능을 높일 수 있습니다
innodb_support_xa는 InnoDB log와 binary log의 일관성을 보장하기 위해서 필요하다고 하는데 여기서는 필요 없기 때문에 0으로 설정하였습니다.
MySQL의 Transaction Isolation Level 기본 값은 REPEATABLE READ입니다. 하지만 이를 보장하기 위해서 Gap Lock을 사용하는데 이를 피하려면 Transaction Isolation Level을 READ COMMITTED나 READ-UNCOMMITTED로 변경하면 됩니다.

2. CTAS(Create Table As Select)

OLDDB 데이터베이스에서 ESTDB 데이터베이스로 동일한 테이블을 옮겨보도록 하겠습니다. CTAS 데이터를 옮기게 되면 테이블 기본적인 스키마(PK, FK, UK, INDEX 제외)를 생성하고, 데이터를 이관하게 됩니다.

MariaDB [(none)]> CREATE DATABASE ESTDB;
Query OK, 1 row affected (0.021 sec)

MariaDB [ESTDB]> CREATE TABLE LARGE_DB_INSPT AS
    -> SELECT * FROM OLDDB.LARGE_DB_INSPT;
Query OK, 1858594 rows affected (20.309 sec)
Records: 1858594  Duplicates: 0  Warnings: 0     ->> 데이터 이관 완료

OLDDB 데이터베이스 LARGE_DB_INSPT 테이블에서 있었던 Primary Key를 생성합니다. 대용량 테이블일 경우 ALTER 문법을 진행할 때는 반드시 여러 번 고민해보고 적용하시기 바랍니다.

MariaDB [ESTDB]> ALTER TABLE LARGE_DB_INSPT ADD PRIMARY KEY (SOLT_INSPT_ID, INSPT_EVENT_ID, EQMT_IP);
Connection id:    1338530
Current database: ESTDB

Query OK, 0 rows affected (2 min 30.731 sec)
Records: 0  Duplicates: 0  Warnings: 0            ->> 정상적으로 PK 생성 완료

3. mysqldump(mysqldump Ver 10.16 Distrib 10.3.8-MariaDB)

mysqldump 유틸리티에서 데이터 백업할 때 필요한 옵션에 대해서 정리해보겠습니다.

--no-autocommit=1 : autocommit을 끄고 개의 테이블 입력 완료 후 commit 수행, 오류 발생 시 다시 처음부터 시작합니다.
--single-transaction=1 : 작업 후에 변경된 데이터의 내역을 다시 적용하지 않습니다.
--extended-insert=1 : INSERT 구문이 늘어나는 것을 차단합니다.

time 명령어를 활용해서 수행 시간을 확인합니다. 작업이 완료되면 습관적으로 tail -1으로 파일을 확인해보면 "Dump completed on 2020-07-08 15:57:00"으로 나오게 됩니다. head 명령어로 앞쪽 스크립트를 확인하는 것도 권장합니다.

[estdbusr@estsvr01 sspark]$ 
time mysqldump -hlocalhost -uroot -proot --databases OLDDB \
--tables LARGE_DB_INSPT --no-autocommit=1 --single-transaction=1 --extended-insert=1 \
> LARGE_DB_INSPT.sql

real    0m3.324s
user    0m2.344s
sys     0m0.169s

이제 데이터를 복원해보겠습니다. 여기에서 작업을 시작하기 전에 MySQL/MariaDB 글로벌 파라미터를 변경해서 성능을 높여 줍니다.

SET global net_buffer_length=1000000;
SET global max_allowed_packet=1000000000;
SET foreign_key_checks = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;

[estdbusr@estsvr01 sspark]$ 
time mysql -hlocalhost -uroot -proot ESTDB < LARGE_DB_INSPT.sql

real    1m4.211s
user    0m2.491s
sys     0m0.114s

데이터 복원을 정상적으로 마쳤을 경우에는 아래와 같이 파라미터 설정을 다시 변경합니다.

SET foreign_key_checks = 1;
SET UNIQUE_CHECKS = 1;
SET AUTOCOMMIT = 1;

4. INTO OUTFILE LOAD DATA LOCAL INFILE

배치 프로세스 개발할 때 많이 사용하는 방법으로 개발할 때 유연성을 보장해주는 장점이 있습니다. 그리고 무엇보다 빠르게 데이터 마이그레이션을 할 수 있습니다. 하지만 단점은 파일 안에 있는 데이터에 특수문자를 제어해야 합니다. 만약에 "FIELDS TERMINATED BY '|'" 옵션을 사용했는데 파일안에 '|' 문자가 존재한다면 에러가 나서 동작하지 않습니다.

데이터를 백업해보겠습니다.

MariaDB [ESTDB]> 
SELECT    SOLT_INSPT_ID       
         ,INSPT_EVENT_ID      
         ,EQMT_IP             
         ,EQMT_HOST_NM        
         ,DB_DUPX_TP_CODE     
         ,SOLT_INSPT_RST_CODE 
         ,SOLT_INSPT_RST_CNTS 
         ,REG_USER_NO         
         ,REG_DTTM            
INTO OUTFILE '/home/estdbusr/sspark/LARGE_DB_INSPT.csv'
CHARACTER SET euckr
FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n'
FROM OLDDB.LARGE_DB_INSPT;
Query OK, 1861555 rows affected (4.903 sec)

데이터를 복원해보겠습니다.

MariaDB [ESTDB]> 
CREATE TABLE "LARGE_DB_INSPT" (
  "SOLT_INSPT_ID" varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ,
  "INSPT_EVENT_ID" varchar(20) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ,
  "EQMT_IP" varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ,
  "EQMT_HOST_NM" varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ,
  "DB_DUPX_TP_CODE" varchar(1) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL ,
  "SOLT_INSPT_RST_CODE" varchar(1) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ,
  "SOLT_INSPT_RST_CNTS" text CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL ,
  "REG_USER_NO" decimal(9,0) NOT NULL DEFAULT 1 ,
  "REG_DTTM" datetime NOT NULL DEFAULT current_timestamp() ,
  PRIMARY KEY ("SOLT_INSPT_ID","INSPT_EVENT_ID","EQMT_IP")
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4  


MariaDB [ESTDB]> 
LOAD DATA LOCAL INFILE '/home/estdbusr/sspark/LARGE_DB_INSPT.csv' 
INTO TABLE ESTDB.LARGE_DB_INSPT CHARACTER SET euckr FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
Query OK, 1862836 rows affected (23.350 sec)
Records: 1862836  Deleted: 0  Skipped: 0  Warnings: 0

"LINES TERMINATED BY '\r\n'" \r 옵션을 사용하면 아래와 같이 warnings이 발생 합니다.

MariaDB [ESTDB]> 
LOAD DATA LOCAL INFILE '/home/estdbusr/sspark/LARGE_DB_INSPT.csv' 
INTO TABLE ESTDB.LARGE_DB_INSPT CHARACTER SET euckr FIELDS TERMINATED BY '|' LINES TERMINATED BY '\r\n';
Query OK, 1 row affected, 1 warning (1.422 sec)
Records: 1  Deleted: 0  Skipped: 0  Warnings: 1

MariaDB [ESTDB]> show warnings;
+---------+------+-----------------------------------------------+
| Level   | Code | Message                                       |
+---------+------+-----------------------------------------------+
| Warning | 1265 | Data truncated for column 'REG_DTTM' at row 1 |
+---------+------+-----------------------------------------------+

5. 결과

데이터 이관 방식	수행 시간(ms)	CPU(4 Core)	건수	용량(size)
CTAS	2분 40초	40%	1,858,594	308 MB
mysqldump	1분 7초	90%
INTO OUTFILE LOAD DATA LOCAL INFILE	28초	170%

결과적으로는 속도는 INTO OUTFILE LOAD DATA를 활용하는 게 좋습니다. 하지만, 큰 용량에 따라서 성능 저하를 가져올 수 있습니다. 속도와 성능을 고려한다면 mysqldump를 활용하는 것을 권장합니다.

6. 참고

[Admin] MySQL/MariaDB AUTO_INCREMENT

EstenPark — Mon, 6 Jul 2020 13:16:26 +0900

1. Auto increment 란?

테이블 컬럼에 auto_increment를 설정하게 되면, 데이터가 삽입 되는 순간 자동으로 증가 됩니다. 데이터 타입은 INT, BIGINT를 주로 많이 사용 합니다. InnoDB 엔진의 경우 Primary Key 생성과 동시에 인덱스 사이즈에 영향을 주기 때문에 테이블 설계시 많이 권고 하는 방법 입니다. MySQL 5.7 이전 버전에서는 MyISAM 엔진의 경우 auto_increment 값이 파일에 저장 해서 관리 되는 반면, InnoDB 인젠의 경우 메모리 기반으로 관리 됩니다. MySQL 8.0 에서는 InnoDB 엔진의 테이블 정보 저장 공간에 auto_increment 카운터 정보를 보관 합니다.

주로 많이 활용되는 방법은 PK + auto_increment를 결합해서 사용 합니다.(아래 샘플 예제)

CREATE TABLE `EST_INFO` (
  `USER_NO` int(11) NOT NULL AUTO_INCREMENT,
  `USER_ID` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `USER_NM` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`USER_NO`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
;

2. Persistent Auto Increment Value

auto_increment의 초기화 방식은 MySQL 8.0에서 변경 되었습니다. 자동 증가 값이 변경될 때마다 redo log에 매번 기록하고, 각 체크포인트를 관리하는 스토리지 엔진의 시스템 테이블에 해당 내용을 저장하게 되었습니다. 그동안 문제가 되었던 InnoDB 엔진의 auto_increment 삭제 후 재시작 할 경우에 문제가 된 부분도 해결 되었습니다. Data Dictionary 시스템 테이블에 저장된 가장 큰 자동 증가값을 사용해 메모리의 auto_increment 카운터를 초기화 합니다.

MySQL 5.7 및 이전 버전에서 롤백 직후 서버를 다시 시작하면 롤백 된 트랜잭션에 할당된 자동 증가 값을 재사용 하지만, MySQL 8.0에서는 현재 최대 자동 증가 값이 유지되므로 이전에 할당된 값을 재활용 할 수 없게 됩니다.

2.1. Auto Increment 카운트 점검(MySQL 8.0.17)

EST_INFO 테이블을 생성하고 AUTO_INCREMENT를 1로 설정 합니다.

mysql> CREATE TABLE `EST_INFO` (
  `USER_NO` int(11) NOT NULL AUTO_INCREMENT,
  `USER_ID` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `USER_NM` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`USER_NO`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
;

EST_INFO 테이블에 3 row를 생성 후 auto_increment 증가된 상황을 확인 합니다.

mysql> INSERT INTO EST_INFO(USER_ID, USER_NM) values('user01', 'estenpark01');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO EST_INFO(USER_ID, USER_NM) values('user02', 'estenpark02');
Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO EST_INFO(USER_ID, USER_NM) values('user03', 'estenpark03');
Query OK, 1 row affected (0.01 sec)

mysql> SELECT  *  FROM EST_INFO;
+---------+---------+-------------+
| USER_NO | USER_ID | USER_NM     |
+---------+---------+-------------+
|       1 | user01  | estenpark01 |   >> auto_increment 1 증가
|       2 | user02  | estenpark02 |   >> auto_increment 2 증가
|       3 | user03  | estenpark03 |   >> auto_increment 3 증가
+---------+---------+-------------+

테스트를 위해서 EST_INFO 테이블에 모든 데이터를 삭제 하고, DDL 결과를 확인 합니다.

mysql> DELETE FROM EST_INFO;
Query OK, 3 rows affected (0.01 sec)

mysql> SELECT  *  FROM EST_INFO;
Empty set (0.00 sec)

mysql> show create table EST_INFO;
+----------+-------------------------------------------------------------------------------+
| Table    | Create Table                                                                  |
+----------+-------------------------------------------------------------------------------+
| EST_INFO | CREATE TABLE `EST_INFO` (
  `USER_NO` int(11) NOT NULL AUTO_INCREMENT,
  `USER_ID` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `USER_NM` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`USER_NO`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
+----------+-------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MySQL 서비스를 재 시작 합니다.

root@localhost /]# systemctl stop mysqld;
[root@localhost /]# systemctl start mysqld;

EST_INFO 테이블에 2 row를 생성 하게 되면, 이전 버전과 다르게 4, 5로 증가된 것을 확인 할 수 있습니다.

mysql> INSERT INTO EST_INFO(USER_ID, USER_NM) values('user04', 'estenpark04');
Query OK, 1 row affected (0.02 sec)

mysql> INSERT INTO EST_INFO(USER_ID, USER_NM) values('user05', 'estenpark05');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT  *  FROM EST_INFO;
+---------+---------+-------------+
| USER_NO | USER_ID | USER_NM     |
+---------+---------+-------------+
|       4 | user04  | estenpark04 |   >> auto_increment 4 증가(초기화 되지 않고 증가 됨)
|       5 | user05  | estenpark05 |   >> auto_increment 5 증가(초기화 되지 않고 증가 됨)
+---------+---------+-------------+

EST_INFO 테이블을 TRUNCATE(DDL 문법) 수행할 경우에는 초기화 된 결과가 나오게 됩니다..

mysql> TRUNCATE TABLE EST_INFO;
Query OK, 0 rows affected (0.04 sec)

mysql> INSERT INTO EST_INFO(USER_ID, USER_NM) values('user06', 'estenpark06');
Query OK, 1 row affected (0.00 sec)

mysql> select * from EST_INFO;
+---------+---------+-------------+
| USER_NO | USER_ID | USER_NM     |
+---------+---------+-------------+
|       1 | user06  | estenpark06 |   >> auto_increment 1 증가(초기화)
+---------+---------+-------------+

3. Auto Increment 결론

MySQL 5.7, MariaDB 10.1.12 버전은 데이터를 삭제하고, DB를 재시작 할 경우 초기화 된 정보가 나오게 되며, MySQL 8.0, MariaDB 10.3.8 버전은 데이터를 삭제하고, DB를 재 시작 한다고 해도 초기화 되지 않고 계속 증가하게 됩니다. 이러한 버전에 특성을 이해 하면 장애를 최소화 할 수 있습니다.

4. 참고

[Admin] MySQL/MariaDB Primary Key vs Unique Key

EstenPark — Thu, 2 Jul 2020 15:30:18 +0900

1. Primary Key 란

Primary Key는 데이터베이스 행을 고유하게 식별할 수 있는 습니다. 테이블 단일 컬럼으로 식별할 수 있고, 복합 컬럼으로 식별할 수 있는데 성능적으로는 단일 컬럼으로 생성해야 Clustered Index를 견고하게 사용 가능합니다. 또한 NULL을 허용하지 않으며, 데이터에 대한 일관성을 보장합니다. 데이터 중복이 발생하지 않아 빠르게 쿼리를 수행 가능합니다.

InnoDB engine기준으로 Primary Key는 항상 Clustered Index이며, Primary Key가 존재하지 않을 경우 Unique Key(Unique Index)를 선택하게 됩니다. 후보가 없을 경우 Auto_Increment 속성의 컬럼을 활용하게 되는데 이는 테이블에 Primary Key를 생성하지 않으면 시스템 적으로 고유값을 찾아서 그 값을 생성하게 됩니다.

2. Unique Key(Unique Index) 란

Unique Key는 데이터베이스 행을 고유하게 식별할 수 있는 구조는 동일하지만, NULL 허용하게 되면 중복된 데이터를 가질 수 있습니다. 대체적으로 논리적으로 보조 식별자를 구분하기 위해서 사용하게 되며, 테이블 기준으로 여러 개를 생성 가능합니다.

InnoDB 기준으로 Unique Key는 Non-Clustered Index입니다.

3. Primary Key와 Unique Key 차이점

Primary Key	Unique Key
테이블에 반드시 하나만 존재	테이블에 여러 개 존재 가능
NULL 허용 하지 않음	NULL 허용 가능
기본 Clustered Index	기본 Non-Clustered Index
데이터 무결성 보장	데이터 무결성 보장(NULL은 여러 개 존재 가능)
CREATE TABLE employee ( emp_no int PRIMARY KEY, name varchar(255), city varchar(150) ) ;	CREATE TABLE employee ( emp_no int PRIMARY KEY, emp_id int, name varchar(255), city varchar(150) ) ; CREATE UNIQUE INDEX employee_idx01 ON employee(emp_id);
제약 조건(constrainnt)	제약 조건 없음

4. Primary Key 반드시 필요한가?

데이터 모델링 관점

관계형 데이터베이스에서 릴레이션을 가지기 위해서는 반드시 필요합니다. 만약 부서와 사원 엔티티가 존재한다고 할 때 부서 엔티티에 식별자를 "부서 코드"를 사원 엔티티에서 부서 코드를 FK로 참조 가능합니다. 부서 엔티티에 식별자가 존재하지 않는다면 이렇게 릴레이션이 연결될 수 없게 됩니다.

데이터 관점

테이블에 Primary Key가 존재하지 않는다면 중복된 데이터로 인해 데이터 정제 작업이 필요하며, 각 컬럼에 값을 어떤 우선순위에 따라 결과를 추출해야 합니다. 데이터 품질 향상에 도움을 줄 수 있습니다.

성능 관점

Primary Key를 생성하게 되면 최소의 Cost를 사용할 수밖에 없습니다. MySQL, MariaDB의 InnoDB engine은 기본적으로 데이터를 저장할 때 인덱스를 활용하기 위해서 후보가 될 수 있는 Primary Key를 생성하게 됩니다. InnoDB engine은 Unique 값을 가진 컬럼을 찾아서 보이지 않는 Clustered Index를 만들게 됩니다.

동기화 관점(HA)

MHA는 데이터 동기화를 진행할 때 테이블 PK 기준으로 맞추게 됩니다. 또한 db compare 유틸리티를 할 때도 Primary Key 기준으로 양쪽 데이터를 비교해서 INSERT, UPDATE, DELETE를 추출하게 됩니다. 양쪽 데이터를 비교할 때 모든 컬럼을 기준으로 비교해서 데이터를 이관한다고 하면 그만큼 성능 저하가 발생하게 됩니다.

결론

Primary Key는 선택 사항이 아니라 필수 사항입니다.

5. Primary Key 조건

유일한 값을 가질 수 있는 컬럼
Null을 허용하지 않은 컬럼
데이터 변경이 발생하지 않은 컬럼
int, bigint datatype 형태 컬럼(auto_increment와 같이 순차적으로 생성)
업무적 유일한 컬럼(사원번호, 부서코드, 종목번호, 회원ID 등)

6. 참고

[Admin] MySQL/MariaDB Clustered vs Non-Clustered Index

EstenPark — Wed, 1 Jul 2020 13:57:09 +0900

1. 인덱스란?

인덱스는 테이블 또는 View에서 행을 가져오는 속도를 높이기 위해서 데이터베이스의 하나 이상의 열에서 작성된 키입니다. 이는 Oracle, SQL Server, MySQL, MariaDB 등과 같은 데이터베이스가 키 값과 관련된 행을 신속하게 찾을 수 있도록 합니다. Clustered Index, Non-Clustered Index 두 가지 형태로 나눠지게 됩니다. MySQL/MariaDB에서 Clustered Index를 사용할 수 있는 엔진은 InnoDB 뿐입니다. MyISAM, Memory, Archive NDB 엔진은 사용할 수 없습니다. InnoDB Buffer Pool 메모리에 존재하지 않을 경우 디스크에서 페이지를 가져오게 됩니다. 한번 가져온 페이지는 대부분은 InnoDB Buffer Pool에 존재합니다. 속도 관점에서는 최대한 디스크에서 페이지를 가져오는 것보다는 메모리에서 가져오는 게 좋을 수밖에 없습니다.

B+Tree Structure of a Clustered Index

2. Clustered Index 란?

클러스터 인덱스는 키 값에 대한 테이블의 데이터 행을 정렬하는 인덱스의 한 유형입니다. 데이터베이스에는 테이블당 클러스터 인덱스가 하나만 존재해야 합니다.

클러스터 인덱스는 테이블의 데이터를 정렬해서 저장되는 순서를 정의합니다. 따라서 테이블마다 클러스터링된 인덱스가 하나만 있습니다. RDBMS에서는 일반적으로 Primary Key를 사용하여 특정 열을 기반으로 클러스터링 된 인덱스를 만들 수 있습니다.

3. Non-Clustered Index 란?

Non-Clustered Index는 데이터와 인덱스를 각각 다른 위치에 저장합니다. 인덱스는 해당 데이터의 위치에 대한 포인터를 포함하고 있습니다. Non-Clustered Index의 인덱스가 서로 다른 위치에 저장되므로 단일 테이블에는 많은 Non-Clustered Index가 있을 수 있습니다.

예를 들면, 책 한권은 내용을 빠르게 찾기 위해서 보통 두 가지 이상의 색인을 가지게 됩니다. 앞쪽에는 "목차" 기준으로 정렬되어 있고, 뒤쪽에는 "찾아보기"와 같은 용어에 대한 알파벳 순으로 표시하는 것을 볼 수 있습니다. 책을 테이블이라고 하고 목차, 찾아보기를 Non-Clustered Index로 생각하면 이해가 될 수 있습니다.

4. Clustered Index와 Non-Clustered Index 차이점

Parameters	Clustered Index	Non-Clustered Index
Use For	물리적으로 행을 재배열	논리적으로 행을 재배열(물리적으로 데이터 파일 포인터 활용 하며 재배열은 안함)
Storing method	인덱스의 리프 노드에 데이터 페이지를 저장	인덱스의 리프 노드에 데이터 페이지 저장 안함
Size	용량 작다	용량 크다
Data accessing	Faster(빠름)	Clustered Index에 비해 느림
Additional disk space	필요하지 않음	인덱스를 별도로 지정하는 데 필요
Type of Key	기본적으로 테이블 Primary Key는 Clustered Index 사용	복합키 역할을 하는 데이블의 고유한 제약조건과 함께 사용
Main Feature	데이터 검색 속도 향상	조인에 사용되는 열에 생성
N per TABLE	테이블 당 1개	테이블 당 249개
engine	InnoDB	InnoDB

5. Clustered Index 장점/단점

5.1. 장점

Primary Key로 검색할 경우 성능 빠름
테이블의 모든 보조 인덱스가 Primary Key를 가지고 있기 때문에 인덱스만으로 처리 가능(커버링 인덱스)
MIN, MAX, COUNT 쿼리를 사용 하는 범위 또는 그룹에 성능 최적화
데이터의 특정 지점으로 바로 이동하거나 그 위치부터 순차적으로 읽기 가능
페이지 전송 최소화, 캐시 히트 최적화

5.2. 단점

정렬 되지 않은 데이터를 적재할 경우(PK를 컬럼을 선정할 때 Auto_increment와 유사한 정렬 순서를 보장하면 좋음)
INSERT, UPDATE, DELETE(DML) 시 추가 작업 증가
Clustered Index 필드가 변경 될 때 업데이트하는 데 시간 오래 걸림
리프 노드는 대부분 Clustered Index의 데이터 페이지를 포함

6. Non-Clustered Index 장점/단점

6.1. 장점

테이블에 여러 개의 인덱스를 생성 가능
Clustered Index Overhead 비용 최소화

6,2. 단점

논리적 순서로 데이터를 저장하는 데 도움을 주지만, 데이터 행을 물리적으로 정렬하지 안 함(물리적으로 I/O 발생)
검색할 때 많은 비용 발생
불필요한 디스크 사용량 증가

7. 주의 사항

Clustered Index 생성 시 Key에 대한 크기를 작게 해야 좋습니다. 따라서 인덱스 설계할 때 데이터 타입과 사이즈를 적절하게 사용하는 것을 권장 합니다.
테이블에 Primary Key를 반드시 명시합니다. 이는 HA 동기화를 할 때 내부적으로는 Primary Key로 Master Node에서 Slave Node로 데이터를 이관하게 됩니다. Clustered Index가 아니더라도 꼭 필요한 부분입니다.
테이블에 Non-Clustered Index를 여러 개 생성하게 되면, DML 작업에 취약하며, 시스템 성능 저하가 발생합니다. 꼭 필요한 인덱스를 추가해야 하며, 주기적으로 운영 DB에서 사용하지 않은 인덱스를 찾아서 제거하시기 바랍니다.

8. 참고

[Admin] ORA-30556 함수 기반 인덱스, 컬럼(타입) 사이즈 변경 에러

EstenPark — Fri, 20 Sep 2019 13:00:28 +0900

오라클 문법중에서 컬럼 사이즈 변경 할 때 "ALTER TABLE 테이블명 MODIFY (컬럼명 VARCHAR2(128))" 명령어로 변경 하게 됩니다. 일반적인 상황에서는 문제 없이 변경이 가능 하지만, 함수 기반 인덱스로 활용된 경우에는 아래와 같은 에러가 발생 합니다.

1. ORA Error

- EST_TABLE 테이블의 EST_TABLE_IDX02는 함수기반 인덱스는 "LOWER("USER_NM")"으로 되어있어서 일반적인 컬럼 속성 변경할 때 문제가 발생 할 수 있습니다. 에러는 아래를 참고 바랍니다.

/* SQL 쿼리 수행 */
ALTER TABLE EST_TABLE MODIFY USER_NM VARCHAR2(128);
/* SQL 쿼리 수행 후 에러 메시지 */
  -- ORA-30556: either functional or bitmap join index is defined on the column to be modified

2. 해결 방법

/* 에러가 발생한 함수 기반 인덱스를 제거 합니다. */
DROP INDEX EST_TABLE_IDX02;

/* EST_TABLE 테이블에서 USER_NM 컬럼 사이즈를 128 Byte로 변경 합니다. */
ALTER TABLE EST_TABLE MODIFY USER_NM VARCHAR2(128);

/* EST_TABLE 테이블 함수 기반 인덱스 추가 합니다. */
CREATE INDEX EST_TABLE_IDX02
 ON  EST_TABLE (
  LOWER("USER_NM") ASC
 )
 NOLOGGING
 TABLESPACE  EST_INDEX
;

3. 결론

결론은 함수기반 컬럼은 내장 함수, 직접 작성된 함수 모두 사용해서 인덱스를 만들었다면 컬럼 속성을 변경 할 때 인덱스를 제외 하고, 컬럼 속성을 변경하고, 다시 원래 인덱스를 생성해줘야 합니다.

[Admin] Oralce 파라미터 설정 자동 가이드(audit_trail, processes, archive log directory, _diag_daemon, memory_target)

EstenPark — Fri, 16 Aug 2019 12:13:26 +0900

오라클을 구축 후 운영단계에서 퍼포먼스 튜닝을 진행해야 합니다.

Oracle 11g 이상 또는 Single 설치에서만 진행 하시기 바라며, 파라미터는 반드시 백업 받고 진행 해주시기 바랍니다.
파라미터 적용 시 DB 종료가 필요하니 DB 종료 가능 여부도 같이 확인 하시기 바랍니다.

1. 주요 변경 사항

audit_trail
  - 주로 감사(Audition)에서 활용되며, 데이터베이스 작업을 모니터링, 기록을 수집하는 기능입니다.
  - 모든 추척 내용을 감사 로그로 기록하기 때문에 시스템의 속도를 저하 시킵니다.

processes
  - 프로세스를 변경하기 위해서 일반적으로 "processes" 파라미터 값을 변경 합니다.
  - 프로세스는 기본적으로 150으로 되어있지만, 운영 하다보면 점점 늘어나기 때문에 표준을 1000 기준으로 합니다.

log_archive_dest_1
   - archive log mode를 확인해서 Default Directory일 경우 변경 합니다.

_diag_daemon
  - 분석 데몬의 자동 시작 유무 결정하는 것이며, Diagnosability Daemon은 process와 instance failure에 관련한 진단 정보를 포착해서 systemstate dump를 생성하는 역할을 합니다.

memory_target
  - 총 메모리 량을 지정하는 파라미터 입니다.
  - memory_target PGA 및 SGA 메모리를 자동으로 조정 해주는 역할 합니다.(11g 부터 가능)
  - memory_target, memory_max_target 동일하게 사이즈를 설정하는 게 좋습니다.


2. Oracle Parameter check PL/SQL
- 전체 운영체제에 존재하는 메모리 사이즈를 확인 후 최소 40~60% 오라클 메모리 사이즈를 지정해주시기 바라며, 해당 사이즈에 맞게 변경된 출력 결과를 얻게 됩니다.

SPOOL /tmp/Parameter_Result.txt  /* 경로는 운영체제 환경에 맞게 조정 해주시기 바랍니다. */

SET LINE 100
SET SERVEROUTPUT ON

DECLARE

  IN_DB_MEMORY   NUMBER;
  V_DB_MEMORY    NUMBER;
  V_VERSION      VARCHAR2(100);
  V_PAM_FILE     VARCHAR2(100);
  V_AUDIT_RS     VARCHAR2(100);
  V_PROCESS_RS   NUMBER;
  V_AR_RS        VARCHAR2(100);
  V_AR_DIR_RS    VARCHAR2(100);
  V_MR_RS        NUMBER;
  V_MR_REC       NUMBER;
  V_DIAG_DAEMON  VARCHAR2(100);
  V_MR_RT_10     NUMBER := 0.7;
  V_MR_RT_11     NUMBER := 0.8; /*SGA_MAX_TARGET 비율*/

  
BEGIN
  DBMS_OUTPUT.PUT_LINE('/*********DB가 사용할 수 있는 메모리를 입력하시기 바랍니다.[단위 G](ex. 8G -> 8)*********/'); 
  
  IN_DB_MEMORY := &in_memory; /*[입력]G 단위로 입력*/
  
  V_DB_MEMORY := IN_DB_MEMORY * 1024;
  
  DBMS_OUTPUT.PUT_LINE(' - DB Memory : '||V_DB_MEMORY||'MB');
  DBMS_OUTPUT.PUT_LINE(' '); 

  DBMS_OUTPUT.PUT_LINE('/****************************************************************************************/'); 
  DBMS_OUTPUT.PUT_LINE('                    파라미터 변경 시 DB 종료가 필요합니다.');
  DBMS_OUTPUT.PUT_LINE('                   DB 종료 가능 여부를 파악한 후에 진행하시고');  
  DBMS_OUTPUT.PUT_LINE('        권고 작업 진행 전, Parameter file(spfile[SID].ora)을 백업하시기 바랍니다.');  
  DBMS_OUTPUT.PUT_LINE('/****************************************************************************************/'); 
  DBMS_OUTPUT.PUT_LINE(' '); 
  DBMS_OUTPUT.PUT_LINE(' '); 
  /*Oracle Version 확인*/
  DBMS_OUTPUT.PUT_LINE('/*************************************Oracle Version*************************************/');   
  DECLARE CURSOR ORACLE_VERSION IS
  SELECT    A.BANNER
  FROM      V$VERSION A; 
  BEGIN
    FOR ORACLE_VERSION_LIST IN ORACLE_VERSION LOOP
      DBMS_OUTPUT.PUT_LINE(ORACLE_VERSION_LIST.BANNER);  
    END LOOP;
  END;
  DBMS_OUTPUT.PUT_LINE('/****************************************************************************************/'); 
  DBMS_OUTPUT.PUT_LINE(' '); 

  /*Oracle Version 확인*/
  SELECT    TO_NUMBER(REGEXP_SUBSTR(A.VERSION,'[^.]+',1,1)) AS VERSION
  INTO      V_VERSION
  FROM      V$INSTANCE A; 
 
  IF V_VERSION < 10 THEN
    DBMS_OUTPUT.PUT_LINE('Oracle Version 10g 이상부터 사용할 수 있습니다.'); 
    RETURN; 
  END IF;
  
  /*Parameter File 확인*/  
  DBMS_OUTPUT.PUT_LINE('Check Parameter File');   
  SELECT    A.VALUE
  INTO      V_PAM_FILE
  FROM      V$PARAMETER A
  WHERE     A.NAME = 'spfile';
  IF V_PAM_FILE IS NULL THEN
    DBMS_OUTPUT.PUT_LINE(' - Parameter File을 spfile로 변경하신 후 재작업하시기 바랍니다.');  
    DBMS_OUTPUT.PUT_LINE(' '); 
    DBMS_OUTPUT.PUT_LINE(' [권고 작업] ');
    DBMS_OUTPUT.PUT_LINE('  CREATE SPFILE FROM PFILE;');
    DBMS_OUTPUT.PUT_LINE('  DB 종료');
    DBMS_OUTPUT.PUT_LINE('  PFILE(INIT[SID].ORA) 파일 제거');
    DBMS_OUTPUT.PUT_LINE('  DB 시작');
    RETURN; 
  ELSE
    DBMS_OUTPUT.PUT_LINE(' - Pass');   
  END IF;
  DBMS_OUTPUT.PUT_LINE(' ');  
  /*audit_trail 확인*/
  DBMS_OUTPUT.PUT_LINE('Check audit_trail');  
  SELECT    A.VALUE
  INTO      V_AUDIT_RS
  FROM      V$PARAMETER A
  WHERE     A.NAME = 'audit_trail';
  IF V_AUDIT_RS != 'NONE' THEN
    DBMS_OUTPUT.PUT_LINE(' - audit_trail을 NONE으로 변경하시기 바랍니다.');
    DBMS_OUTPUT.PUT_LINE(' [현재 audit_trail 설정값]'); 
    DBMS_OUTPUT.PUT_LINE('  - '||V_AUDIT_RS);
    DBMS_OUTPUT.PUT_LINE(' '); 
    DBMS_OUTPUT.PUT_LINE(' [권고 audit_trail 설정값]'); 
    DBMS_OUTPUT.PUT_LINE('  ALTER SYSTEM SET audit_trail=NONE SCOPE=SPFILE;'); 
    DBMS_OUTPUT.PUT_LINE('  DB 종료');      
    DBMS_OUTPUT.PUT_LINE('  DB 시작'); 
  ELSE
    DBMS_OUTPUT.PUT_LINE(' - Pass');
  END IF;
  DBMS_OUTPUT.PUT_LINE(' ');  
  /*processes 확인*/  
  DBMS_OUTPUT.PUT_LINE('Check processes');  
  SELECT    A.VALUE
  INTO      V_PROCESS_RS
  FROM      V$PARAMETER A
  WHERE     A.NAME = 'processes';
  IF V_PROCESS_RS < 1000 THEN
    DBMS_OUTPUT.PUT_LINE(' - processes 개수를 1000개로 변경하시기 바랍니다.');
    DBMS_OUTPUT.PUT_LINE(' [현재 processes 설정값]');  
    DBMS_OUTPUT.PUT_LINE('  '||V_PROCESS_RS);  
    DBMS_OUTPUT.PUT_LINE(' ');     
    DBMS_OUTPUT.PUT_LINE(' [권고 작업] ');
    DBMS_OUTPUT.PUT_LINE('  ALTER SYSTEM SET processes=1000 SCOPE=SPFILE;');
    DBMS_OUTPUT.PUT_LINE('  DB 종료');      
    DBMS_OUTPUT.PUT_LINE('  DB 시작');  
  ELSE
    DBMS_OUTPUT.PUT_LINE(' - Pass');
  END IF;
  DBMS_OUTPUT.PUT_LINE(' '); 
  /*archive log mode 확인 - Default Directory일 경우, 변경문구출력*/
  SELECT    A.LOG_MODE
  INTO      V_AR_RS
  FROM      V$DATABASE A;
  IF V_AR_RS = 'ARCHIVELOG' THEN
    DBMS_OUTPUT.PUT_LINE('Check archive log directory');  
    SELECT    A.VALUE
    INTO      V_AR_DIR_RS
    FROM      V$PARAMETER A
    WHERE     A.NAME = 'log_archive_dest_1';
    IF V_AR_DIR_RS IS NULL THEN
      DBMS_OUTPUT.PUT_LINE(' - archive log 위치를 변경해주시기 바랍니다.'); 
      DBMS_OUTPUT.PUT_LINE(' [현재 Archive log 디렉토리 설정값]');  
      DBMS_OUTPUT.PUT_LINE('  db_recovery_file_dest'); 
      DBMS_OUTPUT.PUT_LINE(' ');     
      DBMS_OUTPUT.PUT_LINE(' [권고 작업] ');
      DBMS_OUTPUT.PUT_LINE('  ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=''location=[directory 경로]'' ; /*directory 경로 변경*/');
    ELSE
      DBMS_OUTPUT.PUT_LINE(' - Pass');    
    END IF;
    DBMS_OUTPUT.PUT_LINE(' '); 
  END IF;
  /*diag_daemon 확인*/
  DBMS_OUTPUT.PUT_LINE('Check _diag_daemon'); 
  SELECT    Y.KSPPSTVL
  INTO      V_DIAG_DAEMON
  FROM      X$KSPPI X
           ,X$KSPPCV Y
  WHERE     X.INDX = Y.INDX
  AND       X.KSPPINM = '_diag_daemon';
  IF V_DIAG_DAEMON = 'TRUE' THEN
    DBMS_OUTPUT.PUT_LINE(' - 파라미터를 FALSE로 변경하시기 바랍니다.'); 
    DBMS_OUTPUT.PUT_LINE(' [현재 _diag_daemon 설정값]');  
    DBMS_OUTPUT.PUT_LINE('  '||V_DIAG_DAEMON);  
    DBMS_OUTPUT.PUT_LINE(' ');     
    DBMS_OUTPUT.PUT_LINE(' [권고 작업] ');
    DBMS_OUTPUT.PUT_LINE('  ALTER SYSTEM SET "_diag_daemon"=FALSE SCOPE=SPFILE;');
    DBMS_OUTPUT.PUT_LINE('  DB 종료');      
    DBMS_OUTPUT.PUT_LINE('  DB 시작');  
  ELSE
    DBMS_OUTPUT.PUT_LINE(' - Pass');     
  END IF;
  DBMS_OUTPUT.PUT_LINE(' ');   
  /*Oracle Memory 확인*/
  DBMS_OUTPUT.PUT_LINE('Check Oracle Memory');  
  SELECT    A.BYTE_VALUE / 1024 / 1024, V_DB_MEMORY AS VALUE
  INTO      V_MR_RS, V_MR_REC
  FROM      (SELECT    CASE
                         WHEN V_VERSION = 10
                         THEN
                           SUM(CASE
                                 WHEN A.NAME IN ('sga_target', 'pga_aggregate_target') THEN TO_NUMBER(A.VALUE)
                                 ELSE 0
                               END)
                         ELSE
                           MAX(CASE
                                 WHEN A.NAME = 'memory_target' THEN TO_NUMBER(A.VALUE)
                                 ELSE 0
                               END)
                       END
                         AS BYTE_VALUE
             FROM      V$PARAMETER A
             WHERE     A.NAME IN ('memory_target', 'sga_target', 'pga_aggregate_target')) A;

  IF V_MR_RS = 0 OR V_MR_RS < V_MR_REC THEN
    DBMS_OUTPUT.PUT_LINE(' - 파라미터를 재설정하시기 바랍니다.');     
    DBMS_OUTPUT.PUT_LINE(' [현재 메모리 설정값]'); 
    DECLARE CURSOR ORACLE_MEMORY IS
    SELECT    A.NAME AS PARAMETER_NAME, A.VALUE AS BYTE_VALUE, ROUND(A.VALUE / 1024 / 1024, 2) || 'MB' AS MB_VALUE
    FROM      V$PARAMETER A
    WHERE     A.NAME IN
                ('sga_max_size'
                ,'sga_target'
                ,'java_pool_size'
                ,'streams_pool_size'
                ,'large_pool_size'
                ,'shared_pool_size'
                ,'shared_pool_reserved_size'
                ,'db_cache_size'
                ,'pga_aggregate_target'
                ,'memory_target'
                ,'memory_max_target')
    ORDER BY  A.NAME;
    
    BEGIN
      FOR ORACLE_MEMORY_LIST IN ORACLE_MEMORY LOOP
        DBMS_OUTPUT.PUT_LINE('  - '||RPAD(ORACLE_MEMORY_LIST.PARAMETER_NAME,25,' ')||' : '||ORACLE_MEMORY_LIST.MB_VALUE);  
      END LOOP;
    END;
    DBMS_OUTPUT.PUT_LINE(' ');  
    DBMS_OUTPUT.PUT_LINE(' [권고 작업] ');  
    
    IF V_VERSION = 10 THEN
      DECLARE CURSOR ORACLE_MEMORY_RT IS
      SELECT    'ALTER SYSTEM SET '|| A.PARAMETER_NAME ||' = '||A.VALUE||'M SCOPE=SPFILE;' AS STMT
      FROM      (SELECT    'sga_max_size' AS PARAMETER_NAME, TRUNC(V_DB_MEMORY * V_MR_RT_10) AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'sga_target' AS PARAMETER_NAME, TRUNC(V_DB_MEMORY * V_MR_RT_10) AS VALUE
                 FROM      DUAL               
                 UNION ALL
                 SELECT    'pga_aggregate_target' AS PARAMETER_NAME, V_DB_MEMORY - TRUNC(V_DB_MEMORY * V_MR_RT_10) AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'java_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'streams_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'large_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'shared_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'shared_pool_reserved_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 ) A    ;
      BEGIN
        FOR ORACLE_MEMORY_STMT IN ORACLE_MEMORY_RT LOOP
          DBMS_OUTPUT.PUT_LINE('  '||ORACLE_MEMORY_STMT.STMT);  
        END LOOP;
      END;
             
      DBMS_OUTPUT.PUT_LINE('  DB 종료');      
      DBMS_OUTPUT.PUT_LINE('  DB 시작');        
      DBMS_OUTPUT.PUT_LINE('  ALTER SYSTEM SET db_cache_size = 0M ;'); 
    
    ELSIF V_VERSION >= 11 THEN
      DECLARE CURSOR ORACLE_MEMORY_RT IS
      SELECT    'ALTER SYSTEM SET '|| A.PARAMETER_NAME ||' = '||A.VALUE||'M SCOPE=SPFILE;' AS STMT
      FROM      (SELECT    'memory_max_target' AS PARAMETER_NAME, V_DB_MEMORY AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'memory_target' AS PARAMETER_NAME, V_DB_MEMORY AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'sga_max_size' AS PARAMETER_NAME, TRUNC(V_DB_MEMORY * V_MR_RT_11) AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'sga_target' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL               
                 UNION ALL
                 SELECT    'pga_aggregate_target' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'java_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'streams_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'large_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'shared_pool_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 UNION ALL
                 SELECT    'shared_pool_reserved_size' AS PARAMETER_NAME, 0 AS VALUE
                 FROM      DUAL
                 ) A    ;
      BEGIN
        FOR ORACLE_MEMORY_STMT IN ORACLE_MEMORY_RT LOOP
          DBMS_OUTPUT.PUT_LINE('  '||ORACLE_MEMORY_STMT.STMT);  
        END LOOP;
      END;
      
      DBMS_OUTPUT.PUT_LINE('  DB 종료');      
      DBMS_OUTPUT.PUT_LINE('  DB 시작');        
      DBMS_OUTPUT.PUT_LINE('  ALTER SYSTEM SET db_cache_size = 0M ;'); 
      
    END IF;
  ELSE
    DBMS_OUTPUT.PUT_LINE(' - Pass');   
  END IF;
END;
/

SPOOL OFF
SET SERVEROUTPUT OFF

3. Oracle Parameter check 결과

Check audit_trail
 - audit_trail을 NONE으로 변경하시기 바랍니다.
 [현재 audit_trail 설정값]
  - DB
 
 [권고 audit_trail 설정값]
  ALTER SYSTEM SET audit_trail=NONE SCOPE=SPFILE;
  DB 종료
  DB 시작
 
Check processes
 - processes 개수를 1000개로 변경하시기 바랍니다.
 [현재 processes 설정값]
  150
 
 [권고 작업] 
  ALTER SYSTEM SET processes=1000 SCOPE=SPFILE;

Check archive log directory
 - archive log 위치를 변경해주시기 바랍니다.
 [현재 Archive log 디렉토리 설정값]
  db_recovery_file_dest
 
 [권고 작업] 
  ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='location=[directory 경로]';

Check _diag_daemon
 - 파라미터를 FALSE로 변경하시기 바랍니다.
 [현재 _diag_daemon 설정값]
  TRUE
 
 [권고 작업] 
  ALTER SYSTEM SET "_diag_daemon"=FALSE SCOPE=SPFILE;
  DB 종료
  DB 시작
 
Check Oracle Memory
 - 파라미터를 재설정하시기 바랍니다.
 [현재 메모리 설정값]
  - db_cache_size             : 0MB
  - java_pool_size            : 0MB
  - large_pool_size           : 0MB
  - memory_max_target         : 616MB
  - memory_target             : 616MB
  - pga_aggregate_target      : 0MB
  - sga_max_size              : 412MB
  - sga_target                : 0MB
  - shared_pool_reserved_size : 13.6MB
  - shared_pool_size          : 0MB
  - streams_pool_size         : 0MB
 
 [권고 작업] 
  ALTER SYSTEM SET memory_max_target = 26M SCOPE=SPFILE;
  ALTER SYSTEM SET memory_target = 26M SCOPE=SPFILE;
  ALTER SYSTEM SET sga_max_size = 20M SCOPE=SPFILE;
  ALTER SYSTEM SET sga_target = 0M SCOPE=SPFILE;
  ALTER SYSTEM SET pga_aggregate_target = 0M SCOPE=SPFILE;
  ALTER SYSTEM SET java_pool_size = 0M SCOPE=SPFILE;
  ALTER SYSTEM SET streams_pool_size = 0M SCOPE=SPFILE;
  ALTER SYSTEM SET large_pool_size = 0M SCOPE=SPFILE;
  ALTER SYSTEM SET shared_pool_size = 0M SCOPE=SPFILE;
  ALTER SYSTEM SET shared_pool_reserved_size = 0M SCOPE=SPFILE;
  DB 종료
  DB 시작
  ALTER SYSTEM SET db_cache_size = 0M ;

해당 내용은 자체적으로 테스트하고 운영하면서 변경된 최적화 내용을 토대로 전달해드립니다.
운영 환경과 오라클 버전에 따라서 조금씩 차이가 날 수 있습니다. 반드시 내부 테스트를 거쳐서 반영하시기 바랍니다.

메모리에 대한 변경은 11G 이상부터 적용가능 합니다.

[Admin] MariaDB/MySQL Linux Filesystem Cache(unmap) 메모리 초기화

EstenPark — Fri, 9 Aug 2019 14:57:33 +0900

1. unmap RPM 목록

gdbm-devel-1.10-8.el7.x86_64.rpm

libdb-5.3.21-20.el7.x86_64.rpm

libdb-devel-5.3.21-20.el7.x86_64.rpm

libdb-utils-5.3.21-20.el7.x86_64.rpm

perl-Digest-1.17-245.el7.noarch.rpm

perl-Digest-MD5-2.52-3.el7.x86_64.rpm

perl-ExtUtils-Install-1.58-292.el7.noarch.rpm

perl-ExtUtils-MakeMaker-6.68-3.el7.noarch.rpm

perl-ExtUtils-Manifest-1.61-244.el7.noarch.rpm

perl-ExtUtils-ParseXS-3.18-3.el7.noarch.rpm

perl-Inline-0.53-4.el7.noarch.rpm

perl-Parse-RecDescent-1.967009-5.el7.noarch.rpm

perl-Test-Harness-3.28-3.el7.noarch.rpm

perl-devel-5.16.3-292.el7.x86_64.rpm

pyparsing-1.5.6-9.el7.noarch.rpm

systemtap-sdt-devel-3.1-3.el7.x86_64.rpm

unmap_RPM_CentOS 7.1511.zip

2.53MB

2. unmap perl source

- 원본 : https://github.com/gywndi/kkb/tree/master/mysql_cache_unmap

- MariaDB/MySQL 설치된 경로가 다를 수 있습니다. 아래 처럼 목적에 맞게 변경 바랍니다.

- my @target_dirs = ( '/estdb/dbms/data', '/estdb/dbms/log/binary', '/estdb/dbms/log/relay' );

#!/usr/bin/perl

#  Copyright (C) 2011 DeNA Co.,Ltd.
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#  Foundation, Inc.,
#  51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

use strict;
use warnings FATAL => 'all';
use Inline C       => 'DATA';

my @target_dirs = ( '/estdb/dbms/data', '/estdb/dbms/log/binary', '/estdb/dbms/log/relay' );
my @fully_unmap_logs = ('ib_logfile');
my $binary_log_name  = 'mysql-bin';
my $relay_log_name   = 'relay-bin';

&main();

sub unmap_binary_logs {
  my $binlog_name = shift;
  foreach my $dir (@target_dirs) {
    opendir DIR, $dir;
    my @files =
      grep { m/$binlog_name\.[0-9][0-9][0-9][0-9][0-9][0-9]/ } readdir DIR;
    @files = sort @files;
    for ( my $i = 0 ; $i < $#files + 1 ; $i++ ) {
      my $fpath = $dir . "/" . $files[$i];

      # The tail of the latest binary/relay logs are read from binlog dump
      # thread or SQL thread. To keep the tail in cache, we don't
      # unmap all area, but unmap 90% of the file (the 10% tail is cached).
      if ( $i == $#files ) {
        my $filesize = -s $fpath;
        unmap_log( $fpath, 0, int( $filesize * 0.9 ) );
      }
      else {
        unmap_log_all($fpath);
      }
    }
    closedir DIR;

    #binlog is under this directry. We don't need to search more
    last if ( $#files + 1 > 0 );
  }
}

sub unmap_logs {
  foreach my $dir (@target_dirs) {
    opendir DIR, $dir;
    foreach my $target (@fully_unmap_logs) {
      my @files = grep { m/$target/ } readdir DIR;
      foreach my $file (@files) {
        my $fpath = $dir . "/" . $file;
        unmap_log_all($fpath);
      }
    }
  }
}

sub main {
  unmap_binary_logs($binary_log_name);
  unmap_binary_logs($relay_log_name);
  unmap_logs();
}

__DATA__
__C__

#define _XOPEN_SOURCE 600
#define _FILE_OFFSET_BITS 64
#include 
#include <sys/types.h>
#include <sys/stat.h>
#include 
#include 
#include 

int unmap_log(const char *fpath, size_t start, size_t len)
{
  int fd = open(fpath, O_RDONLY);
  if (fd < 0) {
    fprintf(stderr, "Failed to open %s\n", fpath);
    return 1;
  }
  int r = posix_fadvise(fd, start, len, POSIX_FADV_DONTNEED);
  if (r != 0) {
    fprintf(stderr, "posix_fadvice failed for %s\n", fpath);
  }
  close(fd);
  return 0;
}

int unmap_log_all(const char *fpath)
{
  return unmap_log(fpath, 0, 0);
}

3. 테스트 환경

- OS : CentOS 7

- CPU : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz

- Memory : 32Gb

- Database : MariaDB 10.1.12

4. MariaDB 메모리 스왑(Swap)

Linux 계열의 OS사용시 MariaDB (or MySQL)에서 사용하는 Innodb_Buffer는 할당된 공간을 미리 확보하는 것이 아니기 때문에 다른 곳에서 메모리를 선점해 버린다면 Innodb_Buffer 사용량이 증가함에 따라 Swap 사용량이 늘어납니다.
리눅스 계열은 FileSystem Cache를 가장 우선시 하고 있어서 실제 서버의 free memory가 없을 경우 FileSystem Cache의 일부를 반환하는 것이 아닌 memory의 가장 많이 사용하고 있는 application의 일정량을 Swap로 내리게 됩니다.

5. Linux Filesystem Cache Swap 메모리 문제 해결

해결 방법으로는 메모리 초기화나 Cache unmap를 주기적으로 실행해야 한다. 메모리 전체 초기화는 테스트 용으로 진행 했으나 DB운영 중에 문제가 발생할 수 있으므로 FileSystem Caching 대상에서 제외하라는 명령을 통해서 메모리 Swap 를 관리할 수 있습니다.

swap 초기화 결과

6. unmap 설치 가이드

# 디렉토리 및 구성
[root@estdb01 /root]# cd /estdb/dbms
[root@estdb01 /estdb/dbms]# mkdir ./scripts
[root@estdb01 /estdb/dbms]# cd scripts
[root@estdb01 /estdb/dbms/scripts]# mkdir conf lib logs
[root@estdb01 /estdb/dbms]# chown -R estdbusr.estdba /estdb/dbms/scripts

# RPM 설치
[root@estdb01 /opt]# cd ./rpm
[root@estdb01 /rpm]# rpm -ivh --force gdbm-devel-1.10-8.el7.x86_64.rpm libdb-5.3.21-20.el7.x86_64.rpm libdb-devel-5.3.21-20.el7.x86_64.rpm libdb-utils-5.3.21-20.el7.x86_64.rpm perl-Digest-1.17-245.el7.noarch.rpm perl-Digest-MD5-2.52-3.el7.x86_64.rpm perl-ExtUtils-Install-1.58-292.el7.noarch.rpm perl-ExtUtils-MakeMaker-6.68-3.el7.noarch.rpm perl-ExtUtils-Manifest-1.61-244.el7.noarch.rpm perl-ExtUtils-ParseXS-3.18-3.el7.noarch.rpm perl-Inline-0.53-4.el7.noarch.rpm perl-Parse-RecDescent-1.967009-5.el7.noarch.rpm perl-Test-Harness-3.28-3.el7.noarch.rpm perl-devel-5.16.3-292.el7.x86_64.rpm pyparsing-1.5.6-9.el7.noarch.rpm systemtap-sdt-devel-3.1-3.el7.x86_64.rpm 

# unmap_mysql_log  파일의 권한을 변경 및 실행 권한 부여(위 소스 참고)
[root@estdb01 ~]# cd /opt
[root@estdb01 /opt]# chmod 755 ./unmap_mysql_logs
[root@estdb01 /opt]# chown estdbusr.estdba ./unmap_mysql_logs
[root@estdb01 /opt]# mv ./unmap_mysql_logs /estdb/dbms/scripts/
[root@estdb01 /opt]# su – estdbusr
[estdbusr@estdb01 ~]$ cd /estdb/dbms/scripts/
[estdbusr@estdb01 /estdb/dbms/scripts]$ ./unmap_mysql_logs
[estdbusr@estdb01 /estdb/dbms/scripts]$ ls
_Inline  conf  lib  logs  unmap_mysql_log 

# crontab 등록(매 10분 마다)
[root@estdb01 /root]# crontab -e
*/10 * * * * /estdb/dbms/scripts/unmap_mysql_logs

7. 결과

- 10분 주기로 스크립트를 통해서 메모리를 초기화 할 경우 아래와 같이 Swap 사이즈가 증가하지 않습니다.

- unmap_mysql_logs 쉘 스크립트 사용 필수

- DB 파라미터 변경 : table_open_cache=4096

- DB 파라미터 변경 : performance_schema=off

- OS 파라미터 : vm.swappiness=1 (검증되지 않았으며, 운영 서버에 바로 반영 하면 안됩니다.)

주기적으로 수행 시 swap 결과

8. 참고 문서

http://small-dbtalk.blogspot.com/2013/09/mysql-linux-filesystem-cache-2.html

https://github.com/gywndi/kkb/tree/master/mysql_cache_unmap

[Admin] MariaDB/MySQL InnoDB 테이블 압축(Compression)

EstenPark — Wed, 7 Aug 2019 10:19:05 +0900

1. 테이블 압축 개요
증가하는 데이터로 인해서 서버의 저장공간이 부족 혹은 추가적인 HDD의 증설을 줄이려는 방법으로 데이터 수정(UPDATE)이 발생하지 않는 로그 테이블에 적용하여 조회 속도 향상 및 저장 공간을 줄일 수 있는 기법. 테이블 압축은 테이블 데이터를 압축해서 보관함으로 파일 I/O를 감소시키는 것이 가장 큰 목적입니다. (반대로 압축을 하게 되면 수정 시에는 속도가 느림)

테이블 압축의 옵션인 블록 사이즈는 2, 4, 8, 16KB로 나눠지게 됩니다. (기본값 : 16KB)

2. 테이블 압축 방법

MariaDB [HIWDB]> ALTER TABLE EST_CONN_LOGIN_2 ENGINE=INNODB DEFAULT CHARSET=UTF8MB4 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=2;
Query OK, 0 rows affected (1 min 36.00 sec) 
Records: 0  Duplicates: 0  Warnings: 0

MariaDB [HIWDB]> ALTER TABLE EST_CONN_LOGIN_4 ENGINE=INNODB DEFAULT CHARSET=UTF8MB4 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4;
Query OK, 0 rows affected (54.58 sec)               
Records: 0  Duplicates: 0  Warnings: 0

MariaDB [HIWDB]> ALTER TABLE EST_CONN_LOGIN_8 ENGINE=INNODB DEFAULT CHARSET=UTF8MB4 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;
Query OK, 0 rows affected (39.06 sec)               
Records: 0  Duplicates: 0  Warnings: 0

MariaDB [HIWDB]> ALTER TABLE EST_CONN_LOGIN_16 ENGINE=INNODB DEFAULT CHARSET=UTF8MB4 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=16;
Query OK, 0 rows affected (25.48 sec)
Records: 0  Duplicates: 0  Warnings: 0

3. 테이블 압축 결과 비교

- 테이블 압축은 100만건을 대상으로 진행했으며, 블록 사이즈가 줄이면 압축률이 좋고 조회시간도 줄어듭니다.

항목	용량	압축률	조회시간(5회 평균)
데이터 건수	1,004,092	-	-
압축 전 용량	413,696KB	-	0.425
압축(블록 사이즈 2KB)	98,304KB	76.2%	0.390
압축(블록 사이즈 4KB)	98,304KB	76.2%	0.377
압축(블록 사이즈 8KB)	180,224KB	56.4%	0.398
압축(블록 사이즈 16KB)	352,256KB	14.9%	0.433

4. 테이블압축 추가 및 수정 테스트

- DML에서 INSERT, UPDATE, DELETE 각각 변경 사이즈에 따른 수행 결과를 확인했습니다.

항목	Insert	Update	Delete
압축 전	2.83	0.02	3.59
압축(블록 사이즈 2KB)	3.5	1.19	6.75
압축(블록 사이즈 4KB)	3.2	0.63	5.63
압축(블록 사이즈 8KB)	3.15	0.32	4.34
압축(블록 사이즈 16KB)	3.09	0.19	3.95

5. 결론

- 장점은 일반 테이블 보다 파일 크기를 줄일 수 있고, 데이터 조회 속도는 큰 차이가 없습니다. 단점은 DML 수행 속도가 느려지며, 과거 데이터에 대한 관리 방법이 필요하다고 판단 합니다.