Oracle Life http://www.eygle.com/blog/ Eygle 的Oracle Blog，提供Oracle技术研究及深入探讨，同时记录个人爱好及生活历程。 en Copyright 2012 format_name= http://www.sixapart.com/movabletype/ http://blogs.law.harvard.edu/tech/rss eygle@eygle.com hourly 1 2007-01-01T12:00+00:00 -------------------------------------------------------------------------------- 2012 龙年新年记事 暧暧远人村，依依墟里烟 http://www.eygle.com/archives/2012/01/2012_newyear_record.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2012/01/2012_newyear_record.html 作者：eygle 发布在 eygle.com

2012的新年在东北老家，第一次开车回东北。记录一下这个龙年的片段，祝大家新年快乐。

1.大年29开车回东北，高速上的车很少很少，非常顺利。高速路上，河北段全部免费，吉林段不仅免费，最后还有小的新年礼物赠送，喜庆且人性化，需要表扬。

2.路过唐山时，跟儿子说这里曾经大地震，那时候爸爸还没有出生。儿子说，爸爸你是不是害怕不敢生出来。

3.今年过年，老家（吉林-四平-公主岭）一点雪也没有下，空有严寒，未有雪意，遗憾，而今年的雨雪又转移到南方去下了。年后东北如果不降雪，则明年农作物将受到影响了。

4.看以前的照片，儿子总是问，你有没有带我去过？我们说没有，你还没有出生。问多了小家伙怒了，说:哼，你们总是说我没有出生。

5.春晚，没有了赵本山，东北乡亲普遍反映没有了期待，还好有李玉刚，还是正宗的公主岭老乡。

6.铁道部的"厨师修铁路"事件影响深远，间接的影响到了朋友的施工队伍，铁路建设项目错综复杂。

7.食品安全问题的重视已经到达老家，市里在组建新的食品安全监察大队，希望全国都能从生产基层开始重视食品安全问题。

8.回京途中，很多车遮挡号牌，超速驾驶，在辽宁亲眼见到一辆车在休息站被警察抓获，予以处罚，开车安全第一，还是不要超速的好。

9.暧暧远人村，依依墟里烟
YanVillege.jpg

10.儿子眼中的玉米大炮
20120123_110704.jpg


相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Life Year Sun, 29 Jan 2012 09:01:27 +0800 -------------------------------------------------------------------------------- 《Oracle DBA手记》以及51CTO 年度图书作者 从出版社获得的消息，在51CTO的年度评选中，再次被评选为年度最受读者喜爱的作者奖。 感谢 51CTO 网站多年以来坚持不懈的图书评选工作，这一评选对于支持图书原创、图书写作来说，具有相当的影响力和支持作用。 感谢出版社，也感谢读者们的支持和厚爱，谢谢，祝大家龙年快乐！ http://www.eygle.com/archives/2012/01/oracle_dba_51cto_2011.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2012/01/oracle_dba_51cto_2011.html 作者：eygle 发布在 eygle.com

从出版社获得的消息，在51CTO的年度评选中，再次被评选为年度最受读者喜爱的作者奖。

感谢 51CTO 网站多年以来坚持不懈的图书评选工作，这一评选对于支持图书原创、图书写作来说，具有相当的影响力和支持作用。

感谢出版社，也感谢读者们的支持和厚爱，谢谢，祝大家龙年快乐！

51CTO2011.jpg

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Books 51cto Thu, 19 Jan 2012 23:50:47 +0800 -------------------------------------------------------------------------------- SCSI读写错误导致文件系统只读的数据库恢复 假期马上来到，一个客户数据库出现问题。两个实例异常终止，文件系统变成只读,数据库无法启动。 http://www.eygle.com/archives/2012/01/scsi_error_crash_database.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2012/01/scsi_error_crash_database.html 作者：eygle 发布在 eygle.com

假期马上来到，一个客户数据库出现问题。

两个实例异常终止，文件系统变成只读：
PCLERPDB2:[10g]:/DBMS/PCMK/admin/PCMK> sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on Thu Jan 19 09:08:05 2012

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

ERROR:
ORA-09925: Unable to create audit trail file
Linux Error: 30: Read-only file system
Additional information: 9925
ORA-01075: you are currently logged on
检查系统日志，发现早晨出现SCSI IO错误：
Jan 19 07:56:00 PCLERPDB2 kernel: SCSI error : <0 0 0 1> return code = 0x10000
Jan 19 07:56:00 PCLERPDB2 kernel: end_request: I/O error, dev sda, sector 26480696
Jan 19 07:56:00 PCLERPDB2 kernel: Buffer I/O error on device sda1, logical block 3310083
Jan 19 07:56:00 PCLERPDB2 kernel: lost page write due to I/O error on sda1
Jan 19 07:56:00 PCLERPDB2 kernel: SCSI error : <0 0 0 9> return code = 0x10000
Jan 19 07:56:00 PCLERPDB2 kernel: end_request: I/O error, dev sdh, sector 60052680
Jan 19 07:56:00 PCLERPDB2 kernel: SCSI error : <0 0 0 4> return code = 0x10000
Jan 19 07:56:00 PCLERPDB2 kernel: end_request: I/O error, dev sdc, sector 20042688
Jan 19 07:56:00 PCLERPDB2 kernel: SCSI error : <0 0 0 9> return code = 0x10000
Jan 19 07:56:00 PCLERPDB2 kernel: end_request: I/O error, dev sdh, sector 26747408
Jan 19 07:56:00 PCLERPDB2 kernel: Buffer I/O error on device sdh2, logical block 843074
Jan 19 07:56:00 PCLERPDB2 kernel: lost page write due to I/O error on sdh2
Jan 19 07:56:00 PCLERPDB2 kernel: SCSI error : <0 0 0 1> return code = 0x10000
Jan 19 07:56:00 PCLERPDB2 kernel: end_request: I/O error, dev sda, sector 32606944
Jan 19 07:56:00 PCLERPDB2 kernel: Buffer I/O error on device sda1, logical block 4075864
然后数据库崩溃.

安排用户重启数据库主机，检查是否硬件软故障。
很幸运，重启后数据库能够正常启动：
Thu Jan 19 09:55:09 2012
Completed redo application
Thu Jan 19 09:55:09 2012
Completed crash recovery at
 Thread 1: logseq 18735, block 5214, scn 5965501404211
 59 data blocks read, 59 data blocks written, 609 redo blocks read
Thu Jan 19 09:55:09 2012
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=23, OS id=14599
Thu Jan 19 09:55:09 2012
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=24, OS id=14601
Thu Jan 19 09:55:09 2012
Thread 1 advanced to log sequence 18736
Thread 1 opened at log sequence 18736
  Current log# 3 seq# 18736 mem# 0: /DBMS/DCERP/dcerpdata/log03a.dbf
  Current log# 3 seq# 18736 mem# 1: /DBMS/DCERP/dcerpdata/log03b.dbf
Successful open of redo thread 1
Thu Jan 19 09:55:09 2012
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Jan 19 09:55:09 2012
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Thu Jan 19 09:55:09 2012
ARC1: Becoming the heartbeat ARCH
Thu Jan 19 09:55:09 2012
SMON: enabling cache recovery
Thu Jan 19 09:55:11 2012
Successfully onlined Undo Tablespace 368.
Thu Jan 19 09:55:11 2012
SMON: enabling tx recovery
Thu Jan 19 09:55:11 2012
Database Characterset is UTF8
Thu Jan 19 09:55:11 2012
Incremental checkpoint up to RBA [0x4930.3.0], current log tail at RBA [0x4930.43.0]
Thu Jan 19 09:55:11 2012
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=25, OS id=14626
Thu Jan 19 09:55:25 2012
Completed: ALTER DATABASE OPEN
Thu Jan 19 10:15:13 2012
Incremental checkpoint up to RBA [0x4930.100d.0], current log tail at RBA [0x4930.107d.0]
Thu Jan 19 10:35:16 2012
Incremental checkpoint up to RBA [0x4930.150f.0], current log tail at RBA [0x4930.155b.0]
Thu Jan 19 10:55:17 2012
Incremental checkpoint up to RBA [0x4930.1724.0], current log tail at RBA [0x4930.175a.0]
Thu Jan 19 11:15:18 2012
Incremental checkpoint up to RBA [0x4930.1edf.0], current log tail at RBA [0x4930.1f13.0]

估计硬件的生命周期达到，需要更新了。



相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Case Case Thu, 19 Jan 2012 09:18:47 +0800 -------------------------------------------------------------------------------- ACOUG 2012年2月 Ask Tom and Eygle - 上海 ACOUG在2012年的首次活动将来到上海，重量级的嘉宾是Thomas Kyte，ASKTOM 网站背后的老大，Oracle的副总裁。 http://www.eygle.com/archives/2012/01/acoug_20122_asktom.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2012/01/acoug_20122_asktom.html 作者：eygle 发布在 eygle.com

ACOUG在2012年的首次活动将来到上海，重量级的嘉宾是Thomas Kyte，ASKTOM 网站背后的老大，Oracle的副总裁。

在这个活动中，我还有一个主题演讲，大家有兴趣的请尽快报名：
http://www.acoug.org/events/239.html

具体信息请关注 ACOUG 微博：
http://weibo.com/acoug


TomEygle.jpg

相关文章|Related Articles

评论数量(2)|Add Comments

本文网址：

]]> Activity acoug Wed, 18 Jan 2012 09:47:32 +0800 -------------------------------------------------------------------------------- TNS-00583 错误解决案例一则 今天删除了本机安装的Oracle 11g数据库，使用drop database命令 http://www.eygle.com/archives/2012/01/tns-00583.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2012/01/tns-00583.html 作者：eygle 发布在 eygle.com

