toDBA

상황: 테이블 생성 후 대량 데이터 insert 했다는 시나리오로 가정 자동 ANALYZE 지연 문제PostgreSQL에는 autovacuum 프로세스가 있어서 자동으로 ANALYZE 를 수행하긴 합니다.하지만 autovacuum은 백그라운드에서 주기적으로 동작하기 때문에,막 데이터를 넣고 바로 조회할 경우 아직 통계가 수집되지 않은 상태일 수 있습니다.따라서 초기 적재 후 수동으로 ANALYZE 실행하는 게 안전합니다 🔹 autovacuum과 통계 수집PostgreSQL은 autovacuum 프로세스를 통해 VACUUM / ANALYZE 를 자동으로 수행합니다.하지만 autovacuum은 즉시 실행되지 않고, 내부적으로 설정된 기준(autovacuum_analyze_scale_factor, autov..

- postgresql 은 ANALYZE 명령이나 VACUUM ANALYZE, 또는 자동 통계 수집(autovacuum을 통한 분석)으로 수집 (변경된 튜플 수) > (전체 튜플 수 * autovacuum_analyze_scale_factor + autovacuum_analyze_threshold) 📌 기본값:autovacuum_analyze_threshold = 50autovacuum_analyze_scale_factor = 0.1 (즉, 전체의 10%)예: 1,000건이 있는 테이블이면, 약 150건(50 + 1,000×0.1) 이상 변경되었을 때 자동으로 통계 수집 실행 → 즉, 테이블의 크기가 커질수록 autovacuum이 점점 더 늦게 실행되는 구조입니다. 테이블 단위로 설정해서 튜닝할 수 있..

목적 : postgresql에서 oracle 또는 mysql 데이터를 조회한다. 방안 : oracle_fdw, mysql_fdw 활용주요 기능데이터 조회 및 수정SQL 쿼리의 통합 실행데이터 통합설치방법oracle_fdwgit clone https://github.com/laurenz/oracle_fdw.gitcd oracle_fdwmakesudo make installCREATE EXTENSION oracle_fdw;CREATE SERVER oracle_serverFOREIGN DATA WRAPPER oracle_fdwOPTIONS (dbserver '//oracle_host:1521/service_name');CREATE USER MAPPING FOR postgresSERVER oracle_serve..

목적: 기존의 sql의 실행계획이 변경되었는지 모니터링하여 장애 예방한다.방안: extension 중 pg_store_plans를 활용 주기적으로 변경된 plan이 있는지 확인한다.plan 변경 감지 쿼리WITH plan_changes AS ( SELECT p.queryid, s.query, p.plan AS new_plan, LAG(p.plan) OVER (PARTITION BY p.queryid ORDER BY p.calls) AS old_plan FROM pg_store_plans p JOIN pg_stat_statements s ON p.queryid = s.queryid)SELECT queryid, ..

카탈로그 정보pg_catalog : tables, views, functions, indexes, fdw, trigger, constraints, rules, users, groups 등등 정보 저장 pg_attribute : 테이블 및 다른 pg_class object columns에 대한 정보 저장 pg_index : 인덱스에 대한 정보 저장 pg_depend : object dependent에 대한 정보 pg_rewrite : 테이블 및 view 에 대한 rules 정보  pg_constraint : 테이블에 constraint 정보  pg_stat_statements : db에서 수행된 쿼리에 대한 통계 정보 pg_buffercache : cache에 대한 deeper 한 정보 informatio..

일반적으로 다음과 같은 순서로 REDO 로그량이 많이 발생합니다:VACUUM FULL > VACUUM > VACUUM FREEZE [테스트 시나리오]데이터 준비100만 건의 초기 데이터 생성각 VACUUM 테스트 전에 서로 다른 패턴으로 데이터 업데이트/삭제각 VACUUM 유형별 특징VACUUM FULL: 테이블 전체 재작성으로 가장 많은 REDO 발생일반 VACUUM: 삭제된 레코드 정리VACUUM FREEZE: 트랜잭션 ID 에이징 처리측정 방법pg_current_wal_lsn() 함수로 WAL 위치 측정pg_wal_lsn_diff() 함수로 발생한 REDO 로그량 계산pg_size_pretty() 함수로 읽기 쉽게 포맷팅결과 분석각 VACUUM 유형별 REDO 로그 발생량 비교 제공VERBOSE 옵..