1. 정합성 체크를 통한 데이터 품질향상, 데이터 프로파일링의 개요

가. 데이터 프로파일링(Profiling)의 정의
 - 데이터에 기반한 정합성을 체크하여 데이터를 구조화하고 보정하는 분석 기법

나. 데이터 프로파일링의 목적

  - 데이터정확성 : 비즈니스 사용자에게 정확한 데이터 제공

  - 데이터 제어 : 이름, 주소 등 비즈니스 데이터에 대한 정제, 표준화, 보강 및 중복제거

  - 데이터 모니터링 : 분석기능을 통한 지속적인 데이터 품질평가 및 변경 내역에 대한 모니터링 제공

2. 데이터 프로파일링 개념도 및 기법

가. 데이터 프로파일링 개념도

- 소스데이터를 효과적으로 분석하기 위해서 데이터 프로파일을 통해서 데이터 오류를 식별
- 데이터 크린싱(Cleansing)을 통해서 검출된 오류 데이터를 변경 및 수정 실행

나. 데이터 프로파일링 절차 및 기능요소

 - 대상선정 : 데이터 프로파일링에 필요한 데이터를 선정

 - 데이터 탐색 : 데이터의 값이 업무 규칙과 정합성을 유지하는지 확인

 - 구조 탐색 : 테이블 사이의 무결성과 데이터 레코드 내의 구조적 이상확인

 - 관계 탐색 : 컬럼과 테이블간 관계(Relation)의 관계분석

 - 결과 리포트 : 발견된 데이터 오류정보를 사용자 및 Cleansing모듈에 전달

다. 데이터 프로파일링 기법

 - 컬럼속성분석 :  하나의 컬럼에 저장된 값 분석

 - 구조 분석  : 테이블을 서로 어떤 관련인지를 정의한 룰 사용

 - 단순데이터 룰 분석 : 값의 결합이 가능한 비즈니스 객체의 여러 컬럼에 걸친 값을 다루는 룰을 분석하여 보다 유용한 것을 찾는 것

 - 복잡한 데이터 룰 분석 : 여러 비즈니스 객체에 연관된 데이터 룰에 부합하는 값을 요구하는 것 보다 복잡한 룰

 - 값 룰 분석 : 합당하지 않는 집계 값에서 부정확한 데이터의 존재를 찾는 것

1. 실시간 대용량 트랜잭션 처리를 위한 MMDB의 개요

가. MMDB(Main Memory DataBase)의 정의

- 데이터베이스 전체를 주기억장치에 상주시켜 데이터베이스 연산을 처리하는 고성능 DB
- 데이터베이스 Start-up과 동시에 데이터베이스를 Memory에 상주시켜 관리 및 운영하는 DB

나. MMDB의 등장배경

 - 기존 DBMS처리 성능한계 메모리 가격 하락과 64Bit 운영체제 등장
 -  실시간 데이터 처리 요구 증가, 고객의 마인드 변화

2. 기존 Disk기반 DB와의 비교

디스크 기반 DB	MMDB
버퍼만 메인메모리에, DB테이블은 디스크	메인 메모리 내에 DB테이블, 인덱스 등 존재

나. Disk 기반 DB와의 특징 비교

3. MMDB의 단점극복을 위한 기술 및 활용현황

가. MMDB의 단점극복 기술

 - 용량제한 → 무제한화 (TB급까지 구현)
 - 안정성 → Disk에 Log 및 Check Point 기록 구현
 - Memory와 Disk 이중기록으로 인한 성능저하 → Memory 성능향상 부분이 Disk I/O 성능 감소부분 보다 월등하도록 설계하여 해소
 - 복구 시 Disk 내용 메모리 로딩 시 소요시간 → 병렬 회복기법 기반 획기적 개선

