2012年9月17日
#
今天在做手機(jī)終端開發(fā)時，發(fā)現(xiàn)連上域名服務(wù)器老是連不上，而直接用ＩＰ連接是ＯＫ的，初步懷凝是ＤＮＳ問題引起來，經(jīng)查相關(guān)的資料，現(xiàn)記錄如下：
Android模擬器默認(rèn)的地址是10.0.2.3，默認(rèn)的DNS也是10.0.2.3，而一般電腦的IP都是192.168.1.100之類的，不在同一個網(wǎng)段。所以就會出現(xiàn)電腦可以上網(wǎng)但是模擬器不能上網(wǎng)的情況。其實設(shè)置方法很簡單，只要把模擬器的默認(rèn)DNS設(shè)置成電腦的DNS地址即可。
第一步：用系統(tǒng)的命令進(jìn)入Android開發(fā)包的tools目錄
cd X:\...\android-sdk-windows\tool
第二布：使用adb的shell，確認(rèn)系統(tǒng)的各項屬性
adb shell
getprop
getprop會列出系統(tǒng)當(dāng)前的各項屬性
第三步：得到模擬器的DNS地址
在結(jié)果里可以看到：
[net.dns1]: [10.0.2.3]
[net.dns2]: [10.0.2.4]
[net.dns3]: [10.0.2.5]
[net.dns4]: [10.0.2.6]
第四步：把dns改成我們自己的DNS
setprop net.dns1 192.168.1.1
連接的URL串
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=vip1)(PORT
=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=vip2)(PORT=1521))(LOAD_BALANCE=yes)(FAILOVER=
on))(CONNECT_DATA=(SERVICE_NAME=gs)))
啟動 lsnrctl start
狀態(tài) lsnrctl status
關(guān)閉 lsnrctl stop
導(dǎo)出命令：exp 用戶名/密碼@數(shù)據(jù)庫 owner=用戶名 file=文件存儲路徑（如：F:\abcd.dmp）
測試截圖：exp ZM/sql123@ORCL owner=ZM file=F\abcd.dmp
出.png)
導(dǎo)入命令：imp 用戶名/密碼@數(shù)據(jù)庫 fromuser=用戶名 touser=用戶名 file=d:\cu.dmp ignore=y
imp:命令類型
cu/mycu@db:導(dǎo)入的數(shù)據(jù)庫登陸(用戶名/密碼@數(shù)據(jù)庫)
fromuser:文件的指定用戶
touser：指定導(dǎo)入到當(dāng)前登錄的數(shù)據(jù)庫某個用戶
file:需要導(dǎo)入的數(shù)據(jù)文件
ignore:是否忽略創(chuàng)建錯誤
測試截圖：
imp ZM/sql123@ORCL fromuser=ZM touser=SZZM file=F:\test.dmp ignore=y
入.png)
linux環(huán)境下的rmi常見問題
問題一：RMI服務(wù)提供程序運行在Windows操作系統(tǒng)下，RMI服務(wù)可以正常訪問，但將RMI服務(wù)提供程序部署到Linux操作系統(tǒng)下后，RMI服務(wù)無法訪問，提示
org.springframework.remoting.RemoteConnectFailureException:
Cannot connect to remote service [rmi://192.168.0.106:1199/ItemRetag]; nested exception is java.rmi.ConnectException: Connection refused to host: 127.0.0.1; ……
解決辦法：在加載RMI服務(wù)之前將當(dāng)前服務(wù)器的IP指定給hostName，如 System.setProperty("java.rmi.server.hostname", "192.168.100.7");或者修改/etc/hosts文件，在這個文件中加 192.168.100.54 testlinux1 localhost.localdomain localhost 就行，或者將/etc/hosts文件中默認(rèn)的127.0.0.1改成當(dāng)前機(jī)器的IP即可！
問題二：java.rmi.server.ExportException: internal error: ObjID already in use Caused by: java.rmi.server.ExportException: internal error: ObjID already in use……
出現(xiàn)這種問題及有可能是/etc/hosts文件中指定的IP并不是當(dāng)前服務(wù)器的真實IP，RMI在初始化時注冊服務(wù)失敗。
通過System.out.println(InetAddress.getLocalHost().toString());查看當(dāng)前主機(jī)的IP是否為真實IP，如顯示為SIMBANK/220.250.64.24，而真實IP為192.168.1.2
解決辦法：修改/etc/hosts文件中錯誤的IP即可，將：
220.250.64.24 SIMBANK
修改為
192.168.1.2 SIMBANK
JAVA中，通過分析Heapdump文件可以檢查程序是否存在內(nèi)存泄露，但是這個文件一般是在程序遇到致命問題時才會產(chǎn)生，而如何事前生成這個文件，從而在程序尚末崩潰前找出問題的所在。
以下記述了各個版本的JDK產(chǎn)生DUMP文件的方法：
UN JDK生成Heapdump文件只需要在tomcat啟動腳本中增加 HeapDumpOnOutOfMemoryError 參數(shù)
此參數(shù)需要Java SE release 5.0 update 14 或以上支持
設(shè)置示例:
set JAVA_OPTS=%JAVA_OPTS% -server -Xms512m -Xmx800m -XX:PermSize=64M -XX:MaxPermSize=128m -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpOnCtrlBreak
IBM JDK生成Heapdump文件的開關(guān)：
— export IBM_HEAPDUMP=true
— export IBM_HEAP_DUMP=true
— export IBM_HEAPDUMP_OUTOFMEMORY=true
— export IBM_JAVADUMP_OUTOFMEMORY=true
— export IBM_JAVACORE_OUTOFMEMORY=true
— export IBM_HEAPDUMPDIR=<directory_path>
HP JDK生成Heapdump文件需要在在環(huán)境變量上，加上export _JAVA_HEAPDUMP=1
今天在做某項目的POC測試，甲方提供了一個三十萬記錄的TXT數(shù)據(jù)文件，需要把該文件的記錄插入到數(shù)據(jù)庫中，由于項目部的同事在搭建測試環(huán)境中用的是Mysql數(shù)據(jù)庫，在把數(shù)據(jù)導(dǎo)入到數(shù)據(jù)庫中用的是JDBC的批處理。代碼如下
private void batchParseGroup()
{
Connection con= null;
PreparedStatement ps =null;
try {
con= DbConnectionManager.getConnection();
con.setAutoCommit(false);
String sql = " insert into jivegroup(uri,groupname,pgroupid,description,creationdate,modificationdate,priority,selfpriority) values(?,?,?,?,?,?,?,?)";
ps= con.prepareStatement(sql);
for(int i=0;i<groupList.size();i++){
Group group = groupList.get(i);
ps.setString(1, group.getUri());
ps.setString(2, group.getName());
ps.setString(3, group.getPgroupId());
ps.setString(4, group.getName());
ps.setString(5, ""+System.currentTimeMillis());
ps.setString(6, ""+System.currentTimeMillis());
ps.setInt(7, group.getPriority());
ps.setInt(8, group.getPriority());
ps.addBatch();
if(i%100==0){
ps.executeBatch();
}
}
con.commit();
ps.executeBatch();
} catch (SQLException e) {
e.printStackTrace();
}finally{
DbConnectionManager.closeConnection(ps, con);
}
}在測試時，發(fā)現(xiàn)三十萬的數(shù)據(jù)居然需要十分鐘左右的時間。首先想到的就是Mysql的相關(guān)配置是不是有問題，反復(fù)修改了Mysql的相應(yīng)配置參數(shù)，收效甚微。
在Mysql的官網(wǎng)上查到如下：
http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-configuration-properties.html
關(guān)于rewriteBatchedStatements參數(shù)，Mysql官方的說明：
Should the driver use multiqueries (irregardless of the setting of "allowMultiQueries") as well as rewriting of prepared statements for INSERT into multi-value inserts when executeBatch() is called? Notice that this has the potential for SQL injection if using plain java.sql.Statements and your code doesn't sanitize input correctly. Notice that for prepared statements, server-side prepared statements can not currently take advantage of this rewrite option, and that if you don't specify stream lengths when using PreparedStatement.set*Stream(), the driver won't be able to determine the optimum number of parameters per batch and you might receive an error from the driver that the resultant packet is too large. Statement.getGeneratedKeys() for these rewritten statements only works when the entire batch includes INSERT statements.
解決辦法：
下載最新的JDBC的驅(qū)動程序。
MYSQL URL的配置參數(shù)如下：
jdbc:mysql://54.200.190.80:3306/ccb_ucstar?rewriteBatchedStatements=true
經(jīng)過測試。三十多萬的數(shù)據(jù)。70秒內(nèi)搞定！
今天在做項目中，供應(yīng)源提供了一小段的源代碼，但文件編碼格式是ＧＢＫ的，而我公司建工程時統(tǒng)一用的ＵＴＦ－８編碼，導(dǎo)進(jìn)來后出現(xiàn)亂碼。為了解決這一問題，在網(wǎng)上查找了相關(guān)的資料，發(fā)現(xiàn)可以用 enca工具來進(jìn)行批量轉(zhuǎn)換
１）下載enca工具
wget http://dl.cihar.com/enca/enca-1.13.tar.gz２）
tar -zxvf enca-1.13.tar.gz３）./configure
4) make
5) make install
轉(zhuǎn)換命令
enca -L zh_CN -x UTF-8 *.java