张家港专科华为认证
来源：教育联展网 编辑：佚名 发布时间：2018-10-30
关于我们
苏州竞予信息科技有限公司拥有电信级的网络实验室，涵盖路由交换、运营商、网络安全、语音协作、视频会议、无线通信、虚拟化、存储、数据中心、及红帽系统等众多专业技术领域。
苏州竞予信息科技有限公司也是一家专业的信息网络提供商，专注于帮助客户规划、构建、维护和管理网络基础设施。为客户提供网络架构、信息安全、融合通信、联系中心、数据中心、云计算、应用交付、服务管理等解决方案，能够为金融、电信、能源、媒体、医疗等各个领域提供专业服务。
苏州竞予信息科技有限公司的技术团队全部拥有厂商**高级别认证， 超过一半工程师具备多个CCIE证书。同时，苏州竞予工程师也是IT行业内的技术服务专家，相关领域工作经验平均超过6年，**长超过12年。
苏州竞予信息科技有限公司下属G-LAB IT实验室依靠专业团队、教材开发，G-LAB还为企业高级IT工程师进行技术升级和培训，并成为苏州乃至全国IT高端培训领域的领头羊。
华为认证网络工程师的发展前景怎么样？
华为认证网络工程师的发展前景如何？华为认证**早始于2001年，后来华为数通业务和3COM成立合资公司，取名H3C;华为认证从而归属H3C认证体系之下。
2012年左右华为重启认证体系，**开始路由交换方向具体认证名称为HCDA，HCDP等，后来统称为HCNA,HCNP,HCIE等，路由交换方向为HCNA-R&S,其他方向以此类推。
2013年，斯洛登事件以后，国家对网络安全空前重视，相继把国外的网络设备换成国产华为的设备。因此，华为的网络产品以及华为认证得到了非常好的发展机遇。很多集成商转向华为，成为华为的经销商。要成为华为的经销商，必然需要不同数量的，各个级别，各个方向的华为认证工程师。
产小于供，所以**近几年华为认证需求非常火热。
不过，认证本身的需求，必然会随着需求的平衡，而区于缓和。
但是，**认证的过程而学到的知识，必然让你终身受益。
如果你选择的网络工程师这个行业，从长远的眼光来看，无论是思科，华为还是华三认证其实都相差不大。关键是要学好技术。
当然，如果您关心网络工程师的发展前景，并且把这当成**重要的指标，来考虑是否从事网络工程师这个行业的话，那么任何行业，只要你能达到20%，那都会有不错的发展。所以，您只需关心在网络工程师行业如何达到20%。
华为大数据平台
华为大数据平台是有着丰富的市场实践的产品。华为FusionInsight大数据平台已在40 个国家，总计700 项目中实现了成功商用。客户包括中国石油、一汽集团、中国商飞、 工商银行、招商银行、中国移动、西班牙电信等众多世界500强企业。同时华为公司在 全球建成有13个开放实验室，在这里华为与各国200 合作伙伴进行大数据方案的联合 创新，包括SAP、埃森哲、IBM、宇信科技、中软国际等，共同推动大数据技术在各行 各业的应用。
RAC 启动过程出错各种实战
CRS启动4405错误
天津仓储一个项目今天现场DBA关了RAC，但启动时报错
Su –
#cd /u01/app/grid/product/11.2.0/bin
#./crsctl start cluster –n tjccdb1 tjccdb2
遇到crs-4405错误，
同时用如下命令
crsctl check crs crsctl check has 系统卡住了，命令不出来结果
这时连甚至连ps -ef的命令都挂起，halt命令无法停机。经询问现场人员，当时
停集群报错，重启服务器后再启动CRS就报这个错，查看CSSD日志，仲裁信息的混乱，在两个节点crs都是启动状态下，两个节点的crs进程都挂起。
用如下步骤来解决：
断电机器，1#节点启动后，crs与db启动正常，关闭db与crs，再启动2#节点，crs与db启动正常，然后启动1#节点的crs和db，恢复正常。
网上哥们遇到双节点RAC数据库，只能启动一个节点，无论哪个节点先启动，另外一个节点就无法正常启动了 具体就是使用hacmp 5管理共享磁盘，无法启动的表现就是可以mount，alter database open就hang在那不动
解决思路：
出现该问题前，客户进行了一下数据转换的操作，中间等待长时间无反应，所以**后选择重启数据库，然后hang住很长时间，然后shutdown abort关闭数据库，然后再启动就出现上述问题！
到达现场，开始尝试启动无法启动的数据库，发现就是hang在alter database open的过程，如果不做任何操作，就一直hang在这个过程不动，观察系统负载，没有任何变动，如果这时候关闭**个启动的节点，第二个启动的节点就能完成正常启动。这个过程数据库中在做什么呢？
判断来判断去，在metalink中也搜索半天，发现有个两个bug可能导致这个问题，但是打相应patch后依然如故！两个patch分别为p5106909和p5190596，感兴趣可以去参考下！
分析从故障开始的日志，发现在alert日志中有Waiting for clusterware split-brain resolution，中文就是脑裂，怀疑网络存在问题，但是使用ping命令ping心跳地址，正常！！！
系统中errpt有：
4507DE58 0507180209 I H ent2 ETHERNET NETWORK RECOVERY MODE
DED8E752 0507180209 T H ent2 ETHERNET DOWN
4507DE58 0507180209 I H ent5 ETHERNET NETWORK RECOVERY MODE
DED8E752 0507180209 T H ent5 ETHERNET DOWN
系统工程师说是网卡模式问题，应该没什么影响！（我就相信了据说是IBM的工程师，结果后来……唉！）
所以下面我就又开始折腾这个数据库啊，各种方法尝试，折腾一天，没有什么眉目，回去休息，明天继续吧！
结果第二天一来，客户就告诉我，应用的工程师，把两个数据库节点都给起来了，方法就是：启动第二个节点的时候，在**个节点执行命令：alter system flush buffer_cache;就是清空**个启动节点的buffer cache，然后第二个节点就能正常启动了！不知道他是怎么想到的，但是这就说明，其实第二个节点启动时候hang在了同步buffer cache的过程了，清除了**个节点buffer cache就好了！具体猜想应该是数据字典！
虽然是都启动了，但是这种方式绝对不是解决办法，因为如果再有需要同步cache的操作，数据库还是会出现问题，结果运行了大约1个多小时，数据库果然出现问题：又出现脑裂，日志如下：
Thu May 7 09:19:11 2009
IPC Send timeout detected. Receiver ospid 160682
Thu May 7 09:19:11 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lms0_160682.trc:
Thu May 7 09:19:12 2009
Trace dumping is performing id=[cdmp_20090507091857]
Thu May 7 09:20:52 2009
Waiting for clusterware split-brain resolution
Thu May 7 09:25:55 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May 7 09:25:56 2009
Trace dumping is performing id=[cdmp_20090507092556]
Thu May 7 09:25:56 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May 7 09:25:56 2009
LMON: terminating instance due to error 481
Instance terminated by LMON, pid = 114856
明天还要去客户现场，又是9点到，还在南城，睡觉～
未完待续～～～～～～～～～～
还是继续写完吧～～～～～～～
后来经过检查，发现在netstat -s查看时发现有丢包现象，但是还是没有引起我的足够注意，再后来我实在是找不到原因，只好建议客户从网络和系统方面都排查！正好这时候客户请来另一家的工程师解决，我觉得人家在两个方面做得比我好：
1、先是去看了现场硬件配置环境（我就没去看过）
2、从可能的原因一一排查（我就一直专注于找到比较可信的原因）
可能是在一家公司呆久了，也可能是经常一个人解决问题，行成了自己的固定思维模式，总之，**后是我没有找到比较可行的解决方法，而另一家公司的工程师建议客户排除网络（心跳线等原因）、系统等方面，再想起他方法，结果心跳线一换就ok啦～～～～～～～
点评：其实从Instance terminated by LMON, pid = 114856 这里显示LMON----来终止实例，LMON就是各个实例的LMON进程会定期通信，以检查集群中各个节点的健康状况，当某个节点出现故障时，负责集群重构、GRD恢复等操作，它提供的服务叫做Cluster Group Services。从这里看这个实例LMON通信不正常， 这个表明是心跳问题。
惜纷飞的例子：
solaris 11.2 两节点rac无法启动，让我帮忙看下。**分析是因为sga_target参数设置不合理导致asm无法正常启动
GI无法正常启动
grid@zwq-rpt1:~$crsctl status resource -t
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status failed, or completed with errors.
grid@zwq-rpt1:~$crsctl status resource -t -init
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
1 ONLINE OFFLINE Instance Shutdown
ora.cluster_interconnect.haip
1 ONLINE ONLINE zwq-rpt1
ora.crf
1 ONLINE ONLINE zwq-rpt1
ora.crsd
1 ONLINE OFFLINE
ora.cssd
1 ONLINE ONLINE zwq-rpt1
ora.cssdmonitor
1 ONLINE ONLINE zwq-rpt1
ora.ctssd
1 ONLINE ONLINE zwq-rpt1 ACTIVE:0
ora.diskmon
1 OFFLINE OFFLINE
ora.evmd
1 ONLINE INTERMEDIATE zwq-rpt1
ora.gipcd
1 ONLINE ONLINE zwq-rpt1
ora.gpnpd
1 ONLINE ONLINE zwq-rpt1
ora.mdnsd
1 ONLINE ONLINE zwq-rpt1
这时查看CSSD，发现
[/export/home/app/grid/bin/oraagent.bin(1348)]CRS-5019:All OCR locations are on ASM disk groups[CRSDG], and none of these disk groupsare mounted. Details are at "(:CLSN00100:)"in"/export/home/app/grid/log/zwq-rpt1/agent/ohasd/oraagent_grid/oraagent_grid.log".
ASM都起不来了，OCR和VOTING DISK 肯定加载不起来，不报错才怪。继续看ASM日志
/export/home/app/oracle/diag/asm/ asm/ ASM1/trace/ ASM1_ora_1732.trc (incident=291449):
ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","unknown object","KGLH0^34f764db","kglHeapInitialize:temp")
这时报share pool 不能allocate,进到pfile查看
ystem parameters with non-default values:
sga_max_size = 2G
large_pool_size = 16M
instance_type = "asm"
sga_target = 0
这里不能自动管理，而有没有设置share pool，这时只需要设置，再重启CRS即可。
相关推荐：
上一篇：太仓华为认证要怎么考 下一篇：苏州华为认证计算机培训