ora 01031 insufficient privileges oracle apex 12cr2

Error: Getting the following error after upgrade Database from Oracle 12c R1 to Oracle 12c R2

ora 01031 insufficient privileges oracle apex 12cr2

Solution

SQL> show parameter sql

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE
plsql_ccflags                        string
plsql_code_type                      string      INTERPRETED
plsql_debug                          boolean     FALSE
plsql_optimize_level                 integer     2
plsql_v2_compatibility               boolean     FALSE
plsql_warnings                       string      DISABLE:ALL
sql92_security                       boolean     TRUE
sql_trace                            boolean     FALSE
sqltune_category                     string      DEFAULT
SQL>

younus01
689456

SQL> alter system set sql92_security=FALSE scope=spfile;

System altered.

SQL>

If the SQL92_SECURITY initialization parameter is set to TRUE and the DELETE operation references table columns, such as the columns in a where_clause, then you must also have the SELECT object privilege on the object from which you want to delete rows.

https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/DELETE.html#GUID-156845A5-B626-412B-9F95-8869B988ABD7

So if you only grant delete, a plain delete with no where clause will work. But you need select to use a where clause (assuming you've set SQL92_SECURITY; true is the default).

Password Oracle 12c SEC_CASE_SENSITIVE_LOGON and ORA-01017... 12c and Later Releases

Error: Oracle 12c SEC_CASE_SENSITIVE_LOGON and ORA-01017

Cause:

This issue is caused by the default setting for allowed logon version in the 12 database.
Note that the SQLNET.ALLOWED_LOGON_VERSION parameter has been deprecated in 12c.
That parameter has been replaced by these:
SQLNET.ALLOWED_LOGON_VERSION_SERVER=n
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=n
Version 12.1:The default setting for the new parameters is 11.  Any client that attempts to connect must
be at version 11 or higher unless these parameters are explicitly set in the server side sqlnet.ora file.
Version 12.2 note:
The default for the SQLNET.ALLOWED_LOGON_VERSION_SERVER setting has changed in 12.2 from 11 to 12.
See:  https://docs.oracle.com/database/122/DBSEG/configuring-authentication.htm#DBSEG33223
Important note for 12.2:  If your client is not at least 11.2.0.3 or includes the CPUOCT2012 patch you will not be able
to use the 12 setting.
Typically, the sqlnet.ora file that would be referenced by the database is located in RDBMS_HOME/network/admin.

Solution

The init.ora/spfile parameter SEC_CASE_SENSITIVE_LOGON got deprecated since Oracle Database 12.1.0.1
This means, we don’t do any further developments to it, you shouldn’t change it from its default TRUE and if you still do you’ll receive a nice warning during STARTUP of your database:
SQL> alter system set sec_case_sensitive_logon=false scope=spfile;
System altered.
SQL> startup force
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Recently a user asked me if we’d changed the behavior of this parameter in Oracle Database 12c Release 2 as he receives now an ORA-01017: Invalid username or password error when having SEC_CASE_SENSITIVE_LOGON=FALSE with every user except SYSDBAs
In which situations may you receive an ORA-01017?
This is outlined in the Oracle 12.1 documentation already:
•Ensure that the SEC_CASE_SENSITIVE_LOGON parameter is not set to FALSE if the SQLNET.ALLOWED_LOGON_VERSION_SERVER parameter is set to 12 or 12a
This is because the more secure password versions used for this mode only support case-sensitive password checking.
For compatibility reasons, Oracle Database does not prevent the use of FALSE for SEC_CASE_SENSITIVE_LOGON when SQLNET.ALLOWED_LOGON_VERSION_SERVER is set to 12 or 12a
Setting SEC_CASE_SENSITIVE_LOGON to FALSE when SQLNET.ALLOWED_LOGON_VERSION_SERVER is set to 12 or 12a causes all accounts to become inaccessible.
The key is the sqlnet.ora parameter SQLNET.ALLOWED_LOGON_VERSION_SERVER and here’s the difference between Oracle Database 12.1 and Oracle Database 12.2:
•Oracle Database 12.1: SQLNET.ALLOWED_LOGON_VERSION_SERVER defaults to 11 out of the box
•Oracle Database 12.2: SQLNET.ALLOWED_LOGON_VERSION_SERVER defaults to 12 out of the box
Behavior difference Oracle 12.1 vs Oracle 12.2
See this simple example after switching SEC_CASE_SENSITIVE_LOGON=FALSE in both databases (as shown above):
•Oracle Database 12.1.0.2:
SQL> alter user system identified by oracle;
User altered.
SQL> connect system/oracle
Connected.
•Oracle Database 12.2.0.1:
SQL> alter user system identified by oracle;
User altered.
SQL> connect system/oracle
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE
How to workaround the ORA-01017?
First of all you need to edit your sqlnet.ora adding (or lowering) the parameter SQLNET.ALLOWED_LOGON_VERSION_SERVER to a value below 12
But if you try to connect directly after restarting your listener you will receive the same ORA-01017 again
The secret is mentioned in the above documentation link as well, you will have to recreate the user’s password if you need the logon process to work as it did work before Oracle Database 12.2
sqlnet.ora
# sqlnet.ora Network Configuration File: /d01/app/oracle/product/12.2.0.1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.

-bash-4.4$ cd $ORACLE_HOME/network/admin/
-bash-4.4$ cat sqlnet.ora
# sqlnet.ora Network Configuration File: /oraclehome/app/oracle/product/12.2.0.1/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.

NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)
SQLNET.ALLOWED_LOGON_VERSION_SERVER=11

