这多出的“1秒”将加在格林尼治时间12月31日23时59分后，通过增加闰秒实现。由于北京处于东八时区，所以将在2017年1月1日7时59分59秒后面增加1秒，届时会出现7时59分60秒的特殊现象。

为什么要增加1秒？这1秒从何而来？据天文专家介绍，为了确定时间，世界上有两种时间计量系统，基于地球自转得出的“世界时”和基于原子振荡周期确定的“原子时”。由于两种时间尺度对秒的测量方法不同，随着时间的推移，这两个时间系统之间就会出现差异，所以有了“协调世界时”的概念。

“协调世界时”以原子时秒长为基础，在时刻上尽量接近于世界时。1972年，国际计量大会决定，当“世界时”与“原子时”之间时刻相差超过0.9秒时，就在协调世界时上加上或减去1秒（正闰秒或负闰秒），以尽量接近世界时，这就是闰秒。

    计算机的时间只要不使用NTP就没什么大问题。

AIX  date -n mmddHHMMYY，mm表示月分，dd表示日期，HH表示小时，MM表示分钟，YY表示年份。

CAUSE

The Oracle oracle.sql.BLOB OutputStream writes the data in chunks. Since autocommit defaults to true, the first chunk is committed. This results in the write operation for the next chunk of the Blob to fail since it appears to be in the next transaction.
In those conditions, the ORA-22990 exception will occur with any version of Oracle JDBC driver.

SOLUTION

Issue the setAutoCommit(false) command. Then, explicitly commit the transaction after all of the Blob chunks have been written to the row and the stream.close() method has been executed.

If using the Oracle 10g JDBC driver (or greater version), a second solution consists of using the standard JDBC api (setBinaryStream method of java.sql.PreparedStatement interface). And in this case, AutoCommit can be set to true.

Here is an example:

where blobTest is a table defined as the following:

数据库版本：11.2.0

今天在使用rman备份的时候随意的查看了一下等待事件，除了了我们现在系统遇到的IO瓶颈外，还额外的发了enq: TX - row lock contention该等待事件

1：查询当前系统的等待事件

select event,sid,p1,p2,p3 from v$session_wait where event not like 'SQL*%' and event not like 'rdbms%';

EVENT                                   SID         P1              P2             P3
----------------------------------     ----      ----------       ----------    ----------
enq: TX - row lock contention     4    1415053318     196638        55836
RMAN backup & recovery I/O      5            1               256       2147483647
enq: TX - row lock contention    12    1415053318     524293        51153
RMAN backup & recovery I/O     25           1                256      2147483647
db file sequential read             27          16             2876703         1
pmon timer                             33         300                0               0
db file scattered read               39          33              790536         128
VKTM Logical Idle Wait            49           0                   0               0
Streams AQ: qmn slave idle wait         50          1          0          0
asynch descriptor resize           53          1              4294967295    1237
jobq slave wait                       54          0                     0          0

EVENT                                   SID         P1           P2                 P3
-------------------------------------------    -------       ----------          ----------
db file sequential read             170         33         1100519            1
direct path read                      181         44          469892           124
enq: TX - row lock contention    212 1415053318     524293         51153
smon timer                             225        300          0       0
enq: TX - row lock contention    232 1415053318     524293         51153
direct path read                      234         16           1099776         128
Streams AQ: qmn coordinator idle wait  242          0          0         0

上面的等待事件说明session4，12，212，232想加锁，但是有别的session占着，所以等待。

enq是一种保护共享资源的锁定机制，一个排队机制，先进先出(FIFO)

发生TX锁的原因一般有几个

1.不同的session更新或删除同一个记录。

2.唯一索引有重复索引

3.位图索引多次更新

4.同时对同一个数据块更新

5.等待索引块分裂

2：下面我们通过enq: TX - row lock contention来看看这些session都在等什么

