ora-00445

sqysl

这个版本坑很多，小到大家遇到的后台进程自己停掉，大到实例自己停掉。正是这个版本，当时因为项目经理急了点，升级到这个版本后，出现诸多问题，最后不得不又降回到11.1，所以，这个版本生产库最好别碰，不然，很多坑等着你去淌。

houyichong

表空间只有一个数据文件？

lfree

futian_187 发表于 2016-6-30 18:09
我的也一样，好长时间了，禁用SMOC后，会对自动扩展有影响吗，求助。。
TNS-00505: 操作超时
    nt seco ...

看来这个版本有问题?
是11.2.0.1 for windows的版本吗?

是使用amm自动内存管理吗?

禁用SMOC没有,如果你觉得不妥.最好先把数据文件加大,关闭扩展.
检测
SELECT object_name, object_type, reason,
       suggested_action,
       --TO_char (time_suggested, 'yyyymmdd hh24:mi:ss') time_sug,
           TO_char (creation_time, 'yyyymmdd hh24:mi:ss')  cr_time,
           advisor_name, metric_value, host_nw_addr
  FROM dba_outstanding_alerts ;

happyjsl1

我的报错和后面这位兄弟的报错时一样的，不单单是后台进程smco分配的进程无法启动，其它后台进程分配的进程同样都无法启动。
所以我觉得和空间预分配关系可能不大。

从进程方面的参数考虑，监控到的session,process,job_queue_process都没有到达阈值。

从资源利用率看，trace file中有记录当时用的内存，也不高，服务器当时的CPU和MEMORY都不高。


我不知道我的PGA和SGA设置是不是太小，都是1.5G，启用了ASMM。
另外一个不确定的是，windows的OS方面是否有限制。

lfree

happyjsl1 发表于 2016-7-1 17:02
我的报错和后面这位兄弟的报错时一样的，不单单是后台进程smco分配的进程无法启动，其它后台进程分配的进程 ...

我觉得跟晚上的几个schedule有关.

还有可能就是自动内存管理,这样情况下pga很小,我们出问题使用用户也很小,不到50.
pga 分配仅仅78M.

我现在关闭了
BEGIN
  DBMS_AUTO_TASK_ADMIN.disable(
    client_name => 'auto space advisor',
    operation   => NULL,
    window_name => NULL);
END;
/
还有sql tuning advisor.

分析统计我没有关闭.现在没有报,当然我自己也做了一点点优化.

lfree

happyjsl1 发表于 2016-7-1 17:02
我的报错和后面这位兄弟的报错时一样的，不单单是后台进程smco分配的进程无法启动，其它后台进程分配的进程 ...

你说的是有道理的,因为smco要一定时间检查做预分配,调用w000 或者做一些job,启动cjq0,j000.而这个时候数据库已经down?,估计不是完全,alert有记录都是这样写.

futian_187

lfree 发表于 2016-7-1 08:35
看来这个版本有问题?
是11.2.0.1 for windows的版本吗?

是11.2.0.2 for windows的版本，比你们高一个小版本，宕机时的session,process才一百多，设置的是1000，内存也没达到最大；没有禁用SMOC，上周五出现后，和ORACLE那边沟通了下，觉得没问题就把SMOC禁了继续看看。windows还是不适合跑数据库啊
什么警告信息也没有，目前查的。
默认是AMM自动内存大概6G左右

lfree

futian_187 发表于 2016-7-4 09:02
是11.2.0.2 for windows的版本，比你们高一个小版本，宕机时的session,process才一百多，设置的是1000，内 ...

我觉得应该是后台某种资源耗尽.这个时候普通用户也不能登录.
出现alert这些信息,仅仅定时要启动这些,才记录下来.

我个人觉得最大的问题可能amm自动内存管理的问题.

lfree

这个时候listener.log记录如下:
Wed Jun 22 07:35:47 2016
22-6月 -2016 07:35:47 * service_update * orcl * 0
Wed Jun 22 07:37:12 2016
22-6月 -2016 07:35:51 * (CONNECT_DATA=(SERVICE_NAME=orcl)(CID=(PROGRAM=C:\Windows\SysWOW64\inetsrv\w3wp.exe)(HOST=SERVER230)(USER=ris64))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.xx.yyy)(PORT=63945)) * establish * orcl * 12518
TNS-12518: TNS: 监听程序无法分发客户机连接
TNS-12560: TNS: 协议适配器错误
22-6月 -2016 07:37:12 * service_update * orcl * 0
Wed Jun 22 07:38:33 2016
22-6月 -2016 07:37:12 * (CONNECT_DATA=(SERVICE_NAME=orcl)(CID=(PROGRAM=C:\Windows\SysWOW64\inetsrv\w3wp.exe)(HOST=SERVER230)(USER=ris64))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.xx.yyy)(PORT=63946)) * establish * orcl * 12518
TNS-12518: TNS: 监听程序无法分发客户机连接
TNS-12560: TNS: 协议适配器错误
Wed Jun 22 07:39:54 2016
22-6月 -2016 07:38:33 * (CONNECT_DATA=(SERVICE_NAME=orcl)(CID=(PROGRAM=C:\Windows\SysWOW64\inetsrv\w3wp.exe)(HOST=SERVER230)(USER=ris6))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.xx.yyy)(PORT=63947)) * establish * orcl * 12571
TNS-12571: TNS: 包写入程序失败
TNS-12560: TNS: 协议适配器错误
  TNS-00530: 协议适配器错误
   64-bit Windows Error: 54: Unknown error
    TNS-12518: TNS: 监听程序无法分发客户机连接
     TNS-12560: TNS: 协议适配器错误
22-6月 -2016 07:38:33 * service_update * orcl * 0
22-6月 -2016 07:39:54 * 12502
TNS-12502: TNS: 监听程序没有从客户机收到 CONNECT_DATA
Wed Jun 22 07:41:14 2016

--说明client已经无法连接服务器.

lfree

而晚上有分析统计.auto space advisor,sql tuning advisor其实是很耗资源的,我停止了后面2个.

我个人的感觉问题可能出在amm管理上.