昨天，遇到了一個測試的環(huán)境，雖然在啟動腳本中，使用-server參數(shù)指定了sun jvm的運行模式，但是通過ProcessExplorer來看，居然是運行在client模式下，后來以為是打開了調(diào)試端口導(dǎo)致的，jvm_opts=%jvm_opts% -classic -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=%port%,server=y,suspend=y，最后發(fā)現(xiàn)時因為-classic造成的，解釋參見 http://wangpan80.javaeye.com/blog/248708

  前天同事反映在測試環(huán)境中，給表創(chuàng)建新的分區(qū)時，出現(xiàn)了：
  根據(jù)經(jīng)驗和oracle官方的解釋，是所在表空間的空間不夠?qū)е碌模歉鶕?jù)OEM觀察，這個表空間的還有不少未使用的部分，這下就比較迷惑了。
  當把oracle的alert.log文件拿出來分析后，發(fā)現(xiàn)有提示指明temp表空間不足了，當擴展了temp表空間的數(shù)據(jù)文件后，異常消失了，看來temp表空間的不足也能引發(fā) ORA-01658異常，并且是提示另一個表空間，值得注意

  今天在linux搭建的IPV6環(huán)境下重新啟動了一下oracle，在啟動listener時得到如下的輸出：
 
  根據(jù)提示listener在start后，顯示啟動成功，但是查看狀態(tài)時報錯，隨即分析了Listener的日志，并且將listener的trace level設(shè)定為了admin，也無法定位問題。
  隨后，在google進行搜索，發(fā)現(xiàn)在linux下出現(xiàn)listener相關(guān)的問題，有很大部分是和/etc/hosts的配置有關(guān)，特別是其中一篇提到在/etc/hosts 中沒有設(shè)定 127.0.0.1，會產(chǎn)生錯誤，的確在這個IPV6的環(huán)境中，已經(jīng)將127.0.0.1從/etc/hosts，替換為::1,在/etc/hosts恢復(fù)了127.0.0.1的配置，問題解決。不知這個問題是否oracle的一個缺陷？特別是啟動的提示太有誤導(dǎo)了，一點提示都找不到

   今天在IPV6環(huán)境下使用NET-SNMP搭建了一個snmp Agnet，搭建步驟記錄在此，操作系統(tǒng)為CentOS 5.3
1.安裝NET-SNMP，需要安裝 net-snmp，net-snmp-libs,net-snmp-utils,其對應(yīng)的rpm都能在CentOS的安裝盤中找到。
2.修改/etc/snmp/snmpd.conf,內(nèi)容如下，其中2001::/64是snmp manager所在IPV6的子網(wǎng)前綴：

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子網(wǎng)中另一臺主機上，運行如下命令進行測試，其中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對象是通過“”創(chuàng)建，而造成程序出現(xiàn)死鎖的現(xiàn)象  閱讀全文