Latest Post

Exadata Database UNKNOWN issue after Grid Upgrade PRCR-1133 PRCR-1132 CRS-2680 CRS-5807 CRS-2680 CRS-5807

Written By Srikrishna Murthy Annam on Saturday, September 15, 2018 | 1:39 PM

In this post ,we are going to discuss about a recent issue we had after completing the exadata grid upgrade from 12.1.0.2 to 12.2.0.1. After completing the grid upgrade, we started seeing some databases status in UNKNOWN status with crsctl status command. The srvctl command show the status of the Database as not running though they are actually running. So let’s see the step by step troubleshooting of this issue.

NOTE : When you are troubleshooting any issue it is very important to first understand the issue and all its symptoms. We can’t just search for error string in google or in Oracle Support portal and start applying the solutions. This is not the right approach. We always suggest my blog followers and my students to first understand the issue and all its error messages. Let’s start discussing our issue….


After completing the GRID upgrade, the following symptoms are identified ….

  • srvctl shows the database status as “not running” though the database is actually up and running
  • Can’t manage the database(start or stop ) using the srvctl utility
  • SQLPLUS is the only utility to start and stop any instance of the RAC database
  • CRSCTL shows the database resource status as UNKNOWN.


With above mentioned symptoms of the issue, any experienced RAC should be able to tell you that the database is not properly talking to clusterware to update its status. That being said, the clusterware is unable to manage the database. These kind of situations arise when any cluster rac nodes gets rebooted abruptly. In our case, It may or may not be the grid upgrade that caused this issue, but there could be some previous occurances where the rac node got rebooted and there was a mismatch of Oracle database status in Oracle Clusterware. So how do we let the clusterware tell to reset the database status and start managing the database? Simple , just disable the resource and re-enable the resource using srvctl utility. But many DBAs are not convinced with the solution provided by the experience, they need a step by step troubleshooting steps …

Check 1:

Validate all the symptoms of the issue specified above. This confirms the status mismatch with Oracle Clusterware.

I am considering one database to show you the commands, but this issue is with many database on Exadata.

The following output shows thath the database is not running on any of the clusterware exadata compute node.

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status database -d ASKMDB
Instance ASKMDB1 is not running on node exaaskmdb01
Instance ASKMDB2 is not running on node exaaskmdb02
Instance ASKMDB3 is not running on node exaaskmdb03
Instance ASKMDB4 is not running on node exaaskmdb04
Instance ASKMDB5 is not running on node exaaskmdb05
Instance ASKMDB6 is not running on node exaaskmdb06
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$


But the above output is not correct. The database instance is actually running on node2 exaaskmdb02.


