Thank you all for your responses my original questions were :-
1. Has anyone got experience of running Oracle V7.323 on a UNIX V4 system.
We are currently running it on V3.2 D UNIX with a view to upgrading to UNIX V4 shortly and would
be interested to find out if there are any known problems or 'gotchas' in doing this.
We would also be interested to know if anyone is using Oracle V7.33 on UNIX V4 with a view to
finding out any problems or 'gotchas' with it.
2. Has anyone got experience with using Oracle and ADVFS. We are about to implement ADVFS
with a view to utilize the cloning facility for backup purposes.
In short what we plan to do is minimize downtime by shutting down the database - doing a clone
start the database backup - let the users back on - roll the clone of to tape as the database backup. Is there any issues with this i.e.. can we restore the clone and be sure of a clean
error free recovery. We plan to use vdump initially with a possible view of using NSR in the future.
Summary 1
Several people are using this successfully on 'test' platforms and have not experienced any problems. However I received an interesting response from Bryan Fredrick who is experiencing
some nasty problems. Which are pasted below
We upgraded one of our Alpha 2100 systems to V4.0 DU and 7.3.2 Oracle
recently. We had to upgrade first to 7.3.2.1, upgrade the database
objects, then go to 7.3.2.3. At first we didn't have the 7.3.2.3 patch,
having only the 7.3.2.2 patch upgrade, and we could NOT make 7.3.2.2
work, no way, no how. There were a bunch of patches for 7.3.2.2 according
to Oracle TS, but instead of going through that agony, we just had them
send out a 7.3.2.3 CD and went directly from 7.3.2.1 -> 7.3.2.3. To run
7.3.2.3 on DU4.0 you HAVE TO install patch 424307. Without it ORACLE would
complain about the control files and would not mount the database. As you
can probably tell, this wasn't a one-timer for us. We had to install,
upgrade, find a problem, de-install, get a patch, install it, find a problem,
deinstall, many times. We still have a problem where the RDBMS core dumps
during our nightly exports. I've also heard from other people of dispatchers
dying and a few other neat gotchas. I'm not altogether convinced that 7.3.2.3
is completely ready for "prime-time". Luckily we installed in a test environment before taking out our production machines.
>Can you give me a bit more detail on the problems that you are experiencing
>with RDBMS core dumping.
I believe this is a data problem with a BLOB table (where MS-Word documents
are stored) we have in our database. I could probably drop the table and
recreate it, as it is a test machine, but I'll wait until Oracle TS (who are
currently looking at the problem) makes that recommendation. An "ANALYZE TABLE
VALIDATE STRUCTURE;" doesn't report errors on the table. The danger here
is if you're not watching disk space closely (like in this test environment) the
core dumps consume all available disk space and then ORACLE does some pretty
funky things (like corrupting it's own executable images).
..............
Summary 2
General consensus is that ADVFS cloning with Oracle is find. However I received a few important
reminders from some of you.
1. Keep a eye on enough available disk space for cloning, I do not see a problem with your approach. As you may know, initially when you create a clone, it's physical disk space requirements are zero. But whenever Oracle writes to a table, the original blocks first are written to the clone. So if during your backup procedure your entire database would be altered, you would need twice the space of your operational database. Also write performance may somewhat degrade since for each write there is another one to the clone. A big advantage of V4.0* AdvFS over V3* AdvFS is that it is parallelized, meaning in a SMP system all AdvFS load is distributed over the available processors.
2. Oracle does not officially support cloning advfs fileset as a way to do online backups. If you must, shutdown the database cleanly first, clone the fileset (and log and control file if these live on another fileset), and restart the database. Although this forces you to shut the database down, it's much safer than cloning the fileset without letting the database know about it. A clone made with database shutdown is as good as a cold backup. Setting tablespace in backup mode and cloning the fileset will not buy you what you're looking for.
3. AdvFS clones for backup purposes sounds fine. Just beaware of one thing: until the backup to tape is complete, you don't have a backup. What I mean is that if you stop the database,clone the fileset, let users back on, start your backup, and then two minutes into the backup you lose one of the disks in your domain, your clone will not be usable.
Samantha Miller Kingston-SCL
Technial Support Group 96 Clermiston Road
Tel: +44 131 3144 5345 Edinburgh EH12 6UP
FAX +44 131 314 5201 SAMANTHA.MILLER_at_KSCL.COM
Received on Mon Mar 24 1997 - 13:34:09 NZST