10.23.07
莫名烦躁
明明知道这样烦躁不好,可是却控制不了自己的烦躁.
也不知道是为什么会烦躁.
那么,写在这,希望写完了,自己能稍微平静点.
10.17.07
Tnsping安全吗?
tnsping,oracle中最常用的判断client和server端通信的命令,应该没有人会觉得这个命令不安全,说实话,今天以前,我也觉得,tnsping不安全的话,oracle就没有那个命令是安全的了,可是,tnsping真的安全吗?
今天碰到一个案例.我们的多台服务器之间,要进行互相的tnsping检查,看到底那些连接已经不需要使用,或者说是需要下线.
服务器太多,有其他部分写了shell给我们,我们测试过shell,只是互相的tnsping,在各个平台上均测试过,没有问题,ok,那就部署到各个服务器上,开始互相tnsping吧.写过来的脚本,对于可以tnsping通的,会很快通过,如果不能连接的,会有一个超时判断,也就是会尝试了,这个想必逻辑上也没有太多的问题.
进行了一个多小时以后,应用突然报故障,有一个服务器失去连接,rlogin,telnet均无法和该服务器连接.找主机的兄弟介入,发现该服务器内存消耗完毕.导致服务器不堪重负,宕机了.
进一步跟踪后发现,该服务器os为aix 5.3,oracle版本为9206,rac环境,因为是多个服务器之间互相tnsping,所以这个环境也就是他自己tnsping其他服务器时候的client的环境.系统检查后发现,tnsping这个进程消耗了所有剩余的内存和page space.tnsping真的有这么强吗.
测试说明一切,找一个完全相同的环境,在人工监测下,进行tsnping操作.发现,如果是tnsping一个不通的服务器,那么,每秒大概消耗整个万分之五的内存.也就是说,大约90分钟后,tnsping会消耗掉client端的所有内存,如果你的这个client刚好又是其他的应用的服务器端的角色,那么,就会导致服务宕机.
在hp平台上,作同样的操作,未发现这个问题,那么,这个问题到底是aix的缘故还是oracle的缘故,持续关注中.也欢迎大家讨论下为何会有这种问题.如果是单机环境,也将不存在这样的问题,是rac引入的bug,又或者是opatch的问题,我们需要继续测试,也欢迎见过这种问题的兄弟,说说到底是什么状况引起的,或者是patch不对,或者是os的补丁问题?
奇怪的问题最近非常多呀!
已确认该问题为bug,bug id为2728394.
搞定手机作为调制解调器上网
这次因为私事回武汉,结果发现到了那里,没有网络,被同事催命,要求处理事务.上不了网真不爽,而cdma的话,太贵,一个月要130多列,而且我去的地方基本都有网络.
所以只能临时用手机作为调制解调器来顶一下,不过在武汉因为没有网络,所以不能google,就找不到解决的方法,今天搞定,记录之.
我的手机型号是Moto E6.
首先,找个e6的驱动,据说是叫MPT,安装再说,不过不知道是不是手机是水货的缘故,居然这东西找不到手机.先不管.在手机的设置中选择usb模式中的调制解调器模式,把手机用usb线捅到我的x60上.
然后在我的电脑的管理中,看看是不是多了个黄色图标,一个没有驱动的调制解调器,给它更新下驱动.
然后新建一个网络连接,拨号的那种就行了.拨号号码为*99***1# ,没有用户名和密码的.
然后,拨号吧,拨号成功以后,将ie的代理设置为10.0.0.172:80,这步一定要作,移动不会告诉你的,不作这步,上了等于没上,啥都干不了.
看看,能上google不,能上就ok了,不能的话,RPWT,需要仔细反省!
10.12.07
又一次郁闷的SQL问题
昨天晚上,应用上线,23点开始干活,前期都十分正常,大概在凌晨3点左右,应用有故障过来.一个sql从应用中执行,运行很慢很慢.
检查那个sql,其实是很简单的一个sql,就是在一个表中(约4kw记录),根据where后的三个条件作一个查询,没有表关联.
在plsql中查看该sql的执行计划,在plsql中,该sql的执行计划正常,cost为6,走的是正确的索引.
检查索引的状况,没有任何不对的地方,而且在10号表以及索引都被分析过.并且该表数据不会出现任何异动,也就是说,数据量没有大的增,删,改.
在sqlplus中explain该sql的执行计划,也正常.
让应用发起该应用,在后台捕获该sql的hash_value,然后根据hash_value到v$sql_plan中去查询sql的真实执行计划.还是正常,因为该执行计划非常之简单,就是走了个索引,cost为6.
如果将该sql中的绑定变量直接写上常量,在plsql或者sqlplus中执行,速度非常好,但是在应用上,就是很慢,应用的后台log看,就是慢在这个select上.
那么,实在没有办法,用dbms_system.set_sql_trace_in_session跟踪该sql到底在作什么,奇怪的问题,就出现了,只要我打开trace,sql执行就很快,trace文件中,没有什么异常,只要我关闭trace,sql立刻执行缓慢.
并且,我有两个一模一样的环境,一个在aix 5.3上,一个在hpux11.11上.两个机器上的表现完全相同.
实在没有办法了,将表重新分析一次,取样5%.aix上的正常了,hp上的不正常,还是慢,并且在等待全表扫描和读取临时表空间.在分析一次hp上的该表.系统正常.
实在想不明白为什么会这样,没道理的事情呀.
谁见过这种情况,还是我被oracle忽悠了下.
10.09.07
大哥,你不是敌人派来忽悠我的吧!
晚上收到一个简历,qq上聊了下,到现在为止,我还是愿意相信,这哥们是敌人派过来忽悠我的.看看qq记录就知道,他是如何忽悠我的.
三少 18:54:50
你好.
**** 18:55:21
好啊
三少 18:55:36
不好意思的问下,
三少 18:55:44
你作oracle管理多久了
**** 18:55:52
你在杭州
三少 18:55:53
是
**** 18:56:17
我其实一直用oracle 做开发。管理只是顺带做的
**** 18:56:43
一般系统的故障都能解决。偏重于系统优化
三少 18:56:53
哦,是吗.
三少 18:57:02
你是作电力的?
**** 18:57:07
可能达不到的你们的要求
**** 18:57:23
我以前在电力公司工作过。
三少 18:57:30
呵呵,
**** 18:57:42
现在做物流信息管理方面的软件。数据库一直用oracle9i
三少 18:57:46
我们这里是维护的亚洲通信行业最大的数据库.
三少 18:57:54
需要的是管理经验非常丰富的人.
三少 18:58:07
数据库的繁忙程度可能会超出你的想像.
**** 18:59:10
是的。看了你们的要求，感觉自己能力还不够。你们那里待遇怎样?
三少 18:59:32
钱不是问题
只要你能达到老板预期的要求,对于水平不同的人,会有不同的待遇
**** 19:00:26
呵呵，其实一些技术细节掌握起来也很容易。我喜欢把oracle里的一些技巧编写成自己用的工具软件。便于使用
**** 19:01:05
工作是长期性的，还是暂时性的
三少 19:01:24
当然是长期的
在客户这里上班,维护oracle
**** 19:02:28
不错，感觉做维护比开发压力小些
三少 19:02:56
那是你想像的吧,所有人都说维护压力大.
**** 19:03:24
我做开发，每天工作都在12小时以上。
**** 19:03:48
做维护的，如果是开发人员转过去的，会好一些
三少 19:03:57
开发的工作,那种只是事情多
我每天工作也差不多了
你试过半夜害怕电话响?
试过全省业务宕机,就等你恢复?
三少 19:04:17
试过系统变慢,客户每5分钟一个电话问你进行的如何了?
**** 19:04:39
可是如果你维护好了，注意点跟客户解释清楚了。系统也不至于那么脆弱
三少 19:04:41
作开发,只要计划好,这些情况都不会出现.
三少 19:05:02
不是系统脆弱
而是系统太大,业务就那么繁忙.
你以为解释好了就可以呀,晕倒.
**** 19:05:04
如果真的有那些地方很脆弱。我会写个软件。让客户自己恢复
三少 19:05:53
哈哈,我们作的和你想像的不一样,你那是可以停机的系统
我的系统,几十颗cpu的RAC环境,几百g内存,
并发连接4k以上.
**** 19:06:00
哦，那也可能是软件系统写的不够好。 容易死锁，事务控制不好等等；
三少 19:06:15
有些东西不是那么简单的,真的.
三少 19:06:24
你在这么大的系统上试试就知道了.
**** 19:06:33
我明白，其实每个工作都有它的难处
三少 19:06:54
当然很大
**** 19:07:15
你们员工平均待遇如何？
三少 19:07:20
作开发,你有犯错误的机会,软件有问题,你可以说是bug
可是我这里,你一个误操作,很可能全省业务宕机.
三少 19:07:36
你觉得多少才算合适?
我说过我们这里高压力,当然高收入,
**** 19:07:45
对，我的软件有上百个bug都正常
三少 19:08:09
可是,我这里不能有任何误操作
一个误操作,业务宕机,后果不堪设想.
**** 19:08:11
我目前收入10w左右。我想如果能过去，应该提高1.5倍
三少 19:08:26
是提高1.5倍,还是提高到1.5倍.
**** 19:09:07
15w 吧。要求不算高吧。不过我目前对oracle 管理也没达到很高的水平
三少 19:09:31
那要看你oracle管理的能力了
你管理过的最大的数据库多大,并发度多少?
**** 19:09:38
不过，让我写存储过程，触发器，包 等业务代码 应该比一般维护的人强很多
三少 19:09:57
我晕,我们的维护不需要写程序的
我们是oracle dba,不是oracle developer
**** 19:10:02
我都是管理我们公司自己开发的系统。 数据库最大的10G一下
**** 19:10:20
我明白，侧重点不一样
三少 19:10:27
10g以下,这个,这个,
我们现在最小的库,内存都比你的数据库所有数据量要大.
**** 19:11:21
我打算考个ocp, 我一个同事oracle 懂个皮毛，也通过ocp了
**** 19:12:00
是啊，我oracle用了7年，也算有点造诣。
三少 19:12:06
ocp考过了也没用
我们看中的是经验呀
我们同事最少都有2个证书.
**** 19:12:38
知道没用。一般没什么经验考出来的，基本是水平不如我
三少 19:12:57
这样吧,要不我们随便聊几个技术问题?
**** 19:13:02
可以
三少 19:13:38
1:我现在一个update操作,需要200M的redo,但是我有3组redo ,每组50M,请问,在非归档和归档模式下,分别能完成这个操作吗?why
**** 19:14:41
不懂
三少 19:14:57
ok
oracle 8i用过吗?
三少 19:15:16
在8i中非常经典的问题.
**** 19:15:27
用过。不过那时2004年前用的
三少 19:15:34
ora-01555这个错误产生的原因是什么,如何避免.
**** 19:16:22
好像是事务太大
**** 19:16:41
一个会话做的事情太多
三少 19:16:45
什么是好像列?什么事物过大,为什么会出现,
三少 19:17:04
一个会话作的事务太多,怎么样是事务太多?
**** 19:18:20
把相关参数设大。
三少 19:18:30
相关参数,是那些参数?
三少 19:19:01
如何设置?
**** 19:19:17
呵呵，这个我平时工作中没用到。万一出现了。我上网查一下。
**** 19:19:30
把这个功能可以写成一个软件
三少 19:19:34
dataguard用过吗?
**** 19:20:23
没有过。用过toad .plsqldev
三少 19:20:53
大哥,你不是没事忽悠我吧.
**** 19:21:03
我已经跟你说过了，我偏重于开发。所以这些技巧我都不熟
三少 19:21:31
那恕我直言.可能这个职位的要求和你相差比较远呀
**** 19:21:55
是很远。不过给我一个月的时间。我想能超过一般的人员
三少 19:22:05
你以为真的可以吗?
**** 19:22:32
因为我的软件技术多。
**** 19:22:45
能解决问题的途径方法多
三少 19:23:07
好,我再问你个问题吧
如果客户突然向你抱怨,系统运行很慢
我让你去处理这个事情
你如何着手
三少 19:24:04
你怎么开始工作吧,说说你的思路.
**** 19:24:27
zui
**** 19:24:48
用工具查看oracle 的各种参数
**** 19:24:59
看看那些参数需要调整
三少 19:25:10
我真的要昏迷了.
三少 19:25:21
现在假定所有参数全部正常.
三少 19:26:50
你如何着手?
**** 19:26:57
从做索引
三少 19:27:06
为什么?
**** 19:27:40
CREATE OR REPLACE PROCEDURE HOLLEYWMS.sys_ANALYZE
IS
/*********************************************************************
过程名: sys_ANALYZE
功能点: 对表和索引优化
描述: 做成 作业计划(job)每周执行一遍；
提供参数:
返回参数:
开发: ******
时间: 2006-02-06 17:27
*********************************************************************/
tmp_val VARCHAR2 (20000);
—p_cursor cursor_types.cur_type;
TYPE t_usr_cur IS REF CURSOR; —定义游标类型
p_cursor t_usr_cur ; —动态游标
BEGIN
—得到未设置的中间库表的表名；
OPEN p_cursor FOR
SELECT ‘ANALYZE ‘||object_type||’ ‘||object_name||’ compute statistics’ as xx
FROM user_objects
WHERE object_type IN (‘TABLE’, ‘INDEX’)
ORDER BY object_type DESC ;
LOOP
FETCH p_cursor
INTO tmp_val;
IF p_cursor%NOTFOUND
THEN
GOTO abc;
END IF;
BEGIN
EXECUTE IMMEDIATE tmp_val;
DBMS_OUTPUT.put_line (tmp_val);
EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.put_line (‘Error: ’ || tmp_val || ‘!’);
END;
END LOOP;
<>
CLOSE p_cursor;
END;
/
三少 19:27:57
我的问题是,为什么要重作索引?
**** 19:28:20
好像是能减少碎片。不过多做也不好
三少 19:28:35
你解决问题,是靠猜测吗?
三少 19:28:51
为什么参数正常的情况下,你没有任何理由就去重作索引?
**** 19:29:15
通过一些sql
**** 19:29:31
语句找出消耗资源的 语句
三少 19:29:35
通过什么sql,你判断要重作索引.
三少 19:29:56
你为什么觉得系统慢,你就一定要找出消耗资源的语句,消耗什么资源的?
**** 19:30:07
网上有，能发现系统瓶颈的sql。我背不了
三少 19:30:28
你的意思是,你是边google,边工作了?
**** 19:31:27
这个可以放在自己软件里
三少 19:31:48
大哥,你真的不是准备今天忽悠我下的吧.我总觉得有点奇怪.
**** 19:31:58
就算是dba，也没有必要一直在dos下敲命令把
三少 19:32:50
我能告诉你的是,客户的系统,不允许其他软件接入;
我们使用的是unix主机,不知道你想要个什么样的图形界面.
**** 19:34:15
就是ｕｎｉｘ ，如果让我搞维护，我也会自己写一套自己使用的图形化软件
三少 19:35:13
我看到此结束吧
我还有点忙.
**** 19:35:21
ok
真的不知道是不是那个老大看我最近比较无聊,来忽悠我下,让我开心,如果是这样,直接请我看电影就好了呀.唉.