[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ sqlplus '/as sysdba'

SQL*Plus: Release 11.2.0.4.0 Production on Fri Sep 14 00:36:16 2018

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

SQL> sho parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +ASKM_DG/ASKMDB/spfileASKMDB.ora


If I try to start this instance using srvctl , it gives me the following error messages …..

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl start instance -d ASKMDB -i ASKMDB2
PRCR-1013 : Failed to start resource ora.askmdb.db
PRCR-1064 : Failed to start resource ora.askmdb.db on node exaaskmdb02
CRS-2680: Clean of 'ora.askmdb.db' on 'exaaskmdb02' failed
CRS-5802: Unable to start the agent process

But the same instance can be started and stopped using sqlplus.


The CRSCTL status of this database resource shows the following UNKNOWN status ….

[grid@exaaskmdb01 ~]$ crsctl status res ora.askmdb.db -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.askmdb.db
       1        ONLINE  ONLINE       exaaskmdb02                 Open,HOME=/u01/app/o
                                                              racle/product/11.2.0
                                                              .4/dbhome_1,STABLE
       2        OFFLINE OFFLINE                               STABLE
       3        OFFLINE OFFLINE                               STABLE
       4        ONLINE  UNKNOWN      exaaskmdb02                 STABLE
       5        ONLINE  OFFLINE                               STABLE
       6        ONLINE  OFFLINE                               STABLE
--------------------------------------------------------------------------------
[grid@exaaskmdb01 ~]$



Check 2 :

With Check1, we confirmed that all the symptoms we specified are met. Now lets see what is being populated in logs and what logs files we need to review …….

All cluster related issues are logged to clusteware logs. These logs are located in /u01/app/grid/diag/crs/exaaskmdb02/crs/trace.  Check the logs alert.log , crsd.trc and crsd_oraagent_oracle.trc files to check the error messages that states the cluster resource status changed to UNKNOWN status with the reason for this status change. As a DBA we should be able to understand the log formatting messages of the clusterware trace files. 


Solution

The following steps are listed to let any DBA understand the sequence of steps to execute to correct the database UNKNOWN status.


1. List the database status and check all the instances status

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status database -d ASKMDB
Instance ASKMDB1 is not running on node exaaskmdb01
Instance ASKMDB2 is not running on node exaaskmdb02
Instance ASKMDB3 is not running on node exaaskmdb03
Instance ASKMDB4 is not running on node exaaskmdb04
Instance ASKMDB5 is not running on node exaaskmdb05
Instance ASKMDB6 is not running on node exaaskmdb06


2. List the services status and check where the services are running.


[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status service -d ASKMDB
Service ASKMDBSC is running on instance(s) ASKMDB2


3. If the database is running a single instance,
3.a. Enable new database instance on a different node using srvctl

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl enable instance -d ASKMDB -i ASKMDB3


3.b. Start this new instance  using srvctl

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl start instance -d ASKMDB -i ASKMDB3


3.c. Modify the database services configuration to make the new instance as the preferred instance

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl modify service -d ASKMDB -s ASKMDBSC -n -i ASKMDB3 -a ASKMDB1,ASKMDB2,ASKMDB4,ASKMDB5,ASKMDB6


3.d. Verify the database configuration that the new instance is listed as the preferred instance.

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl config service -d ASKMDB -s ASKMDBSC
Service name: ASKMDBSC
Service is enabled
Server pool: ASKMDB_ASKMDBSC
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: NONE
Failover method: NONE
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: ASKMDB3
Available instances: ASKMDB1,ASKMDB2,ASKMDB4,ASKMDB5,ASKMDB6
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$



4. If the database is running multiple instances,
4.a. List the database configuration and check if the services have multiple instances as preferred instances.
4.b. Modify if we need to adjust the service configuration, to have atleast one running instance(Other than problematic instance) as preferred instance.
5. Relocate the database services to the new instance.

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status service -d ASKMDB -s ASKMDBSC
Service ASKMDBSC is running on instance(s) ASKMDB3


6. Stop the problematic instance using srvctl.           <<< If there are any errors during this step, it's expected. Don't worry about the error messages, but proceed to the next step.

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl stop instance -d ASKMDB -i ASKMDB2
PRCR-1133 : Failed to stop database ASKMDB and its running services
PRCR-1132 : Failed to stop resources using a filter
CRS-2680: Clean of 'ora.askmdb.db' on 'exaaskmdb02' failed
CRS-5807: Agent failed to process the message
CRS-2680: Clean of 'ora.askmdb.db' on 'exaaskmdb02' failed
CRS-5807: Agent failed to process the message
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$


7. Disable the instance using srvctl

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl disable instance -d ASKMDB -i ASKMDB2


8. Enable the instance using srvctl

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl enable instance -d ASKMDB -i ASKMDB2


9. Start the instance using srvctl

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status database -d ASKMDB
Instance ASKMDB1 is not running on node exaaskmdb01
Instance ASKMDB2 is not running on node exaaskmdb02
Instance ASKMDB3 is running on node exaaskmdb03
Instance ASKMDB4 is not running on node exaaskmdb04
Instance ASKMDB5 is not running on node exaaskmdb05
Instance ASKMDB6 is not running on node exaaskmdb06
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ ps -ef | grep -i pmon | grep -i ASKMDB
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl start instance -d ASKMDB -i ASKMDB2
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status database -d ASKMDB
Instance ASKMDB1 is not running on node exaaskmdb01
Instance ASKMDB2 is running on node exaaskmdb02
Instance ASKMDB3 is running on node exaaskmdb03
Instance ASKMDB4 is not running on node exaaskmdb04
Instance ASKMDB5 is not running on node exaaskmdb05
Instance ASKMDB6 is not running on node exaaskmdb06
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$



10. Now check the status of the database resource using crsctl

[grid@exaaskmdb02 ~]$ crsctl status res ora.askmdb.db -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.askmdb.db
       1        OFFLINE OFFLINE                               Instance Shutdown,ST
                                                              ABLE
       2        OFFLINE OFFLINE                               Instance Shutdown,ST
                                                              ABLE
       3        OFFLINE OFFLINE                               STABLE
       4        ONLINE  ONLINE       exaaskmdb02                 Open,HOME=/u01/app/o
                                                              racle/product/11.2.0
                                                              .4/dbhome_1,STABLE
       5        ONLINE  OFFLINE                               STABLE
       6        ONLINE  OFFLINE                               STABLE
--------------------------------------------------------------------------------
[grid@exaaskmdb01 ~]$



11. Once it is confirmed that the database shows the correct status using crsctl, proceed to bring down the temporary instance that we started.

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl stop instance -d ASKMDB -i ASKMDB3


12. Relocate the services back to the original instance once the problem is resolved with that instance.
13. Stop the temporary instance that we started.

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status database -d ASKMDB
Instance ASKMDB1 is not running on node exaaskmdb01
Instance ASKMDB2 is running on node exaaskmdb02
Instance ASKMDB3 is not running on node exaaskmdb03
Instance ASKMDB4 is not running on node exaaskmdb04
Instance ASKMDB5 is not running on node exaaskmdb05
Instance ASKMDB6 is not running on node exaaskmdb06
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl status service -d ASKMDB
Service ASKMDBSC is running on instance(s) ASKMDB2
[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$


14. Disable the temporary instance that we started.

[oracle@exaaskmdb02.askmlabs.com:ASKMDB2]$ srvctl disable instance -d ASKMDB -i ASKMDB3


Hope this helps …

OEM LDAP Authentication Troubleshooting

Written By Srikrishna Murthy Annam on Wednesday, September 12, 2018 | 7:38 PM

In this post, we will discuss  troubleshooting OEM LDAP authentication issue. Due to various reasons, you may see sometimes the OEM users (LDAP users) getting Authentication failures. Well there could be various reasons for the authentication failures. We need to see how can we enable the tracing/debug to populate the detailed error messages in logs. The procedure is also explained in the Oracle Document.

Our troubleshooting started after users compaining about the authentication issues. We narrowed it with various testings/accessing other enterprise applications that the issue is only with the OEM. Now we have started our focus on troubleshooting authentication issue.

Check1 :

Check if the issue is with all the users ( Local and External ). If the issue is only with the External users(LDAP users), the primary focus of this post, Please proceed with the troubleshooting.

Knowing that the issue is only with the LDAP users, We focussed looking around the external ldap system. In our case, we are using Microsoft Active Directory to authenticate users to OEM.

Check2:

Check if the service account used to integrate for authentication is locked. The security/identity team in your Organization should be able to help you if the accout is locked or not. If the account is locked, Please have this account unlocked it. Verify if the issue is resolved.  But if the issue is not with the account locked, proceed to the next step to continue troubleshooting ….

Check3:

If the issue is not with the account locked, try enabling the Weblogic Debug/Tracing as described below ……

From the WebLogic Server Console, enable logging, set the WebLogic debug log level and then the enable the debug flag.

  1. Navigate to Environment->Servers->EMGC_OMS1 and choose the Logging tab.
  2. Under Rotation, set the file rotation size to 64000.
  3. Expand Advanced.
  4. Under Message destinations(s) (Log file: region) set the Severity level to Trace.
  5. Navigate to the Environment->Servers->EMGC_OMS1 and choose the Debug tab.
  6. Check WebLogic->security->atn->DebugSecurityAtn.
  7. Click Save.


Now these settings will create a logfile ldap_trace.logATN. This file ldap_trace.logATN is located at $OMS_HOME/../../gc_inst/user_projects/domains/GCDomain


Following log messages are populated when we try to access the OEM using LDAP user accounts….


[oracle@askmoem12c GCDomain]$ tail -f ldap_trace.logATN
17:31:47.729 ldc=6 Connected to ldaps://adauth.askmlabs.com:389
17:31:47.730 ldc=6 op=227 BindRequest {version=3, name=CN=oem.service,OU=Users,OU=Accounts,DC=askmlabs,DC=com, authentication=********}
17:31:47.732 ldc=6 op=227 BindResponse {resultCode=49, errorMessage=80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 532, v2580}
17:32:30.334 ldc=7 Connected to ldaps://adauth.askmlabs.com:389
17:32:30.334 ldc=7 op=228 BindRequest {version=3, name=CN=oem.service,OU=Users,OU=Accounts,DC=askmlabs,DC=com, authentication=********}
17:32:30.336 ldc=7 op=228 BindResponse {resultCode=49, errorMessage=80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 532, v2580}
17:35:00.485 ldc=8 Connected to ldaps://adauth.askmlabs.com:389
17:35:00.485 ldc=8 op=229 BindRequest {version=3, name=CN=oem.service,OU=Users,OU=Accounts,DC=askmlabs,DC=com, authentication=********}
17:35:00.487 ldc=8 op=229 BindResponse {resultCode=49, errorMessage=80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 532, v2580}
17:37:06.171 ldc=9 Connected to ldaps://adauth.askmlabs.com:389
17:37:06.171 ldc=9 op=230 BindRequest {version=3, name=CN=oem.service,OU=Users,OU=Accounts,DC=askmlabs,DC=com, authentication=********}
17:37:06.174 ldc=9 op=230 BindResponse {resultCode=49, errorMessage=80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 532, v2580}
17:39:45.033 ldc=10 Connected to ldaps://adauth.askmlabs.com:389
17:39:45.033 ldc=10 op=231 BindRequest {version=3, name=CN=oem.service,OU=Users,OU=Accounts,DC=askmlabs,DC=com, authentication=********}
17:39:45.035 ldc=10 op=231 BindResponse {resultCode=49, errorMessage=80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580}
17:47:17.121 ldc=2 Connected to ldaps://adauth.askmlabs.com:389
17:47:17.122 ldc=2 op=223 BindRequest {version=3, name=CN=oem.service,OU=Users,OU=Accounts,DC=askmlabs,DC=com, authentication=********}
17:47:17.124 ldc=2 op=223 BindResponse {resultCode=49, errorMessage=80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 532, v2580}
^C


From the above error messages, the “resultCode=49” indicates that the bad password is used. Now we understand that the issue is to deal with the service account password. We changed the service account oem.service password and then updated the password in weblogic console as shown below.


Follow the navigation to update the password ….

Domain - > Environment - > Security Realms - > myrealm - > providers

image

image

image

image


Save the password. And then activate the changes.


Ideally we don’t  need to bounce the services to take these changes effect. But if you could offer the bounce, please bounce the complete OEM services.


Hope this information helps….

ACFS Mount Missing On Exadata - ACFS-02017 , CLSU-00101

This post talks about an Exadata RAC ASM issue. This issue is observed after completing Exadata patching.  It is observed that the ACFS mount point is missing. The following steps explains how we identified the issue and How can we troubleshoot this issue.

This is a 8 node Exadata full rack. The ACFS mount point is missing on first node , but all other 7 nodes have this ASM mount point.


First try to get the missing mount point …

Use “df –h” on any node where you can see the ACFS mount point. In our case getting the ACFS mount point details from node2 exaaskmdb02


[root@exaaskmdb02 ~]# df -h /u01/app/askmacfs
Filesystem            Size  Used Avail Use% Mounted on
/dev/asm/askmdata-282  512G   64G  449G  13% /u01/app/askmacfs
[root@exaaskmdb01 ~]#


Check1 :

Using these details, try to manually mount the ACFS on node1 exaaskmdb01


[root@exaaskmdb01 ~]# mount -t acfs /dev/asm/askmdata-282  /u01/app/askmacfs
mount.acfs: CLSU-00100: operating system function: open64 failed with error data: 2
mount.acfs: CLSU-00101: operating system error message: No such file or directory
mount.acfs: CLSU-00103: error location: OOF_1
mount.acfs: CLSU-00104: additional error information: open64 (/dev/asm/askmdata-282)
mount.acfs: ACFS-02017: Failed to open volume /dev/asm/askmdata-282. Verify the volume exists.
[root@exaaskmdb01 ~]#


We are not able to mount the ACFS mountpoint. The first approach for any troubleshooting is to analyze the error messages. Cetain times, there could be useful error messages, which can directly help to point to the issue. But sometimes, the error messages may not help to focus on the real issue , rather informational messages. Your experience will count a lot in these scenarios where you should be able to relate the error message to the issue.


Check2:

The error message which caught to our attention is “No such file or directory”. Now our next check will be to check the directories…

On exaaskmdb01 check the directories  /dev/asm/askmdata-282 and /u01/app/askmacfs

[root@exaaskmdb01 ]# ls -lrt /dev/asm/askmdata-282
ls: cannot access /dev/asm/askmdata-282: No such file or directory

[root@exaaskmdb01 ]# ls -ld /u01/app/askmacfs
drwxrwxr-x 11 grid oinstall 4096 May  9 12:00 /u01/app/askmacfs


Same thing, verify on any other node ( 2-8)

[root@exaaskmdb02 ]# ls -lrt /dev/asm/askmdata-282
brwxrwx--- 1 root asmadmin 248, 144385 Sep 12 15:33 /dev/asm/askmdata-282

[root@exaaskmdb02 ]# ls -ld /u01/app/askmacfs
drwxrwxr-x 11 grid oinstall 4096 May  9 12:00 /u01/app/askmacfs


From the above check, it is clear that node1 exaaskmdb01 is missing a directory. Now lets check further how to bring this directory. As these are ACFS mounts, there could be possibility that these are missing due to ACFS drivers not loading properly during node reboot. Let’s concentrate on the ACFS drivers….


Check3:

Check acfs modules to be loaded …

[root@exaaskmdb01 ~]# lsmod | grep oracle
oracleacfs           4825088  0
oracleadvm            806912  3
oracleoks             659456  2 oracleacfs,oracleadvm


This check looks good, the acfs drivers are loaded properly. The next check would be to check the ACFS volume informaiton.

Check4:

ASMCMD> volinfo --all
Diskgroup Name: ASKM_DG

         Volume Name: ASKMDATA
          Volume Device: /dev/asm/askmdata-282
          State: DISABLED                               <<<< Check this. This volume is disabled.
          Size (MB): 524288
          Resize Unit (MB): 64
          Redundancy: MIRROR
          Stripe Columns: 8
          Stripe Width (K): 1024
          Usage: ACFS
          Mountpath: /u01/app/askmacfs


From the above output, we get that the volume is disabled. Now let’s check the same thing on the other nodes exaaskmdb02-08


[grid@exaaskmdb02 ~]$ asmcmd
ASMCMD> volinfo --all
Diskgroup Name: ASKM_DG

         Volume Name: ASKMDATA
          Volume Device: /dev/asm/askmdata-282
          State: ENABLED                     <<< It is enabled on node2
          Size (MB): 524288
          Resize Unit (MB): 64
          Redundancy: MIRROR
          Stripe Columns: 8
          Stripe Width (K): 1024
          Usage: ACFS
          Mountpath: /u01/app/askmacfs


From the above check4, we understood that this is due to the reason that the volume is not enabled by default after patching. Now we need to enable this volume and mount this ACFS manually.


Solution

ASMCMD> volenable -G ASKM_DG -a
ASMCMD> volinfo --all
Diskgroup Name: ASKM_DG

         Volume Name: ASKMDATA
          Volume Device: /dev/asm/askmdata-282
          State: ENABLED
          Size (MB): 524288
          Resize Unit (MB): 64
          Redundancy: MIRROR
          Stripe Columns: 8
          Stripe Width (K): 1024
          Usage: ACFS
          Mountpath: /u01/app/askmacfs

ASMCMD> exit
[grid@exaaskmdb01 ~]$ ls -lrt /dev/asm/askmdata-282
brwxrwx--- 1 root asmadmin 248, 144385 Sep 12 15:56 /dev/asm/askmdata-282

[root@exaaskmdb01 ~]# ls -ld /u01/app/askmacfs
drwxrwxr-x 2 grid oinstall 4096 Mar 18  2016 /u01/app/askmacfs

[root@exaaskmdb01 ~]# mount -t acfs /dev/asm/askmdata-282 /u01/app/askmacfs

[root@exaaskmdb01 ~]# df -h /u01/app/askmacfs
Filesystem            Size  Used Avail Use% Mounted on
/dev/asm/askmdata-282  512G   64G  449G  13% /u01/app/askmacfs
[root@exaaskmdb01 ~]#


That’s it. We fixed the issue.


Questions to the readers

Q1) Where do you find the ASM related modules/drivers on Linux OS ?

Q2) What to do if you find any missing ASM modules/drivers on Linux OS ?

Q3) How to load the asm drivers if they were not loaded by default during node reboot ?


