Alter Log中VKTM时间drift漂移现象时间是包括数据库系统在内的诸多信息系统基础件的重要因素。对于运行在操作系统OS之上的中间件组件而言，获取到一个准确、连续和一致的时间非常重要，特别是多节点的环境下。如果没有一个统一的时间管理机制，其上的cluster组件工作是及其困难的。本篇主要介绍Oracle vktm时间后台进程报警的Bug问题。1、从11g VKTM进程谈起对Oracle数据库，避免对于操作系统层面时间的调用，维持一个统一稳定的时间体系一直是发展方向。在11g中，一个独立的后台进程vktm被引入到实例体系下。VKTM进程全称为“Virtual Keeper of Time Process”，用于给数据库运行和间隔运算计量提供出一个统一的时间服务。官方解释是：VKTM acts as a time publisher for an Oracle instance. VKTM publishes two sets of time: a wall clock time using a seconds interval and a higher resolution time (which is not wall clock time) for interval measurements. The VKTM timer service centralizes time tracking and offloads multiple timer calls from other clients.在11g之前的版本中，如果数据库实例（包括ASM和RAC Instance）需要当前时间的时候，都调用操作系...

在10G中如果LGWR写出的时间超过500ms,LGWR的后台跟踪文件中将会记录一条警告信息。如下所示：[oracle@dbserver bdump]$ more dbserver_lgwr_13596.trc/u01/admin/dbserver/bdump/dbserver_lgwr_13596.trcOracle Database 10g Enterprise Edition Release 10.2.0.4.0 - ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing optionsORACLE_HOME = /u01/oracleSystem name:    LinuxNode name:      dbserverRelease:        2.6.9-51.ELsmpVersion:        #1 SMP Tue Mar 20 23:10:05 EDT 2007Machine:        i686Instance name: dbserverRedo thread mounted by this instance: 1Oracle process number: 10Unix process pid: 13596, image: oracle@dbserver (LGWR)*** SERVICE NAME:() 2011-05-06 21:27:43.086*** SESSION ID:(1016.1) 2011-05-06 21:27:43.086Maximum redo generation record size = 156160 bytesMaximum redo generation change vector size = 150672 bytestkcrrsarc...

如果你比较心细,可能在11.2的数据库中发现alert文件中存在存在类此下面的记录Errors in file /oradb/diag/rdbms/offon/offon2/trace/offon2_ckpt_19660878.trc:查看trace文件发现*** 2012-08-01 03:36:03.520  1: 1450ms (rw) file: kct.c line: 1011 count: 1 total: 1450ms time: 1594117  2: 890ms (rw) file: kcrf.c line: 10012 count: 6 total: 4266ms time: 1820928  3: 830ms (ro) file: kcf.c line: 5306 count: 1 total: 830ms time: 1594116  4: 530ms (rw) file: kcv.c line: 11783 count: 1 total: 530ms time: 3207607Control file enqueue hold time tracking dump at time: 3376956 *** 2012-08-03 02:14:38.714  1: 1450ms (rw) file: kct.c line: 1011 count: 1 total: 1450ms time: 1594117  2: 890ms (rw) file: kcrf.c line: 10012 count: 7 total: 4953ms time: 1820928  3: 830ms (ro) file: kcf.c line: 5306 count: 1 total: 830ms time: 1594116  4: 530ms (rw) file: kcv.c line: 11783 count: 1 total: 530ms time: 3207607Control file enqueue hold ti...

今天检测测试库时，发现alert告警日志报错，如下： FriApr 29 12:11:34 2016 minact-scn:got error during useg scan e:376 usn:10 minact-scn:useg scan erroring out with error e:376 FriApr 29 12:14:34 2016 minact-scn:got error during useg scan e:376 usn:10 minact-scn:useg scan erroring out with error e:376 FriApr 29 12:17:34 2016 minact-scn:got error during useg scan e:376 usn:10 minact-scn:useg scan erroring out with error e:376 每3分钟会出现一次 网上找了找到解决方法，故障是由MINACT-SCNMASTER-STATUS信息写到MMON的TRACE文件的BUG引起的，BUG号11891463，解决办法如下： 1. 将隐含参数"_enable_minscn_cr"设置为false： altersystem set "_enable_minscn_cr"=false scope=spfile; 2. 重启数据库检查问题是否被解决。 3. 有时设置了"_enable_minscn_cr"参数就可以解决这个问题，有时却不能，如果没能解决，请再设置"_smu_debug_mode"参数： altersystem set "_smu_debug_mode"=134217728; 设置了上述参数后该信息不会再生成，但是这会禁用...

