Skip to content

Unix and Linux - 2. page

Killed远程登录Oracle的所有进程的方法

此方法用在停应用系统后,清除所有远程登录的客户端进程,特别是在进程过多的情况下。

!!!切忌千万不要在生产端轻易运行,否则后果自负

脚本:killsess.sh

########killsess.sh#########
#author:ludatou@2014/07/24 feigigi@qq.com
#desc:kill all session connect from client
ps -ef | grep LOCAL=NO | grep -v grep|awk '{if($3~/^[0-9]+$/)print $2}' > sessinfo.out
cat sessinfo.out |while read pid
do
  kill -9 $pid
done
cat /dev/null > sessinfo.out

例子:

[root@ludatou ~]# ps -ef | grep LOCAL|grep -v grep
ora10g   22367 22333  0 20:21 ?        00:00:00 oraclelu10g (DESCRIPTION=(LOCAL=NO)(ADDRESS=(PROTOCOL=beq)))
[root@ludatou ~]# chmod +x killsess.sh
[root@ludatou ~]# ./kiilsess.sh
[root@ludatou ~]# ps -ef | grep LOCAL|grep -v grep
[root@ludatou ~]# 

关于Aix上的逻辑卷偏移量

##########################
www.ludatou.com 大头
转载请指明处,否则追责法律责任
##########################

在AIX5.3中,系统支持三种类型的VG,分别是Original VG、Big VG、Scalable VG(AIX5.3的新特性)。
mkvg命令默认将创建Origninal VG:最大支持32 physical volumes and 255 logical volumes
mkvg –B命令将创建Big VG:最大支持128 physical volumes and 512 logical volumes
mkvg –S命令将创建Scalable VG:最大支持1024 physical volumes, 256 logical volumes and 32k physical partitions