나. MMDB의 활용현황

 - 차세대 빌링 : 이동통신사의 사용자 인증/빌링을 위한 대용량 고속처리 위해 사용
 - 증권사 : 실시간 주식의 시세 분석, 차트 등 다양한 분석에서 사용됨
 - 유선통신 : NGN기반의 대용량 트랜잭션 처리를 위해 활용
 - 이동통신 : 중앙집중적 일괄처리를 위해 메모리DB의 활용

1. 데이터베이스 확장을 위한 샤딩의 개요

가. 샤딩(Sharding)의 개념

  - 관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서 데이터를 파티셔닝 하는 기술
  - 샤딩은 DBMS 레벨에서 데이터를 나누는 것이 아니고 데이터베이스 자체를 수평분할 방식으로 분산저장하고 조회하는 방법

나. 샤딩(Sharding)의 장점

1) 성능개선: 큰 데이터를 압축, 개별테이블은 각샤드에서 더 빠른 작업을 지원
2) 신뢰성개선: 한 샤드가 실패하더라도 다른 샤드는 데이터서비스를 제공
3) 위치추상화: 애플리케이션 서버에서 어떤 데이터가 어떤 데이터베이스에 위치해 있는지 알 필요가 없음

2. 샤딩의 개념도 및 데이터베이스 분할방법

(Sharding)

가. MongoDB의 샤딩 개념도

- 샤드키로 설정된 칼럼의 범위를 기반으로 각각의 값 에 맞는 Shard에 저장
- 사용하는 Application단에서는 MongoS라는 라우팅 프로세스만 연결하므로 Shard의 구조에 대해서는 알 필요도 없고, 구조 변경에 따른 수정도 필요 없음

나. 샤딩의 데이터베이스 분할방법

3. 샤딩 적용시 가이드라인

 Amazon AWS의 Aurora(오로라) DB에 대하여 간략한 기능과 Q&A 사항을 정리하였다. Aurora(오로라) DB는 탈oracle의 분위기가 커지고 있는 시장에서 사용이 증가되고 있는 PostgreSQL을 자체적으로 추가 개선하여 세팅된 DB로 수동으로 스크립트를 작성하여 관리하던 PostgreSQL을 보다 편리하게 제공하고 있으며, disk 영역(스토리지)에서 데이터를 찾거나 변경할때 아마존 AWS 자체 스토리지 처리 기술을 적용하여 조금더 속도 개선을 진행한 기술로 간단히 이해하고 있다.

 장점으로는 AWS CLI를 통하여 미리 Slave 확장이나 자동화 처리(데이터 스냅샷)를 작성해 놓은 상태라면 언제든지 빠르게 서버를 확장할수 있으며 다양한 스펙의 장비를 선택하고 설정할 수 있다는 부분이 가장 큰 장점으로 보여진다.

 단점으로 아마존 AWS(클라우드)로 들어가게 되면 기존에 On-Premise 방식과는 다르게 DB의 구성 및 파라미터 세팅에 대한 제약이 발생되며, AWS 계약의 종류에 따라 갑자기 서버가 내려가거나 장애가 발생했을때 아무 원인이나 조치내역을 공유 받지 못한는 경우도 발생하는 것 같다.

 또한 긴급하게 대량으로 slave를 확장할 경우, AWS 서버를 할당 받는 zone에서 서버가 없는 경우가 있어 종종 지연이 발생되는 경우가 있으며, AWS -> AWS 안에서 데이터를 전송하는 것은 큰 문제가 없는데 AWS -> 외부 서버로 데이터를 전송 해야할 때 많은 비용이 증가하는 점이 있다.

[기본 정보]
- AWS Aurora(PostgreSQL) 11버전 지원, Master 1대당 Slave 15대 까지 가능
- RDS slave는 5대로 제한
 

1. AWS Aurora DB사용시 사용자기 임의로 파라미터를 수정가능 여부