Refer to my other post <Place Holder> which is similar to this issue , but happened during our exa grid upgrade from 12.1.0.2 to 12.2.0.1.


Hope this information helps….

Oracle Database 18c Upgrade Using DBUA

Written By Srikrishna Murthy Annam on Monday, September 10, 2018 | 8:02 PM

In this post, we will discuss about Oracle Database 18c upgrade from 12.1.0.2 to 18.0.0.0. Though the upgrade using DBUA is simple, we need to consider many other points based on your environment. Those points really vary from environment to environment. The purpose of this post is to give you the introduction to the process of database upgrade. I have few other posts where I explained manual upgrade process.

We assume for this post, that we already have a Non-CDB database 12.1.0.2 up and running on linux OS. We also assume that Oracle Database Vault and Oracle Label Security are not enabled in this database. We have another post that describes the Database Vault and Oracle Label Security considerations when upgrading a database.


For reference, note the direct upgrade path.

direct upgrade path


1.Pre-Upgrade Tasks

1.1 Verify all the components status

Use the following command to list the Database components status along with version.

SQL> select substr(comp_name,1,40) comp_name, status, substr(version,1,10) version from dba_registry order by comp_name;


SQL> select substr(comp_name,1,40) comp_name, status, substr(version,1,10) version from dba_registry order by comp_name;

