How to get the dependencies

11 09 2008

There are two ways you may check the dependencies of a table:

1) Using Toad you can see the dependecies of a table

2) Yaping Chen recommends using a procedure with “dbma_utility.GET_DEPENDENCY”

example:

sys@TEST>exec dbms_utility.GET_DEPENDENCY(‘TABLE’,'TEST’,'T1′);
-
DEPENDENCIES ON TEST.T1
——————————————————————
*TABLE TEST.T1()
*   FUNCTION TEST.FUN_T1_01()
*      FUNCTION TEST.FUN_T1_02()
PL/SQL procedure successfully completed.




Enabling ARCHIVELOG Mode

12 08 2008

This is a good review of enabling archive log – an article coming from cuddletech(http://www.cuddletech.com/articles/oracle/node58.html)

Most of the High Availability features of Oracle require you to enable ARCHIVELOG mode for your database. When you enable this mode redo logs will be archived instead of overwritten. The archivelogs are stored in a seperate place usually can backed up regularly by your standard filesystem backup system (NetBackup or whatever). Archive logs are utilized by RMAN, Data Guard, Flashback and many others.

If your going to enable archivelog mode on a real database thats important to you, I would recommend shutting down the database and doing a cold backup just in case. Keeping a “final noarchivelog mode backup” seems to be a good and excepted practice.

Enabling archive mode is simple, just connect to your database in mounted but closed mode (startup mount) and alter the database. But if you don’t tune alittle you’ll run into problems down the road, so lets specify some parameters too. Namely, consider LOG_ARCHIVE_DEST.

Lets start by checking the current archive mode.

SQL> SELECT LOG_MODE FROM SYS.V$DATABASE;

LOG_MODE
------------
NOARCHIVELOG

So we’re in NOARCHIVELOG mode and we need to change. We can use a database alter statement, but that won’t be perminant, so lets just update the pfile directly. The pfile should be in either $ORACLE_BASE/admin/SID/pfile or $ORACLE_HOME/admin/SID/pfile. I’ll add the following lines to the end of the file:

############################
# Archive Log Destinations -benr(10/15/04)
############################
log_archive_dest_1='location=/u02/oradata/cuddle/archive'
log_archive_start=TRUE

Note that we’re not actually required to specify the location of the log destination, but if you don’t it’ll end up in strange places (in my test it went to $ORACLE_HOME/dbs making a mess). You can specify as many as 10 diffrent archive log destinations by using the paramters log_archive_dest_1 through log_archive_dest_10. Remember, if you run out of space in your archive log destination the database will shut down!

Now we can startup the database in mount mode and put it in archivelog mode.

[oracle@vixen pfile]$sqlplus sys/passwd as sysdba;
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Oct 15 16:00:58 2004
Copyright (c) 1982, 2004, Oracle.  All rights reserved.
Connected to an idle instance.

SQL> startup mount
ORACLE instance started.

Total System Global Area  184549376 bytes
Fixed Size                  1300928 bytes
Variable Size             157820480 bytes
Database Buffers           25165824 bytes
Redo Buffers                 262144 bytes
Database mounted.

SQL> alter database archivelog;
Database altered.

SQL> alter database open;
Database altered.

You can see here that we put the database in ARCHIVELOG mode by using the SQL statement “alter database archivelog”, but Oracle won’t let us do this unless the instance is mounted but not open. To make the change we shutdown the instance, and then startup the instance again but this time with the “mount” option which will mount the instance but not open it. Then we can enable ARCHIVELOG mode and open the database fully with the “alter database open” statement.

There are several system views that can provide us with information reguarding archives, such as:

V$DATABASE
Identifies whether the database is in ARCHIVELOG or NOARCHIVELOG mode and whether MANUAL (archiving mode) has been specified.
V$ARCHIVED_LOG
Displays historical archived log information from the control file. If you use a recovery catalog, the RC_ARCHIVED_LOG view contains similar information.
V$ARCHIVE_DEST
Describes the current instance, all archive destinations, and the current value, mode, and status of these destinations.
V$ARCHIVE_PROCESSES
Displays information about the state of the various archive processes for an instance.
V$BACKUP_REDOLOG
Contains information about any backups of archived logs. If you use a recovery catalog, the RC_BACKUP_REDOLOG contains similar information.
V$LOG
Displays all redo log groups for the database and indicates which need to be archived.
V$LOG_HISTORY
Contains log history information such as which logs have been archived and the SCN range for each archived log.

Using these tables we can verify that we are infact in ARCHIVELOG mode:

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

SQL> select DEST_NAME,STATUS,DESTINATION from V$ARCHIVE_DEST;




How to check Database Availability automatically using a script

8 08 2008

The following script does the database checking automatically:

check_database()
{
if [ `ps -fu oracle | grep smon | wc -l` -gt 0 ] ; then
echo “Database is up and running ” > $status # Just store the status
in a temp file
else
sleep 900 # just sleep for 15 min
if [ `ps -fu oracle | grep smon | wc -l` -eq 0 ] ;then
echo” Database is unavailable for this moment ” >$status_not #
Just store the status in a temp file
fi
fi
}

Thanks to





Top DBA Shell Scripts for Monitoring the Database

8 08 2008

As I was browsing the internet, I found this article and script collection of Daniel T. Liu http://www.dbazine.com/oracle/or-articles/liu2#instance

Please feel free to test his scripts and hope it could help you too in your day to day database administrations.
Introduction

This article focuses on the DBA’s daily responsibilities for monitoring Oracle databases and provides tips and techniques on how DBAs can turn their manual, reactive monitoring activities into a set of proactive shell scripts. The article first reviews some commonly used Unix commands by DBAs. It explains the Unix Cron jobs that are used as part of the scheduling mechanism to execute DBA scripts. The article covers eight important scripts for monitoring Oracle database:

+ Check instance availability
+ Check listener availability
+ Check alert log files for error messages
+ Clean up old log files before log destination gets filled
+ Analyze tables and indexes for better performance
+ Check tablespace usage
+ Find out invalid objects
+ Monitor users and transactions

UNIX Basics for the DBA
Basic UNIX Command

The following is a list of commonly used Unix command:

+ ps – Show process
+ grep – Search files for text patterns
+ mailx – Read or send mail
+ cat – Join files or display them
+ cut – Select columns for display
+ awk – Pattern-matching language
+ df – Show free disk space

Here are some examples of how the DBA uses these commands:

+ List available instances on a server:

$ ps -ef | grep smon
oracle 21832     1  0   Feb 24 ?       19:05 ora_smon_oradb1
oracle   898     1  0   Feb 15 ?        0:00 ora_smon_oradb2
dliu 25199 19038  0 10:48:57 pts/6    0:00 grep smon
oracle 27798     1  0 05:43:54 ?        0:00 ora_smon_oradb3
oracle 28781     1  0   Mar 03 ?        0:01 ora_smon_oradb4

+ List available listeners on a server:

$ ps -ef | grep listener | grep -v grep
oracle 23879    1  0   Feb 24 ?  33:36 /8.1.7/bin/tnslsnr listener_db1 -inherit
oracle 27939    1  0 05:44:02 ?  0:00  /8.1.7/bin/tnslsnr listener_db2 -inherit
oracle 23536    1  0   Feb 12 ?  4:19  /8.1.7/bin/tnslsnr listener_db3 -inherit
oracle 28891    1  0   Mar 03 ?  0:01  /8.1.7/bin/tnslsnr listener_db4 -inherit

+ Find out file system usage for Oracle archive destination:

$ df -k | grep oraarch
/dev/vx/dsk/proddg/oraarch 71123968 4754872 65850768  7%  /u09/oraarch

+ List number of lines in the alert.log file:

$ cat alert.log | wc -l
2984

+ List all Oracle error messages from the alert.log file:

$ grep ORA- alert.log
ORA-00600: internal error code, arguments: [kcrrrfswda.1], [], [], [], [], []
ORA-00600: internal error code, arguments: [1881], [25860496], [25857716], []

CRONTAB Basics

A crontab file is comprised of six fields:
Minute     0-59
Hour     0-23
Day of month     1-31
Month     1 – 12
Day of Week     0 – 6, with 0 = Sunday
Unix Command or Shell Scripts

+ To edit a crontab file, type:

Crontab -e

+ To view a crontab file, type:

Crontab -l
0  4 * * 5       /dba/admin/analyze_table.ksh
30 3  * * 3,6    /dba/admin/hotbackup.ksh /dev/null 2>&1

In the example above, the first entry shows that a script to analyze a table runs every Friday at 4:00 a.m. The second entry shows that a script to perform a hot backup runs every Wednesday and Saturday at 3:00 a.m.
Top DBA Shell Scripts for Monitoring the Database

The eight shell scripts provided below cover 90 percent of a DBA’s daily monitoring activities. You will need to modify the UNIX environment variables as appropriate.
Check Oracle Instance Availability

The oratab file lists all the databases on a server:

$ cat /var/opt/oracle/oratab
###################################################################
## /var/opt/oracle/oratab                                        ##
###################################################################
oradb1:/u01/app/oracle/product/8.1.7:Y
oradb2:/u01/app/oracle/product/8.1.7:Y
oradb3:/u01/app/oracle/product/8.1.7:N
oradb4:/u01/app/oracle/product/8.1.7:Y

The following script checks all the databases listed in the oratab file, and finds out the status (up or down) of databases:

###################################################################
## ckinstance.ksh ##
###################################################################
ORATAB=/var/opt/oracle/oratab
echo “`date`   “
echo  “Oracle Database(s) Status `hostname` :\n”

db=`egrep -i “:Y|:N” $ORATAB | cut -d”:” -f1 | grep -v “\#” | grep -v “\*”`
pslist=”`ps -ef | grep pmon`”
for i in $db ; do
echo  “$pslist” | grep  “ora_pmon_$i”  > /dev/null 2>$1
if (( $? )); then
echo “Oracle Instance – $i:       Down”
else
echo “Oracle Instance – $i:       Up”
fi
done

Use the following to make sure the script is executable:

$ chmod 744 ckinstance.ksh
$ ls -l ckinstance.ksh
-rwxr–r–   1 oracle     dba     657 Mar  5 22:59 ckinstance.ksh*

Here is an instance availability report:

$ ckinstance.ksh
Mon Mar  4 10:44:12 PST 2002
Oracle Database(s) Status for DBHOST server:
Oracle Instance – oradb1:   Up
Oracle Instance – oradb2:   Up
Oracle Instance – oradb3:   Down
Oracle Instance – oradb4:   Up

Check Oracle Listener’s Availability

A similar script checks for the Oracle listener. If the listener is down, the script will restart the listener:

#######################################################################
## cklsnr.sh                                                         ##
#######################################################################
#!/bin/ksh
DBALIST=”primary.dba@company.com,another.dba@company.com”;export DBALIST
cd /var/opt/oracle
rm -f lsnr.exist
ps -ef | grep mylsnr | grep -v grep  > lsnr.exist
if [ -s lsnr.exist ]
then
echo
else
echo “Alert” | mailx -s “Listener ‘mylsnr’ on `hostname` is down” $DBALIST
TNS_ADMIN=/var/opt/oracle; export TNS_ADMIN
ORACLE_SID=db1; export ORACLE_SID
ORAENV_ASK=NO; export ORAENV_ASK
PATH=$PATH:/bin:/usr/local/bin; export PATH
. oraenv
LD_LIBRARY_PATH=${ORACLE_HOME}/lib;export LD_LIBRARY_PATH
lsnrctl start mylsnr
fi

Check Alert Logs (ORA-XXXXX)

Some of the environment variables used by each script can be put into one profile:

#######################################################################
## oracle.profile ##
#######################################################################
EDITOR=vi;export EDITOR ORACLE_BASE=/u01/app/oracle; export
ORACLE_BASE ORACLE_HOME=$ORACLE_BASE/product/8.1.7; export
ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/lib; export
LD_LIBRARY_PATH TNS_ADMIN=/var/opt/oracle;export
TNS_ADMIN NLS_LANG=american; export
NLS_LANG NLS_DATE_FORMAT=’Mon DD YYYY HH24:MI:SS’; export
NLS_DATE_FORMAT ORATAB=/var/opt/oracle/oratab;export
ORATAB PATH=$PATH:$ORACLE_HOME:$ORACLE_HOME/bin:/usr/ccs/bin:/bin:/usr/bin:/usr/sbin:/
sbin:/usr/openwin/bin:/opt/bin:.; export
PATH DBALIST=”primary.dba@company.com,another.dba@company.com”;export
DBALIST

The following script first calls oracle.profile to set up all the environment variables. The script also sends the DBA a warning e-mail if it finds any Oracle errors:

####################################################################
## ckalertlog.sh                                                  ##
####################################################################
#!/bin/ksh
. /etc/oracle.profile
for SID in `cat $ORACLE_HOME/sidlist`
do
cd $ORACLE_BASE/admin/$SID/bdump
if [ -f alert_${SID}.log ]
then
mv alert_${SID}.log alert_work.log
touch alert_${SID}.log
cat alert_work.log >> alert_${SID}.hist
grep ORA- alert_work.log > alert.err
fi
if [ `cat alert.err|wc -l` -gt 0 ]
then
mailx -s “${SID} ORACLE ALERT ERRORS” $DBALIST < alert.err
fi
rm -f alert.err
rm -f alert_work.log
done

Clean Up Old Archived Logs

The following script cleans up old archive logs if the log file system reaches 90-percent capacity:

$ df -k | grep arch
Filesystem                kbytes   used     avail    capacity  Mounted on
/dev/vx/dsk/proddg/archive 71123968 30210248 40594232   43%  /u08/archive

#######################################################################
## clean_arch.ksh                                                    ##
#######################################################################
#!/bin/ksh
df -k | grep arch > dfk.result
archive_filesystem=`awk  -F” “  ‘{ print $6 }’ dfk.result`
archive_capacity=`awk  -F” “  ‘{ print $5 }’ dfk.result`

if [[ $archive_capacity > 90% ] ]
then
echo “Filesystem ${archive_filesystem} is ${archive_capacity} filled”
# try one of the following option depend on your need
find $archive_filesystem -type f -mtime +2 -exec rm -r {} \;
tar
rman
fi

Analyze Tables and Indexes (for Better Performance)

Below, I have shown an example on how to pass parameters to a script:

####################################################################
## analyze_table.sh ##
####################################################################
#!/bin/ksh #
input parameter: 1: password # 2: SID if (($#<1)) then echo “Please enter
‘oracle’
user password as the first parameter !” exit 0 fi if (($#<2)) then echo
“Please enter
instance name as the second parameter!” exit 0 fi

To execute the script with parameters, type:

$ analyze_table.sh manager oradb1

The first part of script generates a file analyze.sql, which contains the syntax for analyzing table. The second part of script analyzes all the tables:

#####################################################################
## analyze_table.sh ##
#####################################################################
sqlplus -s <<!
oracle/$1@$2
set heading off
set feed off
set pagesize 200
set linesize 100
spool analyze_table.sql
select ‘ANALYZE TABLE ‘ || owner || ‘.’ || segment_name ||
‘ ESTIMATE STATISTICS SAMPLE 10 PERCENT;’
from dba_segments
where segment_type = ‘TABLE’
and owner not in (‘SYS’, ‘SYSTEM’);
spool off
exit
!
sqlplus -s <<!
oracle/$1@$2
@./analyze_table.sql
exit
!

Here is an example of analyze.sql:

$ cat analyze.sql
ANALYZE TABLE HIRWIN.JANUSAGE_SUMMARY ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE HIRWIN.JANUSER_PROFILE ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE APPSSYS.HIST_SYSTEM_ACTIVITY ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE HTOMEH.QUEST_IM_VERSION ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE JSTENZEL.HIST_SYS_ACT_0615 ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE JSTENZEL.HISTORY_SYSTEM_0614 ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE JSTENZEL.CALC_SUMMARY3 ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE IMON.QUEST_IM_LOCK_TREE ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE APPSSYS.HIST_USAGE_SUMMARY ESTIMATE STATISTICS SAMPLE 10 PERCENT;
ANALYZE TABLE PATROL.P$LOCKCONFLICTTX ESTIMATE STATISTICS SAMPLE 10 PERCENT;

Check Tablespace Usage

This scripts checks for tablespace usage. If tablespace is 10 percent free, it will send an alert e-mail.

#####################################################################
## ck_tbsp.sh ##
#####################################################################
#!/bin/ksh
sqlplus -s <<!
oracle/$1@$2
set feed off
set linesize 100
set pagesize 200
spool tablespace.alert
SELECT F.TABLESPACE_NAME,
TO_CHAR ((T.TOTAL_SPACE – F.FREE_SPACE),’999,999′) “USED (MB)”,
TO_CHAR (F.FREE_SPACE, ‘999,999′) “FREE (MB)”,
TO_CHAR (T.TOTAL_SPACE, ‘999,999′) “TOTAL (MB)”,
TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)),’999′)||’ %’ PER_FREE
FROM   (
SELECT       TABLESPACE_NAME,
ROUND (SUM (BLOCKS*(SELECT VALUE/1024
FROM V\$PARAMETER
WHERE NAME = ‘db_block_size’)/1024)
) FREE_SPACE
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME
) F,
(
SELECT TABLESPACE_NAME,
ROUND (SUM (BYTES/1048576)) TOTAL_SPACE
FROM DBA_DATA_FILES
GROUP BY TABLESPACE_NAME
) T
WHERE F.TABLESPACE_NAME = T.TABLESPACE_NAME
AND (ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)) < 10;
spool off
exit
!
if [ `cat tablespace.alert|wc -l` -gt 0 ]
then
cat tablespace.alert -l tablespace.alert > tablespace.tmp
mailx -s “TABLESPACE ALERT for ${2}” $DBALIST < tablespace.tmp
fi