Q. 파라미터를 사용자가 편하게 변경 가능한지
A. 변경 가능한 것도 있음, 기본적으로 cost 파라미터 등은 변경 가능하나 변경 불가사항도 존재함
 
    구조가 기본적으로 엑사와 비슷
    Application —> 분산하여 storage에 내려씀 (병렬)
    스토리지 노드는 6개
       
    장점 - shared node로 사용 가능 (스트림노드로 연결은 함, dirty block 때문에), writing 이 많은 서비스에 이득, CPU 사용율 기준으로 Auto - scale 가능
    단점 - CPU 를  20~30% 를 기본적으로 더 사용, 스토리지를 어플리케이션 레벨에서 병렬로 성능이 빠름

2.  AWS Aurora DB에서 Parallel 기능 사용 가능 여부

Q. Parallel  기능 여부
A. 버전 마다 달라서 확인 가능, 패러럴 작업시 스토리지 레벨까지 내려감 (특정 버전에서)
 

3. AWS Aurora DB에서 Vaccum동작에 따른 Slave 세션 끊김 없이 처리 가능한지 여부

Q. 슬래이브의 select 작업시 vaccum 이슈로 select 시 접속 fail

A. 속도가 빠르고 CPU 작업이 빠르기 때문에 기존 대비하여 극단적으로 발생할 확률 축소
 

4. AWS Aurora DB에서 쓰기가 많은 서비스일때 어느정도까지 서비스에 무리가 없는지 문의

Q. Write 중심적인 서비스에서 DML가 많을 때의 이슈
A. 하루에 1억건 정도라면 크게 문제없음
 

5. AWS에서 발생되는 갑작스러운 서버 장애시 고객사에서 장애 원인과 조치내역에 대하여 공유 받을수 있는지 문의

Q. 서버 장애시 케이스(SR)가 공유가 가능한지
A. 계약이 필요한 사항, aurora에서는 슬래이브가 죽을 경우 스토리지를 사용해서 1분정도 안에 자동 재기동 가능

# Amazon AWS Aurora DB construction Q&A summary

# Resumen de preguntas y respuestas sobre la construcción de Amazon AWS Aurora DB

# Amazon AWS Aurora DB構築Q＆Aまとめ

# Amazon AWS Aurora数据库构建问答

# अमेज़ॅन AWS अरोरा DB निर्माण क्यू एंड ए सारांश

1. MySQL hard/soft parse 

답)

1) mysql 5.7.19 에서 hard/soft parse에 대한 기능이 있는지 문의
 -  MySQL 은 ORACLE 에서 의미하는 hard/soft parse 에 대한 개념이 없습니다.
 -  모든 쿼리는 parse 단계 이후 (prepared statement 의 사용유무에 따라 다름), 실행계획을 세우는 단계를 모두 거친 후 실행이 됩니다.
    ○ MySQL 의 query cache 가 ORACLE 의 hard/soft parse 와 비슷한 기능 (parse 및 실행계획을 세우는 단계가 없이 결과를 바로 return) 을 가지고 있지만, MySQL 의 query cache 는 ORACLE 과 다르게 "결과값"도 저장하고 있어 완전히 다른 cache 임을 알려드립니다. MySQL query cache 는 테이블의 데이터가 한건이라도 변경되면 관련된 cache 를 모두 해제하게 됩니다.

2) mysql에서 쿼리 작성 시에 bind 변수 처리하여 작성하는 것과 static 변수로 작성하는 방법 간의 차이점이 있는지 문의
 -  쿼리는 일반적으로 MySQL 에 4가지 단계를 거치게 됩니다.
A) parsing
   SQL 구문을 문법에 맞게 분류하는 작업을 진행합니다. (SELECT, WHERE, GROUP BY...)
B) resolution
분류된 SQL 에 대한 정합성을 체크합니다. (관련 table 에 column 이 존재하는지에 대한 유무, subquery 혹은 join 되는 쿼리의 컬럼 정합성 체크)
C) optimization
실제 실행계획은 세우는 단계
D) execution
실제 쿼리가 실행되는 단계

위와 같은 과정에서, prepared statement (bind 변수 처리) 를 사용하신다면 A),B) 의 단계를 스킵할 수 있습니다.

2. MySQL 파티션 테이블 생성시 주의사항

