Database Upgrade Using AutoUpgrade Option (12c to 19c)

Database Upgrade Using AutoUpgrade Option (12c to 19c)

Database Upgrade Using Autoupgrade

Day to Day Commands

Day to Day Commands

day2day commands

How to verify the OS exact details?

How to verify the OS exact details?

[oracle@qtest ~]$ uname -a
Linux qtest 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

[oracle@qtest ~]$ cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.5 (Maipo)

[oracle@qtest ~]$ more /etc/os-release

NAME="Red Hat Enterprise Linux Server"
VERSION="7.5 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.5"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.5:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.5
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.5"


[oracle@qtest ~]$ cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.5 (Maipo)

Purging of Listener log file in Oracle Database

Purging of Listener log file in Oracle Database

Solution 1 :

First find the location of listener log file.

[oracle@qtest ~]$ lsnrctl status
Go the listener log file location and execute the below commands.

[oracle@qtest]$ cp listener.log listener_backup.log
[oracle@qtest]$ cat /dev/null>listener.log
[oracle@qtest]$ gzip listener_backup.log

Solution 2 :

LSNRCTL>
LSNRCTL> set current_listener <listenername>
LSNRCTL> set log_status off

Login into another window and rename the log file and then return to the previous window
LSNRCTL> set log_status on
The above command will create a new and empty listener.log file which will continue logging.

Top CPU & MEMORY Consuming Sessions

Top CPU & MEMORY Consuming Sessions

Solution:

The ps (process status) command is handy for quickly identifying top resource-consuming processes. For example, this command displays the top 10 CPU-consuming resources on the box:

$ ps -e -o pcpu,pid,user,tty,args | sort -n -k 1 -r | head

Here is a partial listing of the output:

65.5 5017 oracle ? oracleO12C (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
0.8 5014 oracle pts/1 sqlplus
0.8 23255 oracle ? ora_vktm_O12C

In the prior output, the process named oracleO12C is consuming an inordinate amount of CPU resources on the server. The process name identifies this as an Oracle process associated with the O12C database.

Similarly, you can also display the top memory-consuming processes:

$ ps -e -o pmem,pid,user,tty,args | sort -n -k 1 -r | head

Here is a snippet of the output:

11.2 5017 oracle ? oracleO12C (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
7.1 23317 oracle ? ora_mmon_O12C
6.3 23285 oracle ? ora_dbw0_O12C

Troubleshooting Database Network Connectivity Issues

Troubleshooting Database Network Connectivity Issues

Step 1.
Use the OS ping utility to determine whether the remote box is accessible

for example:

$ ping qproddb
qproddb is alive

If ping doesn’t work, work with your system or network administrator to ensure you have server-to-server connectivity in place.

Step 2. 

Use telnet to see if you can connect to the remote server and port (that the listener is listening on)

for example:

$ telnet qproddb 1521
Trying 127.0.0.1...
Connected to qproddb.
Escape character is '^]'.

The prior output indicates that connectivity to a server and port is okay. If the prior command hangs, then contact your SA or network administrator for further assistance.

Step 3. 

Use tnsping to determine whether Oracle Net is working. This utility will verify that an Oracle Net connection can be made to a database via the network.

for example:

$ tnsping qproddb 

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)
(HOST = qproddb.us.farm.com)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = QPRODDB)))
OK (500 msec)

If tnsping can’t contact the remote database, verify that the remote listener and database are both up and running. On the remote box, use the lsnrctl status command to verify that the listener is up. Verify that the remote database is available by establishing a local connection as a non-SYS account (SYS can often connect to a troubled database when other schemas will not work).

Step 4. 

Verify that the TNS information is correct. If the remote listener and database are working, then ensure that the mechanism for determining TNS information (like the tnsnames.ora file) contains the correct information.

Sometimes the client machine will have multiple TNS_ADMIN locations and tnsnames.ora files. One way to verify whether a particular tnsnames.ora file is being used is to rename it and see whether you get a different error when attempting to connect to the remote database.

Step 5. 

If you’re still having issues, examine the client sqlnet.log file and the remote server listener.log file.

Sometimes these log files will show additional information that will pinpoint the issue.