2009年12月23日 星期三

有關資料庫的索引運用,指定索引!

查看查詢式,所有的條件式鍵值欄位,皆有列入索引,
但不知為何,SQL還是採用「掃描整個叢集索引」??
因此採用指定索引查詢,其查詢反應時間由原本的30秒下降至1秒之內!
查詢回應時間大幅改善..


雖然指定索引查詢,效能獲得很大的改善,但是否有什麼後遺症,目前不得而知!

vco_schedule_tab 已建置的索引
IX_vco_schedule_tab nonclustered located on PRIMARY comid, sdate, pflag

PK_vco_schedule_tab clustered, unique, primary key located on PRIMARY vocfile




2009年12月20日 星期日

D-LINK TDS WEB

前陣子由中文網頁下載 DFL-210 的 firmware,屢試不爽,始終遭遇到錯誤訊息!
Firmware upload failed. There is something wrong with the firmware package. Please download the firmware image from the D-Link support website and try again.
花費不少時間,(D-LINK 的客服忙的哩!),總算得到工程師的技術支援!
要求去如下網址下載 firmware http://tsd.dlink.com.tw
弄來弄去,原來中文網頁的firmware放錯了!
我想 tsd.dlink.com.tw恐怕才是他們第一手維護的資料,以後直接參考此網址吧!

2009年12月15日 星期二

看到一些文章,在討論 sql nolock 選項

看到一些文章,在討論 sql nolock 選項
不知各位是否有用過?
我想它不見得是對當下的查詢式回應時間能有顯著的改善, 但對降低整體sql server 的負擔,是有幫助的!
針對一些「過往資料的呈現」,或是「資料統計運算的來源」的查詢 或許 加上 with (nolock) 是有幫助的!
若各位有運用,並感覺有幫助,請提出來分享一下吧!

SELECT COUNT(UserID)
FROM EMPLOYEE WITH (NOLOCK)
JOIN WORKING_GROUP WITH (NOLOCK) ON
EMPLOYEE.UserID = WORKING_GROUP.UserID

sql 索引??評估執行計劃!

select *
from car_workid_ref_tab
where idate ='2009-10-05 00:18:44.653'
-- 我訝異如下的3組查詢式,SQL會採取不同的查詢計劃,
-- 就竟是什麼規則,不得而知,但似乎和預期的量有關!
-- 預期量大時,竟然採掃描整個叢集索引..(2),(3)
-- 意外的,查詢反應時間反而不如預期!!因idate並非叢集索引。

-- (1)
select *
from car_workid_ref_tab
where idate <= dateadd(m,-4,getdate())
-- (2)
select *
from car_workid_ref_tab
where idate <= dateadd(m,-3,getdate())
-- (3)
select *
from car_workid_ref_tab
where idate <= dateadd(m,-2,getdate())