COMP_NAME                                     STATUS               VERSION
--------------------------------------------- -------------------- ----------
JServer JAVA Virtual Machine                  VALID                12.1.0.2.0
OLAP Analytic Workspace                       VALID                12.1.0.2.0
Oracle Application Express                    VALID                4.2.5.00.0
Oracle Database Catalog Views                 VALID                12.1.0.2.0
Oracle Database Java Packages                 VALID                12.1.0.2.0
Oracle Database Packages and Types            VALID                12.1.0.2.0
Oracle Database Vault                         VALID                12.1.0.2.0
Oracle Label Security                         VALID                12.1.0.2.0
Oracle Multimedia                             VALID                12.1.0.2.0
Oracle OLAP API                               VALID                12.1.0.2.0
Oracle Real Application Clusters              OPTION OFF           12.1.0.2.0
Oracle Text                                   VALID                12.1.0.2.0
Oracle Workspace Manager                      VALID                12.1.0.2.0
Oracle XDK                                    VALID                12.1.0.2.0
Oracle XML Database                           VALID                12.1.0.2.0
Spatial                                       VALID                12.1.0.2.0


1.2 Disable the custom triggers that would fire before/after DDL and enable them after the upgrade is complete.

1.3 Take database backup.

Based on your exisint backups strategy, complete the level0 backup. We always prefer consistant RMAN level0 backup if the downtime is offordable. If downtime is not allowed for database , complete RMAN level0 backup.

1.5 Check invalid objects and run utlrp.sql script if you have any invalids

