10.2.0.1 db console启动失败问题一例

帮网友诊断10.2.0.1数据库安装后配置EM的问题一例,主要是在EM启动过程中遇到了错误,日志如下:

2009-7-7 20:11:39 oracle.sysman.emcp.EMConfig perform
严重: 启动 Database Control 时出错
有关详细资料, 请参阅 oracle\product.2.0\db_1\cfgtoollogs\dbca\orcl\emConfig.log 中的日志文件。
2009-7-7 20:11:39 oracle.sysman.emcp.EMConfig perform
配置: Stack Trace:
oracle.sysman.emcp.exception.EMConfigException: 启动 Database Control 时出错
	at oracle.sysman.emcp.EMDBPostConfig.performConfiguration(EMDBPostConfig.java:569)
	at oracle.sysman.emcp.EMDBPostConfig.invoke(EMDBPostConfig.java:181)
	at oracle.sysman.emcp.EMDBPostConfig.invoke(EMDBPostConfig.java:150)
	at oracle.sysman.emcp.EMConfig.perform(EMConfig.java:155)
	at oracle.sysman.assistants.util.em.EMConfiguration.run(EMConfiguration.java:430)
	at java.lang.Thread.run(Thread.java:534)

出现错误的java stack call是EMDBPostConfig说明em db repository 已经完成配置在尝试启动EM,但此时出现了问题。

实际造成该问题的有多种可能性,这里列举最常见的几种:

1. 杀毒软件或者防火墙造成的,这里建议在安装windows期间彻底关闭杀毒类软件和Windows自带的防火墙
2. EM使用的端口已经被其他软件所占用,建议使用netstat命令诊断,或另择网络端口
3. Windows主机名以”U”字母开头

针对第三种可能性,可以在MOS上找到Note <Problem: Startup: Db Control 10.2.0.1 Fails To Start when the hostname begins with the letter “u”>:

Problem: Startup: Db Control 10.2.0.1 Fails To Start when the hostname begins with the letter "u" 

Applies to:
Enterprise Manager for RDBMS - Version: 10.2.0.1 and later   [Release: 10.2 and later ]

Symptoms

The dbconsole 10.2.0.1 is created with emca.The repository creation completes successfully and the
dbconsole is created and configured without any error.
The last phase of emca is to start the dbconsole.
The standalone agent is started successfully but the dbconsole fails to start.

The file $ORACLE_HOME/cfgtoollogs/emca/sid/emca*.log shows:
===================================================
05/11/2005 23:07:49 oracle.sysman.emcp.util.PlatformInterface serviceCommand
CONFIG: Waiting for service 'OracleDBConsoleAMITAL' to fully start
05/11/2005 23:07:59 oracle.sysman.emcp.EMConfig perform
SEVERE: Error starting Database Control
Refer to the log file at
d:\oracle\product.2.0\db_1\cfgtoollogs\emca\amital\emca_2005-11-05_10-55-42-PM.log for more
details.
05/11/2005 23:07:59 oracle.sysman.emcp.EMConfig perform
CONFIG: Stack Trace:
oracle.sysman.emcp.exception.EMConfigException: Error starting Database Control
  at oracle.sysman.emcp.EMDBPostConfig.performConfiguration(EMDBPostConfig.java:569)
  at oracle.sysman.emcp.EMDBPostConfig.invoke(EMDBPostConfig.java:181)
Cause
This issue can be reproduced on all windows platforms which name begins with the letter u.
This issue has been logged in the following bug:
Bug:4714774 DBCONSOLE DOES NOT WORK HAVING A HOSTNAME STARTING WITH "U"
This bug will be fixed in the patchset 10.2.0.2
Solution

Download and apply the RDBMS patchset 10.2.0.2 once/if available or

To enable the dbconsole to start successfully, follow the steps listed below:

1. Save the file $ORACLE_HOME\host_SID\sysman\config\emd.properties to emd.properties.orig
2. Update the file $ORACLE_HOME\host_SID\sysman\config\emd.properties, replacing \ with / in the
   following line:
   For example change:
   omsRecvDir=d:\oracle\product.2.0\db_1\ukp001_db0\sysman\recv
   to
   omsRecvDir=d:/oracle/product/10.2.0/db_1/ukp001_db0l/sysman/recv
3. Stop and restart the DB Control 

