Printable View
Not necessary.. Same plans can take twice the time for 4K block size as it took with 8K block size..Quote:
Originally posted by marist89
but the more likely culprit would be the query plan changing.
Yes am hinting at sequential scans.. (and ofcourse with scattered scans also unless DBMBRC is made twice as was with 8K block size)..
Abhay.
I didn't say "THAT'S IT!", I said "more likely". You can shrug your shoulders and resign yourself to the fact that your queries are now slower, or you can figure out the reason. With three lines of explanation of the problem without knowing any details, I'd spend my time figuring out of the query plan changed. But that's just me...Quote:
Originally posted by abhaysk
Not necessary.. Same plans can take twice the time for 4K block size as it took with 8K block size..
Yes am hinting at sequential scans.. (and ofcourse with scattered scans also unless DBMBRC is made twice as was with 8K block size)..
Abhay.
Jeff,Quote:
Originally posted by marist89
I didn't say "THAT'S IT!", I said "more likely". You can shrug your shoulders and resign yourself to the fact that your queries are now slower, or you can figure out the reason. With three lines of explanation of the problem without knowing any details, I'd spend my time figuring out of the query plan changed. But that's just me...
I didnt mean to pin point you.. was just concerned if the original poster go and try comparing plans of each and every query, and by chance if he know that his application access data mostly by Index Look ups .. then it would be useless to do such a excercise..
Abhay.
Try setting this parameter in your init.ora file then re-start your database.
optimizer_features_enable=8.1.7
I had the same problem when I moved one of our 8.1.7 database to 9.2.0.1. Luckily I have another copy of the database and I was able to compare the execution plan.
excellent point!Quote:
Originally posted by edsperez
Try setting this parameter in your init.ora file then re-start your database.
optimizer_features_enable=8.1.7