Use the following command to check the database invalids. Run utlrp.sql script to correct any invalids.

SQL> select name,user from v$database;
SQL> create user askm_upg_usr identified by xxxxxxx account unlock;
SQL> grant connect,resource to askm_upg_usr;
SQL> grant dba to askm_upg_usr;
SQL> create table askm_upg_usr.source_dba_objects as select * from dba_objects;
SQL> select count(1) from askm_upg_usr.source_dba_objects;
SQL> break on report
SQL> compute sum of INVALIDS on report
SQL> select owner,count(object_name) INVALIDS from dba_objects where status ='INVALID' group by owner;
SQL> create table askm_upg_usr.invalids_preupg as (select owner,object_name,object_type from dba_objects where status='INVALID');
SQL> select count(*) from askm_upg_usr.invalids_preupg;
SQL> select count(*) from dba_objects where status='INVALID';


1.6 Verify the time zone.

Oracle database 1bc brings time zone file 26. So you have the option, either you can upgrade time zone after completing database upgrade or during the database upgrade.

SELECT version FROM v$timezone_file;

From 18.1 onwards, timezone upgrade scripts are included in the target ORACLE_HOME under rdbms/admin directory.


1.7 Gather optimizer statistics

The optimizer statistics are gathered using the following command…

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

1.8 Truncate audit records ( to avoid hanging issues while upgrading)

SQL> truncate table sys.aud$;
SQL> truncate table sys.fga_log$;


1.9 Run pre-upgrade inforation tool preupgrade.jar. ( Doc ID 884522.1 )

You can run preupgrade scripts that the Pre-Upgrade Information Tool generates to fix many issues before you upgrade to the new Oracle Database release.

$ORACLE_HOME/jdk/bin/java -jar  /tmp/askm/preupgrade.jar TERMINAL TEXT

The output of this command is copied in the section scripts output. Refer to the output listed in this post. Refer the “PREUPGRADE SUMMARY”. This scripts generate the fixup scripts. Run the preupgrade_fixups.sql before upgrade.


SQL> @/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/preupgrade_fixups.sql


1.10 Check the accounts use Case-Insensitive password version

Use the following query to find the user accounts that use case-insensitive version.

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;
If you find any user account that use case-insensitive version, refer the Oracle Document for steps to complete.

2.Upgrade Using DBUA

2.1 Install database 18c software only installation in a new oracle home.

Before starting the Database upgrade, we need to install the Database 18c software binaries. We have different posts that explains the detailed procedure to install Oracle Database 18c binaries. Refer my other posts

Oracle Database 18c Simple Installation , Install Oracle Database 18c In Silent Mode and Install Oracle Database 18c In Silent Mode Part2. What is new with Oracle Database 18c software ? What is image based software ?


[oracle@askmdb ~]$ echo $ORACLE_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
[oracle@askmdb ~]$ mkdir -p /u01/app/oracle/product/18.0.0/dbhome_1
[oracle@askmdb ~]$ cd /u01/app/oracle/product/18.0.0/dbhome_1
[oracle@askmdb dbhome_1]$


[oracle@askmdb dbhome_1]$ unzip /mnt/software/Database/Oracle_Database_18.0.0.0.0_sw/V978967-01.zip


Edit the file db_install.rsp from the new software image extracted above , for software installation.

[oracle@askmdb response]$ diff db_install.rsp db_install.rsp_18AUG2018
29c29
< oracle.install.option=INSTALL_DB_SWONLY
---
> oracle.install.option=
34c34
< UNIX_GROUP_NAME=oinstall
---
> UNIX_GROUP_NAME=
41c41
< INVENTORY_LOCATION=/u01/app/oraInventory
---
> INVENTORY_LOCATION=
45c45
< ORACLE_HOME=/u01/app/oracle/product/18.0.0/dbhome_1
---
> ORACLE_HOME=
50c50
< ORACLE_BASE=/u01/app/oracle
---
> ORACLE_BASE=
62c62
< oracle.install.db.InstallEdition=EE
---
> oracle.install.db.InstallEdition=
79c79
< oracle.install.db.OSDBA_GROUP=dba
---
> oracle.install.db.OSDBA_GROUP=
85c85
< oracle.install.db.OSOPER_GROUP=oper
---
> oracle.install.db.OSOPER_GROUP=
90c90
< oracle.install.db.OSBACKUPDBA_GROUP=backupdba
---
> oracle.install.db.OSBACKUPDBA_GROUP=
95c95
< oracle.install.db.OSDGDBA_GROUP=dgdba
---
> oracle.install.db.OSDGDBA_GROUP=
100c100
< oracle.install.db.OSKMDBA_GROUP=kmdba
---
> oracle.install.db.OSKMDBA_GROUP=
105c105
< oracle.install.db.OSRACDBA_GROUP=racdba
---
> oracle.install.db.OSRACDBA_GROUP=
[oracle@askmdb response]$


[oracle@askmdb dbhome_1]$ ./runInstaller -silent -responseFile /u01/app/oracle/product/18.0.0/dbhome_1/install/response/db_install.rsp


Run root.sh to complete the software installation.


[root@askmdb ~]# /u01/app/oracle/product/18.0.0/dbhome_1/root.sh



2.2 Set ORACLE_HOME and invoke DBUA from the 18c binaries installed above.

Oracle Database 18c Upgrade

Oracle Database 18c UpgradeOracle Database 18c UpgradeOracle Database 18c Upgrade


You can’t proceed with the upgrade unless you correct those warnings/errors.  I have manually corrected those errors.




Oracle Database 18c UpgradeOracle Database 18c UpgradeOracle Database 18c UpgradeOracle Database 18c UpgradeOracle Database 18c UpgradeOracle Database 18c Upgrade


3.Post-Upgrade Tasks

3.1 Verify for any invalid objects and run the utlrp.sql

Run the following commands to verify the invalids and run the utlrp.sql script to correct the invalids.

