I don’t want to post the link to this (perhaps, it was left public unintentional?) but here is what I stumbled upon recently. This is a log of production maintenance of IT systems in Perth, Western Australia (as far as I could say):
Good idea but shouldn’t companies keep this sort of information private?
Pythian DBA’s have daily reports for each monitored database and some of the components are using charts to visualize the data. I’m a big fan of charts myself (when applied appropriately) and want to show how you can generate simple charts directly from the database. You’d be very surprised how easy it can be done from *any* database without installing any additional software or configuring something special.
This method is not limited to Oracle by any means — use it with MySQL, SQL Server or any other database as well as without a database — yes, visualize your sar data now!
In this example, we will plot a pie diagram with Oracle tablespaces. This would be very handy when you are starting to analyze the space allocation for a database. Here is the end result of the report for my Grid Control repository test database:
I apologize for off-topic on this blog but I think it’s important…
Victoria experienced unprecedented bushfire this month taking lives of almost 180 (the list is growing) people and leaving thousands without homes. This disaster left tears on everyone’s faces even outside of Australia.
If you would like to show the compassion and provide some help there are few ways. One of them is to contribute to the Red Cross Bushfire Appeal 2009. You don’t have to be in Australia to do that — you just need to have a big heart and few bucks to share.
Don’t forget to ask your company if they want to match your personal contribution — it’s a very effective way of raising funds for ones in need. We collected some money in our Sydney office and Pythian Australia matched that.
(more…)
Last week, I was at the NetApp office in North Sydney for the presentation on NetApp SnapManager for Oracle. It was good opportunity to learn more about NetApp snapshots while working on a project for one of our clients in Sydney. It was an especially interesting topic as I have some experience using Veritas Checkpoints (see my presentation on test systems refreshes), and it was interesting to see what’s different and new in the NetApp implementation. But I digress.
I learned that NetApp can provide access to the same LUNs via either Fiber-Channel (FC) or iSCSI. And this is when the interesting argument surfaced. Apparently, some companies aim to have the technology stack on their disaster-recovery site as different as possible from the primary production site. Their argument is that if one technology fails at the primary site (like FC to access storage), then the DR site using a different technology stack will more likely be unaffected.
Hrm . . . I had never thought about this, and when I consider it now, it still doesn’t appeal to me. If I design a highly-available solution with a disaster-recovery site in place, one of my priorities would be to switch between the sites comfortably at any time. The more differences two sites have, the lower my comfort level is.
The only reason why I think some companies can “demand” having different storage technology stacks at production and DR is to justify a more convenient (a cheaper?) implementation.
Thoughts? Comments?
According to Metalink Note 161818.1 Oracle Server (RDBMS) Releases Support Status Summary, Premier Support of Oracle 10g Release 1 ends in January 2009, which means that those of us supporting Oracle 10.1 databases have less support from Oracle from now on.
Recent Comments