今天删除了本机安装的Oracle 11g数据库，使用drop database命令：
SQL> startup restrict;
ORACLE instance started.

Total System Global Area  535662592 bytes
Fixed Size                  1384752 bytes
Variable Size             268439248 bytes
Database Buffers          260046848 bytes
Redo Buffers                5791744 bytes
Database mounted.
Database opened.
SQL> drop database;
drop database
*
ERROR at line 1:
ORA-01586: database must be mounted EXCLUSIVE and not open for this operation


SQL> alter database close;

Database altered.

SQL> drop database;

Database dropped.

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> connect / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file 'D:\ORACLE\11.2.0\DATABASE\INITORA11G.ORA'
SQL> exit
Disconnected
启动数据库出现了TNS-00583错误：

E:\>lsnrctl start

LSNRCTL for 32-bit Windows: Version 11.2.0.2.0 - Production on 12-JAN-2012 17:07:56

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting tnslsnr: please wait...

TNSLSNR for 32-bit Windows: Version 11.2.0.2.0 - Production
System parameter file is D:\Oracle\11.2.0\network\admin\listener.ora
Log messages written to D:\Oracle\diag\tnslsnr\oracle-vm\listener\alert\log.xml
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=1521)))
TNS-12560: TNS:protocol adapter error
 TNS-00583: Valid node checking: unable to parse configuration parameters


Listener failed to start. See the error message(s) above...
检查发现，是SQLNET.ORA 文件中的Wallet参数配置影响，删除该参数后监听器恢复正常：
ENCRYPTION_WALLET_LOCATION=
  (SOURCE=(METHOD=FILE)(METHOD_DATA=
    (DIRECTORY=D:\Oracle\11.2.0\NETWORK\ADMIN\encryption_wallet\)))
监听程序启动正常：
E:\>lsnrctl start

LSNRCTL for 32-bit Windows: Version 11.2.0.2.0 - Production on 12-JAN-2012 17:09:27

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting tnslsnr: please wait...

TNSLSNR for 32-bit Windows: Version 11.2.0.2.0 - Production
System parameter file is D:\Oracle\11.2.0\network\admin\listener.ora
Log messages written to D:\Oracle\diag\tnslsnr\oracle-vm\listener\alert\log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for 32-bit Windows: Version 11.2.0.2.0 - Production
Start Date                12-JAN-2012 17:09:30
Uptime                    0 days 0 hr. 0 min. 3 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   D:\Oracle\11.2.0\network\admin\listener.ora
Listener Log File         D:\Oracle\diag\tnslsnr\oracle-vm\listener\alert\log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
Services Summary...
Service "ora11g" has 1 instance(s).
  Instance "ora11g", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Case oerror TNS Thu, 12 Jan 2012 17:19:50 +0800 -------------------------------------------------------------------------------- Mysql数据库 当前连接用户及会话查询 在Mysql中，可以通过如下方式查询Mysql数据库当前连接的用户及会话信息 http://www.eygle.com/archives/2012/01/mysql_processlist.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2012/01/mysql_processlist.html 作者：eygle 发布在 eygle.com

在Mysql中，可以通过如下方式查询Mysql数据库当前连接的用户及会话信息：
1. show full processlist
mysql> show full processlist;
+----------+-----------+--------------------+-------------+---------+------+-------+-----------------------+
| Id       | User      | Host               | db          | Command | Time | State | Info                  |
+----------+-----------+--------------------+-------------+---------+------+-------+-----------------------+
| 26321235 | root      | localhost          | socialciv   | Sleep   |    3 |       | NULL                  |
| 26322405 | root      | localhost          | NULL        | Query   |    0 | NULL  | show full processlist |
| 26322588 | dmadbuser | 192.168.0.51:51395 | user_silo_0 | Sleep   |    0 |       | NULL                  |
| 26322621 | dmadbuser | 192.168.0.51:51400 | soooalciv   | Sleep   |    0 |       | NULL                  |
| 26322645 | dmadbuser | 192.168.0.51:51433 | user_silo_2 | Sleep   |    0 |       | NULL                  |
| 26322646 | dmadbuser | 192.168.0.52:42308 | user_silo_1 | Sleep   |    1 |       | NULL                  |
| 26322648 | dmadbuser | 192.168.0.51:51439 | user_silo_0 | Sleep   |    0 |       | NULL                  |
| 26322650 | dmadbuser | 192.168.0.51:51442 | user_silo_1 | Sleep   |    0 |       | NULL                  |
| 26322659 | dmadbuser | 192.168.0.51:51454 | user_silo_1 | Sleep   |    1 |       | NULL                  |
| 26322667 | dmadbuser | 192.168.0.51:51469 | soooalciv   | Sleep   |    0 |       | NULL                  |
| 26322671 | dmadbuser | 192.168.0.51:51475 | user_silo_0 | Sleep   |    0 |       | NULL                  |
| 26322674 | dmadbuser | 192.168.0.51:51481 | user_silo_1 | Sleep   |    0 |       | NULL                  |
| 26322677 | dmadbuser | 192.168.0.51:51485 | user_silo_1 | Sleep   |    0 |       | NULL                  |
| 26322678 | dmadbuser | 192.168.0.52:42356 | user_silo_2 | Sleep   |    0 |       | NULL                  |
| 26322679 | dmadbuser | 192.168.0.51:51486 | user_silo_0 | Sleep   |    0 |       | NULL                  |
| 26322680 | dmadbuser | 192.168.0.51:51487 | user_silo_1 | Sleep   |    0 |       | NULL                  |
| 26322681 | dmadbuser | 192.168.0.52:42359 | user_silo_2 | Sleep   |    0 |       | NULL                  |
| 26322684 | dmadbuser | 192.168.0.51:51493 | user_silo_2 | Sleep   |    0 |       | NULL                  |
| 26322685 | dmadbuser | 192.168.0.52:42367 | user_silo_1 | Sleep   |    0 |       | NULL                  |
| 26322688 | dmadbuser | 192.168.0.51:51500 | user_silo_2 | Sleep   |    0 |       | NULL                  |
| 26322689 | dmadbuser | 192.168.0.52:42368 | user_silo_0 | Sleep   |    0 |       | NULL                  |
| 26322690 | dmadbuser | 192.168.0.52:42371 | user_silo_1 | Sleep   |    0 |       | NULL                  |
+----------+-----------+--------------------+-------------+---------+------+-------+-----------------------+

2. mysqladmin -uroot -p -hlocalhost processlist
-bash-3.2$ mysqladmin -uroot -p -hlocalhost processlist
Enter password:
+----------+-----------+--------------------+-------------+---------+------+-------+------------------+
| Id       | User      | Host               | db          | Command | Time | State | Info             |
+----------+-----------+--------------------+-------------+---------+------+-------+------------------+
| 26309321 | dmadbuser | 192.168.0.53:33532 | soooalciv   | Sleep   | 2    |       |                  |
| 26309374 | dmadbuser | 192.168.0.53:33611 | soooalciv   | Sleep   | 2    |       |                  |
| 26309387 | dmadbuser | 192.168.0.53:33631 | user_silo_1 | Sleep   | 3    |       |                  |
| 26309390 | dmadbuser | 192.168.0.53:33636 | user_silo_1 | Sleep   | 0    |       |                  |
| 26309393 | dmadbuser | 192.168.0.53:33639 | user_silo_0 | Sleep   | 0    |       |                  |
| 26309419 | dmadbuser | 192.168.0.53:33677 | user_silo_2 | Sleep   | 2    |       |                  |
| 26309420 | dmadbuser | 192.168.0.53:33679 | user_silo_2 | Sleep   | 0    |       |                  |
| 26309424 | dmadbuser | 192.168.0.53:33685 | user_silo_1 | Sleep   | 2    |       |                  |
| 26309442 | dmadbuser | 192.168.0.51:33589 | user_silo_1 | Sleep   | 1    |       |                  |
| 26309445 | dmadbuser | 192.168.0.53:33723 | user_silo_0 | Sleep   | 1    |       |                  |
| 26309457 | dmadbuser | 192.168.0.51:33612 | user_silo_2 | Sleep   | 1    |       |                  |
| 26309459 | dmadbuser | 192.168.0.53:33745 | user_silo_1 | Sleep   | 1    |       |                  |
| 26309469 | dmadbuser | 192.168.0.53:33759 | user_silo_2 | Sleep   | 0    |       |                  |
| 26309470 | dmadbuser | 192.168.0.53:33760 | user_silo_2 | Sleep   | 0    |       |                  |
| 26309471 | dmadbuser | 192.168.0.51:33632 | user_silo_2 | Sleep   | 0    |       |                  |
| 26309472 | dmadbuser | 192.168.0.53:33763 | user_silo_2 | Sleep   | 0    |       |                  |
| 26309473 | root      | localhost          |             | Query   | 0    |       | show processlist |
+----------+-----------+--------------------+-------------+---------+------+-------+------------------+
max_connections 参数可以用于控制数据库的最大连接数：

mysql> show variables like '%connect%';
+--------------------------+-------------------+
| Variable_name            | Value             |
+--------------------------+-------------------+
| character_set_connection | latin1            |
| collation_connection     | latin1_swedish_ci |
| connect_timeout          | 10                |
| init_connect             |                   |
| max_connect_errors       | 10                |
| max_connections          | 4000              |
| max_user_connections     | 0                 |
+--------------------------+-------------------+

以下命令用于查询Mysql数据库的状态信息：
mysqladmin  -uroot -p -hlocalhost status

-bash-3.2$ mysqladmin  -uroot -p -hlocalhost status
Enter password:
Uptime: 540120  Threads: 21  Questions: 306833244  Slow queries: 37  Opens: 320214  Flush tables: 19  Open tables: 64  Queries per second avg: 568.083