Hdr: 4714774 10.2.0.1 EMCP 10.2.0.1 PRODID-1370 PORTID-912
Abstract: DBCONSOLE DOES NOT WORK HAVING A HOSTNAME STARTING WITH "U"

Problem Description
-------------------
this seems to be releated to bug 3610052.
Having a hostname like u1234, install rdbms10.2.
start dbconsole will take 4-5 min. Even if the service is shown as started,
dbconsole java processes stops and restarts.

Environment Information
-----------------------

Test Case Step-by-Step Instructions
-----------------------------------
1. rename the hostanme to uXYZ....
2. install 10.2 rdbms into its own oraclehome
3. strt listener, create a database using dbca.
4. access the dbconsole page shows: "page cannot be displayed"

Check the dbconsole java process in taksmanager , you will easily see, that
it is coninously restarting. dbconsole service is shown as "started".

Test Case Location
------------------
not needed easy to reproduce

Diagnostic Analysis
-------------------
run the java command from file emd.nohup file, this will show something like:

java...Exception...
Malformed \uxxxx encoding.

and a java stack trace.

I assume that this problem will always happen, having a "\u" in the path for
the dbconsole

Performance
-----------

NLS Information
---------------

Patches
-------

Log Files Location
------------------

Reproducibility
---------------
everytime, only on windows platforms:
w2k w2003, windowsXP

URL
---
not needed

Did you test with the latest version?
-------------------------------------
yes

Available Workarounds
---------------------
Change the hostname from uXYZ to UXYZ,
do
set ORACLE_SID=
emca -config dbcontrol db -reposrecreate 

Related Bugs
------------
3610052

Hdr: 6313490 10.2.0.1.0 CONSOLE 10.2.0.1.0 PRODID-1370 PORTID-215 4714774
Abstract: 10.2.0.1DBCONSOLE IN A DB CREATED FROM IAS INSTALL FAILS TO START

Problem Description
-------------------
The dbconsole 10.2.0.1.0 creating is failing while starting the dbconsole
dbconsole in a db created from iAS install.

as per the logs:-

SEVERE: Error starting Database Control
    Refer to the log file at

D:\oracle\product.2.0\db_1\cfgtoollogs\emca\mmds\emca_2007-06-19_09-47-70-A
M.log for more details.
    Jun 19, 2007 9:58:17 AM oracle.sysman.emcp.EMConfig perform
    CONFIG: Stack Trace:
    oracle.sysman.emcp.exception.EMConfigException: Error starting Database
Control at
oracle.sysman.emcp.EMDBPostConfig.performConfiguration(EMDBPostConfig.java:569
) at oracle.sysman.emcp.EMDBPostConfig.invoke

Environment Information
-----------------------
dbconsole in a db created from iAS install.
db console 10.2.0.1.0 on Microsoft Windows Server 2003
The 10g application server version  is 10.1.2.0.2. to include January 2007
database and application server CPUs.

Applied the  database CPU patch and after that reconfigured the Dbconsole .
Now it doesn't get configured .Db console generating core dump

Test Case Step-by-Step Instructions
-----------------------------------

Test Case Location
------------------

Diagnostic Analysis
-------------------
Stopped the application server service and then started the dbcosnole .But
still getting the error

D:\oracle\product.2.0\db_1\BIN>emctl status dbconsole
    Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
    Oracle Enterprise Manager 10g is not running.
    ------------------------------------------------------------------
    Logs are generated in directory 

Asked him to move the file from Oracle_Home>/_/emctl.pid file
to another location . Now the dbconsole is started:-

>emctl start dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
Starting Oracle Enterprise Manager 10g Database Control ...The
OracleDBConsoleMM
DS service is starting...................The OracleDBConsoleMMDS service was
started successfully.

D:\oracle\product.2.0\db_1\BIN>emctl upload
Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
EMD upload error: uploadXMLFiles skipped :: OMS version not checked yet..

Asked him to Edit the file
ORACLE_HOME>\oc4j\j2ee\home\applications\dms\WEB-INF\web.xml

Still the dbconsole is not getting started .

可能是因为Windows上主机名以”U”字母开头后导致相关路径发生了转义。

可以通过在cmd中输入hostname来确认Windows上的主机名。

给出了2种解决方案:

1.升级到10.2.0.2以上版本,目前推荐的是10.2.0.5 Patch set; 版本10.2.0.1到10.2.0.3上的bug太多了..

