SELECT s.SID, USERNAME AS “User”, PROGRAM, MODULE,
ACTION, LOGON_TIME “Logon”, l.*
FROM V$SESSION s, V$ENQUEUE_LOCK l
WHERE l.SID = s.SID
AND l.TYPE = ‘CF’
AND l.ID1 = 0
AND l.ID2 = 2;

After finding out the rman session details, you can kill the same so that the other rman jobs would start without any issue.

Happy learning…

This oracle error will appear when you are trying to drop an undo tablespace that contains the active rollback segments. The tablespace can be dropped only if the active rollback segments are cleared. The steps to resolve this issue are,

1. Identifiy the active rollback segment that was reported along with the error while attepting to drop the undo tablespace.

drop Tablespace UNDOTBS
*
ERROR at line 1:
ORA-01548: active rollback segment ‘_SYSSMU1$‘ found, terminate dropping tablespace

2. Make sure you have set the current UNDO_TABLESPACE to the new one.

3. Check whether you have a valid pfile if not then create the pfile from spfile.

4. Bring down the database.

5. Configure the UNDO_MANAGEMENT to Manual in the pfile.

6. Add a un-documented parameter _OFFLINE_ROLLBACK_SEGMENTS to the active segment reported in step 1.

7. Bring up the database.

8. Drop the active rollback segment using drop rollback segment “<name>”.

9. Drop the corrupted undo tablespace.

Hope this resolves the issue…

Method 1: – One can get the systemstate dump and the trace file shows the details about current running processes and the objects held or requested by the active processes. 

Method 2: – Query the ORACLE internal table X$KGLLK, which has more details compared to the V$LOCK Synonym. Combining this table and the V$SESSION Synonym will give you the holding session details. See Metalink note 122793.1 for more details on the query.

Method 3: – One can query the V$ACCESS Synonym to find the sid of the sessions that are accessing the object on which library cache lock event is there. With the help of this, one can narrow down the holding session details.

For more details look into the Metalink Doc. ID: – 122973.1.

SQL> alter system set NLS_LENGTH_SEMANTICS = CHAR

Then restarted the database and the import worked properly… It is better to have the NLS_LENGTH_SEMANTICS as CHAR. Chk out the below link for more info…

Article published in ORACLE Magazine

The OEM Agent after a blackout was restarting automatically again and again. Due to this all the components in the server where the agent was residing was in “Status pending” in OEM UI. The $AGENT_HOME/bin/emctl status agent shows the details of the same.

Solution:-

Even though the blackout has been stopped, stil it would have been registered in the agents registry, so cleaning off the blackout details averted this problem.

Step 1:- Stop the agent

                $AGENT_HOME/bin/emctl stop agent

Step 2:- Remove the blackouts.xml file.

                $ rm -rf $AGENT_HOME/sysman/emd/blackouts.xml  

                For clustered nodes

               $ rm -rf $AGENT_HOME/node/sysman/emd/blackouts.xml

Step 3:- Clear the state of the agent

                 $AGENT_HOME/bin/emctl clearstate agent

Step 4:- Finally start the agent

                 $AGENT_HOME/bin/emctl start agent

ORA-07445: exception encoutered: core dump [lxcsu22m()+12] [SIGSEGV] [unknow code]

Scenario:-

I got this error after restarting the database and when the application start sending its requests. I have checked the metalink and it is of no use. Bouncing the listener and database didn’t solve the issue.

Solution:-

The LD_LIBRARY_PATH and SHLIB_PATH does the trick here. After setting these parameters along with the necessary basic ORACLE environment parameters, the ORALCE Instance was started and the application was also started and this time no core dumps were seen in the alert log file. These variables are normally not required to start an instance, but in some cases we need to set these variables to avoid the core dump errors.

This shell script will help in finding the big files with respect to size in a particular mount point. Normally there is specific command to find out these information, so this shell script will give out the files in the mount point ordered by size in descending order. The output of the shell script will be in final.out file.

Usage :-  chk_ds_fs.sh <mount_point>

Output :-  “final.out” in the same directory where the shell file is residing.

Code:-

echo “Enter the path on which disk usage report is needed?”
read v_path
`du -akr $v_path | sort -n -r | head -n 50 > sample.out`
echo “Filename\t\t\t\t\t\t\t\t\t\t\t\t\tSize” > final.out
echo “=========================================”  >> final.out
while read EachRecord
do
filename=`echo $EachRecord| awk ‘{split($0,array)} END{print array[2]}’`
fsize=`echo $EachRecord| awk ‘{split($0,array)} END{print array[1]}’`
if [ -d $filename ]; then
   continue
else
   echo “$filename\t\t\t\t\t\t$fsize” >> final.out
fi
done < sample.out

 

…Vinod