select ROW_WAIT_OBJ#,ROW_WAIT_FILE#,ROW_WAIT_BLOCK#,ROW_WAIT_ROW# from v$session where event='enq: TX - row lock contention';

ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#
------------- -------------- --------------- -------------
        87556             57             395            88
        87564             57             435             0
        87564             57             435             0
        87564             57             435             0
        87564             57             435             0

3：通过上面sql查找出来的对象编号找到对应的对象名称

SQL> select object_name from dba_objects where object_id in (87564);

OBJECT_NAME
-----------
QRTZ_LOCKS

4：通过对象名称找出该对象的对应属性，对象属性为TABLE

SQL> select OWNER,OBJECT_NAME,OBJECT_ID,DATA_OBJECT_ID, OBJECT_TYPE from all_objects where object_name='QRTZ_LOCKS';

OWNER      OBJECT_NAME  OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE

SCHEDULE   QRTZ_LOCKS     87564          87564               TABLE 

5：通过正在等待的SID查看它们都在执行什么操作

SQL> select sid,sql_text from v$session a,v$sql b where sid in(4,12,41,212,232) and (b.sql_id=a.sql_id or b.sql_id=a.prev_sql_id);

 SID SQL_TEXT
---- ----------------------------------------------------------------------------------------------------
   4 UPDATE QRTZ_CRON_TRIGGERS SET CRON_EXPRESSION = :1 WHERE TRIGGER_NAME = :2 AND TRIGGER_GROUP = :3
  12 SELECT * FROM QRTZ_LOCKS WHERE LOCK_NAME = :1 FOR UPDATE
  41 SELECT * FROM QRTZ_LOCKS WHERE LOCK_NAME = :1 FOR UPDATE
 212 SELECT * FROM QRTZ_LOCKS WHERE LOCK_NAME = :1 FOR UPDATE
 232 SELECT * FROM QRTZ_LOCKS WHERE LOCK_NAME = :1 FOR UPDATE

从上面的结果可以看出，SCHEDULE用户下的五个session同时在执行一条相同的sql语句，对应的对象则是QRTZ_LOCKS 这个表， 所以发生了锁，从而产生等待，通过和同事的交流，得知这个一个ETL程序要访问的表，里面只有五条数据，但是却要时时调度。  

6：下面我们去找一下对应sid产生的锁

SQL> select SID,TY,ID1,ID2,LMODE,REQUEST,CTIME,BLOCK from V$lock where block=1 or request<>0;
         SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
 ---------------- ---- -- ---------- ---------- ---------- ---------- ---------- ----------
         41  TX     524293      51153          0          6       3846             0
         12  TX     524293      51153          0          6       4190             0
         232 TX     524293      51153          0          6       4626             0
         212 TX     524293      51153          0          6       4749             0
          4  TX     196638      55836          0          6       4755              1
         44  TX     196638      55836          6          0       4765              1

由此可以查看，BLOCK=1的sid是该等待事件的根源，其他session则等待该锁被释放。

解决方法：

1：通过v$session找到BLOCK=1的用户，告知用户提交事务

2：通过sid找到pid，kill掉该进程

3：更改sql语句，SELECT * FROM QRTZ_LOCKS WHERE LOCK_NAME = :1 FOR UPDATE no wait

加nowait的意思是得到或者得不到，不会等待

事件起因：

昨天公司运维说机房的HP服务器磁盘坏了，我当时冷汗一下子就出来了，因为这是测试库，没有备份，没有归档，但是里面可是有1.5T的数据啊，下午他们修了一下午，系统可以进去了，但是数据库在启动到OPEN的时候报错SYSTEM01数据文件缺失一千多个数据块，由于没有备份和归档，所以这个数据库是挂掉了。（DBA们一定要做好备份，否则最后全是自己的事情），幸好我们还有一个一周前的冷备库，所以我直接物理迁移，把数据库恢复到一周以前了，恢复的过程非常简单，因为数据库必须的那些文件路径都已存在（如参数文件内的DUMP文件等），我只是把参数文件，密码文件，控制文件，数据文件恢复到指定的目录，然后直接STARTUP，在nomount和mount阶段都是比较顺利的，而到open阶段的时候，则报错了让我闹心的ORA-600ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr]的错误，因为大家都知道，ORA-600是数据库自己内部的BUG，我也是第一次遇到，问了很多人大家都不会，所以只能自己去摸索解决，值得庆幸的是在摸索了一个小时后，我终于把数据库OPEN了，以下就是我恢复的步骤，如果感觉对您有所帮助，那么请支持我一下。

