Prompted by an email from Yves Colin (who’ll be presenting on the Tuesday of UKOUG Tech14) I was prompted to dig out a little script I wrote some years ago and re-run an old test, leading to this simple question: what’s the largest size array insert that Oracle will handle ?
If you’re tempted to answer, watch out – it’s not exactly a trick question, but there is a bit of a catch.
Earlier this week, I attended the 2014 East Coast Oracle Users Conference in Raleigh/Durham, NC. The conference was awesome. It was great meeting new attendees as well as seeing a few of the regular, familiar, faces in our community. That being said, if you’re in the area, I’d certainly recommend attending. Likewise, at the conference, I presented, […]
A fairly important question, and a little surprise, appeared on Oracle-L a couple of days ago. Running 184.108.40.206 a query completed quickly on the first execution then ran very slowly on the second execution because Oracle had used cardinality feedback to change the plan. This shouldn’t really be entirely surprising – if you read all the notes that Oracle has published about cardinality feedback – but it’s certainly a little counter-intuitive.
Just a quick note that I posted slides for the 2 talks I did at ECO in Raleigh this week:
Great crowd. I really enjoyed myself.
Note: You can also find other presentations on my Whitepapers/Presentations page via the link at the top of the screen.
The new Oracle Enterprise Manager 12c Command Line Interface book is available via a number of locations, including Amazon and directly from<
As shared by a well known Oracle and Big Data performance geek!
SQL> ALTER SYSTEM SET inmemory_size = 5T SCOPE=spfile; ALTER SYSTEM SET inmemory_size = 5T SCOPE=spfile * ERROR at line 1: ORA-32005: error while parsing size specification [5T] SQL> ALTER SYSTEM SET inmemory_size = 5120G SCOPE=spfile; System altered.
One of the worst problems with upgrades is that things sometimes stop working. A particular nuisance is the execution plan that suddenly stops appearing, to be replaced by an alternative plan that is much less efficient.
Apart from the nuisance of the time spent trying to force the old plan to re-appear, plus the time spent working out a way of rewriting the query when you finally decide the old plan simply isn’t going to re-appear, there’s also the worry about WHY the old plan won’t appear. Is it some sort of bug, is it that some new optimizer feature has disabled some older optimizer feature, or is it that someone in the optimizer group realised that the old plan was capable of producing the wrong results in some circumstances … it’s that last possibility that I find most worrying.
The last OpenWorld I attended was back in 2009, when I was still in my twenties, prior to my several-year-hiatus from the speaking circuit. At that conference, Oracle had accepted my submission to present “The Life of an Oracle Query.” It was fun to present at an actual Oracle conference. What was even better, in addition […]
No, not the 10th posting about first_rows() this week – whatever it may seem like – just an example that happens to use the “calculate costs for fetching the first 10 rows” optimizer strategy and does it badly. I think it’s a bug, but it’s certainly a defect that is a poster case for the inherent risk of using anything other than all_rows optimisation. Here’s some code to build a couple of sample tables:
A quick question out to the world. What management tools do you use for MySQL?
We currently have: