The differences between Truncate, Delete and Drop

Truncate, Delete, Drop的異同點

注意:這裡說的delete是指不帶where子句的delete語句

相同點
truncate和不帶where子句的delete,以及drop都會刪除表內的數據

不同點:
1. truncate和delete只刪除數據不刪除表的結構(By Definition)
drop語句將刪除表的結構被依賴的約束(constrain),觸發器(trigger),索引(index);依賴於該表的存儲過程/函數將保留,但是變為invalid狀態.

2.delete語句是dml,這個操作會放到rollback segement中,事務提交之後才生效;如果有相應的trigger,執行的時候將被觸發.
truncate,drop是ddl,操作立即生效,原數據不放到rollback segment中,不能回滾.操作不觸發trigger.

3.delete語句不影響表所佔用的extent,高水線(high watermark)保持原位置不動
顯然drop語句將表所佔用的空間全部釋放 ;
truncate語句缺省情況下見空間釋放到minextents個extent,除非使用reuse storage; truncate會將高水線復位(回到最開始).
4.速度,一般來說: drop>; truncate >; delete
5.安全性:小心使用drop和truncate,尤其沒有備份的時候.否則哭都來不及
使用上,想刪除部分數據行用delete,注意帶上where子句.回滾段要足夠大.
想刪除表,當然用drop
想保留表而將所有數據刪除.如果和事務無關,用truncate即可.如果和事務有關,或者想觸發trigger,還是用delete.
如果是整理表內部的碎片,可以用truncate跟上reuse stroage,再重新導入/插入數據

事務中的DDL語句會引起COMMIT的， Truncate是不會全部釋放存儲空間！
Drop會釋放存儲空間！

Source: http://bbs.chinaunix.net/viewthread.php?tid=252763

權限設計參考

遲d整理, 睇住先
http://www.cnblogs.com/a7345678/archive/2008/09/25/1298838.html
http://www.blogjava.net/amigoxie/archive/2007/09/29/149509.html
http://www.cnblogs.com/yukaizhao/archive/2007/04/15/user_role_action_permission.html
http://www.blogjava.net/RongHao/category/20773.html

DBCP, C3P0常用參數,和使用中碰到的問題

DBCP:
driverClassName
url
username
password
上面四個分別是驅動,連接字符串,用戶名和密碼

maxActive連接池支持的最大連接數
maxIdle連接池中最多可空閒maxIdle個連接
minIdle連接池中最少空閒maxIdle個連接
initialSize初始化連接數目
maxWait連接池中連接用完時,新的請求等待時間,毫秒
timeBetweenEvictionRunsMillis timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis一起使用,每

timeBetweenEvictionRunsMillis毫秒秒檢查一次連接池中空閒的連接,把空閒時間超過minEvictableIdleTimeMillis毫秒的連接斷開,直到連接池中的連接數到minIdle為止

minEvictableIdleTimeMillis連接池中連接可空閒的時間,毫秒

removeAbandoned true,false,是否清理removeAbandonedTimeout秒沒有使用的活動連接,清理後並沒有放回連接池
removeAbandonedTimeout活動連接的最大空閒時間
logAbandoned true,false,連接池收回空閒的活動連接時是否打印消息


minEvictableIdleTimeMillis,removeAbandonedTimeout這兩個參數針對的連接對像不一樣,minEvictableIdleTimeMillis針對連接池中的連接對象,removeAbandonedTimeout針對未被close的活動連接.

在dbcp使用中遇到的問題:
當短時間之內活動連接達到maxActive,再請求連接,等maxWait秒後連接池就會報出錯來:Cannot get a connection, pool exhausted.在這maxWait秒裡removeAbandoned並沒有起作用,出錯後連接池就會把所有的連接斷開,為什麼這時候 removeAbandoned沒有起作用呢?


C3P0:
http://sourceforge.net/projects/c3p0 (c3p0-src - c3p0-0.9.1.2)
driverClass
jdbcUrl
user
password
minPoolSize
maxPoolSize
initialPoolSize

acquireIncrement池中沒有空閒連接時,一次請求獲取的連接數
maxIdleTime池中連接最大空閒時間
acquireRetryAttempts獲取連接失敗後,重新嘗試的次數
acquireRetryDelay嘗試連接間隔時間,毫秒
checkoutTimeout等待連接時間,0為無限等待,毫秒
DebugUnreturnedConnectionStackTraces true,false,是否收回未返回的活動連接
unreturnedConnectionTimeout活動連接的時間.

c3p0中的問題:
unreturnedConnectionTimeout是給每個活動連接一個時間限制,到點兒就收回,不管有沒有正在使用連接.這樣不是太好,應該是從最後一次使用連接才開始計時才好.那有沒有這樣的一個參數從最後一次使用計時呢?

source:
http://www.javaeye.com/post/607253
http://www.hibernate.org/214.html
For C3P0
http://www.hibernate.org/214.html?cmd=comphist&histnode=1059

SQL指定時間段的查詢

表名:A
時間字段:ddatetime(datetime類型)

查詢2003-2004年6月7日-7月8日數據。

select * from A where (extract(year from ddatetime) between 2003 and 2004)
and (extract(month from ddatetime) between 6 and 7)
and (extract(day from ddatetime) between 6 and 7)

extract只能取到日。小時，或者到秒，需要to_char。

查詢2003-2004年6月7日-7月8日12時到20時數據。

select * from A where (extract(year from ddatetime) between 2003 and 2004)
and (extract(month from ddatetime) between 6 and 7)
and (extract(day from ddatetime) between 6 and 7) and (to_char(ddatetime,'HH24') between 12 and 20)

以上查詢在oracle可運行。

Oracle中的 IN, NOT IN和 EXISTS, NOT EXISTS的區別

通常聽到的都是說盡量用exists不要用in，因為exists只判斷存在而in需要對比值，所以exists比較快，但看了看網上的一些東西才發現根本不是這麼回事。
下面這段是抄的
Select * from T1 where x in ( select y from T2 )
執行的過程相當於:
select *
from t1, ( select distinct y from t2 ) t2
where t1.x = t2.y;

select * from t1 where exists ( select null from t2 where y = x )
執行的過程相當於:
for x in ( select * from t1 )
loop
if ( exists ( select null from t2 where y = x.x )
then
OUTPUT THE RECORD
end if
end loop

從我的角度來說，in的方式比較直觀，exists則有些繞，而且in可以用於各種子查詢，而exists好像只用於關聯子查詢（其他子查詢當然也可以用，可惜沒意義）。
由於exists是用loop的方式，所以，循環的次數對於exists影響最大，所以，外表要記錄數少，內表就無所謂了，而in用的是hash join，所以內表如果小，整個查詢的範圍都會很小; 如果內表很大，外表如果也很大就很慢了，這時候exists才真正的會快過in的方式。


Not in和Not exists
如果查詢語句使用了not in那麼內外表都進行全表掃描，沒有用到索引；
而not extsts的子查詢依然能用到表上的索引。
所以無論那個表大，用not exists都比not in要快。
也就是說，in和exists需要具體情況具體分析，not in和not exists就不用分析了，盡量用not exists就好了。

source:http://www.blogjava.net/wphmoon

Servlet3.0 Briefing

Servlet3.0規範新鮮出爐，J2EE陣營實力大增

[IT168專稿]在2005年9月26日，Sun推出了Servlet的最新版API：Servlet2.5。這套Servlet API和以前的Servlet有著很大的不同。最大的區別就是Servlet2.5是完全基於J2SE5.0的。因此，它也理所當然地擁有了 J2SE5.0的所有特性。 Servlet2.5利用J2SE5.0的註釋特性使它的配置更容易。然而，由於在2005年J2SE5.0剛推出不久，支持J2SE5.0的Web服務 器也不多，因此，當時Servlet2.5在使用上並沒有馬上普及。時隔兩年後，Sun又推出了基於J2SE5.0的Servlet的第二個版本 3.0（就是JSR-315）。在這一版本中增加了很多有趣的特性。如可編程的登入登出，通過annotations進行配置，異步通訊等。

下面就讓我們 來看看Servet3.0的主要特性。

一、更靈活的Web框架

現在幾乎所有的基於Java的Web框架都是建立在Servlet之上的。大多數Web構架都是通過Servlets或web.xml來 配置和發布的。而J2SE新加入的註釋功能為我們提供了更好的選擇。我們可以利用註釋來設置Servlets、Listeners、filters等。但 註釋是直接寫在程序中的，無法動態改變配置，因此，JSR同時提供了這兩種方式來操作Servlet。這樣將使Web應用程序具有更大的彈性。

二、EOD的支持

Servlet3.0將使用多種技術來增強API的能力。如使用註釋來聲明編程類型。這將成為EOD的目標之一：使Web程序零配置。也就是說我們將使用 發布描述來覆蓋傳統的配置文章。還有就是泛型的應用，將大大加強程序的Servlet的表現力。在未來的J2SE版本中將加入支持其他語言的能力，這也有 助於增強Servlet API本身的實力。

三、異步通訊的支持

Servlet3.0支持以下異步通訊特性：

1.非阻塞(Non-blocking)輸入：使用這種輸入方式，可以在數據因某種原因暫時未到達時程序不會因此而被阻塞。
2.非阻塞輸出：和非阻塞輸入類似，當由於網絡問題寫入數據緩慢時程序不會受到阻塞。
3.延遲請求處理：在AJAX Web程序中客戶端程序可以向服務端發出異步請求，直到超時或事件返回來處理這個請求。延遲請求在其他的地方也是非常有用的，如我們在處理數據之前必須要 得到一些資源，但這些資源正處在遠程網絡中，而且速度並不快。這就需要異步來處理這種情況。
4.阻塞-非阻塞通知：這個功能是將通知信息放到阻塞或非阻塞事件中。然後由客戶端負責提取。
5.支持通道：通道是JDK1.4及以上版本提供的一種新的通訊API。使用Channel可以更好的進行網絡之間的通訊。也可以增強創建、訂閱、取消等操作的安全性。
6.安全：支持登錄和註銷功能。
7.其他功能
(1)支持歡迎界面。
(2) ServletContentListener排序。
(3)在初始化時可以定制容器的大小。
(4)可以監視文件上傳的進程。

上面只是Servlet3.0的一部分特性。從這些特性可以看出，Servlet3.0 API確實得到了很大的飛越，除了Servlet，EJB3.0也利用J2SE5.0的新特性重獲新生。也許在不久的將來Servlet3.0和 EJB3.0將會成為新的組合，在J2EE應用中起著舉足輕重的作用，就讓我們拭目以待吧!

Source: http://tech.it168.com

為什麼Linux比Windows更不會中毒?

(轉載)本篇文章來源於 IB資訊網

可能不少人持這樣一種觀點，認 為 Linux 病毒少是因為Linux不像Windows那麼普及，其實這種觀點很早已經被人批駁過了，一個最有力的論據是：如果寫病毒的人寫 Windows 病毒是因為 Windows 用戶多而因此破壞性大，那麼 Internet 上大多數服務器都是基於 Unix/Linux 的，攻擊這些服務器，破壞性豈不是更大麼？

對一個二進制的 Linux 病毒，要感染可執行文件，這些可執行文件對啟動這個病毒的用戶一定要是可寫的。而實際情況通常並不是這樣的。實際情況通常是，程序被 root 擁有，用戶通過無特權的帳號運行。而且，越是沒有經驗的用戶，他擁有可執行文件的可能性就越小。因此，越是不瞭解這種危險的用戶的主目錄越不適合病毒繁殖。

即使這個病毒成功地感染了這個用戶擁有的一個程序，由於這個用戶權限受限，它進一步傳播的任務也會非常困難（當然，對於運行單用戶系統的 Linux 新手，這個論證可能不適用。這樣的用戶可能會對 root 帳戶比較粗心）。

Linux 網絡程序構建地很保守，沒有使現在 Windows 病毒如此快速傳播變的可能的高級宏工具。這並不是 Linux 的固有特徵；它僅僅是兩種用戶基礎的不同和這種不同導致的在這兩種市場中的成功產品的不同的反映。通過觀察這些問題學到的經驗也會被用到將來的 Linux 產品中。

Linux的應用軟件和系統軟件幾乎都是開源的。這對病毒有兩方面的影響。首先，病毒很難藏身於開源的代碼中間。其次，對僅有二進制的病毒，一次新的編譯安裝就截斷了病毒一個主要的傳播途徑。雖然 Linux 發行商也提供大量的二進制軟件包，但是用戶大都是從發行商提供的可靠的軟件倉庫中下載這些軟件包，大都具有 md5 驗證機制，安全性極高。

這些障礙每一個都是病毒成功傳播的一個重要阻礙。然而當把他們放在一起考慮的時候，基本的問題才浮現出來。

一個計算機病毒，像生物病毒一樣，要想傳播開來，其繁殖速度必須超過其死亡（被消 滅）的速度。上面提到的障礙有效地降低了 Linux 病毒的繁殖速度。如果它的繁殖速度降到取代原來種群所需要的閾值之下，那麼這個病毒的厄運從一開始就注定了－－甚至在潛在受害人意識到它們之前。

我們沒有看到一個真正的 Linux 病毒瘋狂傳播，原因就在於存在的 Linux 病毒中沒有一個能夠在 Linux 提供的敵對的環境中茁壯成長。現在存在的 Linux 病毒僅僅是技術上的好奇；現實是沒有能養得活的 Linux 病毒。

當然，這並不意味著永遠沒有 Linux 病毒能夠流行。然而它確實意味著一個成功的 Linux 病毒要在不適合生存的 Linux 生態系統中存活下來必須是精心製作並具創新的