Incident details in: d:/app/administrator/diag/rdbms/ccxe/ccxe/incident/incdir_2570/ccxe_ora_2164_i2570.trc
Aborting crash recovery due to error 600
Errors in file d:/app/administrator/diag/rdbms/ccxe/ccxe/trace/ccxe_ora_2164.trc:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
Errors in file d:/app/administrator/diag/rdbms/ccxe/ccxe/trace/ccxe_ora_2164.trc:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
ORA-600 signalled during: alter database open...
Tue May 10 10:13:10 2011
Trace dumping is performing id=[cdmp_20110510101310]
Tue May 10 10:13:11 2011
Sweep [inc][2570]: completed
Sweep [inc2][2570]: completed
Tue May 10 10:29:52 2011
Shutting down instance (immediate)
Shutting down instance: further logons disabled

数据库版本：oracle 11.2.0

今天同事需要执行一个拥有大批量运算的存储过程，当执行的时候报错，报错信息如下：

ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 18 with name
"_SYSSMU18_671080725$" too small
ORA-06512: at "TRANUSER.TRAN_ETL_LOAD_J2S_MAIN", line 22
ORA-06512: at "TRANUSER.TRAN_ETL_LOAD_JST_PRE", line 5
ORA-06512: at line 2

--精彩解释

不知道是从哪里转的了, 假设有张表，叫table1，里面有5000万行数据，假设预计全表扫描1次需要1个小时，我们从过程来看： 

1、在1点钟，有个用户A发出了select * from table1;此时不管将来table1怎么变化，正确的结果应该是用户A会看到在1点钟这个时刻的内容。这个是没有疑问的。 
2、在1点30分，有个用户B执行了update命令，更新了table1表中的第4000万行的这条记录，这时，用户A的全表扫描还没有到达第4000万条。毫无疑问，这个时候，第4000万行的这条记录是被写到了回滚段里去了的，我假设是回滚段RBS1，如果用户A的全表扫描到达了第4000万行，是应该会正确的从回滚段RBS1中读取出1点钟时刻的内容的。 
3、这时，用户B将他刚才做的操作commit了，但是这时，系统仍然可以给用户A提供正确的数据，因为那第4000万行记录的内容仍然还在回滚段RBS1里，系统可以根据SCN来到回滚段里找到正确的数据，但是大家注意到，这时记录在RBS1里的第4000万行记录已经发生了一点重大的改变：就是这个第4000万行的在回滚段RBS1里的数据有可能随时被覆盖掉，因为这条记录已经被提交了！！！ 
4、由于用户A的查询时间漫长，而业务在一直不断的进行，RBS1回滚段在被多个不同的tracnsaction使用着，这个回滚段里的extent循环到了第4000万行数据所在的extent，由于这条记录已经被标记提交了，所以这个extent是可以被其他transaction覆盖掉的！ 
5、到了1点40分，用户A的查询终于到了第4000万行，而这时已经出现了第4条说的情况，需要到回滚段RBS1去找数据，但是已经被覆盖掉了，于是01555就出现了。

--错误提示

数据库报错 ORA-01555 什么回滚段 '_SYSSMU168' is too small.很明显 是可用的回滚段太小了 满足不了那个大事物的需要 具体的sql我就不提供了

还有一种可能,一般伴随着ORA-22924出现就是LOB上的问题

辨别ORA-01555是不是发生在LOB上的,一般来说,普通的01555错误会指明发生01555的rollback segment,而LOB的则没有,而是伴随着ORA-22924出现http://www.dbafan.com/blog/?p=11

