Database Reference
In-Depth Information
This parameter is not dynamic and you have to restart the instance for it to take effect. There is one caveat
though: operating system authentication no longer works with the threaded model.
Preparing for Threaded Execution
When you simply restart the instance after changing the initialization parameter you will be in for a surprise after you
issue the “startup” command:
[oracle@server1 ~]$ $ORACLE_HOME/bin/sqlplus / as sysdba
[...]
Connected to an idle instance.
SQL> startup
ORA-01017: invalid username/password; logon denied
You cannot mount or open the database by using the bequeath protocol. Instead, you must use a password file
and connect over the network. Continuing from the previous output:
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> alter database mount;
Database altered.
SQL> alter database open;
Database altered.
If you have not yet created a password file you definitely should do so if you want to use the threaded execution
mode. Additionally you should consider statically registering your databases with the listener. Statically registered
databases allow you to connect to the database using a net*8 connection and still start an instance even if there was
no pmon process to register with the listener.
Administrative connections to the database are not the only area where changes have occurred. Using the threaded
model the architecture changes; you still have the same background processes as before, but they look very different.
Using the ps command to view the processes you will be interested to find that most of them have been combined:
[oracle@server1 ~]$ ps -ef | grep -i cdb1
oracle 22107 1 0 10:11 ? 00:00:00 ora_pmon_CDB1
oracle 22109 1 0 10:11 ? 00:00:00 ora_psp0_CDB1
oracle 22114 1 17 10:11 ? 00:00:58 ora_vktm_CDB1
oracle 22118 1 1 10:11 ? 00:00:04 ora_u004_CDB1
oracle 22124 1 12 10:11 ? 00:00:42 ora_u005_CDB1
oracle 22130 1 0 10:11 ? 00:00:00 ora_dbw0_CDB1
Instead of a one-to-one mapping of entries in v$bgprocess to operating system processes, there is now a
mapping between the thread and the process. To see what's hiding under the ora_u004_CDB1 process you can use a
custom report format when invoking the ps command:
[oracle@server1~]$ ps -eLo user,pid,tid,nlwp,class,rtprio,comm:30 | grep 22118
USER PID TID NLWP CLS RTPRIO COMMAND
oracle 22118 22118 13 TS - ora_scmn_cdb1
 
Search WWH ::




Custom Search