Posts Categorized: Technical Blog
Here’s a test scenario of encryption RMAN backup sets on disk:
App::perlbrew is a tool that simplifies down to triviality the process of making local perl installations. With it, any user can, in the span of a few minutes, have a working perl that is totally independant of whatever the system has. This is a win for you — you’re now in control of your perl, and of your destiny — as well as for the sysadmin, who is now free of the prickly choice between system integrity and users’ happiness. The path to self-sufficient brewing is incredibly easy. First, you have to download and install perlbrew
Last week brought great news to Pythian – one of our DBAs in Pakistan, Fahd Mirza, has become an Oracle ACE. Fahd joined Pythian in September 2010 as the very first Pythian employee in Pakistan and thanks to his skills and ambitions ended up on the team supporting Exadata environments. I should also mention that another Oracle ACE DBA joined us recently – Jared Still. Jared is a well respected member of Oracle community, member of the OakTable Network and a veteran of the Oracle-L mailing list
Greg Rahn of Oracle’s real-world performance group posted a technical review of an article I wrote last summer, entitled Making the Most of Oracle Exadata. I have a few comments on the technical concerns Greg raised.
I’m working on a small story about database consolidation and interested to learn what are success and failures that others are going through. While we have our own experience at Pythian, I find it interesting to learn about what others are going through. If you have enough details, it would be nice to see your feedback along these lines…
I’ve seen many a good DBA make the master of starting slaves from the position in the master.info file, most recently this week, that I want to bring it to everyone’s attention.
The scenario goes like this: The instance was in nomount stage and was unable to mount the database. Checked the uptime, and found that the server was rebooted some 5 minutes ago, and the instance tried to come up automatically but failed to mount the database. Checked the alert log and found the following error: ORA-214 signaled during: ALTER DATABASE MOUNT…Made a quick searched about ORA-00214 and it was about mismatched control files. It was probably due to the fact that control files got out of sync as the not-so-graceful reboot of the server was done without first cleanly shutting down the database. This is what doc says:
Today I’ve spent some time (more than this issue was worth, actually) on a client’s system trying to find out why table was not accessible and failed. The error message suggested something went very wrong with .frm file and I already started thinking about restoring the table from backup, when I noticed that accessing any InnoDB table was producing same error. A quick check of the error log showed that when MySQL server was restarted some time ago InnoDB failed to initialize due to a memory issue.
For this blog I have compiled the main information regarding JDBC drivers specifically considering the 11gR2 platform, but the concepts and idea also apply for older platforms as well.
It started out innocently enough: Two node RAC cluster on two Linux RHEL5 with Netapp NFS used as shared filesystem for all shared files. My favorite OS and storage, so I felt confident that clusterware installation will be as smooth as it usually is. I told the customer that this can be done in 3 hours. What I didn’t take into account is that this was my first 11gR2 installation, and that much have changed since 11gR1. As things turned out, it took over 20 hours of my time and a lot of help from colleagues and even former colleagues before we had a successful installation. The time it takes you to read this blog post (and any other on this subject) is likely to be time well spent.