Sujeet APPS DBA

SYSTEM-UNABLE TO SET NLS SORT

After clone i am not able to run active user concurrent program. facing below issue. Please find log file.
Application Object Library: Version : 12.1

Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved.

FNDSCURS: Active Users
+---------------------------------------------------------------------------+

Current system time is 13-JAN-2020 12:36:09
+---------------------------------------------------------------------------+
+-----------------------------
| Starting concurrent program execution...
+-----------------------------

SYSTEM-UNABLE TO SET NLS SORT
Concurrent Manager encountered an error while running Oracle*Report for your concurrent request 23849699.

Review your concurrent request log and/or report output file for more detailed information.
+---------------------------------------------------------------------------+
Executing request completion options...

Output file size:

Finished executing request completion options.
+---------------------------------------------------------------------------+
Concurrent request completed
Current system time is 13-JAN-2019 12:36:10

Solution :-

Solution is to apply Patch 24675262:R12.FND.B: SCHEDULED REQUEST ERROR SYSTEM-UNABLE TO SET NLS SORT DUE TO NEW NLS_SORT COLUMN, but this patch contains a version of afpcrm.oc that can cause potential data corruption - see bug 23021248.

Ref: BUG 23021248 - CONC REQUEST RUNNING TWICE CREATING BALANCE CORRUPTION

Apply Patch 23021248:R12.FND.B: CONC REQUEST RUNNING TWICE CREATING BALANCE CORRUPTION

ACTION PLAN
=============

On a test environment where the issue occurs, download and apply patch 23021248.

1. Download patch 23021248.
2. Enable 'Maintenance Mode.
3. execute adpatch.
4. Disable 'Maintenance Mode'

SQL> select bug_number,creation_date from ad_bugs where bug_number='23021248';

BUG_NUMBER CREATION_
------------------------------ ---------

23021248 15-JAN-20

Retest issue. I hope issue got resolved.

PLS-00905: object APPS.APPS is invalid

Today development team has reported an issue that when they are trying to compile any package which
have apps.<> schema reference thrown an error:

SQL> alter package XX_XXXX_PKG compile body;

Warning: Package Body altered with compilation errors.

SQL> show error
Errors for PACKAGE BODY XX_XXXX_PKG:

LINE/COL ERROR
-------- -----------------------------------------------------------------
1130/16 PL/SQL: Statement ignored
1130/16 PLS-00905: object APPS.APPS is invalid
1379/16 PL/SQL: Statement ignored
1379/16 PLS-00905: object APPS.APPS is invalid
1563/16 PL/SQL: Statement ignored
1563/16 PLS-00905: object APPS.APPS is invalid
1791/16 PL/SQL: Statement ignored
1791/16 PLS-00905: object APPS.APPS is invalid
SQL>

Cause:
An invalid package specification or stored subprogram was referenced.
A package specification or stored subprogram is invalid if its source code or
any database object it references has been DROPped, REPLACEd, or ALTERed since it was last compiled.

Action:
Find out what invalidated the package specification or stored subprogram,
then make sure that Oracle can recompile it without errors.
Now we should make sure that we have created the package in the right place.

Steps-1.

Package code I have compiled successfully in other instances like QA,
however got the error in dev instance. If we remove schema reference (apps) then it’s compiling from dev also
but as per coding standard it has good practice to use apps.<>.

Steps-2.

Now we should make sure that we have created the package in the right place.

Connect with apps schema :-

[Dev@oracle ~]$ sqlplus apps/apps

SQL > select owner, object_name, object_type
from dba_objects
where object_name='XX_XXXX_PKG'
order by 1,2,3;

Output- Perfect no issue in place.
owner object_name object_type
APPS XX_XXXX_PKG PACKAGE
APPS XX_XXXX_PKG PACKAGE BODY

Steps-3.

I have checked the compiler log again and found APPS.APPS that means some developer mistakenly crated the apps
name package on apps schema. That may be our case.

Now check :

SQL > select owner, object_name, object_type
from dba_objects
where OBJECT_NAME='APPS'
order by 1,2,3;

found one object created with name apps.

Steps-4.

Now we should drop apps object

SQL > drop package apps;

