How to drop DBConsole using EMCA or manually (with and without repository)

How to drop DBConsole configuration along with the repository using EMCA? 

To completely remove the DBConsole configuration files and repository run below command. 

<ORACLE_HOME>/bin/emca -deconfig dbcontrol db -repos drop

Enter the following information:
Database SID: orcl
Listener port number: 1521
Password for SYSMAN user:
Do you wish to continue? [yes(Y)/no(N)]: Y

This command will remove the DBConsole configuration files under <ORACLE_HOME>/<Hostname_SID>,
<ORACLE_HOME>/oc4j/j2ee/OC4J_DBConsole_<Hostname>_<SID>
as well as DBConsole repository from the Database.

How to drop DBConsole configuration files using EMCA (leave repository intact) ?

 To remove DBConsole configuration files (leaving repository intact) run following EMCA command.

<ORACLE_HOME>/bin/emca -deconfig dbcontrol db

Enter the following information:
Database SID: orcl
Do you wish to continue? [yes(Y)/no(N)]:

This command will remove only the DBConsole configuration files which are under <ORACLE_HOME>/<Hostname_SID> and <ORACLE_HOME>/oc4j/j2ee/OC4J_DBConsole_<Hostname>_<SID>

How to drop DBConsole repository objects manually ?

DBConsole repository can be dropped manually by executing following SQL statements.

Step 1: Drop AQ related objects in the SYSMAN schema
Logon SQLPLUS as user SYS
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'SYSMAN.MGMT_NOTIFY_QTABLE',force=>TRUE);

Step 2: Drop the DB Control Repository Objects
Logon SQLPLUS as user SYS or SYSTEM, and drop the sysman account and management objects:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP RESTRICT;
SQL> EXEC sysman.emd_maintenance.remove_em_dbms_jobs;
SQL> EXEC sysman.setEMUserContext('',5);
SQL> REVOKE dba FROM sysman;
SQL> DECLARE
CURSOR c1 IS
SELECT owner, synonym_name name
FROM dba_synonyms
WHERE table_owner = 'SYSMAN';
BEGIN
FOR r1 IN c1 LOOP
IF r1.owner = 'PUBLIC' THEN
EXECUTE IMMEDIATE 'DROP PUBLIC SYNONYM '||r1.name;
ELSE
EXECUTE IMMEDIATE 'DROP SYNONYM '||r1.owner||'.'||r1.name;
END IF;
END LOOP;
END;
/
SQL> DROP USER mgmt_view CASCADE;
SQL> DROP ROLE mgmt_user;
SQL> DROP USER sysman CASCADE;
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

How to delete DBConsole configuration files manually?

To manually delete DBConsole configuration files, remove the following directories from the filesystem:

<ORACLE_HOME>/<hostname_sid>
<ORACLE_HOME>/oc4j/j2ee/OC4J_DBConsole_<hostname>_<sid>

If the dbcontrol is upgraded from lower version, for example, from 10.2.0.3 to 10.2.0.4, then the following directory also needs to be removed from the file system.
<ORACLE_HOME>/<hostname_sid>.upgrade
<ORACLE_HOME>/oc4j/j2ee/OC4J_DBConsole_<hostname>_<sid>.upgrade

NOTE : Be careful while removing these directories as one should NOT remove OC4J_DBConsole or any other directory by mistake, they are very important. You need to delete only those directories with <hostname>_<sid> where hostname is the hostname of the server and SID should be the database SID.

On Windows you also need to delete the DB Console service:
Using regedit
- run regedit
- navigate to HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services
- locate the OracleDBConsole<sid> entry and delete it
Or
On Windows XP and Windows Server 2003 you can run the following from the command line:
CMD> sc delete <service_name>
- where <service_name> is the DB Control service name (typically: OracleDBConsole<sid>)
Or
CMD> nmesrvops delete <servicename>
- where <service_name> is the DB Control service name (typically: OracleDBConsole<sid>)

How to Find a JAR File Which Contains a Particular JAVA CLASS Object?

How to find a jar file which contains a particular JAVA CLASS object
--------------------------------------------------------------------

1) Find invalid java classes:
   --------------------------
Lets assume that we have two JAVA CLASS invalids as returned by the
following query:

SQL>SELECT object_name,object_type,owner,status FROM dba_objects
WHERE object_type='JAVA CLASS' AND status='INVALID';
OBJECT_NAME                    OBJECT_TYPE OWNER   STATUS
------------------------------ ----------- ------- -------
/b0993e19_MyAppsContext        JAVA CLASS  APPS    INVALID
oracle/apps/fnd/common/FileLog JAVA CLASS  APPS    INVALID

2) Try to resolve invalids:
   ------------------------
First of all try to resolve these invalids using following statements.

SQL>ALTER JAVA CLASS "/b0993e19_MyAppsContext" RESOLVE;
SQL> ALTER JAVA CLASS "oracle/apps/fnd/common/FileLog" RESOLVE;
Note: If you don't include java class name in double quotes the statements will fail.

If these objects are still invalid proceed to next step

3) Find respective modules of java classes:
   ----------------------------------------
We need to check as to which module the JAVA CLASS belongs.

To check the module of first invalid run the following statement:
SQL>SELECT dbms_java.longname('/b0993e19_MyAppsContext') FROM dual;
DBMS_JAVA.LONGNAME('/B0993E19_MYAPPSCONTEXT')
---------------------------------------------------
oracle/apps/wms/cartonization/server/MyAppsContext

The result of this query shows that this java class is associated 
with WMS module as it is included in oracle/apps/wms package

From the name of second invalid above, FileLog, it is clear that it is
associated with FND module as it is included in oracle/apps/fnd package.

4) Find jar file which includes the java class:
   --------------------------------------------
Create a shell script, say, whichjar.sh with the following logic:

#!/usr/bin/ksh
for f in `ls $1/java/jar/*.jar`
do
        t=`strings $f | grep $2`
        if test ! -z "$t"
        then
                echo "$2 is found in $f"
        fi
done 

Now run the script with the following command:

$./whichjar.sh <$PRODUCT_TOP> <CLASSNAME>

$./whichjar.sh $WMS_TOP MyAppsContext
MyAppsContext is found in /u01/visappl/wms/11.5.0/java/jar/wmscrtzn.jar

$./whichjar.sh $FND_TOP FileLog
FileLog is found in /u01/visappl/fnd/11.5.0/java/jar/fndaolj.jar

Translation Synchronization Patches.

TSP is a process to synchronize US language and other installed languages which is a very efficient process.

It is based on ad_.. tables like for example AD_FILE_VERSIONS

and those tables are updated when you apply a patch or when you run adadmin / maintain snapshot.

When you generate the file manisfest using adgennls.pl script,

this script compares the files versions (from the AD_.. tables) between the US  and the other installed languages

and generates the adgennls.txt file.

So this means the same TSP can only be applied if your 2 instances are exactly similar (clone)

In case you applied different patches then you need to generate a new file manifest.

The TSP will provide a patch containing all the NLS objects that are in a lower

version that their corresponding US object, so only the objects that really need a translation will be provided by the TSP.