SQL> select count(*) from askm_upg_usr.INVALIDS_preupg;
SQL> select count(*) from dba_objects where status='INVALID';
SQL> set linesize 132
SQL> column object_name format a30
SQL> column object_type format a25
SQL> column owner format a20
SQL> select object_name,object_type,owner from dba_objects a where status = 'INVALID' and not exists (select 0 from askm_upg_usr.INVALIDS_preupg b where b.object_name=a.object_name and b.owner=a.owner);


3.2 Run the post upgrade fixup script.

Run the postupgrade_fixups.sql which is generated as part of the script pre-upgrade information tool preupgrade.jar.

SQL> @/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/postupgrade_fixups.sql


3.2 Check if you have any special instructions specific to your environment and complete all the steps.

3.3 Post upgrade verification steps

SQL> select instance_name,status from v$instance;

INSTANCE_NAME    STATUS
---------------- ---------------
ASKM             OPEN

SQL> select substr(comp_id,1,15) comp_id,substr(comp_name,1,30) comp_name,substr(version,1,10) version,status from dba_registry order by modified;

COMP_ID         COMP_NAME                                     VERSION         STATUS
--------------- --------------------------------------------- --------------- ---------------
APEX            Oracle Application Express                    4.2.5.00.0      VALID
CATALOG         Oracle Database Catalog Views                 18.0.0.0.0      UPGRADED
CATPROC         Oracle Database Packages and T                18.0.0.0.0      UPGRADED
XML             Oracle XDK                                    18.0.0.0.0      UPGRADED
CATJAVA         Oracle Database Java Packages                 18.0.0.0.0      UPGRADED
APS             OLAP Analytic Workspace                       18.0.0.0.0      UPGRADED
OLS             Oracle Label Security                         18.0.0.0.0      UPGRADED
DV              Oracle Database Vault                         18.0.0.0.0      UPGRADED
CONTEXT         Oracle Text                                   18.0.0.0.0      UPGRADED
OWM             Oracle Workspace Manager                      18.0.0.0.0      UPGRADED
RAC             Oracle Real Application Cluste                18.0.0.0.0      UPGRADED
XDB             Oracle XML Database                           18.0.0.0.0      UPGRADED
ORDIM           Oracle Multimedia                             18.0.0.0.0      UPGRADED
SDO             Spatial                                       18.0.0.0.0      UPGRADED
XOQ             Oracle OLAP API                               18.0.0.0.0      UPGRADED
JAVAVM          JServer JAVA Virtual Machine                  18.0.0.0.0      VALID

16 rows selected.

SQL> select owner, object_name, object_type from dba_invalid_objects order by owner, object_type;

no rows selected


SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

PL/SQL procedure successfully completed.

SQL> execute dbms_stats.gather_fixed_objects_stats;

PL/SQL procedure successfully completed.


4. Troubleshooting Oracle Upgrades and Rerunning Failed upgrades

There could be possibilities that you may land into different upgrade issues. The upgrade process has been improved from version to version that we can re-run the failed upgrade process using DBUA again. You can re-run or restart Oracle Database upgrade phases by using Database Upgrade Assistant (DBUA).

Logfiles for the upgrade process can be found at location :   $ORACLE_BASE/cfgtoollogs/$ORACLE_SID

5.Issues and Resolutions

Issue-1

[oracle@askmdb dbhome_1]$ ./runInstaller -silent -responseFile /u01/app/oracle/product/18.0.0/dbhome_1/install/response/db_install.rsp
Launching Oracle Database Setup Wizard...

[FATAL] [INS-35341] The installation user is not a member of the following groups: [backupdba, dgdba, kmdba, racdba]
    CAUSE: The installation user account must be a member of all groups required for installation.
    ACTION: Ensure that the installation user is a member of the system privileges operating system groups you selected.
[oracle@askmdb dbhome_1]$ vi /u01/app/oracle/product/18.0.0/dbhome_1/install/response/db_install.rsp
[oracle@askmdb dbhome_1]$

Solution :

Modify the oracle user to be part of the groups backupdba, dgdba, kmdba, racdba


6.References

Important Notes :

<Place Holder>

Scripts Output :

Session Output for DB Software Installation :

[oracle@askmdb dbhome_1]$ ./runInstaller -silent -responseFile /u01/app/oracle/product/18.0.0/dbhome_1/install/response/db_install.rsp
Launching Oracle Database Setup Wizard...

[WARNING] [INS-13014] Target environment does not meet some optional requirements.
    CAUSE: Some of the optional prerequisites are not met. See logs for details. /u01/app/oraInventory/logs/InstallActions2018-08-18_03-04-54AM/installActions2018-08-18_03-04-54AM.log
    ACTION: Identify the list of failed prerequisite checks from the log: /u01/app/oraInventory/logs/InstallActions2018-08-18_03-04-54AM/installActions2018-08-18_03-04-54AM.log. Then either from the log file or from installation manual find the appropriate configuration to meet the prerequisites and fix it manually.
The response file for this session can be found at:
  /u01/app/oracle/product/18.0.0/dbhome_1/install/response/db_2018-08-18_03-04-54AM.rsp

You can find the log of this install session at:
  /u01/app/oraInventory/logs/InstallActions2018-08-18_03-04-54AM/installActions2018-08-18_03-04-54AM.log

As a root user, execute the following script(s):
         1. /u01/app/oracle/product/18.0.0/dbhome_1/root.sh

Execute /u01/app/oracle/product/18.0.0/dbhome_1/root.sh on the following nodes:
[askmdb]


Successfully Setup Software with warning(s).
[oracle@askmdb dbhome_1]$


root.sh output :

[root@askmdb ~]# /u01/app/oracle/product/18.0.0/dbhome_1/root.sh
Check /u01/app/oracle/product/18.0.0/dbhome_1/install/root_askmdb_2018-08-18_03-13-50-362534151.log for the output of root script
[root@askmdb ~]# cat /u01/app/oracle/product/18.0.0/dbhome_1/install/root_askmdb_2018-08-18_03-13-50-362534151.log
Performing root user operation.