供参考。

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Web Mysql Tue, 10 Jan 2012 08:02:02 +0800 -------------------------------------------------------------------------------- Mysql数据库 mysql-bin 日志的管理与维护 在Mysql中，如果启用mysql-bin日志记录，则Mysql的变更修改都会被记录到日志文件中 http://www.eygle.com/archives/2012/01/mysql_mysql_bin.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2012/01/mysql_mysql_bin.html 作者：eygle 发布在 eygle.com

在Mysql中，如果启用mysql-bin日志记录，则Mysql的变更修改都会被记录到日志文件中：
mysql> show global variables like '%bin%';
+---------------------------------+----------------------+
| Variable_name                   | Value                |
+---------------------------------+----------------------+
| binlog_cache_size               | 32768                |
| innodb_locks_unsafe_for_binlog  | OFF                  |
| log_bin                         | ON                   |
| log_bin_trust_function_creators | OFF                  |
| max_binlog_cache_size           | 18446744073709547520 |
| max_binlog_size                 | 104857600            |
| sync_binlog                     | 0                    |
+---------------------------------+----------------------+
7 rows in set (0.00 sec)
如果使用了配置文件，则可以修改 /etc/my.cnf 把里面的log-bin这一行注释掉，重启mysql服务即可关闭bin日志的记录。

一个客户的数据库，积累了大量的bin日志：
mysql> show binary logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000064 |   3175623 |
| mysql-bin.000065 | 104857696 |
| mysql-bin.000066 |  30124812 |
| mysql-bin.000067 | 104857882 |
| mysql-bin.000068 | 104857829 |
| mysql-bin.000069 | 104857910 |
| mysql-bin.000070 |  29627738 |
| mysql-bin.000071 | 104857777 |
| mysql-bin.000072 | 104857857 |
| mysql-bin.000073 | 104857728 |
| mysql-bin.000074 | 104857739 |
| mysql-bin.000075 | 104857775 |
| mysql-bin.000076 | 104857686 |
| mysql-bin.000077 | 104857875 |
| mysql-bin.000078 | 104857927 |
| mysql-bin.000079 | 104857827 |
| mysql-bin.000080 | 104857856 |
| mysql-bin.000081 | 104857762 |
| mysql-bin.000082 | 104857797 |
| mysql-bin.000083 | 104857860 |
| mysql-bin.000084 | 104857751 |
| mysql-bin.000085 | 104857925 |
| mysql-bin.000086 | 104857791 |
| mysql-bin.000087 | 104857838 |
| mysql-bin.000088 | 104857749 |
| mysql-bin.000089 | 104857836 |
| mysql-bin.000090 | 104857988 |
| mysql-bin.000091 | 104857807 |
| mysql-bin.000092 | 104857691 |
| mysql-bin.000093 | 104857834 |
| mysql-bin.000094 | 104857647 |
| mysql-bin.000095 | 104857814 |
| mysql-bin.000096 | 104857830 |
| mysql-bin.000097 | 104858049 |
| mysql-bin.000098 | 104857862 |
| mysql-bin.000099 | 104858089 |
| mysql-bin.000100 | 104857760 |
| mysql-bin.000101 | 104857650 |
| mysql-bin.000102 | 104857794 |
| mysql-bin.000103 | 104857656 |
| mysql-bin.000104 | 104857961 |
| mysql-bin.000105 | 104857725 |
| mysql-bin.000106 | 104857804 |
| mysql-bin.000107 | 104857925 |
| mysql-bin.000108 | 104857717 |
| mysql-bin.000109 | 104857678 |
| mysql-bin.000110 | 104857675 |
| mysql-bin.000111 | 104857897 |
| mysql-bin.000112 | 104857947 |
| mysql-bin.000113 | 104857651 |
| mysql-bin.000114 | 104858066 |
| mysql-bin.000115 | 104857766 |
| mysql-bin.000116 | 104857719 |
| mysql-bin.000117 | 104857732 |
| mysql-bin.000118 | 104857733 |
| mysql-bin.000119 | 104857814 |
| mysql-bin.000120 | 104857763 |
| mysql-bin.000121 | 104857680 |
| mysql-bin.000122 | 104857742 |
| mysql-bin.000123 | 104858011 |
| mysql-bin.000124 | 104857708 |
| mysql-bin.000125 | 104857821 |
| mysql-bin.000126 | 104857877 |
| mysql-bin.000127 | 104857735 |
| mysql-bin.000128 | 104857781 |
| mysql-bin.000129 | 104857743 |
| mysql-bin.000130 | 104857858 |
| mysql-bin.000131 | 104857860 |
| mysql-bin.000132 | 104857809 |
| mysql-bin.000133 | 104857711 |
| mysql-bin.000134 | 104857744 |
| mysql-bin.000135 | 104857802 |
| mysql-bin.000136 | 104857672 |
| mysql-bin.000137 | 104857933 |
| mysql-bin.000138 | 104857758 |
| mysql-bin.000139 | 104857657 |
| mysql-bin.000140 | 104857664 |
| mysql-bin.000141 | 104857715 |
| mysql-bin.000142 | 104857881 |
| mysql-bin.000143 | 104857958 |
| mysql-bin.000144 | 104857917 |
| mysql-bin.000145 | 104857771 |
| mysql-bin.000146 | 104857731 |
| mysql-bin.000147 | 104857770 |
| mysql-bin.000148 | 104857864 |
| mysql-bin.000149 | 104857726 |
| mysql-bin.000150 | 104857885 |
| mysql-bin.000151 | 104857817 |
| mysql-bin.000152 | 104857909 |
| mysql-bin.000153 | 104857665 |
| mysql-bin.000154 | 104857647 |
| mysql-bin.000155 | 104857880 |
| mysql-bin.000156 | 104858010 |
| mysql-bin.000157 | 104857821 |
| mysql-bin.000158 | 104857649 |
| mysql-bin.000159 | 104857930 |
| mysql-bin.000160 | 104857856 |
| mysql-bin.000161 | 104857673 |
| mysql-bin.000162 | 104857969 |
| mysql-bin.000163 | 104857848 |
| mysql-bin.000164 | 104857656 |
| mysql-bin.000165 | 104857721 |
| mysql-bin.000166 | 104857758 |
| mysql-bin.000167 | 104857934 |
| mysql-bin.000168 | 104857753 |
| mysql-bin.000169 | 104857833 |
| mysql-bin.000170 | 104858059 |
| mysql-bin.000171 | 104857766 |
| mysql-bin.000172 | 104857865 |
| mysql-bin.000173 | 104857741 |
| mysql-bin.000174 | 104857922 |
| mysql-bin.000175 | 104857776 |
| mysql-bin.000176 | 104857720 |
| mysql-bin.000177 | 104857647 |
| mysql-bin.000178 | 104857977 |
| mysql-bin.000179 | 104857736 |
| mysql-bin.000180 | 104857725 |
| mysql-bin.000181 | 104857883 |
| mysql-bin.000182 | 104857810 |
| mysql-bin.000183 | 104857707 |
| mysql-bin.000184 | 104857799 |
| mysql-bin.000185 | 104857977 |
| mysql-bin.000186 | 104857804 |
| mysql-bin.000187 | 104857861 |
| mysql-bin.000188 | 104857665 |
| mysql-bin.000189 | 104857872 |
| mysql-bin.000190 | 104857870 |
| mysql-bin.000191 | 104857891 |
| mysql-bin.000192 | 104857742 |
| mysql-bin.000193 | 104857830 |
| mysql-bin.000194 | 104857873 |
| mysql-bin.000195 | 104857750 |
| mysql-bin.000196 | 104857669 |
| mysql-bin.000197 | 104857867 |
| mysql-bin.000198 | 104857702 |
| mysql-bin.000199 | 104857974 |
| mysql-bin.000200 | 104857866 |
| mysql-bin.000201 | 104857742 |
| mysql-bin.000202 | 104857688 |
| mysql-bin.000203 | 104857654 |
| mysql-bin.000204 | 104857895 |
| mysql-bin.000205 | 104857709 |
| mysql-bin.000206 | 104857922 |
| mysql-bin.000207 | 104858019 |
| mysql-bin.000208 | 104857790 |
| mysql-bin.000209 | 104857655 |
| mysql-bin.000210 | 104857996 |
| mysql-bin.000211 | 104857956 |
| mysql-bin.000212 | 104857659 |
| mysql-bin.000213 | 104857835 |
| mysql-bin.000214 | 104857643 |
| mysql-bin.000215 | 104857999 |
| mysql-bin.000216 | 104857770 |
| mysql-bin.000217 | 104857672 |
| mysql-bin.000218 | 104857753 |
| mysql-bin.000219 | 104857795 |
| mysql-bin.000220 | 104858032 |
| mysql-bin.000221 | 104857861 |
| mysql-bin.000222 | 104857896 |
| mysql-bin.000223 | 104857694 |
| mysql-bin.000224 | 104857747 |
| mysql-bin.000225 | 104857861 |
| mysql-bin.000226 | 104857783 |
| mysql-bin.000227 | 104857680 |
| mysql-bin.000228 | 104857882 |
| mysql-bin.000229 | 104857688 |
| mysql-bin.000230 | 104857756 |
| mysql-bin.000231 | 104857744 |
| mysql-bin.000232 | 104857759 |
| mysql-bin.000233 | 104857794 |
| mysql-bin.000234 | 104857863 |
| mysql-bin.000235 | 104858031 |
| mysql-bin.000236 | 104857902 |
| mysql-bin.000237 | 104857715 |
| mysql-bin.000238 | 104857746 |
| mysql-bin.000239 | 104857839 |
| mysql-bin.000240 | 104857845 |
| mysql-bin.000241 | 104857771 |
| mysql-bin.000242 | 104857692 |
| mysql-bin.000243 | 104857806 |
| mysql-bin.000244 | 104857927 |
| mysql-bin.000245 | 104857729 |
| mysql-bin.000246 | 104857961 |
| mysql-bin.000247 | 104857687 |
| mysql-bin.000248 | 104857872 |
| mysql-bin.000249 | 104857881 |
| mysql-bin.000250 | 104858045 |
| mysql-bin.000251 | 104857817 |
| mysql-bin.000252 | 104857901 |
| mysql-bin.000253 | 104858075 |
| mysql-bin.000254 | 104857730 |
| mysql-bin.000255 | 104857756 |
| mysql-bin.000256 | 104857927 |
| mysql-bin.000257 | 104857892 |
| mysql-bin.000258 | 104857738 |
| mysql-bin.000259 | 104857914 |
| mysql-bin.000260 | 104857774 |
| mysql-bin.000261 | 104857892 |
| mysql-bin.000262 | 104857941 |
| mysql-bin.000263 | 104857845 |
| mysql-bin.000264 | 104857732 |
| mysql-bin.000265 | 104857881 |
| mysql-bin.000266 | 104857782 |
| mysql-bin.000267 | 104857927 |
| mysql-bin.000268 | 104857881 |
| mysql-bin.000269 | 104857791 |
| mysql-bin.000270 | 104857749 |
| mysql-bin.000271 | 104857777 |
| mysql-bin.000272 | 104857879 |
| mysql-bin.000273 | 104857767 |
| mysql-bin.000274 | 104858094 |
| mysql-bin.000275 | 104858023 |
| mysql-bin.000276 | 104857726 |
| mysql-bin.000277 | 104857810 |
| mysql-bin.000278 | 104857868 |
| mysql-bin.000279 | 104857861 |
| mysql-bin.000280 | 104857695 |
| mysql-bin.000281 | 104857974 |
| mysql-bin.000282 | 104857873 |
| mysql-bin.000283 | 104857787 |
| mysql-bin.000284 | 104857778 |
| mysql-bin.000285 | 104857901 |
| mysql-bin.000286 | 104857999 |
| mysql-bin.000287 | 104857860 |
| mysql-bin.000288 | 104857698 |
| mysql-bin.000289 | 104857773 |
| mysql-bin.000290 | 104857751 |
| mysql-bin.000291 | 104857741 |
| mysql-bin.000292 | 104857926 |
| mysql-bin.000293 | 104857693 |
| mysql-bin.000294 | 104857684 |
| mysql-bin.000295 | 104857892 |
| mysql-bin.000296 | 104857697 |
| mysql-bin.000297 | 104857985 |
| mysql-bin.000298 | 104857656 |
| mysql-bin.000299 | 104857683 |
| mysql-bin.000300 | 104857695 |
| mysql-bin.000301 | 104857646 |
| mysql-bin.000302 | 104857812 |
| mysql-bin.000303 |  92771646 |
+------------------+-----------+
240 rows in set (0.00 sec)
如果没有主从复制，可以通过reset master的方式，重置数据库日志，清除之前的日志文件：
mysql> reset master;
Query OK, 0 rows affected (8.51 sec)

