表錯情

約莫半年前，我開始做些網通業在AWS Markteplace 營銷模式的相關研究。面這張心智圖就是當時用了一個晚上紀錄學習的點滴的工具。完成的當下心情是很滿足的，感覺又進了一大步，心中滿是自信在隔天的會議中我應該可以有不小的貢獻意見。

沒想到事與願違。

會議開始後，大家討論的方向慢慢地偏離原本設定的主軸。雖然我想藉由研究的結果幫大家「導回」正途，卻只見大家一臉疑惑的表情，顯然聽不太懂我想表達的事情。那時候我才赫然發現兩件事：第一，他們聽不懂我的研究，因為我用了他們不懂的技術語言。第二，他們還不懂我已經熟稔的AWS Marketplace，所以我表達的內容就算再完整，若不是以他們關切的方式去整理與組織結論，最後也只是落得鴨子聽雷、有聽沒有懂的難堪。

所以，搞清楚聽眾的程度與他們關切的議題，再來組織腦海中所描繪的圖像，才是最有效率的開會方式。

會後心情雖有些落寞，但獲得比失去（發言）的多，就結果而言是相當正面的。

替自己加油囉！

被飆習慣了

從Architect 轉職做PM也已經一年多了。

過程辛酸艱苦不說，自己原有的專長還被以PM的角色來說，視為毫無價值。

只能說自己選的路，只能吞下去了。

今天做完系統升級後，被Ｎ先生臭罵了一頓，怪我怎麼沒把升級時間改為週末來做，難道

以我的經歷還不知道這樣會影響到服務嗎？

我沈默不語。

早在兩年前就做過相同的事，過程中雖有其他介接服務跟著無法執行正常營運，但重點都不是一般上班日作維運的問題。現在怪我，摸摸鼻子也只能認了。

維護通知早在一個月前就開始寄出，所有配合單位也沒異議。現在突然飆我，好像我犯了天條般的白痴一樣 ;但真正的問題點在於維運廠商不肯配合週末加班，才演變成這樣的局面。要說有錯，就是我沒有把N先生搬出來罵廠商，才讓場面變得千錯萬錯都是我的錯。

能怎麼辦？

吞下去，努力學，我已經可以看見我有能力掌控一切的未來了。等羽翼豐厚後，再來決定去留都還來得及。因人去職實在不是理智的行為。  ：）

我又搬回來了

哎，上禮拜才知道IT Home的部落格服務已經謝謝再聯絡。所有的文章突然就這樣不見了。想想算了，雖然有不少文章在那邊，但人家已經關站了，怪自己沒注意到就是。

所以，我又搬回來了。 Orz...

紫糯米搬家了

原先開這個站的用意是要寫些關於資料庫的心得，與另外一個在ITHome純分享程式開發類別的網誌有所區隔。但最後方便管理起見，本網誌將即日起搬到 David' Blog，請舊雨新知移動尊駕到新網誌，小弟會繼續努力耕耘的...

利用IGNORE_DUP_KEY過濾重複的資料

要從SQL SERVER中某table過濾出重複的資料後，塞入另外一個table裡的方法很多。這幾天工作的關係，發現其實也可利用 ignore_dup_key 這個 relation_index_option來取巧。下面我建立個簡單的範例說明：

-------------------------------------------------------------------------------- --建立uniqindex , 並指定ignore_dup_key -------------------------------------------------------------------------------- --1. 建立target table，儲存無重複的資料 if exists (select name from sys.tables t where t.name = 'category')  drop table category go --2. 刪除既有的index create table category(cat_desc varchar(50), cat_code varchar(10)) if exists(select name from sys.indexes i where i.name = 'idx_cat')  drop index idx_cat on cayrgory go --3. 建立unique index，並指定ignore_dup_key create unique index idx_cat on category(cat_desc) with ignore_dup_key go --4. 建立1,000測試資料，其中5,000筆重複 declare @tb1 table(c1 varchar(50), c2 varchar(10)) declare @i int declare @loop_start_date datetime, @loop_end_date datetime declare @uniq_start_date datetime, @uniq_end_date datetime set @i = 1 set @loop_start_date = GETDATE() --設定迴圈起始時間 while @i <= 10000 begin  if @i % 2 = 0   insert @tb1 values('test' + cast((@i-1) as varchar(50)), cast((@i-1) as varchar(10)))  else   insert @tb1 values('test' +cast(@i as varchar(50)), cast(@i as varchar(10)))  set @i = @i + 1 end set @loop_end_date = GETDATE() --設定迴圈結束時間 set @uniq_start_date = GETDATE() --設定insert 至target table的起始時間 insert category(cat_desc, cat_code) select * from @tb1 set @uniq_end_date = GETDATE() --設定insert 至target table的結束時間 select 'inserting loop takes...' select DATEDIFF(SECOND, @loop_start_date, @loop_end_date) select 'inserting into uniq index with ignore_dup_key takes...' select DATEDIFF(SECOND, @uniq_start_date, @uniq_end_date) select * from @tb1 order by c1 select * from category order by cat_desc go

