Re: Bad plan selected at the beginning of the month for partitioned table

From: Jonathan Lewis <>
Date: Thu, 1 Feb 2018 16:54:08 +0000
Message-ID: <MM1P12301MB165892103702F085C5AF55EFA5FA0_at_MM1P12301MB1658.GBRP123.PROD.OUTLOOK.COM>

Is this range partitioned, or interval partitioned ? If it's range, how does a partition get added to the table ?

I would suggest using dbms_scheduler to add one partition just before it is due to be populated and rolling stats forward (with slight adjustements - check dbms_stats.copy_table_stats) rather than adding lots of empty partitions. The scope for some queries doing silly stuff if very high if you've got stats describing a large volume of data that doesn't actually exist. (Obvious example - "select ... where partition_column > sysdate - 7")

Jonathan Lewis

From: <> on behalf of <> Sent: 01 February 2018 15:29
Subject: Bad plan selected at the beginning of the month for partitioned table

Hello everyone,

I'm currently battling an annoying problem and was hoping someone had a better solution than the one I came up with.

One of our databases has 2 frequent queries that run against a partitioned table. At the beginning of the month when the partition is empty they start doing a full partition scan instead of an index range scan (no surprise). However even after rows start being loaded to the partition and stats are gathered that night the plan does not change back. I have verified that the stats have been updated, numrows is populated, and the stats do not show as stale. But even after 3 days the bad plan continues to be used and app performance gets so poor that I manually purge the sql_id from the shared pool. It then reverts to the index range scan and everything is fine.

When I first encountered the problem I thought it was an easy fix, I'd just create a baseline. Unfortunately I then discovered that the text of the sql changes each month to give a month specific alias. E.g., something like select column1 "January 2018 Totals", column2... So the sql_id is different each month and any baselines or profiles will not be used. Also because of this I can't easily schedule a job to purge the plan. I'd donít want to schedule a job to flush the entire shared pool at the beginning of the month due to performance issues when everything is reparsed and the possibility of a bad plan being chosen somewhere else.

Barring any of you suggesting a more elegant suggestion I intend to precreate a few yearsí worth of partitions, copy stats from a current partition, and then lock them. Iíll put an Outlook reminder to do the same in a few years and hope Iím either still with the company or remember to pass this piece of lore down when I leave.

Any better ideas he asked hopefully?

Oracle on RH 6.

Jay Miller
Sr. Oracle DBA

Received on Thu Feb 01 2018 - 17:54:08 CET

Original text of this message