原来的数据库服务器使用rman进行全库的备份，然后再异地的服务器上恢复一模一样的数据库1.1      原服务器备份数据库第一步，查看数据库的实例名和DBIDconnected to target database: DB3 (DBID=2060124769, not open)第二步，进行全备份backup AS COMPRESSED BACKUPSET databaseinclude current controlfile format '/orabak/db_%d_%T_%s'plus archivelog format '/orabak/arch_%d_%T_%s' ;第三步，查看数据库文件的位置： /home/Oracle/oradata/db3/第四步，将备份文件arch_DB3_20140910_8和 db_ DB3_20140910_7复制异机上/home/oracle/orabak1.2      目标服务器上创建数据库第一步，创建实例名相同（db3）,数据库文件的位置相同（/home/oracle/oradata/db3/）的数据库。 第二步，关闭实例，启动到nomount状态。Sql>startup nomount; 第三步，设置dbid和原数据库dbid相同rman target/Recovery Manager: Release 10.2.0.5.0 - Production on Thu Sep 11 19:53:50 2014Copyright (c) 1982, 2007, Oracle.  All rights reserved.connected to target database: db3 (not mounted)RMAN> set dbid 206...

Oracle密码带特殊字符，如”@“号，在imp,exp里的写法。 做Oracle数据导出的时候，由于用户名的密码使用的是特殊字符，所以遇到了错误代码：“EXP-00056: 遇到 ORACLE 错误 12154” windows os: exp username/"""password"""@devdb --3个双引号扩密码 linux/unix os: exp "username/"password"@devdb" --1个双引号扩密码，1个单引号扩全部

mysql查询字段中带空格的值的sql语句    　　(1)mysql replace 函数　　语法：replace(object,search,replace)　　意思：把object中出现search的全部替换为replace  代码如下     update `news` set `content`=replace(`content`,' ','');//清除news表中content字段中的空格 这样就可以直接用like查询了。 　　(2)mysql trim 函数　　语法：trim([{BOTH | LEADING | TRAILING} [remstr] FROM] str)　　以下举例说明：  代码如下   mysql> SELECT TRIM(' phpernote  ');  -> 'phpernote'  mysql> SELECT TRIM(LEADING 'x' FROM 'xxxphpernotexxx');  -> 'phpernotexxx' mysql> SELECT TRIM(BOTH 'x' FROM 'xxxphpernotexxx');  -> 'phpernote'  mysql> SELECT TRIM(TRAILING 'xyz' FROM 'phpernotexxyz');  -&...

Cannot allocate new log - Private strand flush not complete  Question:  I just upgraded to Oracle 10g release 2 and I keep getting this error in my alert logThread 1 cannot allocate new log, sequence 509Private strand flush not completeCurrent log# 2 seq# 508 mem# 0: /usr/local/o1_mf_2_2cx5wnw5_.log What causes the "private strand flush not complete" message? Answer:  This is not a bug, it's the expected behavior in 10gr2.  You can get the message suppressed by increasing thedb_writer_processes parameter.The "private strand flush not complete" is a "noise" error, and can be disregarded because it relates to internal cache redo file management.  It does not necessarily mean that you have a problem, but it depends if the error message is accompanied by other errors. You should check your transaction with used private redo size in the x$ktifp fixed table  ...

检查oracle11g 报警日志时，发现有以下报错。Errors in file /data/app/oracle/diag/rdbms/hextrack/hextrack/trace/hextrack_j000_28066.trc: ORA-12012: 自动执行作业 765 出错ORA-12005: 不能安排过去时间的自动刷新检查下对应job编号的具体情况：select job,       log_user,       schema_user,       what,       LAST_DATE,       LAST_SEC,       THIS_DATE,       THIS_SEC,       NEXT_DATE,       NEXT_SEC,       INTERVAL  from dba_jobs where job = 765 JOBLOG_USERSCHEMA_USERWHATLAST_DATELAST_SECTHIS_DATETHIS_SECNEXT_DATENEXT_SECINTERVAL765NEUDDCNEUDDCbeginTable_Analysis;end;2016/11/9 0:02:1500:02:15  2016/11/9 23:00:0023:0...

Errors in file /data/app/oracle/diag/rdbms/hextrack/hextrack/trace/hextrack_j001_14450.trc  (incident=59154):ORA-01578: ORACLE data block corrupted (file # 6, block # 1284)ORA-01110: data file 6: '/data/app/oracle/oradata/hextrack/gps_data.dbf'ORA-26040: Data block was loaded using the NOLOGGING optionIncident details in: /data/app/oracle/diag/rdbms/hextrack/hextrack/incident/incdir_59154/hextrack_j001_14450_i59154.trcDBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.Errors in file /data/app/oracle/diag/rdbms/hextrack/hextrack/trace/hextrack_j001_14450.trc:ORA-01578: ORACLE data block corrupted (file # 6, block # 1284)ORA-01110: data file 6: '/data/app/oracle/oradata/hextrack/gps_data.dbf'ORA-26040: Data block was loaded using the NOLOGGING option*** 2016-10-27 22:00:21.383*** SESSION ID:(48.42847) 2016-10-27 22:00:21.383*** CLIENT ID:() 2016-10-27 22:00:21.383*** SERVICE NAME:(SYS$USERS) 2016-10-27 22:00:21.383*** MODULE NAME:(DBMS_SCHEDULER) 2016-10-27...