참고사항 # Offline Backup, Offline Backup의 의미 Online => 사용자가 접속된 상태에서 백업 Offline => 사용자가 없는 상태에서 백업 1. Archive Logging(Online : 별도 로그 디렉토리)로 변경하는 방법 *LOGRETAIN을 ON으로 하거나 LOGARCHMETH1가 다른 방식이면 Archive Logging라고 생각하면 됨. LOGRETAIN ON시 다음과 같이 변경됨. $ db2 update db cfg for sample using LOGRETAIN on Log retain for recovery enabled (LOGRETAIN) = RECOVERY First log archive method (LOGARCHMETH1) = LOGRETAIN 후..
■ 쿼리 형태 insert into table select * from table1, table2, table3 where ... create table as select * from table1, table2, table3 where ... 위 형태의 쿼리를 사용할때는 주의 하여야 합니다. 보통 위의 쿼리는 똑같은 형태의 테이블을 생성하거나 똑같은 데이터를 특정 테이블에 밀어넣을때 많이 사용합니다. 하지만 위의 쿼리를 실행하게 되면 select를 하게되는 table1,table2,table3에는 read lock이 걸리게 됩니다. 이는 isolation level이 REPATABLE_READ일때 발생하게 됩니다. 이 REPATABLE_READ의 특징은 현재 select의 데이터 정합성과 버전을 보장하기..
1. Range Key를 정한 후 테이블을 만든다. create table t1(c1 int) in ts_table1 partition by range(c1) (partition rp1 starting from 1 ending 10 in ts_att1, partition rp2 starting from 11 ending 20 in ts_att2, partition rp3 starting from 21 ending 30 in ts_att3); 2. 각 테이블에 데이터를 저장한다. insert into t1 values(5); insert into t1 values(15); insert into t1 values(25); 3. select 문법으로 데이터를 조회한다. C1 ----------- 5 15 25..
■ 사전작업 유의사항 : 장애 및 업데이트 실패를 대비하기 위하며 db2look파일, DBM 정보(인스턴스 정보) 및 DB Parameter정보 그리고 DB백업등 필요한 모든 수단을 강구합니다. 또한 Package를 다시 bind할때 db2rbind로 통째로 할건지 아니면 rebind로 Package를 검증해 나가면서 하나씩 일일이 할것인지 Plan을 정하고 수행하시기 바랍니다. 선작업 : http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/t0024956.html 1. 루트 설치의 경우 루트로 로그온합니다. 비루트 설치의 경우 비루트 설치를 소유할 사용자 ID를 사용하여..
■ LOCK TABLES 그리고 UNLOCK TABLES 문법 LOCK TABLES tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type] ... lock_type: { READ [LOCAL] | [LOW_PRIORITY] WRITE } UNLOCK TABLES MySQL은 클라이언트 세션이 테이블에 액세스하기 위해 다른 세션과 협력하거나 세션에 독점 액세스가 필요한 기간 동안 다른 세션이 테이블을 수정하지 못하도록 하기 위해 명시적으로 테이블 잠금을 획득할 수 있도록 합니다. 세션은 자체 잠금만 획득하거나 해제할 수 있습니다. 한 세션은 다른 세션에 대한 잠금 또는 다른 세션이 보유한 잠금 해제를 획득할 수 없습니다. 잠금은 트랜잭션을 ..
■ tabe open cache 파라미터의 용도 MySQL은 다중 스레드방식으로 운영되는 DBMS입니다. 여러 클라이언트가 붙고 그 안에서 여러 쿼리를 날리는데 그 쿼리 안에는 여러 테이블이 사용될 수 있습니다. 이때 요청되는 테이블이 각 클라이언트에서 공유적으로 열리는것이 아니라 각각의 클라이언트별로 테이블이 열립니다. 이렇게 하면 추가적인 메모리는 사용되지만 각각의 클라이언트에서 독립적으로 사용되는것이기 때문에 속도가 높아지는 효과가 발생하게 됩니다. 이것이 바로 table open cache 파라미터의 용도입니다. mysqladmin status 명령을 실행하면 다음과 같은 내용이 표시되어야 합니다. Uptime: 426 Running threads: 1 Questions: 11082 Reloads..
■ 트랜잭션 격리 수준 [Isolation Level] 트랜잭션 격리는 데이터베이스 처리의 기초 중 하나입니다. 격리는 약어 ACID의 I입니다. 격리 수준은 여러 트랜잭션이 동시에 변경하고 쿼리를 수행 할 때 결과의 성능과 안정성, 일관성 및 재현성 간의 균형을 미세 조정하는 설정입니다. InnoDB는 SQL:1992 표준에 의해 기술 된 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ 및 SERIALIZABLE의 4 가지 트랜잭션 격리 수준을 모두 제공합니다. InnoDB의 기본 격리 수준은 REPEATABLE READ입니다. 사용자는 단일 세션 또는 SET TRANSACTION문으로 모든 후속 연결에 대한 분리 레벨을 변경할 수 있습니다. 모든 연결에 대해 ..
■ InnoDB 모니터 타입 InnoDB 모니터에는 두 가지 유형이 있습니다. + 표준 InnoDB 모니터는 다음 유형의 정보를 표시합니다. - 메인 백그라운드 스레드에 의해 수행 된 작업 - 세마포어 대기 - 가장 최근의 외래 키 및 교착 상태 오류에 대한 데이터 - 트랜잭션에 의한 잠금대기 - 활성 트랜잭션이 보유한 테이블 및 레코드 잠금 - 보류중인 I/O 작업 및 관련 통계 - 삽입 버퍼 및 적응 형 해시 인덱스 통계 - 재실행 로그 데이터 - 버퍼 풀 통계 - 행 연산 데이터 + InnoDB 잠금 모니터는 표준 InnoDB 모니터 출력의 일부로 추가 잠금 정보를 인쇄합니다. ■ InnoDB 모니터 사용 InnoDB 모니터가 주기적인 출력을 위해 활성화되면 InnoDB는 약 15초마다 출력을 my..
■ MySQL 성능 스키마와 InnoDB 통합 MySQL 성능 스키마 기능을 사용하여 특정 내부 InnoDB 작업을 프로파일링 할 수 있습니다. 이 유형의 튜닝은 주로 성능 병목 현상을 극복하기 위해 최적화 전략을 평가하는 전문 사용자를위한 것입니다. 또한 DBA는 용량 계획에 이 기능을 사용하여 일반적인 워크로드에 특정 CPU, RAM 및 디스크 스토리지 조합의 성능 병목 현상이 발생하는지 확인할 수 있습니다. 이 결과로 시스템 일부의 처리량이나 용량을 늘려 성능을 향상시킬 수 있는지 판단할 수 있는 근거가 됩니다. 이 기능을 사용하여 InnoDB 성능을 검사하려면 : + 일반적으로 성능 스키마 기능을 사용하는 방법에 익숙해야 합니다. 예를 들어, 계측기와 소비자를 활성화하는 방법과 performanc..
원글 : https://www.percona.com/blog/2020/03/26/sysbench-and-the-random-distribution-effect/ Sysbench and the Random Distribution Effect - Percona Database Performance Blog How to customize sysbench to extend its use, with one way being the proper tuning of the random IDs generation. www.percona.com Sysbench의 난수 생성에 대해 알아야 할 사항 Sysbench는 벤치마킹을 수행하는 데 잘 알려져 있고 널리 사용되는 도구입니다. Peter Zaitsev가 2000 년 초에..
■ SysBench 히스토리 및 아키텍처 sysbench는 2004 년 Peter Zaitsev에 의해 만들어졌고 곧 Alexey Kopytov가 개발을 인수했습니다. 버전 0.4.12에서 개발이 중단되었습니다. Alexey는 2016년에 다시 작업하기 시작했습니다. 곧 LUA 기반 스크립트를 사용하도록 OLTP 벤치 마크를 다시 작성하여 버전 0.5가 릴리스되었습니다. 그런 다음 2017 년에 SysBench 1.0이 릴리스되었습니다. 이것은 0.4.12 이전 버전과는 비교할 수 없을 정도로 훌륭하게 만들어졌습니다. 하드코딩된 스크립트 대신 LUA를 사용하여 벤치마크를 사용자가 원하는 방법으로 정의하여 테스트할 수 있습니다. 이것은 굉장히 유연하게 테스트 할 수 있는 방법을 제공합니다. SysBench..
■ InnoDB 데드록 교착 상태는 각 트랜잭션마다 다른 잠금이 있기 때문에 다른 트랜잭션을 진행할 수 없는 상황입니다. 두 트랜잭션 모두 자원이 사용 가능할 때까지 대기하므로 보유한 잠금을 서로 해제않아 발생합니다. 트랜잭션이 여러 테이블에서 행을 잠글때(UPDATE 또는 SELECT ... FOR UPDATE와 같은 SQL을 통해) 교착 상태가 발생할 수 있지만 반대 순서로 발생합니다. 교착 상태는 이러한 명령문이 인덱스 레코드 및 간격 범위를 잠그고 각 트랜잭션이 타이밍 문제로 인해 일부 잠금을 획득하지만 다른 잠금은 획득하지 않는 경우에도 발생할 수 있습니다. 교착 상태의 가능성을 줄이려면 LOCK TABLES문 대신 트랜잭션을 사용합니다. 데이터를 삽입하거나 업데이트하는 트랜잭션을 장기간 열어 ..