The following environment variables are set as:
     ORACLE_OWNER= oracle
     ORACLE_HOME=  /u01/app/oracle/product/18.0.0/dbhome_1
    Copying dbhome to /usr/local/bin ...
    Copying oraenv to /usr/local/bin ...
    Copying coraenv to /usr/local/bin ...

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Oracle Trace File Analyzer (TFA) is available at : /u01/app/oracle/product/18.0.0/dbhome_1/suptools/tfa/release/tfa_home/bin/tfactl
[root@askmdb ~]#



Pre-Upgrade Information Tool Output ( preupgrade.jar ) :

[oracle@askmdb dbhome_1]$ $ORACLE_HOME/jdk/bin/java -jar  /tmp/askm/preupgrade.jar TERMINAL TEXT
Report generated by Oracle Database Pre-Upgrade Information Tool Version
18.0.0.0.0 on 2018-08-18T03:19:07

Upgrade-To version: 18.0.0.0.0

=======================================
Status of the database prior to upgrade
=======================================
       Database Name:  ASKM
      Container Name:  ASKM
        Container ID:  0
             Version:  12.1.0.2.0
          Compatible:  12.1.0.2.0
           Blocksize:  8192
            Platform:  Linux x86 64-bit
       Timezone File:  18
   Database log mode:  ARCHIVELOG
            Readonly:  FALSE
             Edition:  EE

  Oracle Component                       Upgrade Action    Current Status
   ----------------                       --------------    --------------
   Oracle Server                          [to be upgraded]  VALID
   JServer JAVA Virtual Machine           [to be upgraded]  VALID
   Oracle XDK for Java                    [to be upgraded]  VALID
   Real Application Clusters              [to be upgraded]  OPTION OFF
   Oracle Workspace Manager               [to be upgraded]  VALID
   OLAP Analytic Workspace                [to be upgraded]  VALID
   Oracle Label Security                  [to be upgraded]  VALID
   Oracle Database Vault                  [to be upgraded]  VALID
   Oracle Text                            [to be upgraded]  VALID
   Oracle XML Database                    [to be upgraded]  VALID
   Oracle Java Packages                   [to be upgraded]  VALID
   Oracle Multimedia                      [to be upgraded]  VALID
   Oracle Spatial                         [to be upgraded]  VALID
   Oracle OLAP API                        [to be upgraded]  VALID

==============
BEFORE UPGRADE
==============

  REQUIRED ACTIONS
   ================
   1.  Set DB_RECOVERY_FILE_DEST_SIZE initialization parameter to at least 7955
       MB.  Check alert log during the upgrade to ensure there is remaining free
       space available in the recovery area.

      DB_RECOVERY_FILE_DEST_SIZE is set at 4560 MB.  There is currently 1223 MB
       of free space remaining, which may not be adequate for the upgrade.

      Currently:
        Fast recovery area :  /u01/app/oracle/fast_recovery_area
        Limit              :  4560 MB
        Used               :  3337 MB
        Available          :  1223 MB

      The database has archivelog mode enabled, and the upgrade process will
       need free space to generate archived logs to the recovery area specified
       by initialization parameter DB_RECOVERY_FILE_DEST.  The logs generated
       must not overflow the limit set by DB_RECOVERY_FILE_DEST_SIZE, as that
       can cause the upgrade to not proceed.

  RECOMMENDED ACTIONS
   ===================
   2.  Run 12.1.0.2.0 $ORACLE_HOME/rdbms/admin/utlrp.sql to recompile invalid
       objects.  You can view the individual invalid objects with

        SET SERVEROUTPUT ON;
         EXECUTE DBMS_PREUP.INVALID_OBJECTS;

      58 objects are INVALID.

      There should be no INVALID objects in SYS/SYSTEM or user schemas before
       database upgrade.

  3.  Upgrade Oracle Application Express (APEX) manually before the database
       upgrade.

      The database contains APEX version 4.2.5.00.08. Upgrade APEX to at least
       version 5.1.3.00.05.

      Starting with Oracle Database Release 18, APEX is not upgraded
       automatically as part of the database upgrade. Refer to My Oracle Support
       Note 1088970.1 for information about APEX installation and upgrades.

  4.  (AUTOFIXUP) Gather stale data dictionary statistics prior to database
       upgrade in off-peak time using:

        EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;

      Dictionary statistics do not exist or are stale (not up-to-date).

      Dictionary statistics help the Oracle optimizer find efficient SQL
       execution plans and are essential for proper upgrade timing. Oracle
       recommends gathering dictionary statistics in the last 24 hours before
       database upgrade.

      For information on managing optimizer statistics, refer to the 12.1.0.2
       Oracle Database SQL Tuning Guide.

  INFORMATION ONLY
   ================
   5.  To help you keep track of your tablespace allocations, the following
       AUTOEXTEND tablespaces are expected to successfully EXTEND during the
       upgrade process.

                                                 Min Size
       Tablespace                        Size     For Upgrade
       ----------                     ----------  -----------
       SYSAUX                            1010 MB      1129 MB
       SYSTEM                             800 MB      1240 MB
       TEMP                                60 MB       150 MB
       UNDOTBS1                           280 MB       449 MB

      Minimum tablespace sizes for upgrade are estimates.

  ORACLE GENERATED FIXUP SCRIPT
   =============================
   All of the issues in database ASKM
   which are identified above as BEFORE UPGRADE "(AUTOFIXUP)" can be resolved by
   executing the following

    SQL>@/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/preupgrade_fixups.sql