Steps-5.

Try compiling the package in dev instance again.

I hope issue fix.

Inventory load failed

Inventory load failed... OPatch cannot load inventory for the given Oracle Home.
Possible causes are:

[ora@oracle OPatch]$ opatch lsinventory

Oracle Interim Patch Installer version 12.1.0.1.3
Copyright (c) 2019, Oracle Corporation. All rights reserved.

Oracle Home : /u01/app/db/tech_st/12.1.0.2
Central Inventory : /u01/app/db/oraInventory
from : /u01/app/db/tech_st/12.1.0.2/oraInst.loc
OPatch version : 12.1.0.1.3
OUI version : 12.1.0.2.0
Log file location : /u01/app/db/tech_st/12.1.0.2/cfgtoollogs/opatch/opatchAM_1.log

List of Homes on this system:

Inventory load failed... OPatch cannot load inventory for the given Oracle Home.
Possible causes are:
Oracle Home dir. path does not exist in Central Inventory
Oracle Home is a symbolic link
Oracle Home inventory is corrupted
LsInventorySession failed: OracleHomeInventory gets null oracleHomeInfo

OPatch failed with error code 73

Solution

[ora@oracle ~]$ cd $ORACLE_HOME/oui/bin
[ora@oracle bin]$ pwd
/u01/app/db/tech_st/12.1.0.2/oui/bin

[ora@oracle bin]$ vi attachHome.sh

[ora@oracle bin]$ ./attachHome.sh

Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB. Actual 8191 MB Passed
The inventory pointer is located at /etc/oraInst.loc

'AttachHome' was successful.

Retest issue.

[ora@oracle OPatch]$ opatch lsinventory

Issue has been resolved.

Recover a dropped table in Oracle 11g

How to recover a dropped table in Oracle 11g when flashback mode is off

After dropping table and before restoring it from the recycle bin, run the following query:

Login with table owner schema.

SQL > SELECT OBJECT_NAME, ORIGINAL_NAME, TYPE FROM RECYCLEBIN;

if table is there than use below statement to restore.

Restore the table with the following command:

SQL > FLASHBACK TABLE drop_table_NAME TO BEFORE DROP;

Recovering dropped table is easy in Oracle, provided that the table was not dropped with PURGE option. In case the table is dropped and space occupied by the table is released and the table does not get moved into the recycle bin. But if table is dropped without PURGE option, Oracle has this very neat feature - Recycle bin, similar to the recycle bin in Windows. There are two recyle bin views in Oracle: USER_RECYCLEBIN and DBA_RECYCLEBIN, Synonym RECYCLEBIN points to your USER_RECYCLEBIN.

The recycle bin can be turned on and off with RECYCLEBIN initialization parameter. When table is dropped, it get rename to system-generated name preceeded with BIN and stored in recycle bin. The important thing to know is that after table has been dropped, it's only been renamed, the table segmants are still in the tablespace, unchanged. the space occupied by the table will not be reclaimed until the table has been purged from the recycle bin.

While in the recycle bin, the table can even be queried using the newly generated name that starts qwith BIN$.

The table can easily be recovered from the recycle bin using flashback drop, which will rename the table to its original name.

You can check flashback mode by running

SELECT FLASHBACK_ON FROM V$DATABASE;

First check the parameter Recyclebin is set to true. Recycle bin is a data dictionary table that contains information about dropped objects. Dropped tables and any associated objects such as indexes, constraints, nested tables, and the likes are not removed and still occupy space. They continue to count against user space quotas, until specifically purged from the recycle bin or the unlikely situation where they must be purged by the database because of tablespace space constraints.

SHOW PARAMETER RECYCLEBIN;

if recyclebin is set to off, perform the following steps:

ALTER SYSTEM SET RECYCLEBIN=ON SCOPE=SPFILE;

verify that recyclebin parameter is now set to ON

shutdown the database
SHUTDOWN IMMEDIATE

Restart the database
STARTUP

then run
SELECT * FROM RECYCLEBIN;

and see if your table is in there. If it is, use the following quesry to restore it:
FLASHBACK TABLE TO BEFORE DROP;

