昨天，遇到了一个测试的环境，虽然在启动脚本中，使用-server参数指定了sun jvm的运行模式，但是通过ProcessExplorer来看，居然是运行在client模式下，后来以为是打开了调试端口导致的，jvm_opts=%jvm_opts% -classic -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=%port%,server=y,suspend=y，最后发现时因为-classic造成的，解释参见 http://wangpan80.javaeye.com/blog/248708

  前天同事反映在测试环境中，给表创建新的分区时，出现了：
  根据经验和oracle官方的解释，是所在表空间的空间不够导致的，但是根据OEM观察，这个表空间的还有不少未使用的部分，这下就比较迷惑了。
  当把oracle的alert.log文件拿出来分析后，发现有提示指明temp表空间不足了，当扩展了temp表空间的数据文件后，异常消失了，看来temp表空间的不足也能引发 ORA-01658异常，并且是提示另一个表空间，值得注意

  今天在linux搭建的IPV6环境下重新启动了一下oracle，在启动listener时得到如下的输出：
 
  根据提示listener在start后，显示启动成功，但是查看状态时报错，随即分析了Listener的日志，并且将listener的trace level设定为了admin，也无法定位问题。
  随后，在google进行搜索，发现在linux下出现listener相关的问题，有很大部分是和/etc/hosts的配置有关，特别是其中一篇提到在/etc/hosts 中没有设定 127.0.0.1，会产生错误，的确在这个IPV6的环境中，已经将127.0.0.1从/etc/hosts，替换为::1,在/etc/hosts恢复了127.0.0.1的配置，问题解决。不知这个问题是否oracle的一个缺陷？特别是启动的提示太有误导了，一点提示都找不到

   今天在IPV6环境下使用NET-SNMP搭建了一个snmp Agnet，搭建步骤记录在此，操作系统为CentOS 5.3
1.安装NET-SNMP，需要安装 net-snmp，net-snmp-libs,net-snmp-utils,其对应的rpm都能在CentOS的安装盘中找到。
2.修改/etc/snmp/snmpd.conf,内容如下，其中2001::/64是snmp manager所在IPV6的子网前缀：

rwcommunity6 public

com2sec6 mynet 2001::/64 public

group mygroup v1 mynet
group mygroup v2c mynet
group mygroup usm mynet

view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1

access mygroup "" any noauth exact all all all
3.修改snmpd
snmpd -f -L udp:161,udp6:161 -d -c /etc/snmp/snmpd.conf
4.在2001::/64子网中另一台主机上，运行如下命令进行测试，其中2001:468:181:f101:20c:29ff:fe5d:10b4为agnet所在主机的IPV6地址
snmpwalk -v 2c -c public udp6:[2001:468:181:f101:20c:29ff:fe5d:10b4] system

     摘要: 使用String对象作为锁时，可能会因为String对象是通过“”创建，而造成程序出现死锁的现象  阅读全文

软件架构的十大错误

作者 Niclas Nilsson译者 郭晓刚 发布于 2007年10月17日 上午10时49分

IASA成员Eoin Woods发表了一篇文章讲述他所认为的十大软件架构错误——常常要碰得头破血流才会得到的一些教训。这十大错误简要总结如下：

1. 不能界定项目范围。“在这种情况发生时，一个简单的出差登记系统结果变成内建了完整的花费报销管理系统，项目费用、时间跨度和质量都留下不可避免的烂摊子……除了简单的登录真的不需要安全措施了？用户登录系统后真的不能够执行任何系统操作吗？”
2. 网撒得不够宽。“我们都曾经犯过的一个错误是，只关注系统所有利益相关者中的一两方——通常受让人（为系统出钱的人）和最终用户得到了全部的关注。”
3. 只关注功能。“……除非系统表现出了全面的高质量（诸如性能、安全、可维护性等等），否则不太可能成功。”
4. 用方框和线条来描述。“[一个无所不包的]巨大的Visio图无法成为有效的架构描述，有两个原因：第一，它试图在单一表示中呈现太多信息；第二，没人真正清楚地知道你画的各种符号到底表示什么意思。”
5. 忘了需要培养的过程。“在建造系统的时候常常需要小心的事物包括：开发者和测试者没法真正理解设计，他们不热衷或者没时间学习技术，以及还没有很好的工具支持的新技术，或者新技术会强迫人们以新的不熟悉的方式工作。”
6. 平台定义不精确。“光用‘需要Unix和Oracle’来描述你的平台是不足够的。你需要精确地说明每一部分具体的版本和配置，才能保证得到你所需的平台。不然如果有人好心为平台的某一部分升级了一个库，就可能导致某些东西停止运作。精确定义平台你才能在部署中避免这样的情形。”
7. 对性能和伸缩能力想当然。“及早开始考虑性能和伸缩性，构建性能模型尝试预测关键的性能指标并定位瓶颈，在设计逐渐成型的同时投入到一些实际的验证性工作中去。这会帮助你提高对设计中不存在严重性能和伸缩性缺陷的信心。”
8. 自己发明安全技术。“多年来许多系统所犯的一个错误是试图加入自己发明的安全技术来提高系统安全性。比如定制的加密算法，开发者自己编写的审核系统，甚至完全DIY的访问控制系统。自家开发的安全方案基本上都是不明智的。虽然很多人都以为自己可以马上搞出一些聪明的安全技术，但通常都只是自作聪明。”
9. 没有灾难恢复。“要想得到资源来实现系统的灾难恢复机制，其关键在于在若干真实的场景中，具体衡量系统不可用所导致的损失。如果你还能估算这些场景发生的概率，你就可以用这两组数据去说服人们灾难恢复的重要性，并获得合理的预算去实现它。”
10. 没有撤退计划。“确保无论在系统部署或升级的过程中发生任何事，你都有一份书面的、经过审查的、一致同意的撤退计划，允许你将整个环境恢复到部署之前的状态。”

Eoin Woods是UBS Investment Bank的软件及企业架构师。

查看英文原文：Top Ten Software Architecture Mistakes

   今天升级诺顿后,居然导致系统瘫痪了,而且我还重装了,我的资料呀~~~~~~~~,