=============
AFTER UPGRADE
=============

  REQUIRED ACTIONS
   ================
   None

  RECOMMENDED ACTIONS
   ===================
   6.  (AUTOFIXUP) If you use the -T option for the database upgrade, then run
       $ORACLE_HOME/rdbms/admin/utluptabdata.sql after the upgrade is complete,
       to VALIDATE and UPGRADE any user tables affected by changes to
       Oracle-Maintained types.

      There are user tables dependent on Oracle-Maintained object types.

      If the -T option is used to set user tablespaces to READ ONLY during the
       upgrade, user tables in those tablespaces, that are dependent on
       Oracle-Maintained types, will not be automatically upgraded. If a type is
       evolved during the upgrade, any dependent tables need to be re-validated
       and upgraded to the latest type version AFTER the database upgrade
       completes.

  7.  Upgrade the database time zone file using the DBMS_DST package.

      The database is using time zone file version 18 and the target 18.0.0.0.0
       release ships with time zone file version 31.

      Oracle recommends upgrading to the desired (latest) version of the time
       zone file.  For more information, refer to "Upgrading the Time Zone File
       and Timestamp with Time Zone Data" in the 18.0.0.0.0 Oracle Database
       Globalization Support Guide.

  8.  (AUTOFIXUP) Gather dictionary statistics after the upgrade using the
       command:

        EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;

      Oracle recommends gathering dictionary statistics after upgrade.

      Dictionary statistics provide essential information to the Oracle
       optimizer to help it find efficient SQL execution plans. After a database
       upgrade, statistics need to be re-gathered as there can now be tables
       that have significantly changed during the upgrade or new tables that do
       not have statistics gathered yet.

  9.  Gather statistics on fixed objects after the upgrade and when there is a
       representative workload on the system using the command:

        EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

      This recommendation is given for all preupgrade runs.

      Fixed object statistics provide essential information to the Oracle
       optimizer to help it find efficient SQL execution plans.  Those
       statistics are specific to the Oracle Database release that generates
       them, and can be stale upon database upgrade.

      For information on managing optimizer statistics, refer to the 12.1.0.2
       Oracle Database SQL Tuning Guide.

  ORACLE GENERATED FIXUP SCRIPT
   =============================
   All of the issues in database ASKM
   which are identified above as AFTER UPGRADE "(AUTOFIXUP)" can be resolved by
   executing the following

    SQL>@/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/postupgrade_fixups.sql


==================
PREUPGRADE SUMMARY
==================
   /u01/app/oracle/cfgtoollogs/ASKM/preupgrade/preupgrade.log
   /u01/app/oracle/cfgtoollogs/ASKM/preupgrade/preupgrade_fixups.sql
   /u01/app/oracle/cfgtoollogs/ASKM/preupgrade/postupgrade_fixups.sql

Execute fixup scripts as indicated below:

Before upgrade log into the database and execute the preupgrade fixups
@/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/preupgrade_fixups.sql

After the upgrade:

Log into the database and execute the postupgrade fixups
@/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/postupgrade_fixups.sql

Preupgrade complete: 2018-08-18T03:19:08
[oracle@askmdb dbhome_1]$



Output of Preupgrade_fixups.sql :

SQL> @/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/preupgrade_fixups.sql
Executing Oracle PRE-Upgrade Fixup Script

Auto-Generated by:       Oracle Preupgrade Script
                          Version: 18.0.0.0.0 Build: 1
Generated on:            2018-08-18 03:18:57

For Source Database:     ASKM
Source Database Version: 12.1.0.2.0
For Upgrade to Version:  18.0.0.0.0

Preup                             Preupgrade
Action                            Issue Is
Number  Preupgrade Check Name     Remedied    Further DBA Action
------  ------------------------  ----------  --------------------------------
     1.  min_recovery_area_size    NO          Manual fixup required.
     2.  invalid_objects_exist     NO          Manual fixup recommended.
     3.  apex_manual_upgrade       NO          Manual fixup recommended.
     4.  dictionary_stats          YES         None.
     5.  tablespaces_info          NO          Informational only.
                                               Further action is optional.

The fixup scripts have been run and resolved what they can. However,
there are still issues originally identified by the preupgrade that
have not been remedied and are still present in the database.
Depending on the severity of the specific issue, and the nature of
the issue itself, that could mean that your database is not ready
for upgrade.  To resolve the outstanding issues, start by reviewing
the preupgrade_fixups.sql and searching it for the name of
the failed CHECK NAME or Preupgrade Action Number listed above.
There you will find the original corresponding diagnostic message
from the preupgrade which explains in more detail what still needs
to be done.

PL/SQL procedure successfully completed.

SQL>



Output of Postupgrade_fixups.sql


SQL> @/u01/app/oracle/cfgtoollogs/ASKM/preupgrade/postupgrade_fixups.sql

Session altered.


PL/SQL procedure successfully completed.


PL/SQL procedure successfully completed.


PL/SQL procedure successfully completed.


Package created.

No errors.

Package body created.


PL/SQL procedure successfully completed.

No errors.



Package created.

No errors.

Package body created.

No errors.
Executing Oracle POST-Upgrade Fixup Script

Auto-Generated by:       Oracle Preupgrade Script
                          Version: 18.0.0.0.0 Build: 1
Generated on:            2018-08-18 03:19:06

For Source Database:     ASKM
Source Database Version: 12.1.0.2.0
For Upgrade to Version:  18.0.0.0.0

Preup                             Preupgrade
Action                            Issue Is
Number  Preupgrade Check Name     Remedied    Further DBA Action
------  ------------------------  ----------  --------------------------------
     6.  depend_usr_tables         YES         None.
     7.  old_time_zones_exist      NO          Manual fixup recommended.
     8.  post_dictionary           YES         None.
     9.  post_fixed_objects        NO          Informational only.
                                               Further action is optional.

The fixup scripts have been run and resovled what they can. However,
there are still issues originally identified by the preupgrade that
have not been remedied and are still present in the database.
Depending on the severity of the specific issue, and the nature of
the issue itself, that could mean that your database upgrade is not
fully complete.  To resolve the outstanding issues, start by reviewing
the postupgrade_fixups.sql and searching it for the name of
the failed CHECK NAME or Preupgrade Action Number listed above.
There you will find the original corresponding diagnostic message
from the preupgrade which explains in more detail what still needs
to be done.

PL/SQL procedure successfully completed.


Session altered.

SQL>



Questions to Readers

Q1) Can we upgrade a database from earlier version to 18c to a read-only ORACLE_HOME ? ( To know more about read-only ORACLE_HOME , Please refer to our post at <> )

Q2) Is it necessary to remove the Oracle Database Express/Database Control before the upgrade ?


Hope this information helps.

 
Support :
Copyright © 2013. askMLabs - All Rights Reserved
Proudly powered by Blogger