solaris

说道“动态库版本兼容”，很多人头脑中首先蹦出的就是“Dll Hell”。啊，这曾经让人头疼的难题。时至今日，这个难题已经很好地解决了。 在进一步讨论之前来思考一个问题：Linux下为什么没有让人头痛的“DllHell”？ 回答这个问题，非常easy，因为——Linux下根本没有dll！ 哈哈，当然这只是个玩笑，接下来展开一下这个话题，很多有动态库的系统都会面临这个难题，但各自解决的思路却各不相同。 Dll hell是指windows 上动态库新版本覆盖旧版本，但是却不兼容老版本。常常发生在程序升级之后，动态库更新，原有程序运行不起来；或者装新软件，但是已有的软件运行不起来。 一、linux下的解决方案——命名规范 Linux 上的Dll ，叫sharedlibrary。Linux 系统面临和Window一样的问题，如何控制动态库的多个版本问题。为解决这个问题，Linux 为解决这个问题，引入了一套命名机制，如果遵守这个机制来做，就可以避免这个问题。但是这只事一个约定，不是强制的。但是建议遵守这个约定，否则同样也会出现 Linux 版的Dll hell 问题。 Real Name 首先是共享库本身的文件名：共享库的命名必须如 libname.so.x.y.z 最前面使用前缀”lib”，中间是库的名字和后缀”.so”,最后三个数字是版本号。x是主版本号(Major Version

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 系统出故障了。当年负责写这个程序的开发者早在十五年前就去世了，现在已经没有人能读得懂他的代码了...... 现在一些关键系统的运行仍依赖于过时的软件，但编写他们的人要么离职要么已经去世。中间也缺少维护或更新，导致现在几乎没人能理解它们，而且一旦出现 Bug 就会给企业造成不可挽回的损失。 而现实中的这种例子，远比你想象中的要多。 一个令人深思的故事 我的一位客户负责数项世界排名前一百的养老基金，该公司在前几个月成功的将程序搬到了云端。作为项目的主任架构师，前两天我很意外地直接收到了 CIO 的短信：“抱歉打扰，我们出 S1X 级的大问题了。你能下午飞过来吗？”。 “S1X”是他们对“比最严重级别还要糟，级联影响到业务其它非直接相关部分”问题的定义。 事情看起来十万火急，当天晚上我就飞到现场进行了诊断，发现是该客户的系统中一个批处理任务发生了崩溃。 该任务每天晚上执行一次，通过写一个 CSV 文件为某些养老金计算缴费率，再将计算的结果输出到另一个收益（benefit）分配程序。原先收益分配程序设定为在缴费（contribution）低于预测（projection）时会向客户发出报警。由于上一个处理任务已发生崩溃，不再产生输出，因此程序认为“所有缴费为零”。

Xshell Xshell 是一个强大的安全终端模拟软件，它支持SSH1, SSH2, 以及Microsoft Windows 平台的 TELNET 协议。Xshell 通过互联网到远程主机的安全连接以及它创新性的设计和特色帮助用户在复杂的网络环境中享受他们的工作。 Xshell可以在Windows界面下用来访问远端不同系统下的服务器，从而比较好的达到远程控制终端的目的。 SSH SSH 为 Secure Shell 的缩写，由 IETF 的网络小组（Network Working Group）所制定；SSH 为建立在应用层基础上的安全协议。SSH 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH最初是UNIX系统上的一个程序，后来又迅速扩展到其他操作平台。SSH在正确使用时可弥补网络中的漏洞。SSH客户端适用于多种平台。几乎所有UNIX平台—包括HP-UX、Linux、AIX、Solaris、Digital UNIX、Irix，以及其他平台，都可运行SSH。 Xftp Xftp是一个软件应用程序,可以帮助您通过网络传输文件。 尽管它是为工作在Windows系统上而设计的，用户还可以安全地传输文件到使用Unix /Linux系统的主机。 它还支持SFTP协议，因此所有通过该软件的网络流量都是加密的。

在Oracle业界混的兄弟们肯定听说过以下的2个传说： LISTENER.LOG日志大小不能超过2GB，超过会导致LISTENER监听器无法处理新的连接 Oracle Instance实例所在的主机运行超过198天必须重启，否则会遇到Oracle BUG 第一条传说LISTENER.LOG日志不能超过2GB，这个绝对是老DBA津津乐道要向新手介绍的经典经验之一，这条传说带来的负面思想是Oracle数据库的监听器最好不要启动过长时间， LISTENER.LOG日志的内容也要定期清理(这条还是应当推荐的)。 以上这个问题在本世纪初大量32bit OS存在的情况下仍是真理，毕竟在当时2GB的文件还算是挺大的。 引起该问题的主要原因是大量32bit OS自带的文件系统不支持2GB以上的文件，导致监听器append write，例如在Solaris 2.6上： OS Limits ~~~~~~~~~ Release Max file-system size Max OS File size < Solaris 2.6 1Tb (UFS) 2Gb >= Solaris 2.6 1Tb (40 bits) 1Tb 在32bit 的Linux上也存在过该2GB文件大小的限制，具体见： http://lkml.indiana.edu/hypermail/linux/kernel/9912.3

存储相关的Metrics disk /proc/diskstats $ cat /proc/diskstats 8 0 sda 19845 144 2468979 81307 5380 1084 181174 47385 0 19839 128640 8 1 sda1 168 0 48862 7580 10 0 4136 192 0 1151 7772 8 2 sda2 19612 144 2416997 73544 4757 1084 177038 44181 0 18997 117673 11 0 sr0 0 0 0 0 0 0 0 0 0 0 0 253 0 dm-0 19443 0 2407493 73345 5693 0 175134 58916 0 19577 132260 253 1 dm-1 206 0 7024 393 238 0 1904 8073 0 1385 8466 前3项是主设备号，次设备号和设备名称。 后面11个域的描述如下： Name units description ---- ----- ----------- read I/Os requests 完成的读请求次数 read merges requests 在IO队列中合并的IO次数，对于机械盘来讲，IO合并对性能帮助太大了， innodb设计中change buffer,double

-> start /SP/faulttmgmt/shell start: Invalid target /SP/faulttmgmt/shell -> start /SP/faultmgmt/shell Are you sure you want to start /SP/faultmgmt/shell (y/n)? y faultmgmtsp> fmadm faulty Time UUID msgid Severity 2019-10-21/13:51:44 7d6be8a5-d27c-6e12-fd6b-b809cde44fe2 DISK-8000-0X Major Fault class : fault.io.disk.predictive-failure FRU : /SYS/MB/HDD0 (Part Number: ) (Serial Number: ) Description : A fault has been diagnosed by the Host Operating System. Response : The service required LED on the chassis and on the affected FRU may be illuminated. Impact : No SP impact. Check the Host OS for

solaris 基本算是消失了， 但是偶尔遇到的老机器需要处理，遇到了记录一下。 console口登录 show /SP/network 查看管理口IP地址 http://IP 登录 默认用户名密码：root/changme 可以查看设备的fru信息、系统硬件状态，告警信息，启动方式等。 更多信息请参考https://docs.oracle.com/cd/E40836_01/ 来源： oschina 链接： https://my.oschina.net/u/4303818/blog/4258156