« February 2006 | Main | April 2006 »
March 29, 2006
Checking Out 10g
Troy has set up a very nice test instance of the 10g database for us to play with. This week we've spent several hours exploring such things as "flashback" and complete database restores using Oracle Enterprise Manager. The flashback feature of 10g is worth the upgrade all by itself. It's kind of like the Windows recycle bin. If a table is accidentally dropped or the data is somehow lost, it is a fairly simple and quick way to restore the lost object. The table can be restored in literally a minute or two. Thinking this was so nice, we also tried dropping an entire tablespace. This didn't work near so nice, as Troy wound up eventually having to reinstall the database the first time we tried to restore the tablespace. We have now managed to recover the database after a tablespace was dropped, but haven't yet been able to replace the missing tablespace. Also, we looked at recreating a dropped package. This is different from other objects in that a compiled version of the package is stored in the database in binary form, and the text of the package is stored in the SYS tablespace. We looked up the table that stores the package text, and Mike Ellis is going to work on a job that backs up this table each night, then write a routine that will recreate any dropped package from the saved table. This means you would lose at most one day's work on a dropped package. (I recommend keeping a complete, current set of your packages on one of the network drives, but can see that not everyone is going to keep those up.)
I'm looking forward to getting 10g up and running as our production database this Summer. It has some very handy features especially in the area of recovery and restore.
Posted by rossm at 8:11 AM | Comments (0)
March 23, 2006
RMAN Is "Handled"
As you know, Dale and I have been expanding our knowledge of Oracle recovery and restore, particularly using Oracle's Rman - recovery manager. We have studied the Oracle manuals and gotten a good handle on the concepts involved and the things needed to make restores available on Aero. The roadblock we've hit here is this: first, we can't play with rman on our production database. Second, we talked with Troy and he has already got rman going on a test instance of 10g. Furthermore, the current goal is to move Aero to another server and upgrade to 10g this Summer. So, it seems unlikely that we will be able to get anything satisfactory in place much before the database is moved and upgraded. Therefore, we've concluded that pursuing rman on Aero any further isn't a good use of our time. We've gathered some valuable knowledge and we're going to take on something new. We both agree that learning more about Oracle is the direction we want to take. Presently we're considering two things: performance tuning or Analytics. We'll keep you advised of what we decide to do. Either of these options will be useful whatever version of Oracle we have running.
Posted by rossm at 11:45 AM | Comments (0)
March 20, 2006
2005.2 Upgrade "In the Mail"
Two new services (a Java JRE and a Sealms daemon for the GUI interface)have been added to the Bookstore's server, and the 2005.2 upgrade CD's are in the mail as of late last week. Interestingly, the MBS 2005.2 Upgrade "Addendum" CD has already arrived. The Addendum is to be applied after the upgrade to correct errors in the upgrade. Yes, I am glad we took a good, long look at the upgrade and didn't just jump in there and apply it right when it was first made available. The upgrade (and Addendum) will probably be applied one night next week as this week is buyback and not good timing for messing with the server.
Posted by rossm at 9:01 AM | Comments (0)
March 17, 2006
WOU's Faculty Negotiations and President Minahan's Talk
Hey, what good is "rants and such" if you can't blast off a good rant once in a while? So, if you're easily offended, read something else.
I attended the "meeting" on Wednesday at noon. It was generally a good meeting and Pres. Minahan did an EXCELLENT job! The faculty member's comments that "we don't have the money" (Pres. Minahan's basic position) isn't a good premise for "negotiating" because it's always the first move in any negotiation was very interesting. And, I think, also very weak. Just because it's been used elsewhere as an excuse, doesn't mean it is never true. In the current circumstances, PM's (Pres. Minahan's) premise is TRUE. I'm convinced that PM has carefully considered WOU's financial status. Further, he KNOWS WHAT HE'S TALKING ABOUT. Who else has the knowledge of this place to match his? PM has WOU's best interests at heart, and is sincere in making his offer as good as it can reasonbly be. In fact, his offer is based on pretty shaky financial predictions. He could easily justify a lower offer based on WOU's current financial picture. The related position of "numbers lie" therefore PM's numbers lie (or are inaccurate) is also weak for the same reasons.
There was also a comment to the effect that faculty aren't the only ones bearing the financial burden here at WOU. As an unclassified employee I say RIGHT ON! We've ALL been under serious financial restrictions for at least the last three years, if not longer. I've seen my friends get layed off, got my "90 day" letter, had my own salary frozen, and had to do without such frivolous things as training and reference books. My point is that the weak financial position of WOU is not a new topic. Neither is it a frivolous negotiating "pawn", with a secret pile of money being hidden at the end of the rainbow. The faculty's demands don't seem to take the reality of the current situation into account.
I've just got to throw this out, too. We're suffering the real and serious effects of really weak leadership the past few years. Real and serious financial consequences as well as losses in many other areas. We now have strong leadership. This one fact will go a long way toward turning things around here at WOU. I hope to be part of the rebuilding effort.
Good job PM! Faculty, please reconsider what you're about to do to this place. I do not call your position "greedy" so much as it is just damn bad timing. WOU does not need any more bad press. WOU needs you to suck it up for another two years.
Posted by rossm at 9:23 AM | Comments (1)
RMAN Recovery Project
Dale and I have been learning the ins and outs of Oracle's rman recovery tool. Our current backup and restore process is good, and in the event of a major calamity we could restore our entire database in a reasonable amount of time. However, we do not have the ability to easily recover erroneously dropped objects, truncated tables, and such. It can be done, and it has been done, but we were hoping to put Rman into action to make the process easy and quick. So, our goal is to create a process whereby dropped or lost database objects can be easily restored.
We have taken the first big step in reaching our goal by chopping Aero into many, smaller tablespaces. What this does is allow us to restore objects in a single tablespace, which can be done by taking only that tablespace offline. The rest of the database will still be up and running, available to all other users. Wilb had essentially one huge tablespace (WEB) and all users shared this one tablespace, so taking it offline wasn't practical as it would effectively shut down the entire database. A tablespace is the smallest unit that can be manipulated when performing a restore.
An important piece of information: Oracle calls this process we are talking about RMAN TSPITR (Recovery Manager Tablespace Point In Time Recovery).
We were able to pretty easily connect up to Wilb in Rman. We were even able to take a test tablespace offline and completely restore it. Unfortunately, this is where "easy" went out the window. There is a HUGE difference between a complete restore of a tablespace (easy) and TSPITR (very difficult). The difference is that a complete restore can be done from the original database and the TSPITR has to be done from a CLONE (or AUX) database. In other words, you must create a completely separate database in which to do the TSPITR recovery, then export the object from this database back to the "real" database.
Another hard won piece of knowledge: The CLONE database must be started with a tablespace backup and a control file backup that PREDATES the time when the target object was lost. Think about this for a minute because it makes no sense right off. To perform a recovery, you have to be able to go back in time, start up the CLONE at this earlier time, then you can roll the CLONE forward in time until just before the object was dropped (using the archive logs). Once this makes sense to you, then you will be pretty much caught up with Dale and me. This is the piece (well, one of several as it turns out) that we are missing right now - you must have Rman running and performing Rman backups of the tablespaces and the control file BEFORE you can perform TSPITR. So, the first step is to divide up your database into nice, compact sized tablespaces. The second step is to get Rman up and running so that you have an Rman tablespace backup and a backup of the control file (the control file backup essentially contains a "snapshot" of the database state at a certain point in time). Notice that these backups don't have to be real regular - the only difference is how many archive logs you have to use, the key is that the backup PREDATES the losing of an object. For Aero we have months worth of archive logs, so any kind of reasonable rate for backup will work.
So far, so good. Now for the bad news. For reasons presently unknown, Rman on Wilb can not be configured. Issuing standard configuration comands to do such critical items as start auto backup of the controlfile throw errors, cause the database to go crazy, and in one case, to hang the entire database. The other bit of bad news is that, so far, we don't have the knowledge to run Rman on Aero in the clustered environment - can't even connect. Well, you know, the heart of computing science is in the solution of seemingly insoluble problems. That's where we are right now. We've done it before and we'll do it again!
So far, we've collected a solid base of knowledge of Rman. We at least know what it is we need. Now, we just have to get there. Also, we need to make our solution workable in 10g when we upgrade our production database. We're anxious to get to the point where we can provide this service to our fellow developers.
Posted by rossm at 8:35 AM | Comments (0)