在日常工作中，特别是像我这种不是纯DB或SA的人来说，经常会到的知道有这么回事，但是想不起来命令的情形，这片文章就会陆续记录我所常用的网络命令

1、tcpdump [ -adeflnNOpqStvx ] [ -c 数量 ] [ -F 文件名 ]
　　　　　　　　　　[ -i 网络接口 ] [ -r 文件名] [ -s snaplen ]
　　　　　　　　　　[ -T 类型 ] [ -w 文件名 ] [表达式 ]

      tcpdump的选项介绍

　　　-a 　　　将网络地址和广播地址转变成名字；
　　　-d 　　　将匹配信息包的代码以人们能够理解的汇编格式给出；
　　　-dd 　　　将匹配信息包的代码以c语言程序段的格式给出；
　　　-ddd 　　　将匹配信息包的代码以十进制的形式给出；
　　　-e 　　　在输出行打印出数据链路层的头部信息；
　　　-f 　　　将外部的Internet地址以数字的形式打印出来；
　　　-l 　　　使标准输出变为缓冲行形式；
　　　-n 　　　不把网络地址转换成名字；
　　　-t 　　　在输出的每一行不打印时间戳；
　　　-v 　　　输出一个稍微详细的信息，例如在ip包中可以包括ttl和服务类型的信息；
　　　-vv 　　　输出详细的报文信息；
　　　-c 　　　在收到指定的包的数目后，tcpdump就会停止；
　　　-F 　　　从指定的文件中读取表达式,忽略其它的表达式；
　　　-i 　　　指定监听的网络接口；
　　　-r 　　　从指定的文件中读取包(这些包一般通过-w选项产生)；
　　　-w 　　　直接将包写入文件中，并不分析和打印出来；
　　　-T 　　　将监听到的包直接解释为指定的类型的报文，常见的类型有rpc （远程过程
调用）和snmp（简单　　　　　　　网络管理协议

例子：
　　　(1)想要截获所有210.27.48.1 的主机收到的和发出的所有的数据包：
　　　　#tcpdump host 210.27.48.1
　　　(2) 想要截获主机210.27.48.1 和主机210.27.48.2 或210.27.48.3的通信，使用命令
：（在命令行中适用　　　括号时，一定要
　　　　#tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)
　　　(3) 如果想要获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包
，使用命令：
　　　　#tcpdump ip host 210.27.48.1 and ! 210.27.48.2
　　　(4)如果想要获取主机210.27.48.1接收或发出的telnet包，使用如下命令：
　　　　#tcpdump tcp port 23 and host 210.27.48.1
今天在客户现场出现了weblogic down的事件，还是老规矩，陆续察看了几个相关日志，在server.log中发现error事件——stuckThreadMaxTime 600 second

首先我们来说明一下stuckThreadMaxTime，如下：
WebLogic Server 提供 stuckThreadMaxTime 及stuck Thread Timer Interval 兩個參數協助偵測 thread stuck 的狀況並發出警訊 , stuckThreadMaxTime 的 default 值為 600 秒 , stuckThreadTimerInterval 的 deault 值也是 600 秒 , 每 600 秒 WebLogic Server 會檢查 Queue 中所有的 thread, 如果發現有持續工作 600 秒的狀況發生 ,Server 認定這個 thread 的狀態為 stuck, stuck 住的 thread 在 Server log 中會有記錄提醒管理者 , 如果情況持續的惡化 ,stuck thread 數量越來越多 , 造成 WEBLogic Server 的 Default Execute Queue 中的 thread 全部 stuck,Server 就會變更自己的狀態為 CrITical, 如果是 Customer Execute Queue,Server 變更自己的狀態為 Warning

在以前的项目中，也遇到过由于thread的异常造成了java processes的异常中断，看了一下相关程序，是用来发送邮件的，为了避免requestTimeout和页面友好度，采用异步发送（采用异步thread），在设计时忽略了一点，那就是异步线程同样受限于stuckThreadMaxTime，而且有多年java经验的人应该清楚，JVM Thread机制相比C/C++是非常不稳定和低效的

为了避免这样的问题，现在改成JNI C进行处理，当然如果有条件或者对应用要求过高的环境，可以使用JMS进行数据主推的分布式工作

以上就是这次事件的记录过程，有兴趣的朋友可以多讨论Oracle10g对于闪回查询进行了增强，支持更简单的SQL操作，允许对误删除、误更新等DML操作进行闪回。
看一下以下测试:
1.原表记录


$ sqlplussys/sys@10.163.139.68as sysdba

SQL*Plus: Release 10.1.0.2.0 - Production on Wed Mar 30 08:52:04 2005

Copyright (c) 1982, 2004, Oracle.  All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  804052


2.误修改后所有记录
并且提交更改。

select * from crm3.tsub_info as of scn 804052;

<显示数据>



我们看到在SCN=10670000时，数据都在。
3.恢复数据.

select * from crm3.tsub_info as of scn 800000;
sql> update crm3.tsub_info t1 set t1.taskid = (select t2.taskid from crm3.tsub_info as of scn 800000)
where exists (
      (
      select 'X' from crm3.tsub_info as of scn 800000
      ) t2 where t1.taskid =  t2.taskid
)

SQL >commit;

Commit com