2.修改$ORACLE_HOME\host_SID\sysman\config\emd.properties中的内容,将omsRecvDir变更改成使用斜杠而非反斜杠的路径形式,并重启EM.

利用SQL DEVELOPER导入EXCEL数据到Oracle数据库中

日常工作中往往涉及到数据导入工作,平时办公中excel应用十分广泛,导入工作我们一般都是将excel内容复制到文本文件中然后利用sqlldr工具导入。较新版本的Sql Developer提供了直接excel导入到表的功能,下面我们来尝试一下:
需要导入的excel的数据如下:
辅导书

在Oracle数据库中建立实验所需要的表:

凤飞飞

其中t1为主键;
点中创建好的表右键选择导入数据,选择需要导入的excel文件(目前仅支持xls格式不支持xlsx格式):

1231

若表格中有列名,则钩上”标题?”选项:

2222

单击下一步,选择需要的列:

3333

选择完成后单击下一步,将源数据列与目标表列一一对应:

vvv

单击下一步,选择导入前验证导入参数,出现以下条目:
验证表名 SUCCESS
验证源列是否映射了目标列 SUCCESS
验证源列是否定义了数据类型 SUCCESS
验证列的大小字段 SUCCESS
针对列大小检查数据 SUCCESS
验证日期列是否具有日期格式 SUCCESS
验证是否支持这些数据类型的导入 SUCCESS
单击完成,消息窗口出现导入日志:

bbbb

注意到这一步为止仍没有commit,需要到相关窗口点下commit按钮:

nnnn

目前Sql Developer中的excel导入功能已经较为完善,在版本1.5.5之前普遍存在next按钮无反应的bug。

转载请注明源地址: www.askmac.cn

autotrace在绑定变量情况下不准确的问题

通常我们在检验SQL执行计划时采用autotrace的方法,但autotrace本身存在许多不准确的情况。
以下为一个例子:
SQL> create table test(t1 int, t2 char(200));

表已创建。

SQL> create index ind_t2 on test(t2);

索引已创建。

SQL> insert into test values (0,’A’);

已创建 1 行。

SQL> commit;

提交完成。

SQL> begin
2  for i in 1..100000 loop
3  insert into test values(i,’ZZZZ’);
4  end loop;
5  commit;
6  end;
7  /
SQL> analyze table test compute statistics ;

表已分析。

SQL> analyze index ind_t2 compute statistics;

索引已分析

SQL> analyze table test compute statistics for all indexed columns;

表已分析。

以上代码 在test表中 产生一条t2为A的记录以及10万条t2为ZZZZ的语句,即列上值出现严重的倾斜。
SQL> set autotrace on;
SQL> variable a char;
SQL> exec :a:=’A’;
SQL> alter system flush shared_pool;

系统已更改。
PL/SQL 过程已成功完成。

SQL> oradebug setmypid;
已处理的语句
SQL> oradebug event 10046 trace name context forever,level 10;
已处理的语句

SQL> select * from test where t2=:a;

T1
———-
T2
————————————————————————–
0
A

执行计划
———————————————————-
Plan hash value: 1357081020

————————————————————————–
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
————————————————————————–
|   0 | SELECT STATEMENT  |      | 50001 |  9961K|   652   (2)| 00:00:08 |
|*  1 |  TABLE ACCESS FULL| TEST | 50001 |  9961K|   652   (2)| 00:00:08 |
————————————————————————–

Predicate Information (identified by operation id):
—————————————————

1 – filter(“T2″=:A)

统计信息
———————————————————-
231  recursive calls
0  db block gets
38  consistent gets
0  physical reads
0  redo size
654  bytes sent via SQL*Net to client
385  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
4  sorts (memory)
0  sorts (disk)
1  rows processed

SQL> oradebug tracefile_name;
e:\oracle\product\10.2.0\admin\orclv\udump\orclv_ora_4956.trc

使用tkprof 工具对 trace文件整理
tkprof  e:\oracle\product\10.2.0\admin\orclv\udump\orclv_ora_4956.trc C:\ora_4956.trc

可以找到以上查询的实际执行计划。
select *
from
test where t2=:a

call     count       cpu    elapsed       disk      query    current        rows
——- ——  ——– ———- ———- ———- ———-  ———-
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          6          0           1
——- ——  ——– ———- ———- ———- ———-  ———-
total        4      0.01       0.01          0          6          0           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS

Rows     Row Source Operation
——-  —————————————————
1  TABLE ACCESS BY INDEX ROWID TEST (cr=6 pr=0 pw=0 time=43 us)
1   INDEX RANGE SCAN IND_T2 (cr=5 pr=0 pw=0 time=32 us)(object id 51539)

可以看到这里实际的执行计划时 INDEX RAGNE SCAN 而非TABLE ACCESS FULL,这是由于优化器(optimizer)实际使用了绑定变量窥视的手段,而autotrace工具似乎不具备这种特性,故其展现的执行计划出现严重偏差。

一般情况下autotrace的结果仍是准确的,但也仅是一般情况,这需要我们凭借直觉去分辨。

关于Oracle中supplemental log的补充说明

在上一篇关于Oracle补全日志的介绍中漏写了关于最小补全日志(minimal supplemental log)与表级补全日志的关系;表级补全日志需要在最小补全日志打开的情况下才起作用,即若一个数据库没有开最小补全日志或之前drop supplemental log data操作则即便指定了表级补全日志,实际在重做日志输出的过程中描述的记录仍只记录rowid和相关列值。

打开最小补全日志的命令如下:

在上一篇关于Oracle补全日志的介绍中漏写了关于最小补全日志(minimal supplemental log)与表级补全日志的关系;表级补全日志需要在最小补全日志打开的情况下才起作用,即若一个数据库没有开最小补全日志或之前drop supplemental log data操作则即便指定了表级补全日志,实际在重做日志输出的过程中描述的记录仍只记录rowid和相关列值。

打开最小补全日志的命令如下:

Alter database add supplemental log data;

其次若如之前叙述的因表上的列数过多(超过200个),则应检查视图 dba_logstdby_not_unique, 该视图记录了在数据库中没有主键或没有唯一索引并且列非空的索引(tables in the primary database that do not have a primary key or unique index with NOT NULL columns)的表。如使用以下SQL:

select owner, table_name, bad_column

from dba_logstdby_not_unique

where table_name not in

(select table_name from dba_logstdby_unsupported);

TSMSYS    SRS$    Y
HTEST    TEST    N
HGET    GETMAXID    N
HGET    HUSER    N
SCOTT    BONUS    N
SCOTT    SALGRADE    N

其中bad_column列较为关键。若该字段为 Y,表示一个表列被使用大数据类型定义,例如CLOB或BLOB。sql apply尝试维护这些表,但是你必须要保证表中除这列外的其他列的单值性。就是说,注意,如果一个表中有两行除了LOB列外,其他的值完全相同,这样表 的改动就不能被逻辑备用数据库应用,sql apply会停止。N,表示表中包含足够的列信息,需要用来在逻辑备用数据库中维护表的。

针对前文叙述的在表上列较多的情况下(超过200个列),且不能添加主键和唯一非空索引的表,我们需要特别关注。但实际如果我们想了解一个段在一定段内产生的重做量却十分困难。(method :check  how much redo generated by one segment)

已知的研究方法例如logmnr工具,和dump redologs以及oradebug都无法提供足够的信息帮助统计。

仅有的方法是通过logmnr估算,v$logmnr_contents视图中记录的rbablk与rbabyte,为重做日志中的块偏移量(redo log中512byte为一个快)与字节偏移量,通过计算差值结合data_obj#列,可以大致估算某个段上一定时间内的重做量:

create table redo_analysis nologging as

select data_obj#,  oper, rbablk*512 + rbabyte curpos,

lead(rbablk*512+rbabyte,1,0) over (order by  rbasqn, rbablk, rbabyte)

nextpos

from

( select distinct data_obj#,  operation oper,

rbasqn, rbablk, rbabyte from v$logmnr_contents

order by rbasqn, rbablk, rbabyte );

select data_obj#, oper, obj_name, sum(redosize) total_redo

from