An example of the alert mail output is as follows:

TABLESPACE_NAME     USED (MB)   FREE (MB)         TOTAL (MB)            PER_FREE
——————- ——— ———– ——————- ——————
SYSTEM              2,047             203               2,250                9 %
STBS01                302              25                327                 8 %
STBS02                241              11                252                 4 %
STBS03                233              19                252                 8 %

Find Out Invalid Database Objects

The following finds out invalid database objects:

#####################################################################
## invalid_object_alert.sh ##
#####################################################################
#!/bin/ksh
. /etc/oracle.profile
sqlplus -s <<!
oracle/$1@$2
set          feed off
set heading off
column object_name format a30
spool invalid_object.alert
SELECT  OWNER, OBJECT_NAME, OBJECT_TYPE, STATUS
FROM    DBA_OBJECTS
WHERE   STATUS = ‘INVALID’
ORDER BY OWNER, OBJECT_TYPE, OBJECT_NAME;
spool off
exit
!
if [ `cat invalid_object.alert|wc -l` -gt 0 ]
then
mailx -s “INVALID OBJECTS for ${2}” $DBALIST < invalid_object.alert
fi
$ cat invalid_object.alert

OWNER        OBJECT_NAME           OBJECT_TYPE          STATUS
———————————————————————-
HTOMEH       DBMS_SHARED_POOL            PACKAGE BODY          INVALID
HTOMEH       X_$KCBFWAIT                 VIEW                  INVALID
IMON         IW_MON                      PACKAGE               INVALID
IMON         IW_MON                      PACKAGE BODY          INVALID
IMON         IW_ARCHIVED_LOG             VIEW                  INVALID
IMON         IW_FILESTAT                 VIEW                  INVALID
IMON         IW_SQL_FULL_TEXT            VIEW                  INVALID
IMON         IW_SYSTEM_EVENT1            VIEW                  INVALID
IMON         IW_SYSTEM_EVENT_CAT         VIEW                  INVALID
LBAILEY      CHECK_TABLESPACE_USAGE      PROCEDURE             INVALID
PATROL       P$AUTO_EXTEND_TBSP          VIEW                  INVALID
SYS          DBMS_CRYPTO_TOOLKIT         PACKAGE               INVALID
SYS          DBMS_CRYPTO_TOOLKIT         PACKAGE BODY          INVALID
SYS          UPGRADE_SYSTEM_TYPES_TO_816 PROCEDURE             INVALID
SYS          AQ$_DEQUEUE_HISTORY_T       TYPE                  INVALID
SYS          HS_CLASS_CAPS               VIEW                  INVALID
SYS          HS_CLASS_DD                 VIEW                  INVALID