답)
1) auto_increment 설정시, 주의사항 (복합 key를 사용할 경우)
     - InnoDB : 복합 primary key 생성시에 첫번째 컬럼으로만 사용 가능 
     - MyISAM : 복합 primary key 생성시에 두번째 컬럼으로도 사용 가능

2) virtual column 생성 및 주의사항
     - 아래와 같은 문법으로 테이블 생성시 사용 가능
     - virtual column으로 partition key로 잡아 사용할 수 없음
예)
 # `emp_dt` int(8) generated always as (DATE_FORMAT(emp_date, '%Y%m%d')) virtual
 #comment 'emp_dt 가상컬럼',

3) auto_increment + partition table 생성시, 주의사항
     - auto_increment 컬럼이 primary key의 첫번째로 오는 것이 기본
     - auto_increment 컬럼을 첫번째에 두지 않을 경우에는 key(인덱스)를 별도로 생성해서 테이블을 만들어야함

4) partiton table에서 date, datetime으로 partiton key를 잡을 경우, 주위사항
     -아래와 같이 2가지 형태로 사용이 가능
     -partition by range (to_days()) ~ partition emp values less than (to_days('2017-08-01 00:00:00')),..
     -partition by range columns () ~ partition emp values less than ('20170801'),..

3. MySQL metadata lock과 일반 lock의 차이관련

답)
 - 일반 잠금은 row level lock, table level lock 등
 - 메타 데이터 잠금은 DDL 문만 허용금지 (물리적 블록에 look을 거는 것이 아님)

4. MySQL 5.7.19 SQL HINT 사용

답)
 - use index (IX_EMP01)" 인덱스를 지정하는 hint(USE|FORCE|IGNORE Index)를 사용할 떄
 - 기존에 IX_EMP01 인덱스가 생성되어 있지 않으면 쿼리 수행시 error code: 1176(not exist)이 발생된다.

5. MySQL open_files_limit 파라미터 설정
(8.0.22-commercial MySQL Enterprise Server)

1) /etc/security/limits.conf

mysql hard nofile 65535
mysql soft nofile 65535

2)
[mysql_m:/mysql_data/tmp]$ulimit -Sn
65535
[mysql_m:/mysql_data/tmp]$ulimit -Hn
65535

3) my.cnf

[mysqld_safe]
open_files_limit = 8192

위와 같이 mysql 파라미터가 8192로 설정되어 있습니다.

해당 DB로 접근하여 조회해보면 65535으로 확인되는데
open_files_limit를 설정할 때 my.cnf 를 보고 세팅되지 않고 os 세팅을 기준으로 설정되는 것인지 문의드립니다.

mysql> show global variables like 'open%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 65535 |
+------------------+-------+

답)
-> root로 기동할 경우, my.cnf 에 적용된 값에 따라서 open_files_limit 값이 적용되나 아래의 조건을 따르게 됨
우선적으로는 my.cnf 에 명시된 값으로 설정되지만 그 값이 아래 조건보다 낮으면 아래 조건 중 큰 수로 설정이 됨 
- 10 + max_connections + (table_open_cache * 2)
- max_connections * 5
- open_files_limit value specified at startup, 5000 if none

-> mysql 유저로 기동할 경우 my.cnf 관계없이 OS설정값으로 설정됨(버그여부확인 필요)

#Oracle MySQL Q&A Summary (2020)

#Resumen de preguntas y respuestas de Oracle MySQL (2020)

#Oracle MySQL Q＆Aまとめ（2020）

#Oracle MySQL问答摘要（2020）