--回滚原理

回退段中存放的信息被称为“前照”(pre-image)，也就是说当一个进程对某个表进行了DML操作以后，
更改前的纪录信息被存放于回滚段，其作用有两个：

1、当进程要求回滚（ROLLBACK）的时候，使用回滚段中信息是纪录复原；

2、保持数据读的一致性，当一个进程从某个表中读纪录的时候，ORACLE返回的是当读开始或者进程开始时的纪录，如果在读取过程中有其他进程更改了表纪录，ORACLE就会从回滚段中读取当读操作开始时的数据。回滚段中信息并不是持久有效的，当进程提交（COMMIT）或者回滚（ROLLBACK）的时候，回滚段就被释放了。当一个进程在执行一个大查询的时候，如果在查询的过程中所读取得的表被更改而且更改COMMIT太久，那回滚段中的“前照”就有可能会被其他的进程覆盖，从而导致ORA-01555错误。

--解决方法

1、增加回滚段的大小，因为ORACLE总是覆盖最旧的回滚段，所以大的回滚段能有效的降低数据被覆盖的可能性。
2、检查你的程序，避免在一个大查询的过程中对所查询的表执行太多更新操作。

下面回顾下关于ora-01555的解决方法 10g默认是使用AUM 这里就不说了. 下面是几个解决方式来自hellodba 总结的很不错 大家可用参考下：

1、扩大回滚段: 因为回滚段是循环使用的，如果回滚段足够大，那么那些被提交的数据信息就能保存足够长的时间是那些大事务完成一致性读取。

2、增加undo_retention时间:在undo_retention规定的时间内，任何其他事务都不能覆盖这些数据。

3、优化相关查询语句，减少一致性读:减少查询语句的一致性读，就降低读取不到回滚段数据的风险。这一点非常重要！

4、减少不必要的事务提交:提交的事务越少，产生的回滚段信息就越少。

5、对大事务指定回滚段,通过以下语句可以指定事务的回滚段：SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment; 给大事务指定回滚段，即降低大事务回滚信息覆盖其他事务的回滚信息的几率，又降低了他自身的回滚信息被覆盖的几率。大事务的存在，往往是1555错误产生的诱因。

6、使用游标时尽量使用显式游标，并且只在需要的时候打开游标，同时将所有可以在游标外做的操作从游标循环中拿出。当游标打开时，查询就开始了，直到游标关闭。减少游标的打开时间，就减少了1555错误发生的几率。http://hi.baidu.com/xu521huan/blog/item/0903ec9b62d85ebec8eaf442.html

--一些实例

我的回答是先看看到底是哪个SQL有这个问题，再确定不是因为SQL本身太糟糕导致SNAPSHOT TOO OLD。再跟他们说我不相信把UNDO_RETENTION加大会有效地解决问题。最后给几个CASES来支持我的观点。
(1)reduce the frequency of commit
(2)set initialization paramter undo_retention(9i)
(3)alter system set retention guarrantee (10g)
(4)increase the size of the undo tablespace
(5)assign a large rollback segment for the large transaction
(6)tuning the long run sql
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the root cause of the error ora-01555:the long run query can not find a consistent image, because the undo blocks that used to construct the consistent image were wrapped by other active transaction.

遇到这个问题，首先可以看是维护需要执行的SQL或者应用执行的SQL报的

1、如果平时不报，只是维护人员执行的SQL报的，一般是SQL写得不好，运行执行过长，超过了参数 redo_retention所设置的时间造成的。这种情况可以协助他们进行SQL分析和优化，减少运行时间，这个情况下系统不需要对系统进行调整

2、如果是应用程序报的，比如批量程序，则需要通知相关人员进行重做，否则批量运行失败，业务可能会因为数据遗漏出现问题。如果出现的频率较多，则需要在优化应用程序（优化的手段有SQL优化、适当增加commit的次数等）。在应用新版本上线前，可通过调整系统配置临时解决问题方法如：

