最新 | 最热门 | 最高评价

+0  基于Solaris spark的Oracle调优

Tag: It's my life | Working case | ..experience
小荷 发于 2014年09月28日 20:07 | 点击: 1257 | 展开摘要
一、RAC 中cluster wait time高问题

1.设置LMS进程为FX 60,不要过多调整lms进程的数量

注:在Solaris 10 Update 10之后,以及Solaris 11,才可以设置进程的优先级。可以通过看/etc/release看其版本。如Oracle Solaris 10 1/13 是表示Solaris 10 Update 11,可参考:Oracle Solaris 10 Update版本及其历史

Oracle Solaris 10 1/0

查看全文: http://www.udpwork.com/item/13323.html

+0  SQL执行时反复一慢两快的问题

Tag: Working case | ..experience
小荷 发于 2014年09月14日 17:47 | 点击: 1265 | 展开摘要
SQL执行的时间,在正常情况下应该是稳定的。如果第一次快,第二次慢,那么可能就是由于cardinality feedback的缘故,我们可以设置”_OPTIMIZER_USE_FEEDBACK”= false来规避。但是这次遇到的问题却是执行过程两快一慢,执行过程是慢->快->快->慢->快->快->慢->快->快->……,执行了慢之后,还能再快回来,这是怎么回事呢?

这个sql初次执行的时候是快的,然后把这次快的执行计划用spm固定下来,再次执行的

查看全文: http://www.udpwork.com/item/13248.html

+0  统计信息收集后不生效的问题

Tag: Working case | ..experience
小荷 发于 2014年09月14日 11:06 | 点击: 1316 | 展开摘要
客户的某系统升级到11g之后,收集统计信息却不生效,查dba_tables看不到其LAST_ANALYZED。这其实是因为11g的一个新特性,延时发布统计信息。

我们看下面的测试案例:

--建立一个测试表:
SQL> create table t_test as select * from dual;
 
Table created.
 
--检查这个publish属性,我们可以查系统级的熟悉和表级别的属性。在默认情况下,是true:即收集后立即

查看全文: http://www.udpwork.com/item/13249.html

+0  关于带lob对象的分区表,移动表空间的问题

Tag: Working case | ..experience
小荷 发于 2014年09月12日 20:36 | 点击: 1411 | 展开摘要
客户有个带lob对象的表空间,希望做表空间的move,可是等move之后,发现在dba_lobs里面查到的lob对象的表空间还是在原来的地方。