但是如果存在复制关系，应当通过PURGE的方式来清理bin日志：
语法如下：
PURGE {MASTER | BINARY} LOGS TO 'log_name'
PURGE {MASTER | BINARY} LOGS BEFORE 'date'

　　用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除，这样被给定的日志成为第一个。

　　例如：

　　PURGE MASTER LOGS TO 'mysql-bin.010';
　　PURGE MASTER LOGS BEFORE '2008-06-23 15:00:00';

  清除3天前的 binlog
        PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);
　　BEFORE变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。MASTER和BINARY是同义词。

　　如果您有一个活性的从属服务器，该服务器当前正在读取您正在试图删除的日志之一，则本语句不会起作用，而是会失败，并伴随一个错误。不过，如果从属服务器是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。当从属服务器正在复制时，本语句可以安全运行。您不需要停止它们。

　　要清理日志，需按照以下步骤：

　　1. 在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志。
　　2. 使用SHOW MASTER LOGS获得主服务器上的一系列日志。
　　3. 在所有的从属服务器中判定最早的日志。这个是目标日志。如果所有的从属服务器是更新的，这是清单上的最后一个日志。
　　4. 制作您将要删除的所有日志的备份。（这个步骤是自选的，但是建议采用。）
　　5. 清理所有的日志，但是不包括目标日志,因为从服务器还要跟它同步

常用的命令：
    mysql>show slave hosts -- 查看所有连接到Master的Slave信息
    mysql>show master status -- 查看Master状态信息
    mysql>show slave status -- 查看Slave状态信息
    mysql>show binary logs -- 查看所有二进制日志
    mysql>show binlog events [IN log_file] -- 查看二进制日志中的事件

供参考。


相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Web Mysql Mon, 09 Jan 2012 11:11:36 +0800 -------------------------------------------------------------------------------- 2011年 年终总结 以及年终这一天 2011年12月31日，在这一年的最后一天，我读完了《史蒂夫 乔布斯传》，这是一本关于一个被神话了的天才的故事，他创造了这个地球上最有价值的公司，成就了诸多伟大的产品，他宣称活着就是为了改变世界，他的确也改变了这个世界。书中到处都是2010、2011的字样，而最终我都不愿意相信，这个伟大的主角已经离开了我们。 当乔布斯去世的消息传来时，我和Julia正在法国，一夜想来，当看到满屏的消息时，久久都不能相信这样一个事实。 我在公司的年会上说：我们每个人，尽自己的全力，都可以改变这个世界，或多或少，使得这个世界变得更加美好。我们也要加油！ http://www.eygle.com/archives/2011/12/2011_mylife.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/2011_mylife.html 作者：eygle 发布在 eygle.com

2011年12月31日，在这一年的最后一天，我读完了《史蒂夫 乔布斯传》，这是一本关于一个被神话了的天才的故事，他创造了这个地球上最有价值的公司，成就了诸多伟大的产品，他宣称活着就是为了改变世界，他的确也改变了这个世界。书中到处都是2010、2011的字样，而最终我都不愿意相信，这个伟大的主角已经离开了我们。
当乔布斯去世的消息传来时，我和Julia正在法国，一夜想来，当看到满屏的消息时，久久都不能相信这样一个事实。

我在公司的年会上说：我们每个人，尽自己的全力，都可以改变这个世界，或多或少，使得这个世界变得更加美好。我们也要加油！

2011年12月31日凌晨，几乎熬了一个通宵，帮助一个用户恢复数据。一个TB级的数据库，因为误操作，导致了大量数据文件被误删除，再然后Offline DROP，从数据库中又清理掉了几个文件，造就了一个大灾难。我们帮助用户，最终恢复了数据。在这一年的最后一天，我们成功的又挽救了一个重要的数据库。

2011年12月31日下午，又有一个客户的TB级数据库崩溃，由于丢失了一个数据文件，现场的工程师重建了控制文件，加隐含参数，强制Resetlogs等，最终导致出现了一系列的600内部错误。见招拆招，大约2个小时左右，帮助用户修复和启动了这个数据库。

从这个意义上说：我们挽救了数据，帮助了用户，使得很多人的生活变得美好了一点点！我们的价值所在，就是扶危救难，拯救数据，拯救因数据陷于重重困境的企业和工程师们。

2011年12月31日，回首这一年，看看哪些事情值得纪念吧。

1.两个公司
2011年，公司的发展更上了一个台阶，我们引入了新的伙伴一起合作，和更专业的资源优势互补，强强联合，共同来开拓服务市场，从恩墨科技到云和恩墨，我们有了更加明确的发展目标。
在这一年中，我们也开放了很多实习机会，为在校学生提供了10多个实习岗位，帮助他们去实现数据库梦想。
感谢我的伙伴和同事们，我们一起必定能够创造成功的未来！

以下是办公室中我最喜欢的一幅画图：
2011YunHe00.jpg

2.两场活动
在2011年，ACOUG的活动持续举行，我主张技术分享，技术传播，我们坚持了下来。
在这一年中，标志性的活动我们举行了两次，第一次是3月份的中韩数据库技术交流会，我们成功邀请了中韩方面的技术专家，进行交流分享，沟通亚洲区的数据库技术。

这样的中韩技术交流，在我们和国内都属首次，希望以后能够多促进亚太区的技术交流：
P1060159.JPG

在2011年10月，我们成功的举办了"Oracle技术嘉年华"活动，邀请了全球的Oracle ACE专家，齐聚北京，共同坐而论道，谈技术、谈分享。

以用户组（ACOUG）为主导和发起，邀请全球专家来举行技术交流和分享活动，这在国内绝对是第一次，我们付出了很多艰辛的努力，但是一切的付出都是值得的，有那么多技术爱好者和朋友们支持了这次盛大的技术盛会：
OTN2011Tour.png

3.两本书
这一年中，修订出版了《循序渐进Oracle》一书，编辑出版了《Oracle DBA手记 3》一书。在11月，几本书经常能够在China-Pub的排行榜上看到。

基于出版的技术分享，我一直在坚持，这是我技术分享理念的一个延伸，知识通过分享才能为社会创造更多价值。
我坚持了10年，希望还能坚持下一个10年：
2011OraBooks.png
4.两次旅行
2011年初，到访Oracle旧金山总部，国庆，和Julia开始了欧洲之旅，中间，还有一段短暂的青海湖之行，这一年，就这样几次远行，走过、路过、见过了许多美景。

