昨天，遇到了一個測試的環境，雖然在啟動腳本中，使用-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