|Mandalika's scratchpad||[ Work blog @Oracle | My Music Compositions ]|
For the impatient:
For the rest:
A little background first.
PeopleSoft application server relies on Jolt, a companion product that co-exists with Tuxedo, to handle all web requests. That is, Jolt is the bridge between PeopleSoft application server and the web server (any supported one) that facilitates web communication. Tuxedo helps schedule PeopleSoft application server processes to perform the actual transactions. When the application server is booted up, Jolt server listener (JSL) is bound to a pre-configured port number and is actively monitored for incoming web requests. On the other hand, web server instance(s) are made aware of the existence of all Jolt listeners in a PeopleSoft Enterprise by configuring the hostname:port# pairs in each of the web domain's configuration.properties file.
By default the variable %PS_MACH% in each of the application server domain configuration file, psappsrv.cfg, gets resolved to the hostname of the system during application server boot-up time. The following example demonstrates that.
/* Application server configuration file */ % cat psappsrv.cfg .. [JOLT Listener] Address=%PS_MACH% Port=9000 .. /* Boot up the application server domain */ % psadmin -c boot -d HRHX .. exec JSL -A -- -d /dev/tcp -n //ben01:9000 -m 100 -M 100 -I 5 -j ANY -x 20 -S 10 -c 1000000 -w JSH : process id=20077 ... Started. .. % hostname ben01 % netstat -a | grep 9000 ben01.9000 *.* 0 0 49152 0 LISTEN % netstat -an | grep 9000 188.8.131.52.9000 *.* 0 0 49152 0 LISTEN % ifconfig -a lo0: flags=2001000849
mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 bge0: flags=1000843 mtu 1500 index 2 inet 184.108.40.206 netmask ffffff00 broadcast 220.127.116.11 bge1: flags=1000843 mtu 1500 index 3 inet 18.104.22.168 netmask ffffff00 broadcast 22.214.171.124 e1000g0: flags=1000843 mtu 1500 index 4 inet 126.96.36.199 netmask ffffff00 broadcast 188.8.131.52 % telnet 184.108.40.206 9000 Trying 220.127.116.11... Connected to 18.104.22.168. Escape character is '^]'. % telnet 22.214.171.124 9000 Trying 126.96.36.199... telnet: Unable to connect to remote host: Connection refused % telnet 188.8.131.52 9000 Trying 184.108.40.206... telnet: Unable to connect to remote host: Connection refused
Notice that %PS_MACH% was replaced by the actual hostname and the Jolt listener created the server socket using the IP address 220.127.116.11 and port number 9000. From the outputs of netstat, ifconfig and telnet, it is apparent that "bge0" is the only network interface that is being used by the Jolt listener. It means web server can communicate to JSL using the IP address 18.104.22.168 over port 9000 but not using any of the other two IP addresses 22.214.171.124 or 126.96.36.199. This is the default behavior.
However some customers may wish to have the ability to connect to the application services from different/multiple networks. This is possible in case of multi-homed systems -- servers with multiple network interfaces that are connected to a single or multiple networks. For example, such a host could be part of a public network, a private network where only those clients that can communicate over private links can connect or an InfiniBand network, a low latency high throughput network. The default behavior of JSL can be changed by using a special IP address "0.0.0.0" in place of the variable %PS_MACH% in application server domains' configuration file. The IP address 0.0.0.0 hints the Jolt listener (JSL) to listen on all available IPv4 network interfaces on the system. (I read somewhere that "::0" is the equivalent for IPv6 interfaces. Didn't get a chance to test it out yet). The following example demonstrates how the default behavior changes with the IP address 0.0.0.0.
% cat psappsrv.cfg .. [JOLT Listener] Address=0.0.0.0 Port=9000 .. /* Update the binary configuration by reloading the config file */ % psadmin -c configure -d HRHX % psadmin -c boot -d HRHX .. exec JSL -A -- -d /dev/tcp -n //0.0.0.0:9000 -m 100 -M 100 -I 5 -j ANY -x 20 -S 10 -c 1000000 -w JSH : process id=20874 ... Started. % netstat -a | grep 9000 *.9000 *.* 0 0 49152 0 LISTEN % telnet 188.8.131.52 9000 Trying 184.108.40.206... Connected to 220.127.116.11. .. % telnet 18.104.22.168 9000 Trying 22.214.171.124... Connected to 126.96.36.199. .. % telnet 188.8.131.52 9000 Trying 184.108.40.206... Connected to 220.127.116.11.
It is not uncommon for Oracle DBAs to create, drop tablespaces for various reasons throughout the life of a database management system. It is a good practice to double check whether a tablespace is really empty before dropping it. One way is to visually check the "Tablespaces" section in Oracle Enterprise Manager (OEM) database console. However sometimes the graphical interface may return false positives. Another way is to rely on data dictionary views to obtain relevant information as accurately as possible. In the latter case, DBA_SEGMENTS / USER_SEGMENTS views are useful in mapping segments such as table, index, table/index partition etc., to a tablespace.eg.,
The following example queries USER_SEGMENTS view to list the segments and their types stored in a tablespace called "TS_SALES_DATA32K".
SQL> COLUMN SEGMENT_NAME FORMAT A30 SQL> COLUMN SEGMENT_TYPE FORMAT A30 SQL> SQL> SELECT SEGMENT_NAME, SEGMENT_TYPE 2 FROM USER_SEGMENTS 3 WHERE TABLESPACE_NAME = 'TS_SALES_DATA32K'; SEGMENT_NAME SEGMENT_TYPE ------------------------------ ------------------------------ SALES_DATA TABLE
The tablespace "TS_SALES_DATA32K" is holding one table called "SALES_DATA". The following query returns no rows meaning tablespace "TS_SALES_DATA" is empty - hence it can be dropped with no hesitation.
SQL> SELECT SEGMENT_NAME, SEGMENT_TYPE 2 FROM USER_SEGMENTS 3 WHERE TABLESPACE_NAME = 'TS_SALES_DATA'; no rows selected
Here is another query that lists out all the tablespaces in a database along with the number of segments/objects stored in each of those tablespaces. Note that it is possible to extract similar information in different ways using more efficient queries.
SQL> COLUMN TABLESPACE FORMAT A40 SQL> SQL> SELECT UT.TABLESPACE_NAME "TABLESPACE", COUNT (US.SEGMENT_NAME) "NUM SEGMENTS" 2 FROM USER_TABLESPACES UT, USER_SEGMENTS US 3 WHERE UT.TABLESPACE_NAME = US.TABLESPACE_NAME 4 GROUP BY (UT.TABLESPACE_NAME) 5 ORDER BY COUNT (US.SEGMENT_NAME) DESC; TABLESPACE NUM SEGMENTS ---------------------------------------- ----------- TS_DP 114989 TS_DP_X 306 .. TS_SALES_DATA32K 1 TS_SALES_DATA 0 13 rows selected.