1）增大undo表空间

2）增大redo_retention

3)为此大事物指定专门的undo 段

http://www.itpub.net/viewthread.php?tid=1021888&extra=&highlight=DBA%C3%E6%CA%D4&page=3

新鲜出炉的案例：APPS的人下午回馈说今天一个DB的JOB一直报SNAPSHOT TOO OLD。这是过去几个月这个数据库第一次有这种回馈。到ALERT LOG中看看，有好多这种ERROR：Wed Jul 16 10:30:44 2008 ORA-01555 caused by SQL statement below (Query Duration=884 sec, SCN: 0x0018.bef62785):Wed Jul 16 10:30:44 2008

Wed Jul 16 10:57:29 2008 ORA-01555 caused by SQL statement below (Query Duration=149 sec, SCN: 0x0018.bf0d3e47):Wed Jul 16 10:57:29 2008

嗯，884S，149S，不可能吧？看看UNDO SETTINGS，很大啊：

SQL> show parameter undo
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     10800
undo_suppress_errors                 boolean     FALSE
undo_tablespace                      string      UNDOTBS2

SQL> select sum(bytes)/(1024*1024*1024) as gbytes from dba_data_files;
    GBYTES
----------
300.654297

SQL> select sum(bytes)/(1024*1024*1024) as gbytes from dba_data_files where tablespace_name='UNDOTBS2';
    GBYTES
----------
  9.765625

自己试试：
create table mytab as <the select statement> where 1=0
16:12:14 SQL> insert into mytab <the select statement>
insert into mytab
            *

ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 27 with name "_SYSSMU27$"
too small
Elapsed: 00:10:08.83
奇怪了。看看今天这个UNTOTBS2 UTILIZATION怎样。

SQL> select snap_time, free_mb from tbs_usage_hist where database='<DB Name>' and tbs='UNDOTBS2' and snap_time>sysdate-1 order by snap_time;
SNAP_TIME              FREE_MB
------------------- ----------
2008-07-15 18:00:00    9172.56
2008-07-15 19:00:00    9172.56
2008-07-15 20:00:00    9156.56
2008-07-15 21:00:00    9188.56
2008-07-15 22:00:00    9204.56
2008-07-15 23:00:00    9212.56
2008-07-16 00:00:00    9228.56
2008-07-16 01:00:00    9228.56
2008-07-16 02:00:00    9236.56
2008-07-16 03:00:00    9228.56
2008-07-16 04:00:00    9252.56
2008-07-16 05:00:00    9252.56
2008-07-16 06:00:00    9252.56
2008-07-16 07:00:00    9260.56
2008-07-16 08:00:00    9244.56
2008-07-16 09:00:00    8486.56
2008-07-16 10:00:00    1683.56
2008-07-16 11:00:00       2.31
2008-07-16 12:00:00       1.94
2008-07-16 13:00:00       2.44
2008-07-16 14:00:00       2.44
2008-07-16 15:00:00       1.25
2008-07-16 16:00:00      17.75

那 问题应当是很明了了，自今天十点多UNDOTBS2一直是HIGHLY UTILIZED。打个电话给APP OWNER，原来他今天早上十点左右做了一个很大的DELETE。即然这个报错的APP只要在二十四小时内能再执行完就可以，而OLTP APP没报错，那就再等等吧。在四点半时，UNDOTBS2就差不多是85% FREE。再试试：
16:37:49 SQL> insert into mytab <the select statement>
182 rows created.
Elapsed: 00:34:47.39
17:12:37 SQL>
现在的UNDOTBS2 UTILIZATION：
SNAP_TIME              FREE_MB
------------------- ----------
2008-07-16 17:00:00    8523.63
问题解决。SNAPSHOT TOO OLD从来就不是一个过时的题目,也没有一个简单的答案。

决ORA--27100 shared memory realm already exists报错