CREATE TABLE SCES1INPUTS
(
  CODREQUEST            VARCHAR2(9 BYTE)        NOT NULL,
  LOBS1INPUT  &nb

查看全文: http://www.udpwork.com/item/13250.html

+0  迁移数据库后启动报错ora-600[25025]

Tag: Working case | ..experience
小荷 发于 2014年09月12日 12:50 | 点击: 1327 | 展开摘要
迁移脚本的日志中报错RMAN-06571: datafile 78 does not have recoverable copy,经查看发现78号文件曾经被offline drop掉。于是重建控制文件,在控制文件中把78号文件去掉,重建控制后,数据库能够mount,mount后数据文件是一致,但是open 时会报错ora-600,异常宕掉。

SYS@mydbtst> alter database open;
alter database open
*
ERROR at

查看全文: http://www.udpwork.com/item/13251.html

+0  修复missing的datafile

Tag: Working case | ..experience
小荷 发于 2014年09月08日 16:45 | 点击: 1323 | 展开摘要
在一次迁移中,原来的数据库中存在一些missing的datafile,如MISSING00006这样的datafile,这些数据文件经查已经在os上不存在,且该数据文件上的信息也已经不需要。一般情况下,我们是将仍旧需要表从这个表空间move到另外的表空间,再将这整个表空间drop掉。但是由于表空间中的对象很多,依赖关系复杂,且missing的表空间只是少数,所以可以用下面的方法清理掉。

注:

1. 该方法是次选,首选应该是drop表空间的方法。
2. 该方法适合非undo

查看全文: http://www.udpwork.com/item/13232.html

+0  tahiti已死,docs接班

Tag: Working case | ..experience
小荷 发于 2014年07月29日 10:45 | 点击: 1155 | 展开摘要
如果你近期访问著名的oracle在线文档的网站tahiti.oracle.com,你会发现这个网站已经不再提供服务,在网站上只留下一段话:

Tahiti index no longer available
 
All Oracle documentation is at docs.oracle.com.

从改版到小清新,到停止服务,让不少老oracle玩家唏嘘不已,目前所有的在线文档,都转移新的docs.oracle.com进行访问。不过转移过去的文档,也只有从

查看全文: http://www.udpwork.com/item/12833.html

+0  active dataguard用户解锁

Tag: Working case | ..experience
小荷 发于 2014年07月17日 15:18 | 点击: 1292 | 展开摘要
有个用户,在备库尝试多次登录,都是密码错误登录不上,再去主库登录,还是登录不上。并且由于尝试过多次数的密码,账户被锁定了。

DBA帮助其在主库解锁后,在active dataguard却还是无法登陆。

在ADG端检查:

SQL> select username ,account_status from dba_users where username='TEST';
 
USERNAME         

查看全文: http://www.udpwork.com/item/12750.html

+0  运行DBCA显示configure选项为灰色

Tag: Working case | ..experience
小荷 发于 2014年07月15日 10:59 | 点击: 1029 | 展开摘要
运行dbca的时候,发现configure database选项为灰色。

处理方式为:

1. 如果在windows环境中:
1.1 开一个窗口。
1.2 set oracle_home=<directory path of the specific oracle home>
1.3 再次运行dbca

2.如果在unix环境中:

2.1 如果是在solaris环境中,修改/var/opt/oracle下的oratab文件
    

查看全文: http://www.udpwork.com/item/12740.html

+0  Job中报错ora-1493,no data found

Tag: Working case | ..experience
小荷 发于 2014年06月06日 11:30 | 点击: 1159 | 展开摘要
客户这边遇到个问题,他们有个package,在job中定期运行,但是会出现时不时的报错ora-1493,no data found。

定位引发ora-1493,no data found的语句为:

SELECT sid, serial#
  INTO v_sid, v_serial#
  FROM v$session
WHERE sid =
       (SELECT MAX(sid) FROM v$sessi

查看全文: http://www.udpwork.com/item/12598.html

+0  11g启动报错ORA-00371: not enough shared pool memory

Tag: Working case | ..experience
小荷 发于 2014年06月06日 11:22 | 点击: 1677 | 展开摘要
问题:

11g的一个库,启库时,报错shared pool不够。由于我是在一个测试的机器上,我不需要那么多的share pool,我只需800M的shared pool就够了。

但指定shared pool的大小为800M在初始化文件中,起库就报错:

SQL> startup
ORA-00371: not enough shared pool memory, should be atleast 2138663491 bytes

解决:

加个processes参

查看全文: http://www.udpwork.com/item/12599.html

+0  data file init write等待

Tag: Working case | ..experience
小荷 发于 2014年06月06日 11:14 | 点击: 1731 | 展开摘要
发生data file init write的等待是数据文件正在发生扩展,在11g中,这往往和SMCO和Wnnn进程的自动预扩展有关。

在生产环境中,如果在生产高峰期出现预扩展,可能会造成短暂的hang住,或者CPU突然的升高,或者查询dba_free_space的hang住。但是,预扩展这个功能是否好处大于坏处,是否需要关闭,我们用一些测试数据来说明。

在测试库测试了load大量数据到表中,触发SMCO进行自动预扩展,在测试中发现如下:

(1)开启预扩展时(即设置_e

查看全文: http://www.udpwork.com/item/12600.html
|<<<1234567>>>| 一共7页, 80条记录