Then check if the table is back:
SELECT * FROM USER_TABLES WHERE TABLE_NAME=;

**********************************************************

SQL > SELECT * FROM RECYCLEBIN;

SQL > SELECT object_name, original_name FROM dba_recyclebin WHERE owner = 'Schema_name';

SQL > SELECT object_name, original_name, createtime FROM recyclebin;

SQL > desc dba_recyclebin;

SQL > select OWNER,OBJECT_NAME,ORIGINAL_NAME,CREATETIME,DROPTIME from dba_recyclebin WHERE owner = 'Schema_name';

Login with drop table owner schema

SQL > show user;

HR

SQL > FLASHBACK TABLE DROP_TABLE_NAME TO BEFORE DROP;

Clear Recyclebin

To remove all dropped objects from the recyclebin (current user):

PURGE RECYCLEBIN;
To remove all dropped objects from the recyclebin (system wide, available to SYSDBA only or, starting with version 12c, to users having the PURGE DBA_RECYCLEBIN system privilege):

PURGE DBA_RECYCLEBIN;
Tables can also be dropped without sending them to the recyclebin. Example:

DROP TABLE tba PURGE;
Tables inside recycle bin can be purged individually. Example:

PURGE TABLE tba;

Drop a table:

SQL> DROP TABLE tba;
Undrop the table:

SQL> FLASHBACK TABLE tba TO BEFORE DROP;

ORA-48913: Writing into trace file failed, file size limit

Error detailed from alert log.

Error message: ORA-48913: Writing into trace file failed, file size limit [10485760] reached
ORA-609 : opiodr aborting process unknown ospid (4397_47562687353296)
ORA-609 : opiodr aborting process unknown ospid (28545_47989084123600)
ORA-609 : opiodr aborting process unknown ospid (4703_47579510747600)
Non critical error ORA-48913 caught while writing to trace file "/u01/prod/db/tech_st/11.1.0/admin/PROD1_prod1/
diag/rdbms/prod1/PROD1/trace/PROD1_dbrm_13082.trc"
Error message: ORA-48913: Writing into trace file failed, file size limit [10485760] reached

Cause :-

We can increase the setting for the parameter MAX_DUMP_FILE_SIZE or set it to unlimited

MAX_DUMP_FILE_SIZE specifies the maximum size of trace files (excluding the alert file). Change this limit if you are concerned that trace files may use too much space.
A numerical value for MAX_DUMP_FILE_SIZE specifies the maximum size in operating system blocks.
A number followed by a K or M suffix specifies the file size in kilobytes or megabytes.
The special value string UNLIMITED means that there is no upper limit on trace file size. Thus, dump files can be as large as the operating system permits.

Solution :-

SQL> show parameter MAX_DUMP_FILE_SIZE;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
max_dump_file_size string 20480
SQL>

You would need to reset value of MAX_DUM_FILE_SIZE in order to have your trace files size extend beyond 20480 MB now. You can use “alert system”
command to change the value. You may also set it to UNLIMITED.

SQL> ALTER SYSTEM SET max_dump_file_size=unlimited;

Pluggable Database (PDB) useful SQL statement

[ora@oracle]$ sqlplus system/****@PROD_CDB

SQL> show con_name;

CON_NAME
------------------------------
CDB$ROOT

SQL> select name from v$database;

NAME
---------
PROD

SQL> show pdbs;

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB MOUNTED

SQL> ALTER SESSION SET CONTAINER= PDB;

Session altered.

SQL> ALTER PLUGGABLE DATABASE OPEN;

Warning: PDB altered with errors.

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> show pdbs;

CON_ID CON_NAME OPEN MODE RESTRICTED

---------- ------------------------------ ---------- ----------

3 PDB READ WRITE YES

SQL> shut immediate

SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;

System altered.

SQL> select value from v$parameter where name='PDB';

SQL> select cause, message from pdb_plug_in_violations where name = 'PDB';

SQL> select * from v$services;

SQL> select SERVICE_ID,NAME,NETWORK_NAME from v$services;

SQL> select NAME from v$services;

[ora@oracle]$ sqlplus apps/****@PDB

SQL> select username from dba_users where USERNAME= 'APPS';

no rows selected