|
-
OK... here is the deal.
1- Since you have stated you need the ORDER BY, that's not your problem.
That's a business requirement which by definition can't be a problem.
2- Your problem is how much data are you sorting at ORDER BY time.
Then, you have to limit how much data are you sorting.
3- How to limit how much data are you sorting?
You have to limit the number of rows returned by your inline view.
4- How to do that?
You have to stop doing Full Table Scan on that table.
Since I do not have access to your system, follows an extreme solution.
a) Build a non-unique index on mb_fix_message.msg_message_type
b) Create a pivot table with a single column: msg_message_type
c) Populate your pivot table with a row for each msg_message_type value you want to retrieve from mb_fix_message
d) Gather fresh stats on both your pivot table and your mb_fix_message table, including indexes.
e) Now, make your pivot table the driving table and your original table your lookup table by writing your inline view like:
Code:
(
select a.msg_oid, a.msg_log_time
from mb_fix_message a,
pivot_table b
where b.msg_message_type = a.msg_message_type
)
f) Do an Explain Plan of your inline view alone, finetune it until you have FTS on pivot_table and index range search on original table.
Good luck!
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|