Page 678
exclusive use; otherwise, the instance fails to open. A discussion of redo threads and the private and public options follows in a later section.
A parallel instance shares the SYSTEM rollback segment with the other instances operating against the database. You will need to add at least one additional rollback segment for each instance to use exclusively or else the instance will not start. After creating your database, which you have to do in an exclusive instance, you should use that instance to add the required rollback segments. Of course, you can add more than one rollback segment for each instance, following the same guidelines as you would in a single instance database.
When creating rollback segments for a parallel server, you can use private or public segments. Although they require a little more work initially, private rollback segments give you more control and are easier to manage in the long run. If you use private rollback segments, which are the default type, you need to list their names in the ROLLBACK_SEGMENTS parameter of their associated initialization file. For public rollback segments, you need the PUBLIC keyword in the CREATE ROLLBACK SEGMENT command. You also need to set the two parameters, TRANSACTIONS and TRANSACTIONS_PER_ROLLBACK_SEGMENT, to the required values. These can easily be set identically for all instances using an included parameter file if you need the same number of rollback segments for each instance. You can also control the number of public rollback segments each individual instance tries to acquire. Oracle computes the ratio of two different parameters, TRANSACTIONS and TRANSACTIONS_PER_ROLLBACK_SEGMENT, and determines the number of rollback segments the instance should obtain for its exclusive use by rounding the result up to the next largest integer (the CEILING function). The formula is:
Number of public rollback segments required = CEILING ( TRANSACTIONS/TRANSACTIONS_PER_ROLLBACK_SEGMENT )
Take care when using public rollback segments that you create a sufficient number for each instance to acquire the number it requests. As long as at least one rollback segment is available, an instance can start up. This can result in an instance acquiring fewer rollback segments than you expected, leading to a poorly performing instance. Of course, if an instance attempts to start up and there are no free rollback segments available because the other instances unexpectedly acquired them all, it simply will not be able to start.
This propensity of instances to be able to start with less than the required number of active rollback segments is one reason why private segments are preferred. Because you must name private segments, your instances will only start if they can acquire their designated rollback segments. If you accidentally name the same one in two different parameter files, only the first instance to start acquires it. The second instance fails to start rather than run without the rollback segment assigned to it.
The second reason for preferring private rollback segments is their location. When you create rollback segments, you can assign them to a particular tablespace. It may be useful to place the rollback segments for each instance in their own tablespace or set of tablespaces. This makes it easy to identify which instance(s) might be affected should the underlying disk drives become unavailable. Also, when using non-shared architectures, you should place the rollback segments on disks that are local to the instance. If you use public rollback segments, you have no
Page 679
control over which ones are acquired by which instance and each one could start up using rollback segments located on another node's disk.
CAUTION |
On some platforms, such as nCUBE, the database will only use public rollback segments. However, such implementations are rare. |
Every instance in a parallel server environment runs its own log writer (LGWR) process. On most platforms, these processes write to their own set of online redo log files. A couple of architectures support log writers that send their output to a centralized process where they are interleaved into a single set of log files. These are rare platforms and you can easily determine if yours is one of them from the installation guide. The remainder of this section addresses only instances that write their own redo log files.
A set of log files used by an instance is called a thread. As with rollback segments, you can make your threads either public or private. Also, like rollback segments, public threads of redo are acquired by an instance at startup from the pool of available resources and you have no control over which thread is acquired by which instance. Hence, the same concerns that relate to public rollback segments apply also to public threads of redo.
When using public redo threads, for example, you will not necessarily know which is being written by which instance, making it difficult to identify which users will be affected if you suffer disk failure. Also, you may not enable enough public threads for all your instances during database expansion and, consequently, less instances than you intended will be able to start. If you are using Parallel Server on a shared-nothing platform, you need to use private redo threads in order to place the associated log files on disks local to each instance's node.
You have to create and enable your threads of redo in an active instance. The commands to achieve this are options of the ALTER DATABASE command as demonstrated in Listing 27.3. You should note that a thread of redo must be created and enabled before its associated instance can be started.
Listing 27.3 Define a Thread of Redo and Make It AccessibleSQL> ALTER DATABASE ADD LOGFILE THREAD 2 2 GROUP 3 (`/ora/testdb/redo1/redo3a.log','/ora/testdb/redo2/redo3b.log') 3 SIZE 1M 4 GROUP 4 (`/ora/testdb/redo1/redo4a.log','/ora/testdb/redo2/redo4b.log') SIZE 1M; Database altered. SQL> ALTER DATABASE ENABLE PUBLIC THREAD 2; Database altered.