alert日志中出现ash size的警告

今天查看数据库的alert日志总出现了如下的警告。
Archived Log entry 202 added for thread 1 sequence 202 ID 0x1ed7a02c dest 1:
Sat Mar 15 01:37:30 2014
Completed checkpoint up to RBA [0xca.2.10], SCN: 267711453
Sat Mar 15 01:44:58 2014
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing
 ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 67108864 bytes. Both ASH size and the total number of emergency flushe
s since instance startup can be monitored by running the following query:
 select total_size,awr_flush_emergency_count from v$ash_info;
Sat Mar 15 01:45:00 2014
Beginning log switch checkpoint up to RBA [0xcc.2.10], SCN: 270149004
Thread 1 advanced to log sequence 204 (LGWR switch)
  Current log# 4 seq# 204 mem# 0: /TEST1/db03/oradata/PRDTEST1/redo_g4_m1.dbf
  Current log# 4 seq# 204 mem# 1: /TEST1/db04/oradata/PRDTEST1/redo_g4_m2.dbf
Sat Mar 15 01:45:11 2014

ash的size大小设置是隐含参数_ash_size中设置的。查看metalink(文档 ID 1385872.1)

CAUSE

Typically some activity on system causes more active sessions, therefore filling the ASH buffers faster than usual causing this message to be displayed. It is not a problem per se, just indicates the buffers might need to be increased to support peak activity on the database.

SOLUTION

The current ASH size is displayed in the message in the alert log, or can be found using the following SQL statement.

select total_size from v$ash_info;

Then increase the value for _ash_size by some value, like 50% more than what is currently allocated.  For example if total_size = 16MB, then an increase of 50% more would be (16MB + (16MB * 50%)) = 24MB. 

sqlplus / as sysdba
alter system set "_ash_size"=25165824;

You can verify the change using the following select:

select total_size from v$ash_info;

时间: 2024-10-24 04:16:50

alert日志中出现ash size的警告的相关文章

alert日志中的一条ora警告信息的分析

今天照例检查数据库alert日志,发现一个错误.但是也没在意,想可能有大的操作导致的,马上会释放空间的,但是转眼一想,这是生产库,而且现在时早上,泰国的运营商还不算忙时,需要重视这个问题,看有没有什么潜在的问题, 从alert日志里面看到的 Fri Jul 12 09:08:23 ICT 2013 ORA-1652: unable to extend temp segment by 128 in tablespace                 TEMP   查询temp_usage,发现目

solaris-Solaris日志中关于硬件驱动程序的警告信息

问题描述 Solaris日志中关于硬件驱动程序的警告信息 M4000服务器上安装了时统中断卡及设备驱动程序.最近操作系统日志频繁出现警告 信息,意思是时统中断卡出现虚假中断,中断号为15.之前硬件卡和驱动程序运行了一年有余无任何问题.请问出现这样的警告信息是什么原因?谢谢! 解决方案 如果软件环境没有改变,那么可能是硬件坏了或者连线松了.

alert日志中的两种ORA错误分析

今天在巡检系统的时候,发现alert日志中有两种类型的ora错误. Errors in file /U01/app/oracle/diag/rdbms/XX/XX/trace/xxdb_j002_20401.trc: ORA-12012: error on auto execute of job "XXDATA"."S_XXXX_HIST_OPS_SERINFO_K" ORA-12170: TNS:Connect timeout occurred ORA-06512

apache2中修改错误日志中的错误级别

一.遇到问题 因为写日志会给系统带来很大的损耗.关闭日志以后,甚至最高可以提高整体性能近40%(粗略估计)那么如何关闭日志呢?可以通过降低log级别的办法来减少日志读写. 这里要提醒的是,这么做将给"入侵检测"以及其他基于日志分析的工作带来麻烦.所以请谨慎使用.  二.解决问题 编辑conf文件夹下的httpd.conf,找到如下内容:  #  # LogLevel: Control the number of messages logged to the error_log.  #

alert日志报checkpoint not complete错误如何解决

高峰期alert日志报checkpoint not complete 比较频繁,需要根据什么进行调整redo? 当oracle想重用你的一个redo log时,发现这个redo log中检查点还在,oracle就会在alter log中报这个警告 与这个告警相关的的调整项有以下几个方面: 1.系统的IO性能有问题,dbwr进程写的太慢 2.LOG_CHECKPOINT_TIMEOUT,FAST_START_MTTR_TARGET, LOG_CHECKPOINT_INTERVAL 设置的不合理,致

事件日志中的"TermService" 服务的性能库

  发现事件记录: "TermService" 服务的性能库 "C:WINDOWSsystem32perfts.dll" 的配置信息  同在注册表中保存的受信任性能库信息不匹配.此库中的函数不会作为受信任函数处理. TermService是系统的一个服务. Terminal Services 提供一个多会话环境,客户端设备可以在此环境中访问虚拟 Windows 桌面会话和服务器上运行的基于 Windows 的程序.Terminal Services 使用户可以远程管

c#.NET中日志信息写入Windows日志中解决方案_C#教程

1. 目的   应用系统的开发和维护离不开日志系统,选择一个功能强大的日志系统解决方案是应用系统开发过程中很重要的一部分.在.net环境下的日志系统解决方案有许多种,log4net是其中的佼佼者.  在Windows2000及以上操作系统中,有一个Windows日志系统,它包括应用程序(Application)事件日志.系统(System)日志和安全(Security)日志,事件日志也可以是自定义日志.在.net Framework中也提供了相应的类和接口来使用应用程序事件日志或者自定义事件日志

Alert Log中“Fatal NI connect error 12170”错误

Alert Log中"Fatal NI connect error 12170"错误 Fatal NI connect error 12170.     VERSION INFORMATION:         TNS for Linux: Version 11.2.0.4.0 - Production         Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production      

alert文件中出現:Auto-tuning: Shutting down background process GTXd

(一)早上查看一套4節點的RAC服務器時發現 alert 日志中有如下顯示內容.            Thu Jun 13 06:20:31 2013Auto-tuning: Shutting down background process GTXdThu Jun 13 06:30:32 2013Auto-tuning: Shutting down background process GTXcThu Jun 13 06:40:33 2013Auto-tuning: Shutting down