html xml
<!-- TODO mytask -->
jsp 
<%-- TODO mytask -->
java javascript
//TODO mytask
CSS
/*TODO mytask */



打开 
(Window->Preferences) 
选择 
General->Editors->Structured Text Edit->Task Tags.
勾选 
"Enable searching for Task Tags" setting. 
在“Filters”标签页中，要保证JSP是选中的。

在任务视图里面可以看到任务的状态。

在发布项目之前，需要管伫一下这个视图防止有未完成的任务就发布了项目。

Uploader.java
2、把这个文件放到src/ueditor包里面
3、把ueditor/jsp/目录下面的两个jar包放到工程里面
4 重新编译项目ok,可以上传附件,图片了!

有点小高兴

解决办法如下：

方法一:   环境: windows 2003 server + SP1企业VOL版 域控环境
安装数据库: SQL 2000

在给出的输入CDKEY的界面中，输入你已经安装的windows server 2003 的CDKEY即可以继续安装，而不是SQL 2000的CDKEY。

方法二: 在开始>运行>输入“regedit"; 打开注册表编辑器。
浏览到
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

将SafeDLLSearchMode的DWORD值并将值从 1 更改为 0。
如果SafeDLLSearchMode值不存在, 新建一个DWORD类型的SafeDLLSearchMode键值。
重新启动 SQL Server 2000 安装，这时就不会出现提示“无法验证产品密钥”。
应用最新 SQL ServicePack 然后重新启动服务器。

在RHEL6.1中，gonme桌面包的名字变成了Desktop，这算是RHEL6.1默认的桌面了。但如果只安装这个组的话，也是不行的，他缺少了X协议的支持，在启动桌面的时候，会出现下面和X相关的错误提示。

xinit: No such file or directory (errno 2): no server "/usr/bin/X" in PATH xinit: No such file or directory (errno 2): unable to connect to X server xinit: No such process (errno 3): Server error.
所以说，要在字符界面下安装Gnome桌面，你需要安装两个组。

yum groupinstall "X Window System" yum groupinstall "Desktop"

如果说，你安装系统的时候，选择了中文语言包的支持的话，那么系统会以中文显示。如果在终端使用的话，有点不方便，告别是用yum group*这些命令的时候，可能无法安装。

解决的办法就是编辑

/etc/sysconfig/i18n

把zh_CN换成en_US LANG="en_US.UTF-8" 然后执行一次下面的命令 source /etc/sysconfig/i18n

最早的一次使用oracle 11g导出数据发现有的表丢失了，感觉莫名其妙的，后来终于找到原因了。
找到问题以后，再看看解决方案。

11GR2中有个新特性，当表无数据时，不分配segment，以节省空间，可是在用EXPORT导出时，空表也不能导出，这就导致迁移时候丢失了一些表，存储过程也失效了。本以为EXP能有相应的控制开关，可以切换是否导出空表，看了下帮助，没有太大的改变。有些奇怪，难道11GR2不更新EXP的功能了，还看有的帖子说11GR1作为客户端去卸载11GR2的，都会出现ora-1455d的错误，得换成11GR2的exp才没事了，心中感慨阿，怎么版本间的兼容这么脆弱了！

　　解决方法：

一、 insert一行，再rollback就产生segment了。

　　该方法是在在空表中插入数据，再删除，则产生segment。导出时则可导出空表。

二、 设置deferred_segment_creation参数

该参数值默认是TRUE，当改为FALSE时，无论是空表还是非空表，都分配segment。修改SQL语句：

alter system set deferred_segment_creation=false scope=both;

　　需注意的是：该值设置后对以前导入的空表不产生作用，仍不能导出，只能对后面新增的表产生作用。如需导出之前的空表，只能用第一种方法。

三、 用以下这句查找空表并分配空间

　　select 'alter table '||table_name||' allocate extent;' from user_tables where num_rows=0;

　　把SQL查询的结果导出，然后执行导出的语句，强行为表分配空间修改segment值，然后再导出即可导出空表了。