-bash-4.4$

Check in DBA_USERS
SQL> select username, password_versions
from DBA_USERS
where username='SYSTEM';
USERNAME      PASSWORD_VERSIONS
------------- ---------------------
SYSTEM        11G 12C
There’s no “10G” mentioned. This will prevent the connection.
Solution: You will have to specify the password again respective ALTER the user(s):

SQL> alter user SYSTEM identified by said;
User altered.

SQL> select username, password_versions
from DBA_USERS
where username='SYSTEM';
USERNAME       PASSWORD_VERSIONS
-------------- ----------------------
SYSTEM         10G 11G 12C
SQL> connect system/said

Connected.

clean up the asm disk header of all the disks in the diskgroup

-bash-4.1$ asmcmd lsdg --discovery
State       Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED     NORMAL  N         512   4096  1048576   6752416   447285           306928           70178              0             N  DATA/
MOUNTED     EXTERN  N         512   4096  1048576   1227964  1216729                0         1216729              0             N  UFRA/
DISMOUNTED          N           0      0        0         0        0                0               0              0             N  ULOG1/
DISMOUNTED          N           0      0        0         0        0                0               0              0             N  ULOG2/
DISMOUNTED          N           0      0        0         0        0                0               0              0             N  ULOG3/
-bash-4.1$

SQL> select name ,state from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
ULOG2                          DISMOUNTED
ULOG3                          DISMOUNTED
DATA                           MOUNTED
ULOG1                          DISMOUNTED
UFRA                           MOUNTED

SQL>


dd if=/dev/zero of=/dev/oracle/dg/c11t7d0 bs=8192 count=100

dd if=/dev/zero of=/dev/rdsk/c0t600601607E734D001E78DB5D1E6BE161d0s0 bs=8192 count=100

SQL> select name ,state from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
ULOG2                          DISMOUNTED
ULOG3                          DISMOUNTED
DATA                           MOUNTED
UFRA                           MOUNTED

SQL>

dd if=/dev/zero of=/dev/rdsk/c0t600601607E734D001E78DB5D99FC3B3Cd0s0 bs=8192 count=100
dd if=/dev/zero of=/dev/rdsk/c0t600601607E734D001E78DB5DFF0A0E8Ed0s0 bs=8192 count=100

root@badb1-t7-2:~# dd if=/dev/zero of=/dev/rdsk/c0t600601607E734D001E78DB5D99FC3B3Cd0s0 bs=8192 count=100
100+0 records in
100+0 records out
root@badb1-t7-2:~# dd if=/dev/zero of=/dev/rdsk/c0t600601607E734D001E78DB5DFF0A0E8Ed0s0 bs=8192 count=100
100+0 records in
100+0 records out
root@badb1-t7-2:~#

SQL> select name ,state from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
DATA                           MOUNTED
UFRA                           MOUNTED