다음 시나리오에서는 Oracle에서 Azure Postgres로 마이그레이션하는 동안 발생한 몇 가지 잠재적인 문제를 간략하게 설명합니다. 권장되는 솔루션은 사용자 고유의 마이그레이션을 계획하고 실행할 때 이러한 문제를 해결하는 데 도움이 될 수 있습니다.
시나리오: 동일한 데이터베이스에서 독립적으로 작동하는 두 개의 별도의 짧은 대기 시간, 높은 처리량의 클라이언트 애플리케이션이 발견되었습니다. 각 애플리케이션이 실수로 버퍼에서 다른 애플리케이션의 캐시된 쿼리를 충돌했습니다. 공유 부하 및 결합된 리소스 경합으로 인해 데이터베이스의 공유 버퍼가 너무 자주 플러시되어 두 시스템에서 성능이 저하되는 상황이 발생했습니다.
권장 솔루션: 초기 평가에서 SGA(시스템 전역 영역) 및 PGA(프로그램 전역 영역) 메모리 구조의 메모리 사용량 및 사용률 패턴을 포함하여 데이터베이스 플랫폼 환경의 모든 측면을 캡처하는지 확인합니다. 리소스 요구 사항과 일치하는 적절한 컴퓨팅 제품군을 선택하고 Postgres 계획된 용량이 필요에 따라 조정되었는지 확인합니다.
팁
pg_buffercache 확장은 사용률을 검사하는 방법을 제공하며 공유 버퍼 캐시에서 발생하는 작업을 실시간으로 관찰할 수 있습니다.
버퍼 캐시 적중률
적중률을 검사하면 캐시 효율성을 평가하고 공유 버퍼 크기가 적절한지 여부를 확인할 수 있습니다. 캐시 적중률이 양호하다는 것은 대부분의 데이터 요청이 디스크가 아닌 메모리에서 제공되어 최적의 성능을 제공한다는 신호입니다.
SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;
가장 자주 액세스하는 테이블 및 인덱스
가장 자주 액세스되는 테이블 및 인덱스를 검사하거나 버퍼 캐시에서 가장 많은 공간을 차지하는 경우 메모리에 캐시되는 핫스팟을 식별하는 데 도움이 될 수 있습니다.
SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;
버퍼 캐시 경합
버퍼 캐시의 상당한 경합은 여러 쿼리가 동일한 버퍼 공간에 대해 경합하여 성능 병목 현상이 발생할 수 있음을 나타냅니다. 버퍼 액세스의 위치 및 빈도를 검사하면 이러한 문제를 진단하는 데 도움이 될 수 있습니다.
SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;
시나리오: Postgres 플랫폼 릴리스 주기의 릴리스 간에 마이그레이션 작업이 시작되었습니다. 최신 릴리스에서 새로운 기능과 향상된 기능을 사용할 수 있음에도 불구하고 마이그레이션 시작 시 선택한 버전은 변경되지 않았습니다. 최적의 성능과 새로운 기능을 달성하기 위해 초기 마이그레이션 후 Postgres 데이터베이스 버전을 업그레이드하기 위해 추가된 노력, 시간 및 비용이 추가되었습니다.
권장 솔루션: 가능하면 마이그레이션 시 최신 릴리스 버전의 Postgres 채택에 우선 순위를 지정합니다. Postgres 커뮤니티 개발 팀은 새 릴리스마다 성능과 안정성을 모두 짜내기 위해 매우 열심히 노력하고 있으며, 이를 보류하면 기본적으로 성능이 사이드 라인에 남게 됩니다. 또한 새로운 Azure 기능을 최대한 활용합니다. 새로운 Azure Postgres 기능에는 SSDv2 스토리지, 최신 서버 인프라 제품군, 자동화된 인덱스 튜닝 및 자율 서버 매개 변수 튜닝 기능이 포함됩니다.
시나리오: Postgres로 처음으로 마이그레이션하는 조직은 느리게 실행되는 쿼리를 식별할 때 모범 사례 및 접근 방식에 익숙하지 않을 수 있습니다. 적절하게 새 인덱스 형식을 구현할 때는 특별한 주의와 주의가 필요합니다. 특히 Postgres 데이터베이스 엔진은 쿼리 힌트를 지정할 필요 또는 기능 없이 쿼리 성능을 최적화하도록 설계되었습니다.
권장 솔루션: 확장은 Postgres를 매우 강력하게 만드는 중요한 부분입니다. 데이터베이스가 최고 성능에서 작동하도록 지원하는 중요한 기능을 제공할 수 있는 몇 가지 확장이 있습니다. 고려해야 할 몇 가지 주요 확장은 다음과 같습니다.
auto_explain: 설정된 임계값을 초과하여 실행되는 쿼리에 대한 실행 계획을 자동으로 기록합니다. 데이터베이스 관리자가 각 쿼리에서 EXPLAIN를 수동으로 실행하지 않고 성능 문제를 진단하고 쿼리 성능을 최적화할 수 있습니다.
pg_trgm: 삼각 일치를 통해 텍스트 기반 데이터의 유사성을 결정하는 함수 및 연산자를 제공합니다. 이 확장은 텍스트 검색, 유사 항목 일치 및 유사성 기반 쿼리와 관련된 작업에 유용합니다. 텍스트 열의 GIN 또는 GIST 인덱스와 결합하면 LIKE 쿼리 및 유사성 검색의 성능이 향상됩니다.
pg_cron: 데이터베이스 내에서 직접 정기 작업을 예약하고 관리할 수 있습니다. cron과 유사한 작업 예약을 Postgres에 통합하여 일상적인 유지 관리 작업, 데이터 처리 및 유사한 반복 작업을 자동화할 수 있습니다.
팁
데이터베이스 작업에 데이터베이스 개체를 반복적으로 만들고 삭제하는 작업이 많은 경우 이전 pg_catalog 시스템 테이블 튜플이 증가하여 테이블 "bloat"이 됩니다. pg_catalog 많은 데이터베이스 작업에 관련된 시스템 테이블이므로 이 테이블에 대한 완화되지 않은 유지 관리로 인해 데이터베이스 전체의 성능이 저하될 수 있습니다. 되풀이 pg_cron 일정을 구성하여 pg_catalog 적절하게 유지 관리되고 적절하게 진공 청소되도록 보장할 수 있습니다.
- pg_hint_plan: Postgres는 수동 개입 없이 일관되고 안정적인 성능을 제공하는 것을 목표로 하므로 쿼리 힌트를 포함하지 않는 의도적인 디자인 결정이 내려집니다. 쿼리 계획 디자인에 대한 구체적이고 정확한 제어가 필요한 일부 시나리오의 경우 pg_hint_plan SQL 주석에 포함된 힌트를 사용하여 쿼리 플래너의 결정에 영향을 주는 방법을 제공합니다. 이러한 힌트를 사용하면 데이터베이스 관리자가 복잡한 쿼리를 최적화하거나 플래너가 자체적으로 처리할 수 없는 성능 문제를 해결하기 위해 쿼리 플래너가 특정 계획을 선택하도록 안내할 수 있습니다.
참고 항목
이러한 예제는 Postgres 데이터베이스에서 사용할 수 있는 매우 방대한 확장 집합의 표면을 긁는 것입니다. 이러한 확장을 완전히 탐색하여 Postgres 데이터베이스를 과급하는 것이 좋습니다. 또한 현재 기능 이상으로 Postgres를 확장할 수 있는 가능성을 볼 수 있는 고유한 확장을 작성할 가능성도 고려할 수 있습니다. 강력한 유연한 확장 아키텍처를 통해 Postgres는 항상 플랫폼 요구 사항에 맞게 적응하고 발전할 수 있습니다.
시나리오: 경우에 따라 레거시 테이블 파티션 전략으로 인해 수천 개의 파티션이 생성되었습니다. 이전에 사용했을 때 효과적일 수 있지만 이러한 전략은 특정 상황에서 Postgres의 쿼리 성능을 저하할 수 있습니다. 매우 구체적인 경우 쿼리 플래너는 쿼리를 구문 분석할 때 적절한 파티션 키를 결정하지 못할 수 있습니다. 결과 동작은 확장된 계획 시간을 생성하고 쿼리 계획이 실제 쿼리 실행보다 오래 걸립니다.
권장 솔루션: 너무 많은 수의 파티션을 생성하는 분할 전략의 필요성을 다시 평가합니다. Postgres 데이터베이스 엔진은 더 이상 동일한 데이터 분할이 필요하지 않을 수 있으며 파티션 수를 줄이면 성능이 향상될 수 있습니다. 레거시 분할 체계가 평가되고 필요한 것으로 확인되면 먼저 동적 파티션 키를 식별하고 추출하기 위해 쿼리를 개별 작업으로 재구성한 다음 쿼리 작업에서 파티션 키를 사용하는 것이 좋습니다.
시나리오: 때때로 외부 종속성 및 환경 상황에서는 Oracle 및 Azure Postgres 데이터베이스가 공존해야 하는 하이브리드 데이터베이스 시나리오가 필요할 수 있습니다. 예를 들어 데이터를 가져오거나 복잡한 ETL 프로세스를 수정하는 오버헤드 없이 Azure Postgres에서 직접 Oracle 데이터에 액세스하고 쿼리하기 위해 단계적 마이그레이션이 필요한 경우가 있을 수 있습니다. 다른 경우에는 Oracle 및 Azure Postgres 환경 모두에서 동등한 데이터 세트를 동시에 비교하여 병렬 데이터 유효성 검사를 수행하면 마이그레이션 중 및/또는 마이그레이션 후에 데이터 일관성과 무결성을 보장하는 데 도움이 될 수 있습니다.
권장 솔루션: PostgreSQL FDW(Foreign Data Wrapper) 확장은 외부 시스템에 저장된 데이터에 액세스하고 해당 데이터가 기본적으로 Azure Postgres 데이터베이스 내에 있는 것처럼 조작할 수 있는 주요 Postgres 기능입니다. FDW를 사용하면 Azure Postgres가 페더레이션된 데이터베이스로 작동할 수 있으므로 Oracle 데이터베이스를 비롯한 여러 외부 데이터 원본과 통합할 수 있습니다. FDW는 Postgres 데이터베이스 내에서 외장 테이블 정의를 만들고 이러한 외세 테이블은 정의된 외부 데이터 원본에 대한 프록시 역할을 하여 사용자가 일반 SQL 쿼리를 사용하여 이러한 외설 테이블을 쿼리할 수 있도록 합니다. 내부적으로 Postgres 엔진은 외부 FDW 정의를 사용하여 원격 데이터 원본에서 요청 시 데이터와 통신하고 조정합니다.
oracle_fdw: (Oracle용 Foreign Data Wrapper)는 Azure Postgres 내에서 Oracle 데이터베이스에 액세스할 수 있는 Postgres 확장입니다. Oracle에서 Azure Postgres로 마이그레이션할 때 oracle_fdw 데이터 액세스, 데이터 유효성 검사, 증분 마이그레이션 및 실시간 데이터 동기화를 제공하여 중요한 역할을 할 수 있습니다. FDW를 사용할 때는 다음과 같은 주요 고려 사항을 염두에 두어야 합니다.
- oracle_fdw 통해 쿼리를 실행하면 원격 Oracle 서버에서 데이터를 처리하고 가져오는 동안 네트워크 통신 및 인증 협상 형식으로 오버헤드가 발생합니다.
- 일부 데이터 형식은 시스템 간에 데이터 형식이 올바르게 매핑되도록 특수한 처리 또는 변환이 필요할 수 있습니다.
oracle_fdw 효과적으로 사용하면 전체 마이그레이션 프로세스 전체에서 애플리케이션 및 데이터에 계속 액세스할 수 있도록 하여 데이터베이스 전환을 간소화하고 데이터 접근성을 보장하는 데 도움이 될 수 있습니다.