Monitor Users and Transactions (Dead Locks, et al)

This script sends out an alert e-mail if dead lock occurs:

###################################################################
## deadlock_alert.sh ##
###################################################################
#!/bin/ksh
. /etc/oracle.profile
sqlplus -s <<!
oracle/$1@$2
set feed off
set heading off
spool deadlock.alert
SELECT   SID, DECODE(BLOCK, 0, ‘NO’, ‘YES’ ) BLOCKER,
DECODE(REQUEST, 0, ‘NO’,'YES’ ) WAITER
FROM     V$LOCK
WHERE    REQUEST > 0 OR BLOCK > 0
ORDER BY block DESC;
spool off
exit
!
if [ `cat deadlock.alert|wc -l` -gt 0 ]
then
mailx -s “DEADLOCK ALERT for ${2}” $DBALIST < deadlock.alert
fi





How to Add Capacity in Existing Tablespace

7 08 2008

First of all, A tablespace is the logical storage unit in Oracle Database and may consist one or more datafiles. If you found your USR table capacity to be 99.7% (good Luck!) then you might want to increase the tablespace where the USR table resides. How do you do that?

ALTER DATABASE
DATAFILE '/directory/path/file_name.dbf'
MAXSIZE 500M ;

That command simply increased the existing tablespace that you have. But if you want to add another datafile to the tablespace in which your table resides you may issue this command:

ALTER TABLESPACE your_ts_name
ADD DATAFILE '/directory_path/file_name.dbf'
SIZE 200M
AUTOEXTEND ON
MAXSIZE 500M;

as simple as that….





How to remove Agent/targets from Grid Control neatly

6 08 2008

I was given the task to remove the target host/agents and other listed targets of Server1 from Oracle grid control. At first I thought it was very easy and I was definitely correct. Here’s what happened:

From OEM Grid Control I clicked on targets and selected the Server1 from the list. Then from its homepage I clicked on the the targets and then I eventually select all the targets except of course from the agent. Note: (the management agent of server1 must be running to do this). The targets were successfully deleted and now the only thing left is the host and the agent of Server1.

To remove the agent and host form the list, I stop the management agent of server1 then I went back to my OEM Grid control to remove the host Server1. Now there comes the challenge, No matter how many times I tried to delete the host Server1 from oem grid control It seems like the page is just running and nothing happens. No matter how long I’ve waited the host Server1 still remains on the list.

Now to clean it manually, I connect to the OEM Grid Repository and perform the following:

SQL> select target_name from mgmt_targets where target_type=’oracle_emd’;

This command show me the list of all the registered targets from my OEM and I can see that Server1 is still there. Then to manually remove Server1 from the list, I then execute:

SQL> exec mgmt_admin.cleanup_agent(‘Server1:3872′);

It will take a while at least 3 to 5 mins the most. Once it was completed  I quickly checked my OEM Grid Control Target List and voila!!! Server1 was successfully removed from the target list together with its agent.

Thanks to Metalink Note:454081.1 and to Luis Cardenas post (http://www.lazydba.com/oracle/0__146127.html)  who gave me the idea to solve my problem.




How to remove a deleted agent from the GRID Control repository database?

5 08 2008
Howto: How to remove a deleted agent from the GRID Control repository database?
Doc ID: Note:454081.1 Type: HOWTO
Last Revision Date: 24-OCT-2007 Status: PUBLISHED
In this Document
Goal
Solution
References


Applies to:

Enterprise Manager Grid Control – Version: 10.2.0.1 to 10.2.0.4
Information in this document applies to any platform.

Goal

The targets are removed from Grid Control UI.  However, it seems it was not completely removed.  The repository still has reference to the removed Agent. Agent was not totally removed from the repository.

How do you remove the deleted agent from the repository?

Solution

1. Please ensure that the agent is stopped.

2. Logon with sqlplus against the repository database as user sysman
and run following command:

exec mgmt_admin.cleanup_agent('<myserver>:<port>');

3. If this program are deleting anything end with submit

4. If the procedure find something to delete you can now start the agent again.

5. If this procedure doesn’t find anything for delete

5.1 Edit the agent agent side edit the $ORACLE_HOME/sysman/config/emd.properties
Change the port number in:
EMD_URL=https://server:port/emd/main/
to the next free port at this node

5.2 Save the emd.properties

5.3 Confirm that the Agent home $ORACLE_HOME/sysman/emd/targets.xml file has the new port number defined for the emd agent.

5.4 Start the agent.

The agent will be now added with the new port number.

It is strongly suggest always to use the procedure
exec mgmt_admin.cleanup_agent(‘<myserver>:<port>’);
to remove entire host targets from the Grid Control.
This avoid that anything not deleted correctly




How to Point an Agent to a different Grid Control OMS and Repository?

1 08 2008
Subject: How to Point an Agent to a different Grid Control OMS and Repository?
Doc ID: Note:413228.1 Type: HOWTO
Last Revision Date: 25-FEB-2008 Status: PUBLISHED
In this Document
Goal
Solution


Applies to:

Enterprise Manager Grid Control – Version: 10.2.0.0
Information in this document applies to any platform.

Goal

This Note intends to explain how to point an Oracle Management Agent to a different Grid Control OMS and Repository?

NOTE: These steps are NOT necessary if you are simply pointing the Oracle Management Agent to a new OMS that points to the SAME repository.  If simply moving from one OMS to another within the same Grid infrastructure, follow the instructions in the Documentation, Oracle® Enterprise Manager Advanced Configuration, Chapter 12 Reconfiguring the Management Agent and Management Service, 12.1.1 Configuring the Management Agent to Use a New Management Service

Solution

A. Drop the Agent from the current OMS

Note: this assumes that the Agent is still pointing to the old OMS. You will first drop the Agent from the old OMS, then add it to the new OMS. This can be ignored if the OMS doesn’t exist anymore.

1. Leave the monitoring agent up and running in order to delete all the targets, except the host and the agent itself).

2. From the old OMS, drop all the Targets on the host to be removed, except the Host and Agent.

Do not remove Host yet, but to confirm all targets are gone, choose Targets > Hosts, highlight the host in the list and hit “Remove” button. Grid will not allow the Host to be dropped until all targets on the Host are gone, so this will list any remaining targets. Again: Do not remove Host yet.

All targets except the Host and Agent should now be gone from the OMS.

3. Confirm the targets (except Host and Agent) are removed successfully and completely from the OMS:

Click on “Setup” in upper right.
Click on the “EM 10g Grid Control Management System” tab

You will see this information on the page:

–> Management Services and Repository
–> Overview page
–> General section
–> Deleted Targets: < click on the digit listed here >

3a. Click on “Deleted Targets” (Note this only appears once a delete is attempted.)

3b. Confirm that the “Time Delete Completed” column is filled in; once that column is filled in then the delete is complete.

4. Stop the monitoring Agent

5. Drop the Host target from the old OMS.
Targets > Hosts, highlight the host in the list and hit “Remove” button.

Monitor for the “Time Delete Completed” column.
Proceed once the column is updated.

6. Drop the Agent target from the old OMS.

Targets > All Targets > [pick Agent from list] > “Remove” button.

Monitor for the “Time Delete Completed” column.
Proceed once the column is updated.

–> At this point the removal from the old OMS is completed.

B. Point the Agent at the new OMS

7. Follow the steps to reconfigure the Agent to point to the new OMS.

Here is the Documentation reference, which does explain several steps in a clear manner and will help clarify the process needed.

Oracle® Enterprise Manager Advanced Configuration, Chapter 12 Reconfiguring the Management Agent and Management Service, 12.1.1 Configuring the Management Agent to Use a New Management Service

Quick Summary of steps to point Agent at new OMS

To associate the Management Agent with a new Management Service after you have installed the Management Agent:

#1 Stop the agent

#2 Edit the Agent’s $ORACLE_HOME/sysman/config/emd.properties file

#3 Search for REPOSITORY_URL
Change this to point to the non-secure Grid Control hostname and port
*also change HTTPS://….. to HTTP (non-secure.)

#4 Search for EMD_URL
This is your Agent’s address – if it has HTTPS, change it to HTTP

#5 Modify the value for the emdWalletSrcUrl and emdWalletDest properties. The emdWalletSrcUrl references the new Management Service. The emdWalletDest is the location where the agent saves the wallet received from the OMS, in its own file system. This is normally a directory on the agent node.

For example, if the new Management Service is on a host called mgmthost2.acme.com, modify the properties as follows:
emdWalletSrcUrl=http://mgmthost2.acme.com:4889/em/wallets/emd
emdWalletDest=<AGENT_HOME>/sysman/config/server

#6 Save and exit emd.properties.

Disclaimer: Clean starting the agent is only to be performed in this specific scenario and should only be used for all other issues under guidance from Oracle Support as this can damage the functionality of Grid Control and may require a re-installation.

#7 Clean up Agent: from the Agent $ORACLE_HOME

rm -r $ORACLE_HOME/sysman/emd/state/*
rm -r $ORACLE_HOME/sysman/emd/collection/*
rm -r $ORACLE_HOME/sysman/emd/upload/*
rm $ORACLE_HOME/sysman/emd/lastupld.xml
rm $ORACLE_HOME/sysman/emd/agntstmp.txt
rm $ORACLE_HOME/sysman/emd/blackouts.xml
rm $ORACLE_HOME/sysman/emd/protocol.ini

#8 Issue an agent clearstate from the Agent $ORACLE_HOME
$ORACLE_HOME/bin/emctl clearstate agent

#9 Secure the agent
$ORACLE_HOME/bin/emctl secure agent
*if this fails, double-check OMS information and start from step #2 again

#10 Start the agent
$ORACLE_HOME/bin/emctl start agent
*wait about 30 seconds before going to step 11 – give agent time to “wake up”

#11 Force an upload to the OMS
$ORACLE_HOME/bin/emctl upload agent

After 10-15 minutes the Agent and Host should show up in the new OMS.





WHY ARE MY JOBS NOT RUNNING

1 08 2008

ANSWERS TO “WHY ARE MY JOBS NOT RUNNING ?”

Thanks to : http://forums.oracle.com/forums/thread.jspa?threadID=646581&tstart=0

This is one of the most common Scheduler questions asked.
Here we list some of the common problems and their solutions.

1) job_queue_processes may be too low (this is the most common problem)
The value of job_queue_processes limits the total number of dbms_scheduler
and dbms_job jobs that can be running at a given time.
To check whether this is the case check the current value of
job_queue_processes with
SQL> select value from v$parameter where name=’job_queue_processes’;
Then check the number of running jobs
SQL> select count(*) from dba_scheduler_running_jobs;
SQL> select count(*) from dba_jobs_running;

If this is the problem you can increase the parameter using
SQL> alter system set job_queue_processes=1000;

2) max_job_slave_processes may be too low
If this parameter is not NULL then it limits how many dbms_scheduler jobs can
be running at a time. To check whether this is the problem, check the current
value using
SQL> select value from dba_scheduler_global_attribute
where attribute_name=’MAX_JOB_SLAVE_PROCESSES’;
Then check the number of running jobs
SQL> select count(*) from dba_scheduler_running_jobs;

If this is the problem you can increase the number or just NULL it out using
SQL> exec dbms_scheduler.set_scheduler_attribute(‘max_job_slave_processes’,null)

3) sessions may be too low
This parameter limits the number of sessions at any time. Every Scheduler job
requires 2 sessions. To check whether this is the problem, check the current
valule using
SQL> select value from v$parameter where name=’sessions’;
Then check the current number of sessions using
SQL> select count(*) from v$session ;

If the numbers are too close you can increase the maximum using
SQL> alter system set job_queue_processes=200;

4) Have you recently applied a timezone update patch or upgraded the database
to a version with newer timezone information ? If you skipped any steps when
updating the timezone information, jobs may not run. To check whether this
is the case try doing
SQL> select * from sys.scheduler$_job;
and make sure it finishes without errors.

If it throws a timezone warning, reapply the upgrade or
timezone patch making sure to follow all the steps.

5) Is the database running in restricted mode ?
If the database is running in restricted mode then no jobs will run (unless
you are using 11g and use the ALLOW_RUNS_IN_RESTRICTED_MODE attribute).
To check this use
SQL> select logins from v$instance ;

If logins is restricted you can disable the restricted mode using
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

6) Has the Scheduler been disabled ? This is not a supported action
but it is possible that someone has done it anyway. To check this do
SQL> select value from dba_scheduler_global_attribute where attribute_name=’SCHEDULER_DISABLED’

If this query returns TRUE then you can fix this using
SQL> exec dbms_scheduler.set_scheduler_attribute(’scheduler_disabled’,'false’);

Reasons why jobs may run late

1) The first thing to check is the timezone that the job is scheduled with
SQL> select owner, job_name, next_run_date from dba_scheduler_jobs ;

If the jobs are in the wrong timezone they may not run at the expected
time. If the next_run_date is using an absolute timezone offset (like
+08:00) instead of a named timezone (like US/PACIFIC) then the jobs may not
run as expected if daylight savings is in effect – they may run an hour
early or late.

2) It may be that at the time the job was scheduled to run, one of the several
limits above may have been temporarily reached causing the job to be delayed.
Check if the limits above are high enough and if possible check them during
the time that the job is being delayed.

3) One possible reason that one of the above limits may be hit is that a
maintenance window may have come into effect. Maintenance windows are Oracle
Scheduler windows that belong to the window group named
MAINTENANCE_WINDOW_GROUP. During a scheduled maintenance window, several
maintenance tasks are run using jobs. This may cause one of the limits listed
above to be hit and user jobs to be delayed. See the admin guide for more info
about this (chapter 24).

To get a list of maintenance windows use
SQL> select * from dba_scheduler_wingroup_members;

To see when the windows run use
SQL> select * from dba_scheduler_windows;

To fix this you can either increase the limits or reschedule the maintenance
windows to run at more convenient times.

Diagnosing other Problems

If none of this works, here are some further steps you can take to try to
figure out what is going on.

1) Check whether there are any errors in the alert log. If the database is
having trouble allocating memory or has run out of disk space or any other
catastrophic errors have occurred, you should resolve those first. You can
find the location of the alert log by using
SQL> select value from v$parameter where name = ‘background_dump_dest’;
The alert log will be in this directory with a name starting with “alert”.

2) Check whether if a job coordinator trace file and if it does, check if it
contains any errors. If this exists, it will be located in the
‘background_dump_dest’ directory which you can find as above and will look
something like SID-cjq0_nnnn.trc . If there are any errors here they may
hint at why jobs are not running.

3) If either of the above indicates that the SYSAUX tablespace (where the scheduler stores its logging tables) is full, you can use the dbms_scheduler.purge_log procedure to clear out old log entries.

4)try running a simple run-once job and see if it runs
SQL>begin
dbms_scheduler.create_job (
job_name => ‘test_job’,
job_type => ‘plsql_block’,
job_action => ‘null;’,
enabled => true);
end;
/
SQL> — wait a while
SQL> select * from user_scheduler_job_run_details where job_name=’TEST_JOB’;





HOW TO CHECK GROWTH OF THE DATABASE

1 08 2008

Thanks to: http://ayyudba.blogspot.com/2007/09/how-to-check-growth-of-database.html

Step : 1 Calculate total Size of tablespace
select sum(bytes)/1024/1024 “TOTAL SIZE (MB)” from dba_Data_files
Step : 2 Calculate Free Space in Tablespace
select sum(bytes)/1024/1024 “FREE SPACE (MB)” from dba_free_space
Step : 3 Calculate total size , free space and used space in tablespace
select t2.total “TOTAL SIZE”,t1.free “FREE SPACE”,(t1.free/t2.total)*100 “FREE (%)” ,(1-t1.free/t2.total)*100 “USED (%)”
from (select sum(bytes)/1024/1024 free from dba_free_space) t1 , (select sum(bytes)/1024/1024 total from dba_Data_files) t2
Step : 4 Create table which is store all free/use space related information of tablespace
create table db_growth
as select *
from (
select sysdate,t2.total “TOTAL_SIZE”,t1.free “FREE_SPACE”,(t1.free/t2.total)*100 “FREE% “
from
(select sum(bytes)/1024/1024 free
from dba_free_space) t1 ,
(select sum(bytes)/1024/1024 total
from dba_Data_files) t2
)
Step : 5 Insert free space information in DB_GROWTH table (if you want to populate data Manually)
insert into db_growth
select *
from (
select sysdate,t2.total “TOTAL_SIZE”,t1.free “FREE_SPACE”,(t1.free/t2.total)*100 “FREE%”
from
(select sum(bytes)/1024/1024 free
from dba_free_space) t1 ,
(select sum(bytes)/1024/1024 total
from dba_Data_files) t2
)
Step : 6 Create View on DB_GROWTH based table ( This Steps is Required if you want to populate data automatically)
create view v_db_growth
as select *
from
(
select sysdate,t2.total “TOTAL_SIZE”,t1.free “FREE_SPACE”,(t1.free/t2.total)*100 “FREE%”
from
(select sum(bytes)/1024/1024 free
from dba_free_space) t1 ,
(select sum(bytes)/1024/1024 total
from dba_Data_files) t2
)

Step : 7 Insert data into DB_GROWTH table from V_DD_GROWTH view
insert into db_growth select *
from v_db_growth
Step : 8 Check everything goes fine.
select * from db_growth;
Check Result
Step : 9 Execute following SQL for more time stamp information
alter session set nls_date_format =’dd-mon-yyyy hh24:mi:ss’ ;
Session altered.
Step : 10 Create a DBMS jobs which execute after 24 hours
declare
jobno number;
begin
dbms_job.submit(
jobno, ‘begin insert into db_growth select * from v_db_growth;commit;end;’, sysdate, ‘SYSDATE+ 24′, TRUE);
commit;
end;

PL/SQL procedure successfully completed.
Step: 11 View your dbms jobs and it’s other information
select * from user_jobs;
TIPS: If you want to execute dbms jobs manually execute following command other wise jobs is executing automatically
exec dbms_job.run(ENTER_JOB_NUMBER)
PL/SQL procedure successfully completed.
Step: 13 Finally all data populated in db_growth table
select * from db_growth