一開始我先建立一個target table，以儲存待會測試資料中已經過濾出來的無重複資料。在target table上我們建立一個unique index，並以WITH  IGNORE_DUP_KEY指定relational_index_option的值；接著宣告一個 table type的暫存資料表，並以迴圈塞入10,000筆資料，其中有5,000筆重複。最後我們直接將測試資料表insert 到target table中。這裡就是重點了。以往要是在建立索引時沒有加上 with ignore_dup_key這個選項，則insert到重複的資料時，就會得到一個錯誤的訊息，整個insert的transaction就會終止並且rollback：

訊息 2601，層級 14，狀態 1，行 8

無法以唯一索引 'idx_cat' 在物件 'dbo.category' 中插入重複的索引鍵資料列。

為了能略過該筆重複的資料所造成的錯誤並使insert動的繼續進行，create unique index時指定 with ignore_dup_key 即可辦到。以後如果懶得寫一堆過濾語法，或許可以偷個懶用用這個方法。

select 是否會使用 undo segment?

根據 Ask Tom的文章，我做了些實驗，得到的結論如文章中所描述：

• 單純的select 並不會使用到undo segment；
• 對於一個有一筆紀錄以上的Table來說，只要select statement 尾巴多加了 for update，就會用到undo segment。

我先建立一個測試表格T(char(1))，並insert了一筆資料，隨後進行以下的測試：

SQL> select used_ublk from v$transaction;                                                               沒有任何資料列被選取 SQL> truncate table t; 表格被截斷. SQL> select used_ublk from v$transaction; 沒有任何資料列被選取 SQL> insert into t values('1'); 已建立 1 個資料列. SQL> commit; 確認完成. SQL> select used_ublk from v$transaction; 沒有任何資料列被選取 SQL> select * from t for update; T1 -- 1 SQL> select used_ublk from v$transaction;  USED_UBLK ----------          1 SQL> commit; 確認完成. SQL> select used_ublk from v$transaction; 沒有任何資料列被選取 SQL>

請注意以上紅色部分，不管你有沒有異動T Table內的資料，只要一旦下了 for update，undo space就會備準備出來儲存現有的資料列版本，而且更恐怖的是Table Lock也同時跟著發生。一旦有其它 transaction 要進行異動，那真的是死在那邊等你解了。所以千萬小心、在意 for update用完要趕快commit以釋放undo space跟table lock，否則大禍臨頭(DBA找出兇手的時候)可就糗了...

SQL Writer 自發性的啟動?

SQL Writer 預設和SQL Server一起安裝，主要目的在於和VSS互動，讓備份軟體可在SQL Server運行時，執行備份或復原鎖定的data files。

這個服務預設是Disabled的，但我試著把SQL 2005 sp2升級到sp4，卻發現升級精靈檢查鎖定檔案時，SQL Writer服務卻出現了！奇怪，難道我又誤入了什麼嗎? 查了一下文章，才發現SQL SQL 2005 上了 sp2後就會自動的啟動這項服務。原文如下：

The SQL Writer Service provides added functionality for backup and restore of SQL Server 2005 through the Volume Shadow Copy Service framework.

This SQL Writer Service is automatically installed but not enabled by default. It must be explicitly enabled to run on the server machine and must be running at the time that the Volume Shadow Copy Service (VSS) application requests a backup or restore. Use the Microsoft Windows Services applet to configure the service. The SQL Writer Service installs on all operating systems but is only needed on server systems. For Microsoft Windows XP, use the MSDE Writer.

SQL Server 2005 Service Pack 2 configures SQL Writer to start automatically.

真是差點以為自己見鬼了...(筆記)