应用程序直接访问LVCB是比较危险的,因此在建立数据文件使用的裸设备时,不能从逻辑卷开始位置,而是应该有一个偏移量(offset),偏移量的大小应大于LVCB的大小,一般用一个AIX逻辑块的大小做偏移量,即4096字节。Oracle数据库会自动跳过前 4k不用,这样保证了lvcb不会被覆盖,但这带来了另一个潜在的问题,当 Oracle的db_block_size大于4k的时候,一个Block可能跨在两个PV/LUN/磁盘上(如果做了条带化,那么将总有数据块跨在两个条带上–其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候,很有可能造成大量的IO不完整,一个PV上IO写入,另一边可能未完成,启动Oracle的时候将会看到ORA-1578 错误,这几乎是致命的。
原有的带有偏移量的lv类型就叫做DS_LV。未解决上述问题,AIX引进了一种新的LV类,也就是“Z”类型LV,这种类型的LV通过lslv -L lv_name可以看到它的类型为:DS_LVZ。
零偏移量LV的创建:
1.在Origninal VG中,不论是否使用“-T O”参数,创建出来的lv都是DS_LV类型。
2.在Scalable VG中,不论是否使用“-T O”参数,创建出来的lv都是DS_LVZ类型。
3.在Big VG中,使用“-T O”参数,创建出来的lv都是DS_LVZ类型,而不使用则是DS_LV类型。

由此可见,为了解决alert日志中报告的问题,使用scalable VG或是big VG创建DS_LVZ类型的LV(zero offset)即可解决。

检查lv是不是0偏移的裸设备命令:
1、用oracle账户执行:dbfsize /dev/rlv_test
2、lslv -L lvName
案例:

hz@bank:[/home/oracle]#lslv -L lvdata002
LOGICAL VOLUME:     lvdata002              VOLUME GROUP:   datavg02
LV IDENTIFIER:      00cffde300004c000000012157f880d8.81 PERMISSION:     read/write
VG STATE:           active/complete        LV STATE:       opened/syncd
TYPE:               raw                    WRITE VERIFY:   off
MAX LPs:            512                    PP SIZE:        256 megabyte(s)
COPIES:             2                      SCHED POLICY:   parallel
LPs:                16                     PPs:            32
STALE PPs:          0                      BB POLICY:      relocatable
INTER-POLICY:       minimum                RELOCATABLE:    no
INTRA-POLICY:       middle                 UPPER BOUND:    16
MOUNT POINT:        N/A                    LABEL:          None
MIRROR WRITE CONSISTENCY: off
EACH LP COPY ON A SEPARATE PV ?: no
Serialize IO ?:     NO
DEVICESUBTYPE : DS_LVZ

确认VG的类型,用命令 lsvg 看 MAX PVs 的值—-Normal: 32, Big:128, Scalable:1024 (不一定准确,准确的查询用下面的方法)

lqueryvg -At -g VGID(如00cffde300004c000000012157f8acd7)

10.111.4.1上查看到datavg03的 VG Type:1,0对应的是普通,1对应的是big,2对应的是scale

创建数据库使用的裸设备

mklv -y 'lvxscmxindx004' -T O -w 'n' -s 'n' -r 'n' -t raw datavg 20

关于AIX双网卡的负载均衡与HA冗余

在AIX上一般在开始设计的一套数据库后台系统时候,在Power AIX层面都会考虑到硬件的冗余,比如交换机,网卡,Host DISK,FC卡,FC线等,今日一个朋友提出疑问,在AIX层面做EtherChannel时候是否存在流量的负载均衡以及互备模式,AIX的EtherChannel模式如下,

1.Standard: 在这种模式下EtherChannel使用目标主机的IP地址来决定用哪一块网卡来发送数据。EtherChannel用目标IP的末字节除以成员网卡的个数的余数(模)来决定由哪一块网卡发送数据。比如目标IP是10.10.10.1, EtherChannel中有两块成员网卡, (1 % 2) = 1, 所以第二块网卡被用来发送数据 (网卡编号从0开始)。 网卡编号按照它们在smit界面中列出的顺序排列。对于非IP流量(如ARP), 目标MAC地址的末字节被用来进行计算。 这是默认的运行模式。

2.Round Robin: 在这种模式下各个成员网卡被轮流使用,每轮每个网卡发送一个数据包。

3.Network Interface Backup: 这种模式是用于AIX 5.1和AIX 4.3.3的网卡后备模式。在这种模式下,EtherChannel在任何时刻都只将一块网卡用于负担网络流量。主要用于网卡连接到不同的交换机上,并且通过任何的交换机都可以到达同样的网络的情况下。当检测到某个网卡-交换机连接出现问题时(通过网线检测或选择ping某个IP地址, EtherChannel将停止当前的成员网卡并启动下一个成员网卡。只有这种模式会用到Internet Address to Ping, Number of Retries和Retry Timeout选项。

4.Backup Adapter: 可选项。用于AIX 5.2的EtherChannel后备模式。指定您想要用来后备整个EtherChannel的网卡。

6.Internet Address to Ping: 仅用于网卡后备模式。EtherChannel会ping您在这里指定的IP地址。如果回应超时达到指定的数目,EtherChannel会切换网卡。 Number of Retries: 允许的回应超时的次数,默认是3。

7.Retry Timeout: 回应超时的时限。默认是1秒。

答案已经很明显,Round Robin模式具备此功能,只是这种模式采用轮询的方式,不够智能,所以建议流量负载均衡方面还是需要在网络层去规划。

遭遇ORA-27300: OS system dependent operation:fork failed with status: 12

系统平台为

Oracle Solaris on SPARC (64-bit)

数据库版本

11.2.0.3

遭遇这个错误主要是因为备份恢复出问题了,执行介质恢复一下吃光了而且系统告警日志报错如下:

/opt/app/oracle/diag/rdbms/standbydbrtps/RTPS/trace/RTPS_psp0_6332.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3

在系统的/var/adm/messages中同时也收到信息如下:

shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,

经过诊断与Oracle bug 18387547吻合.该bug信息如下:

Hdr: 18387547 11.2.0.3 RDBMS 11.2.0.3 SECURITY PRODID-5 PORTID-23
Abstract: MEMORY LEAK OF RECOVERY PROCESS IF TDE IS ENABLED

*** 03/12/14 01:45 am ***

PROBLEM:
--------
Customer uses TDE and physical standby. The memory will be eaten by the
recovery process (manual or managed).

DIAGNOSTIC ANALYSIS:
--------------------
When media recovery starts, process that do media recovery (ora_mrp if
recovery is run without parallelism or ora_pr if it is parallel recovery), is
allocating 96 bytes buffers in order to do ioctl() for /dev/crypto, but the
memory is not beeing freed (dtrace shows only malloc() calls, and no free()
calls). Each ioctl() call will be issued with new 96 buffer, and that will
deplete memory on server, causing server to stop once all virtual memory is
used.

In /var/adm/messages we can see the errors:
Feb 9 18:19:58 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16090 (oracle_server_mo)
Feb 9 18:21:43 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16097 (oracle_server_mo)
Feb 9 18:23:33 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16103 (oracle_server_mo)
Feb 9 18:25:19 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16106 (oracle_server_mo)
Feb 9 18:27:05 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16110 (oracle_server_mo)
Feb 9 18:28:54 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16117 (oracle_server_mo)
Feb 9 18:30:42 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16129 (oracle_server_mo)
Feb 9 18:32:31 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16138 (oracle_server_mo)
Feb 9 18:34:17 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16148 (oracle_server_mo)
Feb 9 18:36:03 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16151 (oracle_server_mo)
Feb 9 18:37:50 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16156 (oracle_server_mo)

In alert log:
Process startup failed, error stack:
Errors in file
/u01/app/oracle/diag/rdbms/standbydbrtps/RTPS/trace/RTPS_psp0_6631.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3

WORKAROUND:
-----------
Restart MRP

RELATED BUGS:
-------------


REPRODUCIBILITY:
----------------


TEST CASE:
----------


STACK TRACE:
------------


SUPPORTING INFORMATION:
-----------------------


24 HOUR CONTACT INFORMATION FOR P1 BUGS:
----------------------------------------


DIAL-IN INFORMATION:
--------------------


IMPACT DATE:
------------


*** 03/12/14 01:46 am ***
*** 03/12/14 01:47 am ***
*** 03/12/14 01:48 am ***
*** 03/27/14 04:40 am ***
*** 03/27/14 05:30 am *** (CHG: Sta->10)
*** 03/27/14 05:30 am ***

*** 04/01/14 01:27 am *** (CHG: Sta->16)
*** 04/01/14 01:27 am ***
*** 04/01/14 03:28 am ***
*** 04/01/14 04:54 am *** (CHG: Sta->10)
*** 04/01/14 04:54 am ***
*** 04/01/14 05:02 am ***
*** 04/15/14 11:25 pm *** (CHG: Sta->16)
*** 04/15/14 11:25 pm ***
*** 04/20/14 12:59 am *** (CHG: Sta->91)
*** 04/20/14 01:00 am ***
*** 04/20/14 01:00 am *** (ADD: Impact/Symptom->LEAK - DB MEMORY/OTH...)

libXp.so.6: cannot open shared object file,during installing oracle database 11g on rhel as 6.1 x64

报错信息:

/tmp/OraInstall2011-09-24_10-16-11PM/jre/1.4.2/lib
/i386/libawt.so: libXp .so.6: cannot open  shared object file: No such file or directory occurred..

这个错误是我在以前安装时候碰到的,最近问的人挺多,则顺便趁早上这个点发布出来.首先我们从错误上看能很明显看到是libxp.so.6这个文件出问题了,但是你使用rpm -qa | grap libXp你会发现,这个包已经安装了,
仔细检查你会发现,系统提示的是/tmp/OraInstall2011-09-24_10-16-11PM/jre/1.4.2/lib/i386/libawt.so,i386而不是686,而现在安装的平台都常都是linux 6.1 x64上,默认安装的libXp版本也是64bit版本的,所以这里的解决办法基本就可以明了了,使用rpm -e | grep libXp,然后安装正确的386版本的libXp即可。如果有依赖包先卸载依赖包。