Reason[2071]MQRC_STORAGE_NOT_AVAILABLE

客户给我发邮件,反映以下问题:也就是应用测试时,应用日志报错如下:

2018-09-27 08:53:40.688-0003 CSPS        aosRecvMerc.c 261 IBMMQ_ERROR  11825914
 CTISMQ00 k03201 8585228 31208821
连接MQ消息队列管理器[Css7806QMgr]失败
MQ Error:CompCode[2]MQRCMQCC_FAILED, Reason[2071]MQRC_STORAGE_NOT_AVAILABLE

经过分析,与搜索IBM 官网support网站,并且凭经验,综合分析,并给客户作出如下答复:

通过分析报错日志所得,针对以下问题,提出如下建议:
首先:
1、确认连接MQ的JAVA代码里,正确连接MQ 队列管理器。即队列管理器没有写错。
2、应用代码访问的MQ队列没有写错。也就是应用没有访问错误的MQ队列。
3、写入MQ 队列的报文不能太大,IBM官方建议写入队列的信息报文尽量不要超过4M,如果超过,请将报文分段写入MQ队列。
其次:
1、如果确认应用代码没有错误,并且读入MQ队列的报文没有超过4M,并且报文格式没有错误。那就按下面方法,调整系统文件大小限制和MQ 队列管理器的最大信息大小值:
如下所示:

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

  1. 1、In /etc/security/limits, increase the “data” ulimit for the account used to start the queue manager (usually root) to 192 MB or greater. Setting the data segment size (ulimit -d) to unlimited will resolve the issue. Note that the value is configured in 512 byte blocks, and -1 means unlimited.
  2. 2、In runmqsc, decrease the queue manager’s MAXMSGL attribute to something like 33554432, depending on the “data” ulimit value.

 

IHS升级到最新补丁报400/406错误

今年九月份,IBM 对外公布了IBM WebSphere Application Server远程代码执行漏洞,也就是CVE-2018-1567 漏洞,并在官网提供修补补丁以及匹配的补丁包。客户为了安全起见,也为了回应上面总部下发的修补要求,也就安排在省分公司,组织人员与安排时间,对现有的WAS系统修补这个漏洞。

客户的应用环境是IHS/WAS8.0.0.7,需要升级到was8.0.0.15,才可以打修补PI95973.  (今天才发现这个补丁已经升级,2018.10.13已经升级成PH03986),客户在上周四晚,在现有系统升级到IHS/WAS8.0.0.15,就打上这个IF95973, 打完后,客户业务同事就反映有个应用访问有点异常,具体问题 就是,发现有个应用没升级前,某个地级市 节点是正常往省行分享出来的端口POST数据,而升级后就不能正常 POST数据,并且在IHS的 access.log日志里,报400/406错误代码,奇怪的,有几个地级市往这个省行分享出来的接口POST数据,是正常,就这个地级市 POST数据时,报400/406错误。客户技术人员排查一天,都找不出问题 ,就要求我过去一起排查,过去后,要求客户重启布署在WAS的应用,并查看systemout.log,发现日志没有异常信息,确认WAS应用没有问题,再查看IHS/WAS的 versionInfo.sh输出信息,确认IHS/WAS版本已经成功升级到ihs/was8.0.0.15.  起初,怀疑是省行这边IHS作升级时,地级市的应用没有停止,致使地级市应用跟省行接口的网络进程不一致。致使地级市跟省行的IHS的网络进程 不同步。不一致。建议地级市重启地级应用程 序,但经过沟通,地级市应用不能重启,因为影晌面大。那只能将排查重点再放到省行IHS升级这个方向上,查看IHS的access.log时,除了发现这个地级市POST数据时报400/406错误,其它地级市节点访问省行这边的都正常。排查很久,都找不出问题所在,决定将IHS回滚,回复到没升级的IHS版本,即是ihs8.0.0.7版本。加上客户的业务运维技术人员也强烈要求回滚。于是进行IHS回滚,就从NBU备份,将IHS的版 本回复到ihs8.0.0.7.  回滚完后,重启IHS后,客户业务运维人员就反映,该地级市的应用的数据就正常POST到省行的接口上,原来问题 出在IHS的补丁升级上,

事后,查了查400/406错误,都是说跟MIME.type类型有关。估计是IHS8.0.0.7升级到IHS8.0.0.15后,新增了一些MIME.type 类型 ,而地级市的应用还是用回IHS8.0.0.7的MIME.type,这个应该是之前应用的开发人员沟通后,定义好所有的MIME.type类型的。IHS一升级后,就出现MIME.type类型不兼容的情况。而客户因为没有完整模拟到客户应用系统的数据环境,所以没有经过测试,就直接在生产环境升级IHS的版本到最新的IHS8.0.0.15版本,致使出现之前的应用无法访问的情况。需要最后回滚到没升级前的版本。

ORACLE12C RAC For RHEL6.5 linux 配置注意事项

国庆节前,完成VMWRE WORKSTATION RHEL linux环境下,ORACEL12C RAC环境的安装,在安装地程中,虽然参考一些网上一些技术文档,但发现在实际配置过程中,还是有一要特别注意的地方,因而记录下来,方便日后,查证。、

关于共享磁盘的创建:

在虚拟机里,创建一个三个硬盘,一个是DATA(数据盘),一个是ocr_vote(投票仲裁盘),一个是FRA(快速恢复盘),分别是:8g,10g,10g, 建议这三个硬盘并建立在同一个sharestore文件夹下。

创建过程中,选择:立即分配所有磁盘空间 以及将虚拟磁盘存储为单个文件。

创建磁盘后,打开虚拟机设置,选择硬盘,点击右下角的高级,在虚拟设备节点,下拉框,选择SCIS1:X 硬盘(SCSI),第一个新增的硬盘就是:SCIS1:0 硬盘2(SCSI), 第二个新增的硬盘就是:SCIS1:1 硬盘3(SCSI), 第三个新增的硬盘就是:SCIS1:2 硬盘4(SCSI)。 模式就 选 独立 ,选 永久.

建多一个网络适本器:网络适配器2 的网络连接状态选自定义(U):特定虚拟网络:VMnet2. 配置RAC环境的每台机都要建.

关于共享磁盘的设置:

在一台机创建并设置三个硬盘后,打开这台机机虚机的vmx文件,加上以下内容,方便另外一台机正常访问这台机新增的三个硬盘。特别要注意,加以下文件内容时,要关掉VMWARE WORKSTION,而不是只关掉虚拟机。如果只是关掉虚拟机,而不是关掉VMWARE。改完vmx文件后,再重启虚拟机,会报字典错误。

fileSearchPath = “.”

scsi1.present = “TRUE”

scsi1.virtualDev = “lsilogic”

scsil.sharedBus = “VIRTUAL”

scsi1:0.present = “TRUE”

scsi1:0.mode = “independent-persistent”

scsi1:0.fileName = “E:\ShareStore\rac12c\ocr_vote.vmdk”

scsi1:0.deviceType = “disk”

scsi1:0.redo = “”

scsi1:1.present = “TRUE”

scsi1:1.mode = “independent-persistent”

scsi1:1.fileName = “E:\ShareStore\rac12c\data.vmdk”

scsi1:1.deviceType = “disk”

scsi1:1.redo = “”

scsi1:2.present = “TRUE”

scsi1:2.mode = “independent-persistent”

scsi1:2.fileName = “E:\ShareStore\rac12c\fra.vmdk”

scsi1:2.deviceType = “disk”

scsi1:2.redo = “”

阅读更多