骑行旧金山，无比惬意：
S1050440.jpg

在巴黎，以朝圣的心情领略了无数的艺术珍宝：

在青海，我最爱贵德：

SP1080321.jpg

是以为记，告别2011，迎接2012.

大家新年好！




相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Life Life Sat, 31 Dec 2011 18:07:32 +0800 -------------------------------------------------------------------------------- 记云和恩墨2011公司年会 - 感恩今日 共创未来 这是多么难得的小概率事件，一个iPad让我们都感受了一次中奖的快乐，希望这能为公司明年带来好运，让公司的业务更上一层楼，让我们的技术能够更好的为更多用户服务，为用户创造价值，为我们实现梦想。 http://www.eygle.com/archives/2011/12/2011_yunhe_christmas.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/2011_yunhe_christmas.html 作者：eygle 发布在 eygle.com

公司今年的年会在12月23日举行，全国各地的同事齐聚北京，先做交流，晚上聚餐，抽奖。

在抽奖环节有非常戏剧性的一幕必须记录，当时要由我抽出一个iPad 2奖品，小概率事件开始出现，我们一桌开始顺时针轮回：
我先开始抽奖，结果抽中了我上游的老杨（http://yangtingkun.net）,然后老杨抽奖，抽中了我，我再抽奖，又抽中了下手边的金总，老金出手，继续抽中了下边的老陈，老陈再抽，抽中了顺时针挨着的Kamus。
就这样，由我开始，由老杨第一个中奖，然后顺时针，我们一桌每个人都轮流中了一次大奖。最后Kamus抽中了公司的一位美女同事，将iPad奖品送了出去。

这是多么难得的小概率事件，一个iPad让我们都感受了一次中奖的快乐，希望这能为公司明年带来好运，让公司的业务更上一层楼，让我们的技术能够更好的为更多用户服务，为用户创造价值，为我们实现梦想。

几张图几年一下那个快乐的夜晚。

第一：公司的墙壁画

2011YunHe00.jpg

中间的小伙是公司一等奖获得者，和两位美女合影：

2011YunHe01.jpg

这位小伙是 iPhone 4S的获得者，连干了三杯啤酒，幸运儿：

2011YunHe02.jpg

最后，中间这位是戏剧性获得iPad 2大奖的美女，手机一激动，还出现了特效：

2011YunHe03.jpg

记住这个日子，我们还要共同去开创明日的未来！



相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Life Life Wed, 28 Dec 2011 21:44:46 +0800 -------------------------------------------------------------------------------- 高Latch等待 - 'Object queue header operation' 最近在某用户系统中，发现有一个Latch等待非常显著：object queue header operation http://www.eygle.com/archives/2011/12/latch_object_queue_header_operation.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/latch_object_queue_header_operation.html 作者：eygle 发布在 eygle.com

最近在某用户系统中，发现有一个Latch等待非常显著：object queue header operation

Bug 7588384  Long waits for 'object queue header operation' / 'cache buffers chains' latches

这在10.2.0.4中被标记为BUG，在10.2.0.4.3之后被修正。
这个BUG的描述为：
    Long latch waits may be seen on 'object queue header operation' and
    'cache buffers chains' latches showing a holder location
    of kcb_flush_undo_segment or kcb_flush_undo_buffers
    
    In some instances, nodes can crash with ORA-481 or ORA-484

影响版本还包括：11.1.0.7。

其主要的Latch竞争点位于： kcb_flush_undo_segment 或者 kcb_flush_undo_buffers   。


相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Case Latch Tue, 27 Dec 2011 16:11:06 +0800 -------------------------------------------------------------------------------- Delete sdo_geor_ddl__table$$ 的异常删除操作 在某客户的数据库跟踪中，发现如下程序块，对sdo_geor_ddl__table$$执行删除操作。 这是被Oracle Spatial 触发的一个后台操作，由触发器调用 SDO_GEOR_ERR_TRIGGER ，如果数据库不需要Spatial组件，建议不要安装，也可以禁用相关触发器或者写在Spatial选件。 http://www.eygle.com/archives/2011/12/delete_sdo_geor_ddl_table.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/delete_sdo_geor_ddl_table.html 作者：eygle 发布在 eygle.com

在某客户的数据库跟踪中，发现如下程序块，对sdo_geor_ddl__table$$执行删除操作。

这是被Oracle Spatial 触发的一个后台操作，由触发器调用 SDO_GEOR_ERR_TRIGGER ，如果数据库不需要Spatial组件，建议不要安装，也可以禁用相关触发器或者写在Spatial选件。

********************************************************************************

declare
  m_stmt  varchar2(512);
begin
   m_stmt:='delete from sdo_geor_ddl__table$$';
   EXECUTE IMMEDIATE m_stmt;
   EXCEPTION
     WHEN OTHERS THEN
       NULL;
end;

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           1

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 52     (recursive depth: 1)
********************************************************************************

SQL ID: 3972rvxu3knn3

delete from sdo_geor_ddl__table$$


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 52     (recursive depth: 2)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  DELETE  SDO_GEOR_DDL__TABLE$$ (cr=0 pr=0 pw=0 time=0 us)
         0          0          0   TABLE ACCESS FULL SDO_GEOR_DDL__TABLE$$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)

********************************************************************************

SQL ID: cb21bacyh3c7d

select metadata
from
 kopm$  where name='DB_FDO'


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          2          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          2          0           1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         1          1          1  TABLE ACCESS BY INDEX ROWID KOPM$ (cr=2 pr=0 pw=0 time=0 us cost=1 size=108 card=1)
         1          1          1   INDEX UNIQUE SCAN I_KOPM1 (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 540)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net break/reset to client                   2        0.00          0.00
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1       20.65         20.65
********************************************************************************


相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Case Case Tue, 27 Dec 2011 08:00:16 +0800 -------------------------------------------------------------------------------- 年终难终 - 记年底前的几则数据恢复案例 每到年底，很多数据库就开始动荡不安起来，这是一个数据库故障的多发期，大家都应当提高警惕。 以下收录了最近我在微博上发布的关于数据库恢复的案例，供大家参考警示。 http://www.eygle.com/archives/2011/12/recovery_case_3020.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/recovery_case_3020.html 作者：eygle 发布在 eygle.com

每到年底，很多数据库就开始动荡不安起来，这是一个数据库故障的多发期，大家都应当提高警惕。

以下收录了最近我在微博上发布的关于数据库恢复的案例，供大家参考警示。

【数据恢复】刚刚又接到一个用户电话，Linux系统，Oracle Database 11g，因为某些故障，去fsck修复文件系统，结果数据库崩溃，主机也无法正常启动，数据库服务中断。fsck 是一个相对危险的操作，对于无备份的数据库系统，任何一个块的修复和变更都可能导致数据库故障，慎用慎用！

【数据恢复】上午接到用户电话，一个目录，24个文件，直接被rm删除掉了，之前用户的空间紧张，为了保证运行，经常性四处倒腾空间，删除、转移文件，为了一块硬盘，损失了整个数据库，这就是得不偿失！

【数据恢复】刚刚收到用户电话，某集成商在帮助用户恢复REDO损坏故障时，强制重置日志，启动数据库，丢失了重要数据，结果遭到用户质疑，难以收尾。这 个案例给我们的启示是：在恢复数据库时，一定要充分考虑数据的重要性，精心设计方案，并取得用户认同。任何一条数据对于用户都可能无比重要。

