Posts Categorized: Technical Blog
OEM 12c Cloud Control looks daily for new targets, placing them in a queue for admin promotion to managed objects. Details and troubleshooting info follow.
As usual, the who’s-who of the Oracle tech space will be assembling in Denver the week of February 11 for the Rock Mountain Oracle Users’ Group. A plethora of Pythian employees with be speaking as will we also have a booth in the vendor hall. Please drop by and say “hi”. See the full detail of who is presenting and when.
This post should give you some insights into the risk that your databases are in by switching to the bulk-logged recovery model. So, what do you need to do to avoid this risk? Make sure that you run a backup immediately after the transactions you are running under the bulk-logged recovery model complete.
I describe AlwaysOn Availability Groups as a “database mirroring configuration sitting on top of a Windows Failover Cluster infrastructure.” Why do I say this? It’s because I want SQL Server DBAs to leverage what they already know on features like database mirroring and failover clustering and apply them when dealing with AlwaysOn Availability Groups.
Following my “Building Integrated DWH with Oracle and Hadoop” webinar for IOUG Big Data SIG, I got a bunch of excellent follow up questions. The most frequently asked questions are: What is the minimum I need to do to get started with Hadoop? and How do I load data into Hadoop? Since so many people are interested in the same question, it makes more sense to answer on the blog.
I recently helped setup an Exadata X2-8 Database Machine with the latest version of OEM Cloud Countrol (220.127.116.11). A few documents do exist for this process. However I found a few inconsistencies and problems; I think the existing documents I found were written on older versions of OEM and older versions of the tools. I’m publishing my final procedure here with hopes that it helps you, but as always please cross-reference this with the appropriate documentation before doing anything in your own environment.
What happens when you update the crontab on a critical system to accommodate year-end processing? What happens when, despite all your diligence and devotion to human reliability guidelines, you perform a simple slip, and instead of typing crontab -e, you type crontab -r? Well, the documentation tells you what happens:
Pythian’s friendly Oracle e-Business Suite DBAs would like to congratulate all of our friends, clients, Pythian colleagues, prospects, new team members whom we haven’t yet met (join us!), all database geeks, and blog readers for successfully completing 2012! Have a very peaceful Christmas and the happiest year ever in 2013! May all of your pagers be quiet, and your year-end maintenance be incident-free! ;) Here comes our Christmas card to you :)
A client recently supplied a list of 50+ SQL IDs that should receive SQL profiles, and I’ve been working with Gwen Shapira to review the list. Further discussion showed that this list had come from the Automatic SQL Tuning feature, installed by default in Oracle 11g. The report includes a list of recommended SQL profiles ordered by “Maximum Benefit”, and in our case it included several hundred statements. The expected workflow, as far as I can gather, is to see the recommendations, look at the before- and after- execution plans, and accept the recommendations. Before blindly accepting recommendations, though, I like to see what exact changes are being proposed. They aren’t listed anywhere in the report, and require some extra work to uncover. The first step is to get the automatic SQL tuning advisor report. (
The environment was an Exadata environment undergoing pre-production stress testing. We used Real Application Testing to take a highly-concurrent OLTP workload, and replayed the workload with the synchronization parameter set to FALSE, effectively increasing concurrency beyond the original test system. AWR showed a large volume of buffer busy activity.