Posts Categorized: Pythian
So you have followed the recipes to create a standby database, setup the database to switch logs automatically, and now, as with any good database, the space required to support the application grows and grows and grows. Eventually, using your monitoring software (in my case, Pythian’s avail or dailies), you get an alert suggesting that you will need to add additional space. In this case you are going to add a datafile to a tablespace, or add a brand new tablespace.
Yesterday was the opening and I should say it was great — nice tour on the Whiskey Heritage Center and couple interesting and humorous sessions delivered by Jonathan Lewis and Graham Wood combined with whiskey tasting. The evening obviously continued after that but you can assume that anyway if you know what I’m talking about.
If you are following my blog then you might recall that I’m going to make a presentation on the Miracle Scotland Database Forum 2007. My presentation is called RAC load testing adventures and it’s based on a project I’ve been through with one of our clients.
Welcome to the 46th edition of Log Buffer, the weekly review of database blogs.
With this post, I’m starting a series about Oracle Block Change Tracking internals. The feature was introduced in Oracle 10 Release 1. I have already published my past presentations and the white paper about that. When I first started, I tried to dig at least something from Metalink, but the public notes contained no implementation details. What I extracted is some pieces of bug texts, and from there I concluded that fixed tables starting with X$KRC are most probably related to the BCT feature.
I’ve just added 6 reports about RAC in the SQL*Developer Plug-In.
With the help of an anonymous friend, I’ve made available a new SQL*Developer Plug-In.
The excellent Doug Burns has published the 45th edition of Log Buffer, the weekly review of database blogs, on Doug’s Oracle Blog.
One of our clients had an ORA-1555 “snapshot too old” error two nights in a row. The quick and dirty fix would be to increase the retention_period and the potential size of the UNDO tablespace. I was looking at it together with Dave, my new team mate, and a small detail popped up right away — Query Duration=76584 — 21+ hours? I checked the retention period, and it was 2 hours, so the dirty fix would probably fail unless it’s very dirty — dumping undo retention to something like a day and blowing the UNDO tablespace, and still without guarantee that the query finish within a day.
I just want to raise a warning flag for DBAs using RMAN and flash recovery area in Oracle 10g. The lesson is, to avoid backing up archivelogs that have already been backed up when using plus archivelog in a backup script, make sure you enable RMAN optimization.