今天在ITPUB论坛上又看到两则严重的数据库故障，收录信息如下：
1.SYSTEM表空间损坏
类似的案例本站之前描述过：
Mon Dec 19 12:00:16 2011
ALTER DATABASE OPEN
Mon Dec 19 12:00:16 2011
Beginning crash recovery of 1 threads
Mon Dec 19 12:00:16 2011
Started first pass scan
Mon Dec 19 12:00:17 2011
Completed first pass scan
3953 redo blocks read, 365 data blocks need recovery
Mon Dec 19 12:00:17 2011
Started recovery at
Thread 1: logseq 2866, block 2, scn 0.288668733
Recovery of Online Redo Log: Thread 1 Group 3 Seq 2866 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\TH\REDO03.LOG
RECOVERY OF THREAD 1 STUCK AT BLOCK 9 OF FILE 1
ORA-1172 signalled during: ALTER DATABASE OPEN...
Sat Dec 24 10:05:35 2011
alter database open
Sat Dec 24 10:05:35 2011
Beginning crash recovery of 1 threads
Sat Dec 24 10:05:35 2011
Started first pass scan
Sat Dec 24 10:05:36 2011
Completed first pass scan
3953 redo blocks read, 365 data blocks need recovery
Sat Dec 24 10:05:36 2011
Started recovery at
Thread 1: logseq 2866, block 2, scn 0.288668733
Recovery of Online Redo Log: Thread 1 Group 3 Seq 2866 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\TH\REDO03.LOG
RECOVERY OF THREAD 1 STUCK AT BLOCK 9 OF FILE 1
ORA-1172 signalled during: alter database open...
Sat Dec 24 10:05:59 2011
ALTER DATABASE RECOVER  datafile 1  
Sat Dec 24 10:05:59 2011
Media Recovery Datafile: 1
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 2866
Datafile 1: 'D:\ORACLE\ORADATA\TH\SYSTEM01.DBF'
Media Recovery Log
Recovery of Online Redo Log: Thread 1 Group 3 Seq 2866 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\TH\REDO03.LOG
Sat Dec 24 10:06:08 2011
Errors in file d:\oracle\admin\th\udump\th_ora_3672.trc:
ORA-00600: 内部错误代码，参数: [3020], [4194313], [1], [2866], [3], [16], [], []
ORA-10567: Redo is inconsistent with data block (file# 1, block# 9)
ORA-10564: tablespace SYSTEM
ORA-01110: 数据文件 1: 'D:\ORACLE\ORADATA\TH\SYSTEM01.DBF'
ORA-10560: block type 'KTU UNDO HEADER W/UNLIMITED EXTENTS'
Errors with log .
Media Recovery failed with error 600
ORA-283 signalled during: ALTER DATABASE RECOVER  datafile 1  ...
2.SYSTEM表空间恢复
数据库不能启动，信息不多：
oracle 9206,windows 2003 SP2
电压不稳,电脑突然断电后,ORACLE数据库无法加载

ORA-03113: end-of-file on communication channel
ORA-01113: file 1 needs media recovery

为了数据安全，再多一份的备份也值得，请大家注意数据安全。

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Backup&Recovery Recovery Sun, 25 Dec 2011 21:27:31 +0800 -------------------------------------------------------------------------------- Oracle数据恢复 - Linux / Unix 误删除的文件恢复 今天有客户的数据库意外被删除了整个目录中的数据文件，操作系统级别的删除，然而幸运的是这个数据库没有崩溃，仍然处于open状态的时候，客户就发现了问题，求助到我们，最终完整地恢复了所有数据文件。 http://www.eygle.com/archives/2011/12/oracle_linux_rm_rf.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/oracle_linux_rm_rf.html 作者：eygle 发布在 eygle.com

前几天提到的一则误删除案例：

http://www.eygle.com/archives/2011/12/oracle_lsof_recovery_database.html

Kamus 写了一篇详细步骤，转载供参考：

http://www.dbform.com/html/2011/1761.html


今天有客户的数据库意外被删除了整个目录中的数据文件，操作系统级别的删除，然而幸运的是这个数据库没有崩溃，仍然处于open状态的时候，客户就发现了问题，求助到我们，最终完整地恢复了所有数据文件。

在Linux下大致重新演示一下恢复的过程，恢复的步骤与数据库版本没有太大关系，与操作系统的不同会有所不同。

1. 在数据库open的时候，直接删除users表空间中的数据文件。

SQL> select name from v$datafile;
 
NAME
--------------------------------------------------------------------------------
/app/oracle/oradata/ORCL/datafile/o1_mf_system_555wqbnk_.dbf
/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_555wqxgl_.dbf
/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_555wr5p6_.dbf
/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf
 
SQL> host rm /app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf

2. 尝试在users表空间中创建表，开始报错。

SQL> create table t tablespace users as select * from dual;
create table t tablespace users as select * from dual
                                                 *
ERROR at line 1:
ORA-01116: error in opening database file 4
ORA-01110: data file 4:
'/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

在告警日志中，同样也可以看到类似信息。

Mon Dec 19 21:48:17 CST 2011
Errors in file /app/oracle/admin/orcl/bdump/orcl_m000_3897.trc:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

3. 检查dbwr的进程PID

$ ps -ef|grep dbw0|grep -v grep
oracle    2879     1  0 21:38 ?        00:00:00 ora_dbw0_orcl

4. dbwr会打开所有数据文件的句柄。在proc目录中可以查到，目录名是进程PID，fd表示文件描述符。

$ cd /proc/2879/fd
$ ls -l
total 0
lr-x------ 1 oracle dba 64 Dec 19 21:50 0 -> /dev/null
lr-x------ 1 oracle dba 64 Dec 19 21:50 1 -> /dev/null
lr-x------ 1 oracle dba 64 Dec 19 21:50 10 -> /dev/zero
lr-x------ 1 oracle dba 64 Dec 19 21:50 11 -> /dev/zero
lr-x------ 1 oracle dba 64 Dec 19 21:50 12 -> /app/oracle/product/10.2.0/db_1/rdbms/mesg/oraus.msb
lrwx------ 1 oracle dba 64 Dec 19 21:50 13 -> /app/oracle/product/10.2.0/db_1/dbs/hc_orcl.dat
lrwx------ 1 oracle dba 64 Dec 19 21:50 14 -> /app/oracle/product/10.2.0/db_1/dbs/lkORCL
lrwx------ 1 oracle dba 64 Dec 19 21:50 15 -> /app/oracle/oradata/ORCL/controlfile/o1_mf_555wq3ng_.ctl
lrwx------ 1 oracle dba 64 Dec 19 21:50 16 -> /app/oracle/oradata/ORCL/datafile/o1_mf_system_555wqbnk_.dbf
lrwx------ 1 oracle dba 64 Dec 19 21:50 17 -> /app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_555wqxgl_.dbf
lrwx------ 1 oracle dba 64 Dec 19 21:50 18 -> /app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_555wr5p6_.dbf
lrwx------ 1 oracle dba 64 Dec 19 21:50 19 -> /app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf (deleted)
lr-x------ 1 oracle dba 64 Dec 19 21:50 2 -> /dev/null
lrwx------ 1 oracle dba 64 Dec 19 21:50 20 -> /app/oracle/oradata/ORCL/datafile/o1_mf_temp_555wrbnz_.tmp
lr-x------ 1 oracle dba 64 Dec 19 21:50 21 -> /app/oracle/product/10.2.0/db_1/rdbms/mesg/oraus.msb
lr-x------ 1 oracle dba 64 Dec 19 21:50 3 -> /dev/null
lr-x------ 1 oracle dba 64 Dec 19 21:50 4 -> /dev/null
l-wx------ 1 oracle dba 64 Dec 19 21:50 5 -> /app/oracle/admin/orcl/udump/orcl_ora_2871.trc
l-wx------ 1 oracle dba 64 Dec 19 21:50 6 -> /app/oracle/admin/orcl/bdump/alert_orcl.log
lrwx------ 1 oracle dba 64 Dec 19 21:50 7 -> /app/oracle/product/10.2.0/db_1/dbs/lkinstorcl (deleted)
l-wx------ 1 oracle dba 64 Dec 19 21:50 8 -> /app/oracle/admin/orcl/bdump/alert_orcl.log
lrwx------ 1 oracle dba 64 Dec 19 21:50 9 -> /app/oracle/product/10.2.0/db_1/dbs/hc_orcl.dat

注意其中"/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf (deleted)"字样，表示该文件已经被删除，如果是Solaris操作系统，ls命令不会有如此清晰的显示，为了在Solaris系统中确认哪个句 柄对应哪个文件，则需要使用lsof程序。

5. 直接cp该句柄文件名回原位置。

cp 19 /app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf

6. 进行数据文件recover

SQL> alter database datafile 4 offline;
 
Database altered.
 
SQL> recover datafile 4;
Media recovery complete.
SQL> alter database datafile 4 online;
 
Database altered.

完成数据文件恢复。

恢复的原理是，在Linux操作系统中，如果文件从操作系统级别被rm掉，之前打开该文件的进程仍然持有相应的文件句柄，所指向的文件仍然可以读 写，并且该文件的文件描述符可以从/proc目录中获得。但是要注意的是，此时如果关闭数据库，则此句柄会消失，那么除了扫描磁盘进行文件恢复之外就没有 其它方法了，因此在数据库出现问题的时候，如果不确认情况的复杂程度，千万不要随便关闭数据库。重启数据库往往是没有意义的，甚至是致命的。

当然，客户的操作系统是Solaris，并且客户删除的文件还包括current online redo log，因此还有其它更复杂的操作，不在这里描述。


相关文章|Related Articles

评论数量(2)|Add Comments

本文网址：

]]> Backup&Recovery Recovery Thu, 22 Dec 2011 15:34:46 +0800 -------------------------------------------------------------------------------- 数据安全 - 从CSDN网站数据泄露说开去 在网路数据大量集中的今天，一旦发生安全问题，则将对广大的用户带来极大的困扰，我相信有很多用户不能及时获得这一消息，则其重要信息就可能被泄露窃取。后果不堪设想。 所以，对数据进行充分的安全保护、安全防范，是每一个有责任的公司都应该全面考虑的内容。 我们可以想象，在数据被发布出来之前，黑客可能已经利用该数据进行了大量的非法活动，那么谁又会为侵害来承担责任呢？ http://www.eygle.com/archives/2011/12/csdn_userdata_leak.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/csdn_userdata_leak.html 作者：eygle 发布在 eygle.com

今天互联网上传得沸沸扬扬的一个消息是：
360安全卫士 新浪机构认证： 【紧急通知】今日有黑客在网上公开了CSDN网站用户数据库，包括600余万个明文的注册邮箱帐号和密码。CSDN是国内最大的程序员网站， 请广大程序员务必重视并尽快修改密码，包括CSDN帐号密码，以及采用相同注册邮箱和密码的其他网络帐号，如邮箱、微博、购物网站、聊天软件等帐号，以免 蒙受盗号损失！
开始并未重视，随后看到更多的信息发布出来，查询了一下，赫然发现我的密码也在被泄露之列，随后花了几个小时去网上的各处网站修改密码。

接着CSDN网站承认数据泄露：
CSDN 新浪机构认证： 对于CSDN用户账号密码数据库被泄露一事，经过初步分析，该库系2009年CSDN作为备份所用，由于未查明原因被泄露，特向所有因此而受 到影响的用户致以深深歉意。目前CSDN已向公安机关报案，公安机关也正在调查相关线索。CSDN现有2000万注册用户的账号密码数据库已经全部采取了 密文保护和备份。

在网路数据大量集中的今天，一旦发生安全问题，则将对广大的用户带来极大的困扰，我相信有很多用户不能及时获得这一消息，则其重要信息就可能被泄露窃取。后果不堪设想。

所以，对数据进行充分的安全保护、安全防范，是每一个有责任的公司都应该全面考虑的内容。

