Problem: AgentCA: Install Fails with OUI-25031 error during Grid Control 10.2.0.1 installation

Subject: Problem: AgentCA: Install Fails with OUI-25031 error during Grid Control 10.2.0.1 installation on SuSE SLES9
Doc ID: Note:405308.1 Type: PROBLEM
Last Revision Date: 27-MAR-2007 Status: PUBLISHED

In this Document
Symptoms
Cause
Solution
References



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



Applies to:
Enterprise Manager Grid Control - Version: 10.2.0.1
Linux x86

Symptoms
Installing Enterprise Manager Grid Control 10.2.0.1 on SuSE SLES9, with 'Using a New Database' or 'Using an Existing Database' option.

Near the end of the installation, Agent Configuration Assistant fails with OUI-25031 error:
Configuration assistant "Agent Configuration Assistant" failed
-----------------------------------------------------------------------------
The "/oracle/app/oracle/product/10.2/agent10g/cfgtoollogs/configToolFailedCommands" script contains all commands that failed , were skipped or were cancelled.
This file may be used to run these configuration assistants outside of OUI. Note that you may have to update this script with passwords (if any) before executing the same.
-----------------------------------------------------------------------------
Command = oracle.sysman.emcp.agent.AgentPlugIn has failed

The following error messages can be found in $AGENT_HOME/cfgtoollogs/oui/installActionsTimestamp.log:
Command = oracle.sysman.emcp.agent.AgentPlugIn has failed
Exception : java.lang.Exception:
The Management Agent Configuration Assistant has failed. The following failures were recorded:
configureAgent:discovery on non RAC: Host discovery failed.
Oracle Database discovery failed.



The following solutions have been tested, but none of them work:
1. No symbolic link directories have been created for grid control installation destination.
2. No environment parameters contain a semicolon or space in the value.
3. No IPv6 entries in /etc/hosts file.
4. Set environment variable OPATCH_NO_FUSER to FALSE.

Cause
OPatch needs to use 'fuser' command when applying some interim patches during Agent configuration, but 'fuser' cannot be found in $PATH environment variable.
Solution
1. Clean up the failed installation.



2. Find OS 'fuser' command, and normally it is in '/bin' directory. Add this directory to PATH environment variable for oracle user. For example: export PATH=$PATH:/bin

AND

Set environment variable OPATCH_NO_FUSER=TRUE for oracle user.



3. Reinstall Enterprise Manager Grid Control 10.2.0.1.

References
Bug 5136795 - INSTALLING 10.2 AGENT OUI-25031 AGENT CONFIGURATION FAILED
Note 352357.1 - Problem: AgentCA: 10.2 Gc Install Failed Near End (Agentplugin)
Note 352507.1 - Problem: AgentCA: Installing 10.2.0.1 Grid fails on AgentPlugIn with Oui-25031
Note 380507.1 - Problem: AgentCA: OUI-25031: Environment Settings Preventing AgentCA to Complete Successfully

Errors
OUI-25031

Keywords
'GRID~CONTROL' 'INSTALLATION~PROBLEM' 'INSTALLATION~FAILS' 'ENTERPRISE~MANAGER'

How to Move from ANALYZE to DBMS_STATS - Introduction

DBMS_STATSを使うことにより、EMPTY_BLOCKSを0にすることも可能です。

DBMS_STATSはDBA_TABLESの中のEMPTY_BLOCKS列を0にすることができるにもかかわらず，
MetaLinkの中にて記述された内容によりますと，正確にEMPTY_BLOCKSの統計情報を収集
する方法はANALYZE文との一つしかありません。