(

select data_obj#, oper, obj.name obj_name , nextpos-curpos-1 redosize

from redo_analysis redo1, sys.obj$ obj

where (redo1.data_obj# = obj.obj# or  redo1.data_obj# = obj.dataobj#)

and  nextpos !=0 — For the boundary condition

union all

select data_obj#, oper, ‘internal ‘ , nextpos-curpos  redosize

from redo_analysis redo1

where  redo1.data_obj#=0 and  redo1.data_obj# = 0

and nextpos!=0

)

group by data_obj#, oper, obj_name

order by 4

以上估算并不准确,在有手动切换(switch logfile)日志及其他特殊情况时误差较大。

绑定变量介绍

Oracle在执行SQL语句时,普遍存在以下几个步骤:

  1. 当SQL语句首次执行,Oracle将确认该句语句的语法是否正确(语法解析Syntax parse)并进一步确认语句相关表和列的存在性等因素(语义解析semantic parse)以及优化器决定执行计划等步骤。整个过程称之为硬解析,硬解析消耗大量的CPU时间和系统资源。硬解析过多会有效降低系统性能。
  1. 若之前已进行过硬解析,且解析后的分析树和执行计划仍存在于共享池中,则同样的SQL仅需要软解析。软解析将输入的SQL语句转换为哈希代码,同共享池内哈希链表上的已有记录进行对比,找出对应的游标信息,使用已有的执行计划执行。
  1. 绑定变量,将实际的变量值代入SQL语句中。
  1. 执行SQL语句,查询语句将返回结果集。

不使用绑定变量的SQL语句,Oracle无法将它们视为相同的,如以下两句语句:

select * from emp where empno=1234

select * from emp where empno=5678

因为自由变量的不同,Oracle认为以上是2句不同的语句,则当第一条被硬解析后,第二条SQL执行时仍无法避免硬解析。实际在以上不使用绑定变量的情况中,只要自由变量有所改变则需要一次硬解析。这是强烈建议使用绑定变量的主要原因,使用绑定变量的语句变量的实际值仅在SQL执行的最后阶段被代入。如以下语句:

select * from emp where empno=:x

该语句使用绑定值:x替代自由变量,在应用中语句可能以预编译或普通编译的方式存在,仅在执行阶段代入变量值,多次执行仅需要一次硬解析,较不使用绑定变量情况性能大大提升。

同时过多的硬解析还会引发共享池碎片过多的问题。因为每当需要硬解析一个SQL或者PLSQL语句时,都需要从shared pool中分配一块连续的空闲空间来存放解析结果。Oracle首先扫描shared pool查找空闲内存,如果没有发现大小正好合适的空闲chunk,就查找更大的chunk,如果找到比请求的大小更大的空闲chunk,则将它分裂,多余部分继续放到空闲列表中。因为过多的硬解析加剧了内存段分配的需求,这样就产生了碎片问题。系统经过长时间运行后,就会产生大量小的内存碎片。当请求分配一个较大的内存块时,尽管shared pool总空闲空间还很大,但是没有一个单独的连续空闲块能满足需要。这时,就可能产生 ORA-4031错误。

通常我们可以通过以下SQL语句将系统中非绑定变量的语句找出:

SELECT substr(sql_text,1,40) “SQL”,

count(*) ,

sum(executions) “TotExecs”

FROM v$sqlarea

WHERE executions < 5 –-语句执行次数

GROUP BY substr(sql_text,1,40)

HAVING count(*) > 30 –-所有未共享的语句的总的执行次数

ORDER BY 2;

以上语句在实际使用中substr函数截取到的字符串长度需要视乎实际情况予以变化。

对于非绑定变量且短期内无法修改的应用,Oracle存在参数cursor_sharing可以改善其表现。cursor_sharing默认为exact,对使用自由变量的语句不做额外处理;当设为force时,非绑定变量的SQL语句被进一步处理以达到共享SQL的目的,但以上处理步骤同样要消耗一定的CPU时间;当设为similar时,若数据库存在语句相关统计信息则其表现如exact,若无统计信息则表现为force。cursor_sharing参数是Oracle针对无法修改的非绑定变量应用所提出的折中方案,但cursor_sharing为force值时存在一定SQL引发bug或语句无效的情况,且额外的处理操作同样需要消耗一定量的CPU时间和系统资源。故针对系统性能的最优方案往往是直接修改应用代码,使用绑定变量特性。

Network Interface No Longer Operational?

Solaris平台上的Oracle数据库,Alert日志偶尔会出现”Network Interface No Longer Operational”的相关记录:

ospid 11223: network interface with IP address 192.4.1.22 no longer operational
requested interface 192.4.1.22 ioctl get mtu. Check output from ifconfig command

该错误一般是由Solaris操作系统Bug 6546482引起的,该错误一般可以忽略。

沪ICP备14014813号-2

沪公网安备 31010802001379号