我们可以想象，在数据被发布出来之前，黑客可能已经利用该数据进行了大量的非法活动，那么谁又会为侵害来承担责任呢？

所以，这件事情给我们的教训和经验就是：
1.重要账号的密码一定和普遍的密码不同
2.尽量按照一个规则对不同密码进行设定
3.如果记得住不同网站都要用不同的密码

对密码做了一点统计运算，给大家参考吧：
1.用户名和口令相同
这部分用户有大约30万：
SQL> set timing on
SQL> select count(*) from test;

  COUNT(*)
----------
   6428632

Elapsed: 00:00:00.60
SQL> select count(*) from test where trim(lower(username))=trim(lower(password));

  COUNT(*)
----------
    308157

2.密码的流行度
最流行的密码是：123456789 ， 有23万人使用， 其次是 12345678 ，有21万人使用：
SQL> select * from (select password,count(*) from test group by password order by 2 desc) where rownum < 21;
 
PASSWORD                                                                           COUNT(*)
-------------------------------------------------------------------------------- ----------
 123456789                                                                           235012
 12345678                                                                            212749
 11111111                                                                             76346
 dearbook                                                                             46053
 00000000                                                                             34952
 123123123                                                                            19986
 1234567890                                                                           17790
 88888888                                                                             15033
 111111111                                                                             6995
 147258369                                                                             5965
 987654321                                                                             5553
 aaaaaaaa                                                                              5459
 1111111111                                                                            5145
 66666666                                                                              5025
 a123456789                                                                            4435
 11223344                                                                              4096
 1qaz2wsx                                                                              3667
 
PASSWORD                                                                           COUNT(*)
-------------------------------------------------------------------------------- ----------
 xiazhili                                                                              3649
 789456123                                                                             3610
 password                                                                              3501
 
20 rows selected

为了安全，远离弱密码，远离明文网站！


相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> OraNews CSDN Wed, 21 Dec 2011 21:49:20 +0800 -------------------------------------------------------------------------------- Oracle数据恢复 - 使用 lsof 查看进程打开的文件列表 对于Oracle数据库来说，如果有文件被删除，只要文件句柄未关闭，则就可以在lsof的输出中看到标记为deleted的状态标记. 通过 proc 下的文件目录，可以找到文件句柄信息，这个就是Oracle的数据文件 http://www.eygle.com/archives/2011/12/oracle_lsof_recovery_database.html eygle@eygle.com(eygle) http://www.eygle.com/archives/2011/12/oracle_lsof_recovery_database.html 作者：eygle 发布在 eygle.com

在Unix、Linux系统上，Oracle数据库启动之后，后台进程会维护一个文件列表，锁定打开的文件。

这个进程文件列表，可以通过lsof命令查看。
对于Solaris平台，可以从 SUNFreeWare 站点获得lsof的安装包，不同版本安装源不同，也可以通过源码自行编译：
http://sunfreeware.com/indexsparc9.html

以下是在Solaris 9上安装的过程：
Pro:tmp eygle$ wget ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/lsof-4.80-sol9-sparc-local.gz
--09:38:42--  ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/lsof-4.80-sol9-sparc-local.gz
           => `lsof-4.80-sol9-sparc-local.gz'
Resolving ftp.sunfreeware.com... 66.193.208.66
Connecting to ftp.sunfreeware.com[66.193.208.66]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /pub/freeware/sparc/9 ... done.
==> PORT ... done.    ==> RETR lsof-4.80-sol9-sparc-local.gz ... done.
Length: 489,916 (unauthoritative)

100%[=================================================================================>] 489,916       93.36K/s    ETA 00:00

09:38:55 (93.24 KB/s) - `lsof-4.80-sol9-sparc-local.gz' saved [489916]

然后执行安装：
root@db2 # pwd
/tmp
root@db2 # gzip -d lsof-4.80-sol9-sparc-local.gz
root@db2 # pkgadd -d lsof-4.80-sol9-sparc-local  

The following packages are available:
  1  SMClsof     lsof
                 (sparc) 4.80

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: all

Processing package instance <SMClsof> from </tmp/lsof-4.80-sol9-sparc-local>

lsof
(sparc) 4.80

This appears to be an attempt to install the same architecture and
version of a package which is already installed.  This installation
will attempt to overwrite this package.

Vic Abell
Using </usr/local> as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.

The following files are already installed on the system and are being
used by another package:
  /usr/local/bin <attribute change only>
  /usr/local/bin/sparcv7 <attribute change only>
  /usr/local/bin/sparcv9 <attribute change only>
  /usr/local/doc <attribute change only>
  /usr/local/man <attribute change only>
  /usr/local/man/man8 <attribute change only>

Do you want to install these conflicting files [y,n,?,q] y
## Checking for setuid/setgid programs.

The following files are being installed with setuid and/or setgid
permissions:
*/usr/local/bin/lsof <setgid sys>
*/usr/local/bin/sparcv7/lsof <setgid sys>
*/usr/local/bin/sparcv9/lsof <setgid sys>

* - overwriting a file which is also setuid/setgid.

Do you want to install these as setuid/setgid files [y,n,?,q] y

Installing lsof as <SMClsof>

## Installing part 1 of 1.
/usr/local/bin/lsof
/usr/local/bin/sparcv7/lsof
/usr/local/bin/sparcv9/lsof
/usr/local/doc/lsof/00.README.FIRST
/usr/local/doc/lsof/00CREDITS
/usr/local/doc/lsof/00DCACHE
/usr/local/doc/lsof/00DIALECTS
/usr/local/doc/lsof/00DIST
/usr/local/doc/lsof/00FAQ
/usr/local/doc/lsof/00LSOF-L
/usr/local/doc/lsof/00MANIFEST
/usr/local/doc/lsof/00PORTING
/usr/local/doc/lsof/00QUICKSTART
/usr/local/doc/lsof/00README
/usr/local/doc/lsof/00TEST
/usr/local/doc/lsof/00XCONFIG
/usr/local/doc/lsof/lsof.man
/usr/local/man/man8/lsof.8
[ verifying class <none> ]

Installation of <SMClsof> was successful.
接下来就可以使用lsof了，首先选取一个进程，如 dbwr 进程：
root@db2 # ps -ef|grep dbw
    root 14348  9859  0 10:15:50 pts/3    0:00 grep dbw
  oracle   762     1  0   Jun 10 ?       202:01 ora_dbw0_cinms
