모든 쿼리에 사용할 수있는 병렬 처리 수준 (DOP) 제한

Oracle Exadata (11gR2)에는 비교적 강력한 데이터베이스가 있습니다.

• cpu_count는 24입니다
• parallel_server_instances는 2입니다
• parallel_threads_per_cpu는 2입니다

Oracle Enterprise Manager (OEM)의 관찰을 통해 쿼리가 연속적으로 실행되어 성능이 끔찍했습니다. 이를 해결하기 위해 모든 테이블, 구체화 된 뷰 및 인덱스가 병렬 처리를 활용하도록 변경되었습니다. 예 :

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

병렬화를 켜도록 시스템이 변경되었습니다.

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

이로 인해 성능이 향상되었지만 OEM에서 단일 쿼리가 96의 DOP (사용 가능한 모든 리소스)를 묶는 경우가 종종있었습니다. 그 결과 후속 쿼리가 DOP 1 (병렬화 없음)로 다운 그레이드되었습니다. 호깅 쿼리가 완료 될 때까지 성능이 저하되었습니다.

이 문제를 해결하기 위해 모든 쿼리에 사용할 수있는 DOP를 제한하려고 시도했습니다.

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

이것은 효과가 없었습니다. 제한을 초과하는 쿼리 (일반적으로 48 또는 96이지만 실제 패턴은 없음)가 자주 관찰됩니다.

단일 쿼리가 사용 가능한 모든 리소스를 사용하지 못하게하려면 어떻게해야합니까?

병렬 서버 세트 : PARALLEL_DEGREE_LIMIT는 병렬 처리 수준을 제한하지만 쿼리가 정렬 또는 그룹화되는 경우 병렬 프로세스 수는 두 배가 될 수 있습니다 (프로세스 간 병렬 처리를 가능하게하는 두 개의 서버 세트). 24 개의 제한으로도 48 개의 병렬 프로세스가 표시되는 이유를 설명합니다. 자원 관리자를 사용하여 DOP를 제한하는 경우에도 발생합니다.

병렬 힌트 : PARALLEL_DEGREE_LIMIT는 자동 병렬 처리 수준을 사용하는 명령문에만 적용됩니다. 하드 코딩 된 정도 또는 모든 유형의 개체 수준 병렬 힌트를 사용하는 문은 제한을 무시합니다. 힌트가 있다면, 왜 96 번을 보게되는지 설명 할 수 있습니다.

IO 보정 : 자동 DOP를 사용하지 않아 IO가 보정 되지 않았기 때문에 한계를 따르지 않을 수 있습니다. 이 쿼리는 IO가 교정되었는지 알려줍니다.

select * from V$IO_CALIBRATION_STATUS;

이전에이 문제가 발생하는 것을 보았지만 현재 시스템이 보정되지 않고 자동 DOP가 제대로 작동하는 것 같습니다. Explain Plan의 참고 섹션을 보면 이것이 실제로 문제인지 알 수 있습니다. - automatic DOP: Computed Degree of Parallelism is 2당신이 좋아 하는 것을 보았지만보고 싶지는 않습니다 automatic DOP: skipped because of IO calibrate statistics are missing.

PARALLEL_MAX_SERVERS 늘리기 : 병렬 서버 부족에 대해 걱정하는 대신 PARALLEL_MAX_SERVERS 를 크게 늘리는 것이 좋습니다. 메모리 설정에 따라 최소한 PARALLEL_THREADS_PER_CPU x CPU_COUNT x 동시 _parallel_users x 5 (240 ~ 960) 사이 의 기본값으로 돌아 가려고합니다 .

이 숫자는 많은 DBA에게 말도 안되는 소리이지만 실제로 다음과 같은 이유로 의미가 있습니다.

• Oracle 병렬 서버는 대부분의 사람들이 생각하는 것보다 훨씬 가볍습니다. (아무도 그것을 테스트하는 사람은 거의 없으며, 큰 DOP가 문제를 일으키는 한 가지 상황을 발견하고 높은 DOP가 항상 나쁜 것으로 가정합니다.)
• 처음 50 개의 행만 검색하지만 여전히 수십 개의 병렬 서버를 사용하는 GUI 도구에서 임시 쿼리를 실행하는 것이 일반적입니다. PARALLEL_MAX_SERVERS가 너무 낮지 않으면 이러한 쿼리는 많은 리소스를 소비하지 않습니다. 그런 다음 사람들은 완벽하게 합리적인 쿼리를 실행하여 소리를 지르므로 추악한 상황이 발생할 수 있습니다.
• 단일 쿼리에 대한 매우 큰 DOP가 항상 나쁜 것은 아닙니다. 모두 DOP를 계속 늘리면 오버 헤드가 너무 높아지고 성능이 크게 떨어질 것이라고 가정합니다. 그러나 많은 시스템에서 나는 엄청나게 높은 DOP조차도 확실히 감소하는 수익이 있지만 다른 세션에는 매우 불공평 할 수 있지만 더 나은 성능으로 이어질 것임을 발견했습니다. 그러나 추측하지 말고 테스트하십시오. 쿼리를 가져 와서 모든 종류의 DOP와 함께 최대 1000 개까지 실행하십시오. 놀랄 수도 있습니다.
• 예, 너무 많은 병렬 처리는 나쁠 수 있습니다. 그러나 시스템이 최적의 세션 수보다 약간 더 많거나 쿼리를 직렬화하여 기본적으로 중요한 작업을 강제 종료하는 것은 무엇입니까? 임의 제한을 도입하기 전에 시스템을 모니터링해야합니다.