#Oracle MySQL Q & A सारांश (2020)

 현재 우리 사회에 많은 상품들이 생산되고 구매자를 통하여 새 상품인 상태로 판매되어 일정 기간 사용하다보니 불편하거나 사용이 필요없게 되는 물건들이 많아지게 되면서 기존 구매자들이 판매자가 되어 중고 제품, 상품을 팔아서 수익을 창출하는 비즈니스가 많이 활성화 되고 있는 상황이다.

 과거에는 동내마다 불필요한 물건을 사러 다니는 차량들을 볼수 있었을 것이다. 요즘에는 기존 구매자들이 직접 중고 시작에 물건을 팔기 시작하면서 과거와 같은 모습은 보이지 않고 직거래를 통하여 물건을 사고 파는 행위가 안전하게 가능하도록 온라인 상으로 전시 및 결제를 하게한뒤에 직거래로 마무리하는 형태의 중고 거래가 늘고 있다.

 또한 검색창이 "무료나눔"이라고 검색하게되면 자신이 불필요해진 물건을 무료로 공유하는 사람들도 늘고 있다. 

 그에 따른 제품 하자나 사기와 같은 중고 거래 시장의 문제점도 아직은 존재하지만 기술적으로 편리하고 안전하게 거래할수 있도록 하는 국내 중고 거래 사이트들이 있어서 소개하려한다.

국내 중고사이트 TOP 5

1. 중고나라 (네이버 중고나라, 중고나라 앱)

 - 중고 판매와 구매가 가능하도록 네이버의 중고나라 라는 카페에서 시작한 최초의 중고거래 사이트라고 볼수 있다. 다양한 상품이 지역과 동내 상관없이 확인할수 있으며 좋은 상품에 가격까지 괜찮으면 경쟁이 치열하다. 

초창에는 중고 사기 및 상품 하자같은 문제 점으로 인하여 많은 문제를 발생시켰으나 조금씩 해결해 나가고 있는 상태이며 PC와 모바일까지도 확장하는 사업을 하고 있는 상황이다. 

cafe.naver.com/joonggonara

www.joongna.com/

2. 당근마켓

- 당근마켓은 중고나라가 PC의 카페에서만 거래될 때, 발빠르게 모바일 형태로 중고거래가 가능하도록 구축함으로써 많은 고객을 중고나라에서 가져왔으며 동내라는 범위 안에서 중고거래가 가능하도록 하는 컨셉으로 좀더 빠르고 빈번하게 거래가 이루어질수 있도록 하고 있다.

www.daangn.com/

3. 번개장터

 - 번개장터는 중고나라와 당근마켓보다는 후발주자이긴하지만 기존 중고 거래소와 다르게 원터치택배같은 추가 서비스를 보강하여 중고거래가 활성화 될수 있도록 하고 있다.

m.bunjang.co.kr/

4. 다나와장터

 - 기존 가격비교에 최적화 되어 있는 다나와 사이트와 별개로 중고 IT 제품에 특화되어 중고제품을 거래 할수 있도록 다나와에서 별도 페이지로 지원해주고 있다. 

dmall.danawa.com/v3/

5. 옥션중고장터

 - 기존 옥션사이트에서 중고장터 페이지를 확장하여 경매를 하는 형태로 물건을 좀더 저렴하게 구매할수 있도록 기능을 사용자들에게 제공하고 있다.

corners.auction.co.kr/corner/UsedMarket.aspx?pid=346

# Top 5 domestic used sites

# Los 5 mejores sitios de uso doméstico

# 国内中古サイトTOP 5

# 国内5大二手网站

# शीर्ष 5 घरेलू उपयोग की गई साइटें

 오라클 운영중인 테이블에 Update/Delete/Insert를 대량으로 해야하는 상황이 있는데, Lock 현상을 피하기 위하여 데이터를 PK Level로 Loop Commit 형태로 작업하게 될때 사용하는 스크립트이다.

 가능하다면 대량작업은 정기점검시점에 서비스 사용이 없을때 인덱스까지 정리한뒤 대량의 데이터 변경 작업을 CTAS로 한뒤, 테이블 교체 및 인덱스를 재생성하여 테이블을 깨끗하게 재생성하는 방향으로 작업되는 것이 가장 좋은거 같다.

 PL/SQL 형태와 Merge into 구문으로 작성된 내역으로 대상 테이블과 조건사항만 변경하여 사용이 가능한 상태이다.