次に引用されているのはMetaLink(Note#237293.1)の一部です：
---------------------------------------------------------------------------------
If statistics unrelated to the cost based optimizer are required, then these
must still be collected using the the ANALYZE command. These statistics include:

- Space Usage information :

. EMPTY_BLOCKS,
. AVG_SPACE,
. CHAIN_CNT
---------------------------------------------------------------------------------

附：Note#237293.1


Subject: How to Move from ANALYZE to DBMS_STATS - Introduction
Doc ID: Note:237293.1 Type: FAQ
Last Revision Date: 16-FEB-2007 Status: PUBLISHED


PURPOSE
=======

This note is an introduction to a set of notes which helps DBA through examples
to move gathering statistics from ANALYZE or DBMS_UTILITY to DBMS_STATS.

SCOPE & APPLICATION
===================

This set of Notes is aimed at anyone wishing to gather statistics for use by the Cost Based Optimizer (CBO).


How to Move From ANALYZE/DBMS_UTILITY.ANALYZE_* to DBMS_STATS
=============================================================

Cost-Based optimization relies on accurate statistics to determine the relative
cost of execution plans. In Oracle 7, there was two methods to gather statistics:

o ANALYZE
o DBMS_UTILITY

Since the Oracle Version 8.1.5, a single package has been provided to gather
statistics:

o DBMS_STATS package

It is strongly recommended to use the DBMS_STATS package and all the different
functions that are defined by it to handle the collect of statistics.
Using DBMS_STATS is the only way to access the new sampling functionality
provided in later releases since ANALYZE is not being enhanced.

- Note 236935.1 Global statistics - DBMS_STATS versus ANALYZE
- estimate_percent => dbms_stats.auto_sample_size
- method_opt => 'FOR ALL COLUMNS SIZE AUTO', -
- degree => DBMS_STATS.DEFAULT_DEGREE, -
- options => 'GATHER AUTO', -


For an overview of sampling recommendations see:

Note 114671.1 Gathering Statistics for the Cost Based Optimizer

For specific package related detail, consult the Oracle9i Supplied PL/SQL
Packages and Types Reference documentation



Moving from Legacy sampling (ANALYZE and DBMS_UTILITY) to DBMS_STATS
--------------------------------------------------------------------

Examples of various sampling scenarios are provided in the following aricles:

Note 237537.1 How to Move from ANALYZE to DBMS_STATS on Non-Partitioned Tables - Some Examples
Note 237538.1 How to Move from ANALYZE to DBMS_STATS on Partitioned Tables - Some Examples
Note 237539.1 How to Move from ANALYZE to DBMS_STATS on Composite-Partitioned Tables - Some Examples
Note 237397.1 How to Move from ANALYZE (using DBMS_UTILITY) to DBMS_STATS:

Difference in statistics collection between ANALYZE and DBMS_STATS ?
--------------------------------------------------------------------

The DBMS_STATS package only gathers statistics for use by the CBO wheras the
legacy ANALYZE command gathered statistics for other purposes. The following
statistics are gathered:

- Table statistics -
****************

. Number of rows : NUM_ROWS
. Number of blocks : BLOCKS
. The Average row length : AVG_ROW_LEN
. Sample size : SAMPLE_SIZE
. Last analyzed : LAST_ANALYZED
. Global statistics : GLOBAL_STATS
. User statistics : USER_STATS

. These are visible in the following Dictionary Views :

- DBA_TABLES, DBA_TAB_PARTITIONS, DBA_TAB_SUBPARTITIONS


- Column statistics -
*****************

. Number of distinct values (NDV) in column : NUM_DISTINCT
. Number of null values in column : NUM_NULLS
. Average column length : AVG_COL_LEN
. Number of Buckets : NUM_BUCKETS
. Low Value : LOW_VALUE
. High Value : HIGH_VALUE
. Sample size : SAMPLE_SIZE
. Last analyzed : LAST_ANALYZED
. Global statistics : GLOBAL_STATS
. User statistics : USER_STATS
. Data distribution : See note below


. Standard Column statistics are visible in the following Dictionary Views :

- DBA_TAB_COL_STATISTICS, DBA_PART_COL_STATISTICS, DBA_SUBPART_COL_STATISTICS

. Column Data distribution statistics are stored separately in the DBA_*_HISTOGRAMS views:

- DBA_HISTOGRAMS, DBA_PART_HISTOGRAMS, DBA_SUBPART_HISTOGRAMS


- Index statistics -
****************

. Number of leaf blocks : LEAF_BLOCKS
. Number of Levels : BLEVEL
. Clustering factor : CLUSTERING_FACTOR
. Number of Distinct Keys : DISTINCT_KEYS
. The Average Leaf Index Blocks per Key : AVG_LEAF_BLOCKS_PER_KEY
. The Average Data Blocks per Key : AVG_DATA_BLOCKS_PER_KEY
. Sample size : SAMPLE_SIZE
. Last analyzed : LAST_ANALYZED
. Global statistics : GLOBAL_STATS
. User statistics : USER_STATS

. These are visible in the following Dictionary Views :

- DBA_INDEXES, DBA_IND_PARTITIONS, DBA_IND_SUBPARTITIONS

If statistics unrelated to the cost based optimizer are required, then these
must still be collected using the the ANALYZE command. These statistics include:

- Space Usage information :

. EMPTY_BLOCKS,
. AVG_SPACE,
. CHAIN_CNT

- Information on freelist blocks

. AVG_SPACE_FREELIST_BLOCKS,
. NUM_FREELIST_BLOCKS


RELATED DOCUMENTS
=================

Note 236935.1 Global statistics - DBMS_STATS versus ANALYZE
Note 237537.1 How to Move from ANALYZE to DBMS_STATS on Non-Partitioned Tables - Some Examples
Note 237538.1 How to Move from ANALYZE to DBMS_STATS on Partitioned Tables - Some Examples
Note 237539.1 How to Move from ANALYZE to DBMS_STATS on Sub-Partitioned Tables - Some Examples
Note 237397.1 How to Move from ANALYZE (using DBMS_UTILITY) to DBMS_STATS

Note 31412.1 SCRIPT - Select to show Optimizer Statistics for CBO

Note 210673.1 Different Values For EMPTY_BLOCKS and AVG_SPACE Using DBMS_STATS and ANALYZE
Bug 1874139 STATISTICS (EMPTY_BLOCKS & AVG_SPACE) ARE DIFFERENT AFTER EXPORT/IMPORT:
Bug 1759544 DBMS_STATS PACKAGE REPORTS '0' FOR EMPTY_BLOCKS:
Bug 2932639 WRONG TABLE STATISTICS CALCULATED IN AUTO SEGMENT SPACE MANAGED TABLESPACE:

Note 35272.1 Is ANALYZE on the Data Dictionary Supported (TABLES OWNED BY SYS)?
Note 245051.1 Gathering Data Dictionary Statistics

Bug 2222368 DBMS_UTILITY.ANALYZE_DATABASE ALSO ANALYZES SYS
Bug 1422285 DBMS_STATS.GATHER_DATABASE_STATISTICS COLLECTS STATISTICS FOR SYS OBJECTS
Bug 2453682 DBMS_STATS.GATHER_SCHEMA_STATS DOES NOT GATHER STATISTICS FOR OBJECT TABLES

Discoverer中Choose connection模式，connection信息在哪里保存

Discoverer中Choose connection模式，connection信息在哪里保存
<質問内容>
ディスカバラーの接続で、接続選択と直接接続があるが、
接続選択の場合だと１度ユーザID等を登録すると、
次に接続する時にはその登録した情報が使用できる。
この登録した情報はどこに保持しているのか教えてほしい。
(クライアントなのかアプリケーションサーバなのか)


<回答内容>
接続選択の場合，根据是否使用Single Sign-On分为两种情况。
Single Sign-On が有効になっていない場合、接続信息在Cookie中保存（クライアント）。
Single Sign-On 有効的場合，接続信息在Single Sign-On database中保存（サーバ）。

详细信息请参考：
------------------------------------------------------
Oracle® Business Intelligence Discoverer
構成ガイド
10g リリース2（10.1.2.0.0）
部品番号: B15635-01
4-3 プライベート接続

Oracle® Application Server Single Sign-On
管理者ガイド
10g リリース2（10.1.2）
部品番号: B15823-01
1-2 外部アプリケーション
------------------------------------------------------

audit, fga, vpd and sys

audit, fga, vpd and sys

sys永远免疫vpd
The database user SYS is thus always exempt from VPD or Oracle Label Security enforcement, regardless of the export mode, application, or utility used to extract data from the database.

sys免疫普通的audit
AUDIT_SYS_OPERATIONS enables or disables the auditing of operations issued by user SYS, and users connecting with SYSDBA or SYSOPER privileges. The audit records are written to the operating system's audit trail.

sys免疫fga，这里有个bug需要注意
Subject: Bug 3450991 - FGA does not work if SQL is run by the SYS user
Doc ID: Note:3450991.8 Type: PATCH
Last Revision Date: 10-AUG-2005 Status: PUBLISHED
Click here for details of sections in this note.

Bug 3450991 FGA does not work if SQL is run by the SYS user
This note gives a brief overview of bug 3450991.

Affects:
Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions < 10.2
Versions confirmed as being affected 9.2.0.4
10.1.0.3

Platforms affected Generic (all / most platforms affected)

Fixed:
This issue is fixed in 9.2.0.7 (Server Patch Set)
10.1.0.4 (Server Patch Set)
10.2.0.1 (Base Release)


Symptoms: Related To:
(None Specified)
Security ( Authentication / Privileges / Auditing )


Description
Once a SELECT statement has been run by SYS then other users sharing
that cursor do not get audited if there is an FGA policy on the table.

Workaround:
Do not run SQL from SYS user for FGA objects.

How to add swap space to rhel 3

How to add swap space to rhel 3

这只是几种可选方法中的一种。

1.使用fdisk创建新的分区(例如创建sdb1)
2.mkswap /dev/sdb1
3.在/etc/fstab文件中加入"/dev/sdb1 swap swap defaults 0 0"这一行
4.swapon -va
5.使用cat /proc/swaps或者cat /proc/meminfogrep Swap或者free令名确认

=================================================
附：How to remove swap space to rhel3

这种方法只是针对上面的增加swap的方法

1.swapoff -v /dev/sdb1
2.如果想要永久的删除swap空间，去掉/etc/fstab文件中相应的行。
3.使用cat /proc/swaps或者cat /proc/meminfogrep Swap或者free令名确认

STATISTIC "cache hit ratio" - Reference Note

Subject: STATISTIC "cache hit ratio" - Reference Note
Doc ID: Note:33883.1 Type: REFERENCE
Last Revision Date: 12-FEB-2004 Status: PUBLISHED


*** See Note 130955.1 for a description of the "STATISTIC" reference articles

Definition:
~~~~~~~~~~~
The "cache hit ratio" is a derived statistic referred to in a number of
manuals and articles. There is more than one definition of the cache hit
ratio in existence.
The hit ratio is intended to give an indication of how often the various
processes accessing the data buffers find the blocks in the Oracle buffer
cache. The exact value of the hit ratio is of less importance than the
ability to monitor it over time to notice any significant changes in the
profile of activity on the database.

*** Important: A very high hit ratio (close to 100%) is not necessarily good
The reasons for this are explained later.


Calculation:
~~~~~~~~~~~~
The most common formula in circulation for the hit ratio for the buffer cache
for Oracle7/8 is:

hit ratio = 1 - ( physical reads )
-----------------------------------
( consistent gets + db block gets )

This is often expressed as a percentage (by multiplying the result by 100).
However, in 7.3.4 and Oracle8 onwards the definition of the "physical reads"
statistic changed to include direct block reads as well as reads to get data
into the buffer cache. Hence the above formula only gives an lower bound for
the hit ratio on these releases.


A better formula in Oracle8i/9i is:

hit ratio =

1 - ( physical reads - (physical reads direct + physical reads direct (lob)) )
--------------------------------------------------------------------------
( db block gets + consistent gets - (physical reads direct + physical reads direct (lob)) )


In Oracle8.0 onwards it is possible to use multiple buffer pools (by setting
the BUFFER_POOL_KEEP or BUFFER_POOL_RECYCLE init.ora parameters). Multiple
buffer pools are not discussed here but the hit ratios for each pool can be
seen using the V$BUFFER_POOL_STATISTICS view (which is created by the
CATPERF.SQL script in Oracle8 and is a standard view in Oracle8i onwards)
thus:

SELECT name, 1-(physical_reads / (consistent_gets + db_block_gets ) ) "HIT_RATIO"
FROM V$BUFFER_POOL_STATISTICS
WHERE ( consistent_gets + db_block_gets ) !=0
;

(Note that this view shows 0 for CONSISTENT_GETS and DB_BLOCK_GETS in 8.1.7 and so
the above select is useless in this release - See Bug 1491213 )


The "Miss Ratio"
~~~~~~~~~~~~~~~~
Occasionally you may see reference to the "miss ratio". This is just

Miss ratio = 100% - Hit Ratio (expressed as a percentage)



Notes about the Hit Ratio
~~~~~~~~~~~~~~~~~~~~~~~~~
A good hit ratio is expected for OLTP type systems but decision support type
systems may have much lower hit ratios. Use of parallel query will make the
hit ratio less meaningful if using the first form of calculation based on
"physical reads" only.

A hit ratio close to 100% does not mean the application is good. It is quite
possible to get an excellent hit ratio by using a very unselective index in a
heavily used SQL statement.
Eg: Consider a statement like:

SELECT * FROM employee WHERE empid=1023 AND gender='MALE';

If EMPLOYEE is a large table and this statement always uses the GENDER index
rather than the EMPID index then you scan LOTS of blocks (from the GENDER
index) and find nearly all of them in the cache as everyone is scanning this
same index over and over again. The hit ratio is very HIGH but performance
is very BAD. A common 'variation' on an "unselective" index is a heavily
skewed index where there are a large number of entries with one particular
value (eg: a workflow status code of CLOSED) - the index may perform well for
some queries and very poorly for the most common value.


A few comments:
~~~~~~~~~~~~~~~
- The "good" hit ratio is generally considered to be one >80%
There is probably still scope for tuning if it is <90% *BUT*
note that the hit ratio is not the best measure of performance.

- The ratio can be artificially high in applications making
poor use of an UNSELECTIVE index.

- In Oracle8.1 onwards "physical reads direct" are recorded

- Some documentation incorrectly reports hit ratio to be:

Hit Ratio = Logical Reads / ( Logical Reads + Physical Reads )

this is incorrect for any version of Oracle.


Related:
~~~~~~~~
Bug to change "physical reads" to include direct reads in Bug 404802
Documented Hit Ratio is incorrect Bug 2002504
7.3.4/8.0 onwards
reference note Note 47420.1

Differences between sysdba and sysoper

概要 SYSDBA, SYSOPER 権限について
内容:
[Problem]
connect / as sysdba (sysoper) で SYSDBA や SYSOPER としてアクセスできますが、
SYSOPER 権限と SYSDBA 権限は、どう違うのですか？
SYSOPER権限にはどういった制限があるのでしょうか。


[To reproduce]
SYSOPERは、以下のような作業を行なうことを許されています：
startup
shutdown
alter database open | mount
alter database backup controlfile
recover database
alter database archivelog
restricted session
SYSDBAは、これに加えて、以下の権限を持ちます：
sysoper 権限 with admin option
create database
recover database until

SYSOPERは startup/shutdown 等の基本的な管理業務を行なえますが、
ユーザのデータを見る権限を持ちません。これに対して、SYSDBAは
無制限の権限が与えられます。

connect / as sysdba で接続するとSYSスキーマに、
connect / as sysoper で接続すると、PUBLICスキーマに接続されます。

[更新履歴]
2007/01/22 SYSOPER権限で「alter tablespace begin/end backup」は実行できないため削除