Posts Categorized: Pythian
Doug Burns is finally here in Ottawa. You must see his smile in the airport – somehow he managed to read my comment and already expected me while I thought it would be surprise.
Steve Karam, the Oracle Alchemist, has published the 26th edition of Log Buffer, the weekly review of database blogs.
To the subject at hand (psst, there will be some technical stuff in the end)… A few days ago I came across Twitter. I liked that idea very much and even tried it for one evening. I don’t think Twitter fits my lifestyle, but I recognized a very familiar concept. Indeed, it reminds me of one feature of our Pythian Support Track. Time for a bit of technical stuff…since we are mostly talking about databases on this blog, here is a view in Oracle I found very useful one day: SYSTEM_PRIVILEGE_MAP.
Over-the-Top Tales from the Trenches:: Bringing order to the chaos of everyday DBA life.
Do you want to know a secret? Understanding it will prevent pain and gnashing of teeth, and also leave your face comfortably free of egg. Here it is: Some Oracle functions assume there are 31 days for each month of the year! The moral of the story: be careful when using MONTHS_BETWEEN for fractional dates.
Sheeri Kritzer has published the 25th edition of Log Buffer, the weekly review of database blogs, on The MySQL She-BA.
A short story depicting the life of an on call DBA
Welcome to the 24th edition of Log Buffer, the weekly review of the database blogosphere.
Carl Sagan is a personal hero of mine. Ten years ago today this gifted communicator died of cancer. And so today the community of bloggers that loved and admired Carl Sagan is having a spontaneous blogathon in his memory. You might ask, what does Carl Sagan have to do with being a good DBA? Believe it or not, a lot. Yes, really.
Welcome, reader, to the 23rd edition of Log Buffer, the weekly, human-edited review of the database blogosphere.
Oracle thinks it can make queries run better by not having to parse them repeatedly, so it grows the shared pool to keep as many queries as it can. Problem: the shared pool is now 4G+. That takes a while to trawl through, which of course adds to the spins on the library cache lock and pushes up CPU usage. I’m going to get into more detail on this when I have the time, but for this db, I think I’m going to switch to manual SGA and set a hard limit of 500M-1G on the shared pool