root@db2 # lsof -p 762
COMMAND PID   USER   FD   TYPE        DEVICE   SIZE/OFF   NODE NAME
oracle  762 oracle  cwd   VDIR       85,8272       2048 106800 /u01/app/oracle/product/9.2.0/dbs
oracle  762 oracle  txt   VREG       85,8272   66187776  10258 /u01/app/oracle/product/9.2.0/bin/oracle
oracle  762 oracle  txt   VREG         118,1      13280  18580 /usr/lib/sparcv9/libmd5.so.1
oracle  762 oracle  txt   VREG         118,1      24336  18582 /usr/lib/sparcv9/libmp.so.2
oracle  762 oracle  txt   VREG         118,1     262112  19762 /usr/lib/sparcv9/libm.so.1
oracle  762 oracle  txt   VREG         118,1      13936  18568 /usr/lib/sparcv9/libkstat.so.1
oracle  762 oracle  txt   VREG         118,1      48768  18597 /usr/lib/sparcv9/librt.so.1
oracle  762 oracle  txt   VREG         118,1      48544  18545 /usr/lib/sparcv9/libaio.so.1
oracle  762 oracle  txt   VREG         118,1     971872  18523 /usr/lib/sparcv9/libc.so.1
oracle  762 oracle  txt   VREG         118,1       5160  18551 /usr/lib/sparcv9/libdl.so.1
oracle  762 oracle  txt   VREG         118,1      47816  18564 /usr/lib/sparcv9/libgen.so.1
oracle  762 oracle  txt   VREG         118,1     915320  45739 /usr/lib/sparcv9/libnsl.so.1
oracle  762 oracle  txt   VREG       85,8272    7519968   1234 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  txt   VREG         118,1      75224  18605 /usr/lib/sparcv9/libsocket.so.1
oracle  762 oracle  txt   VREG       85,8272      38616   1293 /u01 -- libskgxn9.so
oracle  762 oracle  txt   VREG       85,8272      12256    814 /u01 -- libskgxp9.so
oracle  762 oracle  txt   VREG       85,8272       9064   1296 /u01 -- libodmd9.so
oracle  762 oracle  txt   VREG         118,1       4760  43126 /usr/platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
oracle  762 oracle  txt   VREG         118,1     234296  94651 /usr/lib/sparcv9/ld.so.1
oracle  762 oracle    0r  VCHR          13,2        0t0  11044 /devices/pseudo/mm@0:null
oracle  762 oracle    1r  VCHR          13,2        0t0  11044 /devices/pseudo/mm@0:null
oracle  762 oracle    2r  VCHR          13,2        0t0  11044 /devices/pseudo/mm@0:null
oracle  762 oracle    3r  VCHR          13,2        0t0  11044 /devices/pseudo/mm@0:null
oracle  762 oracle    4r  VCHR          13,2        0t0  11044 /devices/pseudo/mm@0:null
oracle  762 oracle    5w  VREG       85,8272        583 111252 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle    6w  VREG       85,8272   85019992 111002 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle    7w  VREG       85,8272   85019992 111002 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle    8r  VCHR         13,12        0t0  11046 /devices/pseudo/mm@0:zero
oracle  762 oracle    9r  VCHR         13,12        0t0  11046 /devices/pseudo/mm@0:zero
oracle  762 oracle   10r  DOOR         338,0        0t0     53 /var/run (swap) (door to nscd[332])
oracle  762 oracle   11r  VREG       85,8272     657920   6421 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle   12u  VREG       85,8272        923 109747 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle   13uR VREG       85,8272         24 109060 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle   14u  IPv4 0x35f15674040        0t0    UDP *:38127 (Idle)
oracle  762 oracle  256uW VREG       85,8272    1859584 110979 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  257uW VREG       85,8272    1859584 110980 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  258uW VREG       85,8272    1859584 110981 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  259uW VREG       85,8272  414195712 110986 /u01/oradata/cinms/system01.dbf
oracle  762 oracle  260uW VREG       85,8272 6291464192 110993 /u01/oradata/cinms/undotbs01.dbf
oracle  762 oracle  261uW VREG       85,8272  161488896 110999 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  262uW VREG       85,8272   20979712 111000 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  263uW VREG       85,8272   26222592 111001 /u01/oradata/cinms/indx01.dbf
oracle  762 oracle  264uW VREG       85,8272   10493952 111151 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  265uW VREG       85,8272  473178112 111152 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  266uW VREG         118,0 1048584192 192549 / (/dev/dsk/c1t0d0s0)
oracle  762 oracle  267uW VREG         118,0 1048584192 192550 / -- data_res10.dbf
oracle  762 oracle  268uW VREG         118,0 1048584192 192551 / (/dev/dsk/c1t0d0s0)
oracle  762 oracle  269uW VREG         118,0 1048584192 192552 / -- data_res12.dbf
oracle  762 oracle  270uW VREG       85,8252 1048584192      5 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  271uW VREG       85,8252 1048584192      6 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  272uW VREG       85,8252 1375739904      9 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  273uW VREG       85,8252 1376788480     10 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  274uW VREG       85,8242 1048584192      5 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  275uW VREG       85,8242 1048584192      6 /u04/oradata/cnnc_hist02.dbf
oracle  762 oracle  276uW VREG       85,8242 1048584192      8 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  277uW VREG       85,8242 1048584192      9 /u04/oradata_res/data_res02.dbf
oracle  762 oracle  278uW VREG       85,8242 1048584192     10 /u04/oradata_res/data_res03.dbf
oracle  762 oracle  279uW VREG       85,8242 1048584192     11 /u04/oradata_res/data_res04.dbf
oracle  762 oracle  280uW VREG       85,8252 1048584192     11 /u03/oradata_res/idx_res01.dbf
oracle  762 oracle  281uW VREG       85,8272  524296192 111198 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  282uW VREG       85,8272  104865792 111200 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  283uW VREG       85,8252 1048584192     12 /u03/oradata/cnnc_user05.dbf
oracle  762 oracle  284uW VREG       85,8242 1048584192     12 /u04/oradata/cnnc_user06.dbf
oracle  762 oracle  285uW VREG         118,0 1377837056 192553 / (/dev/dsk/c1t0d0s0)
oracle  762 oracle  286uW VREG         118,0 1377312768 192554 / (/dev/dsk/c1t0d0s0)
oracle  762 oracle  287uW VREG         118,0 1048584192 192538 /u02/oradata/cnnc_user01.dbf
oracle  762 oracle  288uW VREG         118,0 1048584192 192539 /u02/oradata/cnnc_user02.dbf
oracle  762 oracle  289uW VREG         118,0 1048584192 192540 /u02/oradata/cnnc_user03.dbf
oracle  762 oracle  290uW VREG       85,8252 1048584192     13 /u03/oradata/cnnc_user12.dbf
oracle  762 oracle  291uW VREG       85,8252 1048584192     14 /u03/oradata/cnnc_user13.dbf
oracle  762 oracle  292uW VREG       85,8242 1048584192     13 /u04/oradata/cnnc_user15.dbf
oracle  762 oracle  293uW VREG       85,8252 1048584192     15 /u03/oradata/cnnc_user14.dbf
oracle  762 oracle  294uW VREG         118,0 1048584192 192541 /u02/oradata/cnnc_user04.dbf
oracle  762 oracle  295uW VREG         118,0 1048584192 192542 /u02/oradata/cnnc_user07.dbf
oracle  762 oracle  296uW VREG       85,8252 1048584192     16 /u03/oradata/cnnc_user17.dbf
oracle  762 oracle  297uW VREG       85,8252 1048584192     17 /u03/oradata/cnnc_user18.dbf
oracle  762 oracle  298uW VREG       85,8242 1048584192     14 /u04/oradata/cnnc_user19.dbf
oracle  762 oracle  299uW VREG       85,8242 1048584192     15 /u04/oradata_res/data_res05.dbf
oracle  762 oracle  300uW VREG       85,8242 1048584192     16 /u04/oradata_res/data_res06.dbf
oracle  762 oracle  301uW VREG       85,8242 1048584192     17 /u04/oradata_res/data_res07.dbf
oracle  762 oracle  302uW VREG       85,8242 1048584192     18 /u04/oradata_res/data_res08.dbf
oracle  762 oracle  303uW VREG       85,8252 1048584192     18 /u03/oradata/cnnc_user20.dbf
oracle  762 oracle  304uW VREG       85,8252 1048584192     19 /u03/oradata/cnnc_user21.dbf
oracle  762 oracle  305uW VREG       85,8252 1048584192     20 /u03/oradata/cnnc_user22.dbf
oracle  762 oracle  306uW VREG       85,8242 1048584192     19 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  307uW VREG       85,8242 1048584192     20 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  308uW VREG         118,0 1048584192 192543 /u02/oradata/cnnc_user08.dbf
oracle  762 oracle  309uW VREG         118,0 1073750016 192544 /u02/oradata/cnnc_user09.dbf
oracle  762 oracle  310uW VREG         118,0 1073750016 192545 /u02/oradata/cnnc_user10.dbf
oracle  762 oracle  311uW VREG         118,0 1073750016 192546 /u02/oradata/cnnc_user11.dbf
oracle  762 oracle  312uW VREG       85,8252 1073750016     21 /u03/oradata/cnnc_user24.dbf
oracle  762 oracle  313uW VREG         118,0 1048584192 192547 /u02/oradata/cnnc_user15.dbf
oracle  762 oracle  314uW VREG         118,0 1048584192 192548 /u02/oradata/cnnc_user16.dbf
oracle  762 oracle  315uW VREG       85,8252 1048584192     22 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  316uW VREG       85,8252 1048584192     23 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  317uW VREG       85,8242 1048584192     21 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  318uW VREG       85,8242 1048584192     22 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  319uW VREG         118,0 1048584192 192555 /u02/oradata/cnnc_indexes05.dbf
oracle  762 oracle  320uW VREG       85,8242 1048584192     23 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  321uW VREG         118,0 1048584192 192556 /u02/oradata/cnnc_user25.dbf
oracle  762 oracle  322uW VREG       85,8252 1048584192     24 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  323uW VREG       85,8252 1048584192     25 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  324uW VREG       85,8252 1048584192     26 /u03 (/dev/md/OraDG/dsk/d60)
oracle  762 oracle  325uW VREG         118,0 1048584192 192557 / (/dev/dsk/c1t0d0s0)
oracle  762 oracle  326uW VREG         118,0 1048584192 192558 /u02/oradata/cnnc_user27.dbf
oracle  762 oracle  327uW VREG       85,8252 1048584192     27 /u03/oradata/cnnc_user28.dbf
oracle  762 oracle  328uW VREG       85,8242 1048584192     24 /u04/oradata/cnnc_user29.dbf
oracle  762 oracle  329uW VREG       85,8242 1048584192     25 /u04/oradata/cnnc_user30.dbf
oracle  762 oracle  330uW VREG       85,8272  104865792 111088 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  331uW VREG       85,8272  104865792 111089 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  332uW VREG       85,8272  104865792 111090 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  333uW VREG       85,8272  104865792 111091 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  334uW VREG       85,8272  104865792 111092 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  335uW VREG       85,8272  104865792 111093 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  336uW VREG       85,8272  104865792 111094 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  337uW VREG       85,8272  104865792 111095 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  338uW VREG       85,8272  104865792 111096 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  339uW VREG       85,8272  104865792 111097 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  340uW VREG       85,8242 1048584192     26 /u04/oradata_res/data_res13.dbf
oracle  762 oracle  341uW VREG       85,8242 1048584192     27 /u04 (/dev/md/OraDG/dsk/d50)
oracle  762 oracle  342uW VREG       85,8252 1048584192     28 /u03/oradata_res/idx_res02.dbf
oracle  762 oracle  343uW VREG       85,8272 1409294336 111241 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  344uW VREG         118,0 1048584192 192559 / (/dev/dsk/c1t0d0s0)
oracle  762 oracle  345uW VREG         118,0 1073750016 192560 /u02/oradata/cnnc_indexes11.dbf
oracle  762 oracle  346uW VREG         118,0 1073750016 192561 /u02/oradata/cnnc_indexes12.dbf
oracle  762 oracle  347uW VREG       85,8272   52436992 111150 /u01 (/dev/md/OraDG/dsk/d80)
oracle  762 oracle  348uW VREG       85,8252 8388616192      8 /u03 (/dev/md/OraDG/dsk/d60)
对于Oracle数据库来说，如果有文件被删除，只要文件句柄未关闭，则就可以在lsof的输出中看到标记为deleted的状态标记.
通过 proc 下的文件目录，可以找到文件句柄信息，这个就是Oracle的数据文件：
root@db2 # ls -l /proc/762/fd/329
-rw-r-----   1 oracle   dba      1048584192 Dec 20 10:16 /proc/762/fd/329

可以通过复制拷贝恢复这个文件。

-The End-



相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：

]]> Backup&Recovery Recovery Wed, 21 Dec 2011 09:45:27 +0800