Database Reference
In-Depth Information
Y Resource 'ora.LISTENER_SCAN2.lsnr' (1/1) will be
in state [OFFLINE]
Y Resource 'ora.asm' (3/1) will be in state
[OFFLINE]
Y Resource 'ora.knewdb.db' (2/1) will be in state
[OFFLINE]
Y Resource 'ora.knewracn4.vip' (1/1) will be in
state [OFFLINE]
Y Resource 'ora.net1.network' (knewracn4) will be
in state [OFFLINE]
Y Resource 'ora.ons' (knewracn4) will be in state
[OFFLINE]
Y Resource 'ora.proxy_advm' (knewracn4) will be in
state [OFFLINE]
Y Resource 'ora.scan2.vip' (1/1) will be in state
[OFFLINE]
2 Y Resource 'ora.knewracn4.vip' (1/1) will be in
state [ONLINE|INTERMEDIATE] on server
[knewracn1]
Y Resource 'ora.scan2.vip' (1/1) will be in state
[ONLINE] on server [knewracn1]
3 Y Resource 'ora.LISTENER_SCAN2.lsnr' (1/1) will be
in state [ONLINE|INTERMEDIATE] on server
[knewracn1]
To evaluate the impact of these operations on resources with the .ora prefix, you must use the SRVCTL command
with eval option. For example, to evaluate the failure consequence of DAT1 diskgroup by using SRVCTL command,
use the following:
$srvctl predict diskgroup -g DATA1
Resource ora.DATA1.dg will be started on nodes knewracn1,knewracn2,knewracn4
PDBs on Oracle RAC
In 11gR2 and previous versions of the database, if we want to implement a multi-tenancy database by consolidating
multiple sets of data for different business applications on a single database, we could put them into different
database schemas of one database. However, it can be very challenging to manage security and access auditing on
this type of configuration, as these different data sets share the same database. On the other hand, some applications
such as Oracle E-Business Suite (EBS) Applications have fixed schema names such as APPS, AR, GL, etc. In this case,
it is simply not allowed to consolidate more than one applications data set on the same database, as these data
sets have identical schema names, which is not allowed in the same Oracle database. One alternative option is to
run multiple database instances on the same database server, in which case you have multiple sets of database
background processes and SGAs, etc. This will definitely increase overhead on performance and capacity
requirements as well as administrative tasks.
Oracle 12c introduced a better solution to this multi-tenancy issue with the new architecture called PDBs.
This feature essentially allows having multiple PDBs within a big CDB that is run with a database instance of the
Oracle database software. This architecture can consolidate several data sets into separate PDBs within the CDB. And
these PDBs are a self-contained and can be easily plugged or unplugged to a CDB.
