This note describes the new features related to the Oracle Database Multitenant option which have been introduced in Oracle 12c Release 2 (12.2.0.1).
The hands-on exercises included in the note demonstrates the use of the following new multitenancy features:
In Oracle 12c Release 2, tablespaces can now be encrypted while they are online and in read-write mode. In earlier releases, the tablespace had to be taken offline first or the database had to be in the mount state and not open.
In addition, now in 12.2 the SYSTEM,
Data Redaction was introduced in Oracle Database 12c Release 1 (read a note on this)
/awhere we could hide or mask sensitive data in tables from non-privileged users. The data was ‘redacted’ at query run time and was stored in the database in its normal non-redacted form. The redaction
The Oracle Exadata plug-in for OEM enables us to monitor as well as manage Exadata targets through Enterprise Manager Cloud Control 12c.
The features include:
Microservices Architecture is a method or approach to developing applications where an application is deployed as a suite of independently deployed small modular services.
Each module supports a specific business goal and uses a simple, light weight and well-defined interface to communicate with other sets of services.
Oracle GoldenGate Microservices Architecture (MA) is a similar architecture based on REST APIs which enable us to configure, monitor, and manage Oracle GoldenGate services using a web-based user interface.
So now in Oracle GoldenGate 12.3, we have two architectures available for deploying GoldenGate – the (original) Classic Architecture and the new Microservices Architecture.
The Microservices Architecture in Oracle GoldenGate is comprised of five main components:
Service Manager: Enables us to administer, monitor and manage other services available with Microservices Architecture. Through Service Manager, we can manage one or multiple Oracle GoldenGate deployments on a local host.
Administration Server: It is the central and main entity for managing the various components of a GoldenGate deployment. Administration Server can create and manage local Extract and Replicat processes even without access to the server where Oracle GoldenGate is installed. Tasks like creating or altering extract and replicat processes, creating credentials for GoldenGate security, viewing report files, adding supplemental log data, creating checkpoint and heartbeat tables etc can all be performed from web browser as well as from the command line Admin Client.
Distribution Server: It is a high performance application which functions as a networked data distribution agent. The Distribution Server distributes one or more trails to one or more destinations and also performs some filtering operations if configured to do so. It supports a number of different communication protocols including the classic Oracle GoldenGate protocol for communication between the Distribution Server and the Collector , WebSockets for SSL secured HTTPS-based streaming and Proxy support for cloud-based environments.
The Distribution Server is used to set up a Path between the source and target deployments.
Receiver Server: It provides the central services to handle all incoming trail files and communicates with the Distribution Server over the network.
Performance Metrics Server: It collects and stores performance data related to a GoldenGate deployment. Enables us to monitor performance metrics using a web application and use the data to tune deployments for maximizing performance.
Let us look at an example of GoldenGate 12c Release 3 Microservices Architecture (MA) at work!
We will be using a single Oracle 12c Release 2 database for this demo with two schemas – SOURCE and TARGET.
We will create the MYOBJECTS table in both schemas and perform some DML activity on the source table and note how replication is performed and managed using GoldenGate Microservices.
SQL> alter database force logging;
Database altered.
SQL> alter database add supplemental log data;
Database altered.
SQL> alter system set enable_goldengate_replication=true;
System altered.
SQL> create user oggadmin identified by oracle;
User created.
SQL> grant dba to oggadmin;
Grant succeeded.
SQL> exec dbms_goldengate_auth.grant_admin_privilege('OGGADMIN');
PL/SQL procedure successfully completed.
SQL> create user source identified by oracle
default tablespace users
temporary tablespace temp;
User created.
SQL> create user target identified by oracle
default tablespace users
temporary tablespace temp;
User created.
SQL> grant connect,resource,create table to source,target;
Grant succeeded.
SQL> alter user source quota unlimited on users;
User altered.
SQL> alter user target quota unlimited on users;
User altered.
SQL> conn source/oracle
Connected.
SQL> create table myobjects
as select * from all_objects
where 1=2;
Table created.
SQL> conn target/oracle
Connected.
SQL> /
Table created.
SQL> conn source/oracle
Connected.
SQL> alter table myobjects add constraint pk_myobjects
primary key (object_id);
Table altered.
SQL> conn target/oracle
Connected.
SQL> /
Table altered.
Launch the Configuration Assistant via the oggca.sh script located in the $OGG_HOME/bin directory. Through the Configuration Assistant we can create the Service Manager as well as configure the deployment.
A single Service Manager can support a number of deployments.
[oracle@linux01 Disk1]$ export TNS_ADMIN=/u02/app/oracle/product/12.2.0/dbhome_1/network/admin [oracle@linux01 Disk1]$ export OGG_HOME=/u04/app/oracle/ogg_ma [oracle@linux01 Disk1]$ cd $OGG_HOME/bin [oracle@linux01 bin]$ ./oggca.sh
Note: in this example we are not configuring any wallets or certificates required for SSL security.
Allocate the ports – enter 9001 for the Administration Server port and the other ports are assigned automatically by clicking in the port number fields.
[root@linux01 etc]# /u04/app/oracle/ogg_sm/bin/registerServiceManager.sh ---------------------------------------------------- Oracle GoldenGate Install As Service Script ---------------------------------------------------- OGG_HOME=/u04/app/oracle/ogg_ma OGG_CONF_HOME=/u04/app/oracle/ogg_sm/etc/conf OGG_USER=oracle Running OracleGoldenGateInstall.sh...
Edit the parameter file and add the TABLE parameter
Click on the Distribution Server link in the Service column.
Edit the parameter file and change the MAP and TARGET parameters
On the SOURCE schema MYOBJECTS table, we will now run an INSERT statement.
SQL> conn source/oracle Connected. SQL> insert into myobjects select * from all_objects; 56332 rows created. SQL> commit; Commit complete.
Click on the Action drop-down ….
Click on EXT1
One of the new features introduced in GoldenGate 12c Release 3 (12.3.0.1) is the Parallel Replicat feature.
So now in addition to the Classic Replicat, Co-ordinated Replicat and Integrated Replicat options, we also have another replicat option available as well.
The Parallel Replicat on the surface appears to be very similar to the Integrated Replicat in the sense that we can control the number of applier processes manually and also the apply process is auto-tuned as well where additional applier processes are added on the fly based on the workload being performed by the replicat process. This is managed by the Parallel Replicat parameters APPLY_PARALLELISM, MIN_APPLY_PARALLELISM and MAX_APPLY_PARALLELISM.
In addition, similar to the EAGER_SIZE which was used in the Integrated Replicat to help define what a ‘large’ transaction was, now in the Parallel Replicat we have something quite similar called CHUNK_SIZE.
We also have a parameter called SPLIT_TRANS_RECS which we can use to break a large transaction into logically smaller pieces which can then be applied in parallel. Dependencies are managed and maintained as well.
But what is different from the Integrated Replicat is that there is no requirement to set the STREAMS_POOL_SIZE and no Log Miner Server related processing happening inside the database.
Let us look at an example of using the Parallel Replicat feature.
The example assumes the following:
SQL> create table mysales (id number, flag number , product varchar2(20), channel_id number, cust_id number , amount_sold number, order_date date, ship_date date) ;
We will see how to use the web interfaces as well as the command line Admin Client to configure Parallel Replicat.
Launch Service Manager
Create a Classic Extract
Add the MYSALES table to the extract parameter file
Create the distribution path – very similar to creating the Extract Pump process in the Classic Architecture.
Create the Parallel Replicat. In this case we are creating a non-integrated Parallel Replicat.
Add the MYSALES table to the replicat parameter file
We next use the Admin Client to add some other parameters to the replicat parameter file.
We are changing the value of the parameter MAP_PARALLELISM from the default value of 2 to 4 – this controls the number of mapper processes which will scan or process the trail file.
The default value for APPLY_PARALLELISM is 4 which controls the number of apply processes.
The parameter SPLIT_TRANS_RECS will break up the transaction into units of 10000 rows each and these will be applied in parallel.
[oracle@rac03 bin]$ ./adminclient Oracle GoldenGate Administration Client for Oracle Version 12.3.0.1.0 OGGCORE_12.3.0.1.0_PLATFORMS_170721.0154 Copyright (C) 1995, 2017, Oracle and/or its affiliates. All rights reserved. Linux, x64, 64bit (optimized) on Jul 21 2017 07:16:02 Operating system character set identified as UTF-8. OGG (not connected) 1> connect http://rac03.localdomain:9001 deployment test_ogg_123 as oggadmin password oracle OGG (http://192.168.56.102:9001 test_ogg_123) 29> info all Program Status Group Lag at Chkpt Time Since Chkpt ADMINSRVR RUNNING DISTSRVR RUNNING PMSRVR RUNNING RECVSRVR RUNNING EXTRACT RUNNING EXT1 00:00:00 00:00:09 REPLICAT RUNNING REP1 00:00:00 00:00:10 OGG (http://192.168.56.102:9001 test_ogg_123) 30> edit params rep1 replicat rep1 useridalias oggadmin domain OracleGoldenGate MAP_PARALLELISM 4 SPLIT_TRANS_RECS 10000 MAP source.mysales, TARGET target.mysales;
Check that the extract and replicat process are both up and running.
On the source database, issue the INSERT statement which will populate the MYSALES table with 200,000 rows and commit the transaction.
SQL> insert into mysales select rownum, rownum + 1, 'Samsung Galaxy S7', mod(rownum,5), mod(rownum,1000) , 5000, trunc(sysdate - 10000 + mod(rownum,10000)), trunc(sysdate - 9999 + mod(rownum,10000)) from dual connect by level<=2e5 ; 200000 rows created. SQL> commit;
View the statistics of the extract process – similar to STATS ext1 LATEST command. Do the same for the Parallel Replicat.
Note the position in the trail files the extract and distribution server process pump1 are writing to.
We can see that the parallel replicat process is processing trail file rt000000000 and the location of the trail file now in the Micro Service architecture environment is under the specific deployment name top level folder in the /var/lib/data sub-directory.
OGG (http://192.168.56.102:9001 test_ogg_123) 40> info rep1 No EXTRACT groups found, but some coordinated threads may have been excluded REPLICAT REP1 Last Started 2017-10-19 16:55 Status RUNNING Parallel Checkpoint Lag 00:00:00 (updated 00:00:02 ago) Process ID 10459 Log Read Checkpoint File /u01/app/oracle/test_ogg_123/var/lib/data/rt000000000 2017-10-19 21:06:15.715609 RBA 42758112
Connect to the Performance Metrics Server home page from Service Manager home page and we can see the individual performance related metrics for REP1 parallel replicat process as well as the 4 mapper processes REP1M0* and 4 applier processes REP1A0*.
One of the new features in Oracle 12c Release 2 is real-time refreshable Materialized Views.
In earlier releases, even if a single row in the base table got changed, the underlying materialized view was marked as stale and this prevented any query rewrite operations until the materialized view
Trace File Analyzer Collector also known as TFA is a diagnostic collection utility which greatly simplifies the diagnostic data collection for both Oracle Database as well as Oracle Clusterware/Grid Infrastructure RAC environments.
Trace File Analyzer provides a central and single interface for all diagnostic data collection and analysis.
When a problem occurs, TFA collects all the relevant data at the time of the problem and consolidates data even across multiple nodes in a clustered Oracle RAC environment. Only the relevant diagnostic data is collected and can be packaged and uploaded to Oracle Support and this leads to faster resolution times. All the required diagnostic data is collected via a single tfactl command instead of having to individually look for the required diagnostic information across a number of database and cluster alert logs, trace files or dump files.
In addition to the core functionality of gathering, consolidating and processing diagnostic data, Trace File Analyzer comes bundled with a number of support tools which enable us to obtain a lot of other useful information like upgrade readiness, health checks for both Engineered as well as non-Engineered systems, OS performance graphs, Top SQL queries etc.
Oracle Trace File Analyzer is shipped along with Oracle Grid Infrastructure (from version 11.2.0.4). However, it is recommended to download the latest TFA version which can be accessed via the My Oracle Support Note 1513912.1 since the TFA bundled with the Oracle Grid Infrastructure does not include many of the new features, bug fixes and more importantly the Oracle Database Support Tools bundle.
Oracle releases new versions of the TFA several times a year and the most current version is Trace File Analyzer 18.1.1 which is now available for download via the MOS Note 1513912.1.
Select the version appropriate to your operating system. Note that TFA supports Oracle databases and Grid Infrastructure versions 11.2 upwards.
Installation
For a new installation, the recommended location is /opt/oracle.tfa and in case an existing version of TFA exists, it will be upgraded as part of the installation.
It is recommended to carry out the installation as the root user.
If root access is not available, the installation can be carried out by the ORACLE_HOME owner, but this installation will cause TFA to function with lower capabilities. Functionalities like automatic collections and collection from remote hosts will not be available as well as collection and analysis of files not readable by the ORACLE_HOME owner like /var/log/messages and log files pertaining to certain clusterware daemon processes.
The TFA download also includes Java Runtime Environment (JRE) version 1.8 which is required for running TFA.
To install TFA, download the appropriate platform specific zip file, copy it to the required machine and unzip. Then execute the file installTFA<platform>.
For example:
[root@autprorac1 oracle]# unzip TFA-LINUX_v18.1.1.zip
Archive: TFA-LINUX_v18.1.1.zip
inflating: README.txt
inflating: installTFA-LINUX
# ./installTFA-LINUX
The installation will prompt if a local install or a cluster install is going to be carried out. A cluster installation does require password-less SSH user equivalency for the root user to all cluster nodes. If this is not already configured, then the installation optionally sets up password-less SSH user equivalency for the root user account.
Running TFA
The Oracle TFA has a daemon process which is configured to start automatically on system start up. It runs from init on UNIX systems or init/upstart/systemd on Linux and in the case of Microsoft Windows runs as a Windows Service.
To start or stop Oracle Trace File Analyzer daemon manually we can use the tfactl start or tfactl stop commands.
We can also enable or disable the automatic restarting of the Oracle Trace File Analyzer daemon via the tfactl disable or tfactl enable commands.
TFA is invoked via the tfactl command which in turn can be run from the command line or from within the Shell interface or via the TFA Menu interface.
Automatic Collections
TFA is configured to collect diagnostic information automatically for a number of specific Oracle errors and we can also configure it to collect diagnostics for any other user-defined Oracle errors as well.
For instance the following Oracle and Cluster errors would have automatic diagnostic collection enabled:
ORA-297(01|02|03|08|09|10|40)
ORA-00600
ORA-07445
CRS-016(07|10|11|12)
When TFA detects a problem, it would collect the necessary and relevant diagnostic data related to the problem going back by default to the past 12 hours and would also trim the log files it collects to gather only the bare amount of information required for problem diagnosis.
It then would collect and package the diagnostic data and also consolidate the data on one node in case of a clustered environment. The diagnostic data is then stored in the TFA repository and if configured, can send an email notification that a problem has been detected and the collection of the packaged diagnostic data is now available for upload to Oracle Support.
On-demand Analysis and Diagnostic Collection
In addition to the automatic collection which is configured by default, we can use TFA to analyze all logs and identify any recent errors by performing an on-demand collection and analysis of diagnostic data.
We can collect diagnostic data based on a search string like say ‘ORA-00600’ and also specify the time duration in the past or time interval for which the diagnostic data should be analyzed.
Oracle Database support tools bundle
This is only available in case of TFA which is downloaded from My Oracle Support via the note 1513912.1.
ORAchk and EXAchk: Performs health check as well as upgrade readiness checks of the entire stack for both Engineered as well as non-Engineered systems
oswatcher: Utility to capture and store performance metrics from the operating system
procwatcher: Monitor and collect stack traces of database and clusterware processes using tools like oradebug and pstack
oratop: Utility similar to the unix OS utility top which gives a real-time overview of performance from a database perspective and can be used in combination with the unix top utility to get a more complete overview of system performance
summary, alertsummary, events: High level configuration summary as well as event details along with summary of events from clusterware and databases alert logs across all nodes
param: Find and display database and OS parameters that match a specified pattern
changes: Reports system changes for a given period of time which will include database parameters, operating system parameters, and the patches applied
Other utilities and tools: vi ls grep ps
One Command Service Request Data Collections
Very often when we raise a Service Request with Oracle Support, we are asked to provide additional log and trace files to help Oracle Support better diagnose the problem. Collecting the various log and trace files individually can be a laborious task and we may miss out collecting an important log file required by Oracle Support.
Oracle TFA now provides a single command SRDC (Service Request Data Collection) to collect exactly what is needed by Oracle Support (as well as the DBA) to diagnose a specific problem.
A wide variety of SRDCs are available covering Oracle errors like ORA-00600, ORA-07445, database performance problems (dbperf), database resource problems (dbunixresource), database install and upgrade problems (dbinstall,dbupgrade) , database storage problems (dbasm) etc.
Based on the SRDC, TFA will scan and analyze the relevant log and trace files it requires and then trims those files to only contain the required diagnostic information. The data is then packaged into a zip file which can be then uploaded to Oracle Support.
For example, the TFA command tfactl diagcollect -srdc dbperf will generate a bundled package containing files like the AWR report, ADDM report, ASH report, OSWatcher and ORAchk performance related checks.
Trace File Analyzer Repository
TFA stores all diagnostic data collections in the repository and the size of the repository is the lower of the value 10GB or 50% of available directory free disk space. The location of the repository is the sub-directory tfa/repository under the Trace File Analyzer installation top level directory.
The amount of data collected in the repository is determined by the Trace Level parameter which defaults to the value 1. The possible values are in the range 1-4 and a higher value will obviously lead to the repository being filled at a faster rate.
The Oracle TFA daemon process monitors and automatically purges the repository when the free space falls below 1 GB and by default purges collections older than 12 hours. This can also be configured by the parameter minagetopurge.
Trace File Analyzer Command Examples
tfactl summary
tfactl analyze -last 1d
tfactl analyze -search “ora-00600” -last 8h
tfactl set notificationAddress=joeblogs@oracle.com
tfactl set autodiagcollect=OFF
tfactl diagcollect -last 1 h
tfactl diagcollect -from “2018-03-21″
tfactl diagcollect from “2018-03-21” -to “2018-03-22”
tfactl diagcollect -all -last 12h
tfactl diagcollect -last 1d -node rac01
tfactl -diagcollect -database hrdb -last 1d
Execute tfactl setupmos to configure Oracle Trace File Analyzer with MOS user name and password followed by
tfactl diagcollect -last 1d -sr 1234567
tfactl analyze -search “ORA” -comp db -last 1d
tfactl analyze -last 6h
tfactl summary
tfactl access add -user oracle
tfactl access lsusers
tfactl run orachk
tfactl print config
Oratop is a utility very similar in nature to the ‘top’ unix OS utility.
It provides an almost real-time overview of both RAC as well as single-instance database performance and can be used in combination with top to get a more complete overview of system performance and identify and monitor any activity causing bottlenecks.
Oratop is available as part of the Trace File Analyzer (TFA) Collector package and also can be downloaded via the MOS note 1500864.1.
What information does oratop show us? – a lot!
For example:
And much more..!
We can launch oratop via the TFA menu interface as shown below :
We can also launch oratop from the command line via tfactl.
/u01/app/12.1.0.2/grid/tfa/aunmmorac1n1/tfa_home/bin/tfactl oratop -database “tppsnm1”
There are a number of switches available in the oratop utility to enable us to toggle the information which is displayed.
Let us have a look at some of them.
By default, oratop will display the Top 5 Wait Events since instance start. To view the information real-time we can use ‘d‘.
The Events are now shown real-time (RT) instead of the default (C).
Use ‘k‘ to toggle between Events/Latches and File Number and Data Block.
Use ‘m‘ to toggle between display of Programs and display of Modules.
Use ‘s‘ to toggle between Process Mode (default) and SQL Mode.
Use ‘t‘ to view Tablespace information.
Use ‘a‘ for ASM Disk Group information.
Use ‘x‘ to display the SQL Execution Plan for a specific SQL ID.
Use ‘i‘ to change the refresh or data gathering interval.
Use ‘h‘ to display the Help menu. We can view the Help menu for each section individually.
Oracle 12c Release 2 now provides the ability to reissue the previously executed SQL*Plus commands.
This functionality is similar to the shell history command available on the UNIX platform.
This feature enables us to run, edit, or delete previously executed SQL*Plus, SQL, or PL/SQL commands from the history list in
New in Oracle 12c Release 2 is the ability for scripts to be executed through the Data Guard broker DGMGRL command-line interface very similar to like say in SQL*Plus.
DGMGRL commands, SQL commands using the DGMGRL SQL command, and OS commands using the new HOST (or !) capability can be
Download the 18c Grid Infrastructure software (18.3)
Prerequisites
oracle soft stack 10240
grid soft stack 10240
Notes
During Upgrade:
[root@rac01 trace]# cd /u02/app/18.0.0/grid/bin
[root@rac01 bin]# ./crsctl query crs softwareversion
Oracle Clusterware version on node [rac01] is [18.0.0.0.0]
[root@rac01 bin]# ./crsctl query crs softwareversion -all
Oracle Clusterware version on node [rac01] is [18.0.0.0.0]
Oracle Clusterware version on node [rac02] is [12.1.0.2.0]
[root@rac01 bin]# ./crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [12.1.0.2.0]
[root@rac01 bin]#
After Upgrade:
[root@rac01 bin]# ./crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [18.0.0.0.0]
[root@rac01 bin]# ./crsctl query crs softwareversion -all
Oracle Clusterware version on node [rac01] is [18.0.0.0.0]
Oracle Clusterware version on node [rac02] is [18.0.0.0.0]
[grid@rac01 grid]$ cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain rac.localdomain
nameserver 192.168.56.102
options timeout:3
options retries:1
Create the directory structure on both RAC nodes
[root@rac01 app]# su – grid
[grid@rac01 ~]$ cd /u02/app/18.1.0/
[grid@rac01 ~]$ cd /u02/app
[grid@rac01 app]$ mkdir 18.1.0
[grid@rac01 app]$ cd 18.1.0/
[grid@rac01 18.0.0]$ mkdir grid
[grid@rac01 18.0.0]$ cd grid
[grid@rac01 grid]$ ssh grid@rac02
Last login: Sun Jul 29 11:22:38 2018 from rac01.localdomain
[grid@rac02 ~]$ cd /u02/app
[grid@rac02 app]$ mkdir 18.1.0
[grid@rac02 app]$ cd 18.1.0/
[grid@rac02 18.0.0]$ mkdir grid
Unzip the 18c GI Software
[grid@rac01 ~]$ cd /u02/app/18.1.0/grid
[grid@rac01 grid]$ unzip -q /media/sf_software/LINUX.X64_180000_grid_home.zip
Execute gridSetup.sh
[grid@rac01 18.0.0]$ export DISPLAY=:0.0
[grid@rac01 18.0.0]$ ./gridSetup.sh
ASM Configuration Assistant 18c
GIMR pluggable database upgraded to 18c
[grid@rac01 bin]$ export ORACLE_SID=-MGMTDB [grid@rac01 bin]$ pwd /u02/app/18.0.0/grid/bin [grid@rac01 bin]$ ./sqlplus sys as sysdba SQL*Plus: Release 18.0.0.0.0 - Production on Sun Jul 29 22:09:17 2018 Version 18.3.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production Version 18.3.0.0.0 SQL> select name,open_mode from v$pdbs; NAME -------------------------------------------------------------------------------- OPEN_MODE ---------- PDB$SEED READ ONLY GIMR_DSCREP_10 READ WRITE SQL> alter session set container=GIMR_DSCREP_10; Session altered. SQL> select tablespace_name from dba_tablespaces; TABLESPACE_NAME ------------------------------ SYSTEM SYSAUX UNDOTBS1 TEMP USERS SYSGRIDHOMEDATA SYSCALOGDATA SYSMGMTDATA SYSMGMTDATADB SYSMGMTDATACHAFIX SYSMGMTDATAQ 11 rows selected. SQL> select file_name from dba_data_files where tablespace_name='SYSMGMTDATA'; FILE_NAME -------------------------------------------------------------------------------- +OCR/_MGMTDB/7224A7DF6CB92239E0536438A8C03F3A/DATAFILE/sysmgmtdata.281.982792479 SQL>
Oracle RAC How-To Series – Tutorial 1
How to install and configure Oracle 12c Release 2 RAC environment on VirtualBox (Part 1).
Download the note (for members only…)
Oracle RAC How-To Series – Tutorial 2
Download the note (for members only…)
Oracle RAC How-To Series – Tutorial 3
Download the note (for members only…)
Oracle RAC How-To Series – Tutorial 4
Download the note (for members only…)
Oracle RAC How-To Series – Tutorial 5
Download the note (for members only…)
Oracle RAC How-To Series – Tutorial 6
Download the note (for members only…)
Oracle RAC How-To Series – Tutorial 7
Download the note (for members only…)
Oracle RAC How-To Series – Tutorial 8
Download the note (for members only…)