Re: Oracle 7 parallel Server
Date: 1996/08/04
Message-ID: <4u2vrb$6il_at_newsbf02.news.aol.com>#1/1
We have been running parallel server for a couple of years and there isn't much more work to running it than regular oracle. Plan your disk layout with the fact that your environment will be parallel and you will hardley notice the difference.
You do need to try to have all updaters for a table coming from the same machine, but some pinging caused by updaters on two or more oracle instances will not cause problems. Indeed if your system is truely a short transaction based system and your boxes have ample memory to support the UNIX lock manager programs then you can support a fair level of updates from both instances. The gc locks do require a fair amount of UNIX memory and if you run short Oracle will crash without giving you a decent message, just a 0600 error. If doesn't take long for system administration and dba to figure out which UNIX parameters to change. Also be advised that the parallel server lock manager I am talking about is actually hardware vendor provided and is not actually a part of oracle. The oracle lck0 process is separate.
I suggest that you will probably want to provide each instance with its own separate rollback segment tablespace and if you do not use private rollback segments that Oracle will calculate how many he wants and go get them. This can leave the second to start instance with too few rollback segments (even if the segments are listed in the init.ora). Use private segments or provide a more than ample number of segments. The instances do not share rollback segments in normal use except when one instance crashes the other instance will read the crashed instances segments to run backout.
Also the parallel default locking policy is round robin with one gc lock allocated for each 255 oracle blocks in the first database files until there are no more files or no more locks. If the lockes are used up before the oracle file blocks have been covered then the rdbms reuses the locks so that the lock that covers file 1 block 1 - 255 may also cover file 5, block 513 - 768 or some such. You can start with default locking and use v$ping to determine which files need to have gc locks allocated to them via the init.ora parameters. I think the parameter is gc_file_locks but you should be able to find it in the manual.
Be sure that all the parallel server parameters in the init.ora file that Oracle says much match for each instance of the database do in fact match.
One warning that you should know is that under 7.1.3 and lower is that when you compile a package in one instance of Oracle it goes invalid in the other instance. If you packages are large this can lead to memory error on execution if enough contiguous memory is not available to support a recompile. We used to load and pin our packages on startup, but the second instance to start was causing our first instance applications to run into 'module not found' errors since we use a lot of large 80 - 100K packages. We got around this by adding a dummy routine into each package that we use to load our packages into memory. This avoids the validation problem.
In your specification add: ' procedure loadme; -- dba standard '
and then in your body ' procedure loadme is
begin
null;
end;
end loadme; '
(Please double check my syntax, but the routine work.)
Finally, on our hardware platform to run parallel requires that all database data files be raw partitions and not UNIX file systems. You may want to check this out for your system. Some people seem to think raw partitions are a problem, but we have found them as easy to manage as unix files systems. Just plan your system in advance, and try to have spare raw partitions available to add to tablespace when they need another file or you lose a disk and need to do a file recovery.
That is about all the advise I have, and probably more than most people want to read. Good luck. Received on Sun Aug 04 1996 - 00:00:00 CEST