Remove Oracle table row lock

STEP 1:  To identify the SID for the table with the lock, you will use this system ID in a later query to get the serial number for the table row lock:

SQL> select * from dba_dml_locks;

SQL> select
   session_id
from
   dba_dml_locks
where
   name = 'EF_AP_BALANCE';

Output :

SID
___
607

STEP 2:  The next step is a script to find the Serial# for the table row lock :

SQL> select
   sid,
   serial#
from
   v$session
where
   sid in (
   select
      session_id
   from
      dba_dml_locks
   where
      name = 'F_AP_BALANCE');

Output :

SID SERIAL#
---- -------
607 1402

STEP 3:  Finally, we can use the "alter system" command to kill the session that is holding the table lock:

alter system kill session 'SID,SERIALl#';

SQL> alter system kill session '607,1402';

Clean FND_NODES table after cloning in Oracle APPS R11/R12

Why we need to clean FND_NODES table post cloning by firing

 EXEC FND_CONC_CLONE.SETUP.CLEAN ?

Ans
-----
Because this table contains the IP Addresses of the source servers (apps and db) and when you clone your target servers have different IP Addresses that need to be populated in FND_NODES table.

Steps to Clean Nonexistent Nodes or IP Addresses from FND_NODES 

How to Clean :
------------------

SQL> select node_name, node_mode, support_cp, support_web, support_admin,support_forms from FND_NODES;

NODE_NAME              N S S S S
-----------------------------------------------
TARGET                     O Y Y Y Y
SOURCE                     O Y Y Y Y


1) Always apply the latest cloning patches, to avoid all the bugs and fixes

2) SQL> EXEC FND_CONC_CLONE.SETUP_CLEAN;
    COMMIT;
    EXIT;


3) Run AutoConfig on all tiers, firstly on the DB tier and then the APPS tiers,to repopulate the required system tables.



Note that step two will delete all data from system tables such as
FND_NODES, FND_OAM_CONTEXT_FILES, etc.


The correct information for the current system will be repopulated when AutoConfig is run.

Query for active users with v$session

select sesion.sid,
sesion.username,
optimizer_mode,
hash_value,
address,
cpu_time,
elapsed_time,
sql_text
from v$sqlarea sqlarea, v$session sesion
where sesion.sql_hash_value = sqlarea.hash_value
and sesion.sql_address = sqlarea.address
and sesion.username is not null


SQL> select a.sid, a.serial#, b.sql_text 2 from v$session a, v$sqlarea b 3 where a.sql_address=b.address 4 and a.username='APPS';

 SID         SERIAL#                     SQL_TEXT

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

 122         61521     select count(*) from gen_person where gen_person_id=95000

R12: Create Accounting Program Failed With xla_accounting_pkg.ValidateAAD. ORA-0000 Error Message

(Doc ID 1227207.1)

APPLIES TO:

Oracle Assets - Version 12.0.0 and later
Information in this document applies to any platform.
XLAACCUP - Create Accounting Program

SYMPTOMS

When attempting to run Create Accounting - Assets, the Accounting Program request (XLAACCUP) ends with the following error in the log file:-

ERROR
-----------------------
An internal error occurred. Please inform your system administrator or support representative that:
An internal error has occurred in the program xla_accounting_pkg.ValidateAAD.

ORA-0000: normal, successful completion.
.
The application accounting definition Assets Standard Accounting* owned by Oracle is not validated. Please validate the application accounting definition or update the application accounting definitions contained in the subledger accounting method Standard Accrual*.
---------

*The names may vary from these standard names where a customer is using a different Subledger Accounting Method / Application Accounting Definition.

CAUSE

The Application Accounting Definition for Assets is invalid.

SOLUTION

1. Validate the AADs via the concurrent request XLAABACR Validate Application Accounting Definitions for module = Assets.

Note xlaapeng.pkb requires that all AADs on the application be valid, even if they aren't used.  

2. Confirm all Asset AADs are validate (view output in #1)

3.  Re-run Create Accounting - Assets.

    

Find ORACLE_SID

There are several commands, some internal and some external to Oracle that will find your current ORACLE_SID.  Within Oracle (SQL*Plus) you can display your ORACLE_SID with any of these commands:

SQL>  select distinct sid from v$mystat;

SQL>  select * from global_name;

SQL>  select instance from v$thread;

SQL> select name from v$database;

There are also external commands that show the current settings for the ORACLE_SID variable:

[oradev@test ~]$ . /u01/dev/devdb/tech_st/11.2.0/DEV_test.env

[oradev@test ~]$ ps -ef | grep pmon

oradev 8034 1 0 Jan29 ? 00:00:34 ora_pmon_DEV
orarman 19983 1 0 2017 ? 00:19:40 ora_pmon_rmandb
oradev 29537 29494 0 12:00 pts/6 00:00:00 grep pmon

Hyper-V Linux Client Can't Talk To Network

#tail -f /var/log/messages

#tail -f -n 200 /var/log/messages

Eventually dmesg fills up with noise like:

eth2: 21140 transmit timed out, status fc6981c7, SIA fffffe00 00000068 00000070 fffffec8, resetting...
(or whatever your eth device is).

Solution:

# chkconfig irqbalance off 

# reboot


(Source)

How to resolve error "-bash: fork: retry: Resource temporarily unavailable" launching wsadmin scripts

Increasing the value of the ulimit -u (NPROC - max user processes) setting will prevent and eliminate the problem.

Check the current values of ulimit settings by issuing the following command as root (superuser) user:

ulimit -a

Red Hat Enterprise Linux v6 has default values of 1024 for both ulimit -u (nproc : maximum user processes) and ulimit -n (nofiles : open files : file descriptors) which are grossly inadequate for WebSphere environments.

WebSphere Support recommends a value of '131072' for NPROC. Engage the Unix / Linux System Administrator, to login to the affected Linux system or server as root (superuser) user, and issue the following command:

ulimit -u 131072

The value of the ulimit -n (NOFILES) setting should also be increased to the recommended value of '65536' at the same time, if it is at the default value of 1024, or a lower value than 65536, in order to prevent a variety of failures in WebSphere environments that can occur during install, update, jvm startup, application startup, administration, and application deployment operations, by issuing the following command as root user:

ulimit -n 65536

https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/resolve_too_many_open_files_error_and_native_outofmemory_due_to_failed_to_create_thread_issues_in_websphere_application_server_running_on_linux?lang=en

https://access.redhat.com/solutions/543503