[1안]

DECLARE 

    CNT NUMBER;
    
    CURSOR C IS
        SELECT  *
        FROM    EMP  
        WHERE   UP.EMP_DATE = TO_DATE('SYSDATE-1','YYYYMMDDHH24MISS');

BEGIN
    CNT := 0;
    
    FOR CUR IN C LOOP

        DELETE  FROM EMP UP
        WHERE   UP.EMPNO = CUR.EMPNO;

        CNT := CNT + 1;
        
        IF (MOD(CNT, 100) = 0) THEN 
            COMMIT;
        END IF;            

    END LOOP;
    
END;
/

[2안]

MERGE
INTO EMP SI 
USING (
          SELECT  *
          FROM    EMP   UP
          WHERE   UP.EMP_DATE = TO_DATE('SYSDATE-1','YYYYMMDDHH24MISS')
        ) TGT
ON ( SI.EMPNO = TGT.EMPNO )

WHEN  MATCHED THEN 
UPDATE
SET     SI.SAL = '0'

DELETE  WHERE 1 = 1 ;

# Oracle running table Loop Commit task script

# Script de tarea de confirmación de bucle de tabla en ejecución de Oracle

# オラクル運営しているテーブルLoop Commitジョブスクリプト

# Oracle रनिंग टेबल लूप कमिट स्क्रिप्ट

# Oracle运行表Loop Commit任务脚本

1. Oracle Engine,OCR,VOTE 백업 수행

1) ocr/vote 백업

백업수행: $ORACLE_HOME/bin/ocrconfig -manualbackup
백업위치확인: $ORACLE_HOME/bin/ocrconfig -showbackup

2) oracle, oragrid 엔진 백업
/oracle, /oragrid 영역 전체를 tar로 묶음

2. Oracle Engine,OCR,VOTE 복구 수행

0) grid / oracle / oraInventory 압축 해제 

tar xvfp <grid_home> 
tar xvfp <oracle_home> 
tar xvfp <oraInventory>

1) shared volume 확인 (oragrid user)

# $ORACLE_HOME/bin/cluvfyrac.sh comp ssa -n testdb1,testdb2 -s /dev/rhdisksys1

# $ORACLE_HOME/bin/cluvfyrac.sh comp ssa -n testdb1,testdb2 -s /dev/rhdisksys2

2. crs exclusive mode로 open (root user)

# $CRS_HOME/bin/crsctl start crs -excl -nocrs

3. ocr/vote diskgroup 생성 (oragrid user)

$ sqlplus / as sysasm
SQL> alter system set asm_diskstring='/dev/*sys*' scope=memory sid='*';
SQL> create diskgroup ASM_CRS external redundancy disk '/dev/rhdisksys1','/dev/rhdisksys2' attribute COMPATIBLE.ASM' = '11.2';
SQL> exit;

4. crs restore (root user)

# cd $GRID_HOME/cdata/<cluster name>/
# ocrconfig -restore <backup_20190610_111155.ocr>

5. vote disk 재생성 (1번 노드 / root)

# crsctl replace votedisk +ASM_CRS

6. asm spfile 재생성 (1번노드 / asm user)

 - ASM 경로 변경이 없다면 제외해도 됌

$ sqlplus / as sysasm
SQL> create spfile='+ASM_CRS' from pfile='/ora_backup/init+ASM1.ora';

7. crs 재기동 (1번노드 / root)
# crsctl stop crs -f
-- 올리는건 1/2번 노드 양쪽에서 수행
# crsctl start crs

-- 검증
# crsctl check cluster -all
# crsctl query css votedisk

# Oracle 11G RAC Engine Backup/Recovery

# Copia de seguridad / recuperación de Oracle 11G RAC Engine

# Oracle 11G RAC引擎备份/恢复

# Oracle 11G RAC Engineバックアップ/リカバリ

# Oracle 11G RAC इंजन बैकअप / रिकवरी