2009年2月25日 星期三

Sql Server: 校能調整前需要執行的 sql script

每次都需要重打,而且很容易忘。因此記在這裡,提供大家。

 

語法如下。

每次都需要重打,而且很容易忘。因此記在這裡,提供大家。

 

語法如下。

CheckPoint               --將 dirty pages 寫到磁碟 
dbcc FreeProcCache        --將 plan cache 清除 
dbcc DropCleanBuffers        --將 快取在 cache pages 的資料清除

Declare @DBID smallint
select @DBID = db_id('databasename')
dbcc FlushProcInDb(@DBID)  -- clears all clean plan cache for specified database
  

Sql Server: Statement Execution

在 Sql Server 上執行 Sql Query  時,Sql Server 到底需做了什麼事情呢?

以下的圖說明了一切。

在 Sql Server 上執行 Sql Query  時,Sql Server 到底需做了什麼事情呢?

以下的圖說明了一切。

snapshot20090225071006

2009年2月23日 星期一

現在開始投資 Linq to entities

看了 LINQ to SQL next steps 這一篇,感到 Linq to sql 大概真的不行了呢。

Update on LINQ to SQL and LINQ to Entities Roadmap (由Tim Mallalieu,也是 LINQ to SQL and Entity Framework 的 Team Program Manager)更是建議直接改用 Entity Framework.

http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx 更是宣告 Linq to Sql is Dead.
現在必須開始使用 Linq to entities.

Sql Server 2005 於AWE啟用時的 Memory 使用量

在使用 Sql Server 2005 時,每日檢查的關鍵,當然要 Check 一下 Sql Server 的記憶體使用量是否如預期。

所謂的如預期,通常是「伺服器有多少,就儘量用多少」。
例如之前提到伺服器有 8GB,那最好 Sql Server 就用到 7GB,留下 1GB 給作業系統。這樣才是物盡用。

然而,Sql Server 2005 在 AWE 模式時,在工作管理員查到的 SqlServer.exe 這個程序,只顯示約100 MB 的使用量。這樣對嗎?

當然不對。在AWE模式啟用時,必須使用效能計數器 SQL Server: Memory Manager / Total Server Memory 來檢視當下的記憶體使用量。

如下圖,雖然工作管理員顯示只使用 89.540 KB,但實際上是使用 1,262,592 KB才是。

image

而 效能計數器 SQL Server: Memory Manager / Target Server Memory 意味著「Sql Server 想要的記憶體」,一般等同於 Max Server Memory。當 Target Server Memory 長期大於實體憶體時,就可能代表記憶體不足。

2009年2月20日 星期五

Diskeeper 使用心得

之前從 Diskeeper 2008 ProPremier Edition For Microsoft Taiwan MVP 看到了這個好康,不久後,也就厚著臉皮要了一個序號回來。

但總不能收了人家的好處,就歌功頌德吧?
於是,使用了好一陣子。

現在整理一下使用的結果。

  1. 硬碟不知為何,Diskeeper 會整理出一些free空間出來。這一點我也感到奇怪,照理來說,磁碟重整工具只會重整,不會清出空間啊?但我一開始的確會多出一些空間,後來就無法再觀察了。畢竟持續使用電腦,c drive 一定會存放一些資料的。
  2. 背後持續重整硬碟。這一點無庸致疑地,Diskeeper 作的相當好。
  3. 防毒軟體是硬碟效能殺手。我在公司,家中都使用 Vista + Diskeeper,但公司使用 Symantec AntiVirus, 而家中使用 NOD32。問題是,公司每次開機,都必須掃描病毒,而且規定每星期一要完整掃描。這下可慘了公司的電腦,才買不到2年,星期一下午只能看到硬碟燈號狂閃一下午,工作起來倍感辛苦。而家中使用的是在防毒界中向來以節省系統資源出名的 NOD32,且不排程完整掃描,使用下來,整個系統效能順暢許多。注意哦,未安裝Diskeeper前使用起來,感覺是被K(二聲)K(二聲)的,安裝Diskeeper後,像是剛裝好 Vista 一樣相當順暢。
  4. Indexing Option 不要使用過度。Index Option 是 Vista 上桌面搜尋的解決方案。在做 index 時,當然會大量使用硬碟存取。因此,如果您做Index 的位置相當多,而且您的檔案也相當多,當然也需要很多時間來做 Index。與Diskeeper 一樣,Indexing Option 也是背景執行,因此正負相抵,Diskeeper 所掙出來的效能又被抵消一些。
    不過,如果沒使用Diskeeper 的話,系統會因防毒軟體 + Indexing Option 而完全拖慢下來,灰心之餘,我難免會開始罵「人之初」…。
    我,無法容忍找個檔案需要花太多時間,因此全系統都做了 Index。哈哈!因此,硬碟效能就會被拖下來,當然非常需要Diskeeper 來提升。
  5. Diskeeper 的中文化是對岸翻的,用詞不太習慣。

 

結論:

市面上當然也有一些免費的,我也使用過其中一個,但覺得不好用,連名字都忘了。 (後來找到了,是 Smart Defrag)
我已經無法使用差的磁碟重整軟體。之前原本以為Vista 內附的應該不錯用,但使用了Diskeeper 後,才知道一分錢一分貨呢。

2009年2月18日 星期三

Sql Server 需要多少的記憶體?

要知道 Sql Server 需要多少的記憶體,需要使用在 Sql server 上的效能計數器

1. 在功能表上,按「開始」,「執行」,輸入 perfmon 後按「確定」鍵

clip_image002

clip_image004

2. 新效能計數器

clip_image006

選擇 SQLServer:Memory Manager

clip_image008

再選計數器 Target Server Memory (KB)

clip_image010

3. 觀察「最大」值。例如下圖,代表在最近的100秒內,SQL Server 想要使用的最大記憶體量為 508504 KB,即約508 MB

clip_image012

Sql Server 2005 安裝於 Windows 2003, RAM 8 Gb 時的問題

放假的時候,公司同事安裝 Sql Server 2005 時,發生了 Sql Agent 無法啟動的問題。

回到公司後,只好自己檢查了一下。

果然,在 Sql Server Configuration Manager 啟動 Sql Agent 時,發生了問題。

現象一:

SQL Server blocked access to 程序 'dbo.sp_sqlagent_get_startup_info' of component 'Agent XPs' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Agent XPs' by using sp_configure

但事件檢視器上,也發生這樣的錯誤訊息

現象二:

SQLServerAgent could not be started(reason: SQLServerAgent 必須能夠以系統管理員(SysAdmin) 的身皆連接到 SQLServer, 但'(未知)'不是系統管理員(SysAdmin)角色的成員)

image

此時還搞不清楚狀況。只知道服務起不來。

另外,改用 sql script 來啟動時,也會發生狀況。

exec sp_configure 'show advanced options', '1'
RECONFIGURE
exec sp_configure
exec sp_configure 'Agent XPs', '1'
RECONFIGURE

結果發生以下的錯誤。

現象三:

訊息 5845,層級16,狀態1,行2
處理序的存取 Token 中,目前沒有 Address Windowing Extensions (AWE) 需要的 'lock pages in memory' 權限。

此時開始警覺到是否與伺服器的環境相關,尤其是記憶體的大小與配置設定的問題。

然後,在C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLAGENT.OUT 也找到了下列的錯誤訊息

現象四:

2009-02-17 15:35:14 - ! [298] SQLServer 錯誤: 5845,處理序的存取 Token 中,目前沒有 Address Windowing Extensions (AWE) 需要的 'lock pages in memory' 權限。 [SQLSTATE 42000] (DisableAgentXPs) 
  2009-02-17 15:35:14 - ! [298] SQLServer 錯誤: 15281,SQL Server 已封鎖元件 'Agent XPs' 的 程序 'dbo.sp_sqlagent_has_server_access' 之存取,因為此元件已經由此伺服器的安全性組態關閉。系統管理員可以使用 sp_configure 來啟用 'Agent XPs' 的使用。如需有關啟用 'Agent XPs' 的詳細資訊,請參閱《SQL Server 線上叢書》中的<介面區組態>(Surface Area Configuration)。 [SQLSTATE 42000] (ConnIsLoginSysAdmin) 
  2009-02-17 15:35:14 - ! [298] SQLServer 錯誤: 15281,SQL Server 已封鎖元件 'Agent XPs' 的 程序 'dbo.sp_sqlagent_get_startup_info' 之存取,因為此元件已經由此伺服器的安全性組態關閉。系統管理員可以使用 sp_configure 來啟用 'Agent XPs' 的使用。如需有關啟用 'Agent XPs' 的詳細資訊,請參閱《SQL Server 線上叢書》中的<介面區組態>(Surface Area Configuration)。 [SQLSTATE 42000] 
  2009-02-17 15:35:14 - ? [100] Microsoft SQLServerAgent 版本 9.00.4035.00 (x86 unicode 零售 組建) : 處理序識別碼 2620 
  2009-02-17 15:35:14 - ? [101] SQL Server  版本 9.00.4035 (0 連接限制) 
  2009-02-17 15:35:14 - ? [102] SQL Server ODBC 驅動程式版本 9.00.4035 
  2009-02-17 15:35:14 - ? [103] 驅動程式所使用的 NetLib 為 DBNETLIB.DLL; 本機主機伺服器為 
  2009-02-17 15:35:14 - ? [310] 偵測到 16 個處理器和 4096 MB RAM 
  2009-02-17 15:35:14 - ? [339] 本機電腦為 TW006VATDB001,正在執行 Windows NT 5.2 (3790) Service Pack 2 
  2009-02-17 15:35:14 - ! [000] SQLServerAgent 必須能夠以系統管理員 (SysAdmin) 的身分連接到 SQLServer,但 '(未知)' 不是系統管理員 (SysAdmin) 角色的成員 
  2009-02-17 15:35:15 - ? [098] SQLServerAgent 已結束 (正常)

現象五:

資料庫伺服器上,實體記憶體配有 8GB,但實際 Sql Server 只吃到1.6 GB 左右。
打開 c:\boot.ini ,發現是如下的配置

[boot loader] 
timeout=30 
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS 
[operating systems] 
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /PAE /noexecute=optout /fastdetect

現象六:

據同事描述,此電腦曾經改電腦名稱。即 ServerA 換成 ServerB

因此,根據之前的經驗,下了

select @@servername

結果是 ServerA,而非改名過後的 ServerB

解決

步驟一:

參考 交通部Microsoft SQL Server 效能再進階,知道了伺服器記憶體> 4 GB,<= 16 GB, Boot.ini 除了加上/3GB的參數,還必須要再加上/PAE的參數,因此改 c:\boot.ini 成如下配置
[boot loader] 
timeout=30 
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS 
[operating systems] 
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /3GB /PAE /noexecute=optout /fastdetect 

步驟二:

http://msdn.microsoft.com/en-us/library/ms190730.aspx 所述,將 SqlAgent 的服務Account 加入。

image

步驟三:

根據 http://msdn.microsoft.com/en-us/library/ms143799.aspx 所說的步驟,將 ServerA 改成 ServerB。

步驟四:

重新開機。 步驟一是鐵定需要重新開機的。而步驟二與三原則上只需重起 SqlServer 的服務即可。

結論

經過了一番努力,終於完成了。而記憶體在半小時之內也吃到了 2.7 GB。
那怎麼知道 Sql Server 是尚未需要超過 2.7 GB 的記憶體,還是再也吃不了更多的記憶體呢?
此時 Performon counter 就發揮作用了。效能物件 SQL Server:Memory Manager,計數器 Target Server Memory。此計數器描述伺服器曾經需要的伺服器記憶體大小。如果此值大於實體記憶體,就代表記憶體不足。

2009年2月13日 星期五

Binding (4): Others binding elements

由上三回的說明,您大概可看出,其是 一個Binding是以數個 binding element 有順序地組成一個 stack。每一個 binding element 負責溝通的一部份功能。

Binding Binding Elements 說明
BasicHttpContextBinding
<basicHttpContextBinding>
TextMessageEncodingBindingElement, HttpTransportBindingElement BasicHttpBinding 的主要差別,BasicHttpContextBinding 將 allowCookies 設為 true
MsmqIntegrationBinding

<msmqIntegrationBinding>

BinaryMessageEncodingBindingElement,
MsmqTransportBindingElement
 
NetMsmqBinding
<netMsmqBinding>
BinaryMessageEncodingBindingElement,
MsmqTransportBindingElement
 
NetPeerTcpBinding

<netPeerTcpBinding>

BinaryMessageEncodingBindingElement,
PnrpPeerResolverBindingElement,
PeerTransportBindingElement
 
WebHttpBinding

<webHttpBinding>

TextMessageEncodingBindingElement,
HttpTransportBindingElement
BasicHttpBinding 使用 SOAP 作為訊息格式,而WebHttpBinding 使用 HTTP 作為訊息格式
WSFederationHttpBinding
<wsFederationHttpBinding>
TransactionFlowBindingElement, TextMessageEncodingBindingElement, HttpTransportBindingElement  
WSHttpContextBinding

<wsHttpContextBinding>

TransactionFlowBindingElement, TextMessageEncodingBindingElement, HttpTransportBindingElement  
WS2007FederationHttpBinding
<ws2007FederationHttpBinding>
TransactionFlowBindingElement, TextMessageEncodingBindingElement, HttpTransportBindingElement  
WS2007HttpBinding

<ws2007HttpBinding>

TransactionFlowBindingElement, TextMessageEncodingBindingElement, HttpTransportBindingElement 與WsHttpBinding 相同,但使用了新版的Security, ReliableSession, 與 TransactionFlow binding elements。

Binding(3): wsDualHttpBinding

<wsDualHttpBinding>

 

<wsDualHttpBinding>
        <binding name="string"
        closeTimeout="TimeSpan"
        openTimeout="TimeSpan" 
        receiveTimeout="TimeSpan"
        sendTimeout="TimeSpan"
        bypassProxyOnLocal="Boolean"
        clientBaseAddress="URI"
        transactionFlow="Boolean" 
        hostNameComparisonMode="StrongWildCard/Exact/WeakWildcard"
        maxBufferPoolSize="integer"
        maxReceivedMessageSize="Integer"
        messageEncoding="Text/Mtom" 
        proxyAddress="URI"
                
textEncoding="Unicode/BigEndianUnicode/UTF8"
        useDefaultWebProxy="Boolean">
        <reliableSession ordered="Boolean"
            inactivityTimeout="TimeSpan" />
        <security mode="None/Message">
           <message clientCredentialType="None/Windows/UserName/Certificate/CardSpace"
                negotiateServiceCredential="Boolean"
                    algorithmSuite="Basic128/Basic192/Basic256/Basic128Rsa15/Basic256Rsa15/TripleDes/TripleDesRsa15/Basic128Sha256/Basic192Sha256/TripleDesSha256/Basic128Sha256Rsa15/Basic192Sha256Rsa15/Basic256Sha256Rsa15/TripleDesSha256Rsa15" />
                </security>
        <readerQuotas maxDepth="integer" 
           maxStringContentLength="integer"
           maxByteArrayContentLength="integer"
           maxBytesPerRead="integer"
           maxNameTableCharCount="integer" />
    </binding>
</wsDualHttpBinding>

 

  1. WSDualHttpBinding 除了使用了原來在 BasicHttpBinding 所使用的 TextMessageEncodingBindingElementHttpTransportBindingElement 這兩個 binding element,也使用了 TransactionFlowBindingElement
  2. 使用 CompositeDuplexBindingElement, 讓 Client 可以 callback (回呼)。為了讓 Client 可以回呼, WSDualHttpBinding 是一個雙通道的 Binding,除了一般由 Client 傳送訊息給 Service 的通道(Channel)外,另外建立一個讓Service傳送訊息給Client 的通道。
  3. 一個 Service 通常有多個 Client 會使用該Service。WSDualHttpBinding 為了回呼Client,必須保持每個 Client 的資訊,因此需要維護 Session。此時引入了ReliableSessionBindingElement

2009年2月12日 星期四

2009 年 2 月安全性公告發行

資訊安全公告 2009 年 2 月 11 日 (等級 2)
本通告的內容為何?
這個通告的目的是提供您在 2009 年 2 月 11 日發行的新資訊安全公告概觀。每個月都會發行資訊安全公告以解決問題的重大弱點。

Microsoft 同時於 2009 年 2 月 11 日發行安全性摘要報告 960715 - ActiveX Kill Bit 的更新程式彙總套件,我們將於下方簡要說明這個新安全性摘要報告。


Microsoft 發行下列十一個新的安全性公告,解決最近發現的弱點:
安全性公告編號: MS09-002 嚴重性等級:
公告標題:Internet Explorer 累積的安全性更新 (961260)
受影響的軟體:Microsoft Windows、Internet Explorer
重新開機需求: 需要重新開機
安全性衝擊:遠端程式碼執行
安全性公告編號: MS09-003 嚴重性等級:
公告標題:Microsoft Exchange 的弱點可能會導致遠端程式碼執行 (959239)
受影響的軟體: Microsoft Exchange Server
重新開機需求: 可能需要重新開機
安全性衝擊:遠端執行程式碼
安全性公告編號: MS09-004 嚴重性等級:
公告標題:Microsoft SQL Server 的弱點可能會導致遠端程式碼執行 (959420)
受影響的軟體: Microsoft SQL Server
重新開機需求: 可能需要重新開機
安全性衝擊:遠端執行程式碼
安全性公告編號: MS09-005 嚴重性等級:
公告標題:Microsoft Office Visio 的弱點可能會導致遠端程式碼執行 (957634)
受影響的軟體:Microsoft Office
重新開機需求: 可能需要重新開機
安全性衝擊:遠端執行程式碼

  • 高優先順序的非安全性更新
    下列知識庫文件會詳細說明 Microsoft 在 Microsoft Update (MU)、Windows Update (WU) 或 Windows Server Update Services (WSUS) 中提供的非安全性高優先順序更新:http://support.microsoft.com/?id=894199
  • 新安全性摘要報告(Advisory)
    Microsoft 透過摘要報告 (960715) - ActiveX Kill Bit 的更新程式彙總套件,發行這個 ActiveX Kill Bit。這個更新包括先前發佈之 Microsoft 資訊安全公告中的 Kill Bit:
  • 這個更新同時包括下列協力廠商軟體的Kill Bit:
    Microsoft 透過摘要報告 (960715) - ActiveX Kill Bit 的更新程式彙總套件,發行這個 ActiveX Kill Bit。這個更新包括先前發佈之 Microsoft 資訊安全公告中的 Kill Bit:
    • Akamai 下載管理員:這個更新針對 Akamai Technologies 開發的 ActiveX 控制項,設定了 Kill Bit。Akamai Technologies 已針對受影響之元件中的弱點,發行安全性更新來解決問題。如需詳細資訊和下載位置,請參閱 Akamai Technologies 的資訊安全公告。系統已應 ActiveX 控制項擁有者的要求設定此 Kill Bit。此 ActiveX 控制項的類別識別項 (CLSID) 已列在本摘要報告的常見問題集章節中。
    • Research in Motion (RIM) AxLoader:這個更新針對 Research In Motion (RIM) 開發的 ActiveX 控制項,設定了 Kill Bit。RIM 已針對受影響之元件中的弱點,發行安全性更新來解決問題。如需詳細資訊和下載位置,請參閱 Research In Motion 的資訊安全公告。F系統已應 ActiveX 控制項擁有者的要求設定此 Kill Bit。此 ActiveX 控制項的類別識別項 (CLSID) 已列在本摘要報告的常見問題集章節中。
  • 如需如何安裝此更新的詳細資訊,請參閱下列資訊:

Microsoft 安全性公告 MS09-002

公告標題: Internet Explorer 累積的安全性更新 (961260)
摘要:

這個安全性更新能解決二個未公開報告的弱點。如果使用者使用 Internet Explorer 檢視蓄意製作的網頁,此弱點可能會允許執行遠端程式碼。在系統上帳戶使用者權限較少的使用者受到的影響,比擁有系統管理使用者權限的使用者小。

安全性更新修改了 Internet Explorer 對這些弱點所導致之錯誤的處理方式,以解決這些弱點。

嚴重性等級: 對於在支援之 Windows XP 和 Windows Vista 版本中執行的 Internet Explorer 7 而言,這個安全性更新的嚴重性等級為「重大」。

對於在支援之 Windows Server 2003 和 Windows Server 2008 版本中執行的 Internet Explorer 7 而言,這個安全性更新的嚴重性等級為「中度」。

受影響的軟體: Microsoft 開發工具與軟體、Microsoft Office
弱點的影響: 遠端執行程式碼
CVE 和弱點攻擊指數:
CVE-2009-0075:[1] 可能出現一致的惡意探索程式碼。攻擊者可輕易撰寫一致的惡意探索程式碼。
CVE-2009-0076:[1] 可能出現一致的惡意探索程式碼。攻擊者可輕易撰寫一致的惡意探索程式碼。
重新開機需求: 需要重新開機。
移除資訊: 若是 Windows XP 或 Windows Server 2003 中的 Internet Explorer 7,請使用 [控制台] 中的 [新增或移除] 工具或是 Spuninst.exe 公用程式。

若是 Windows Vista 或 Windows Server 2008 中的 Internet Explorer 7,WUSA.exe 不支援更新的解除安裝作業。如果要解除安裝由 WUSA 安裝的更新,請按一下 [控制台],然後按一下 [安全性]。接著在 Windows Update 下按一下 [檢視安裝的更新],並在更新清單中進行選擇。

取代的安全性公告:: MS08-073 和 MS08-078
完整詳細資訊: http://www.microsoft.com/taiwan/technet/security/bulletin/MS09-002.mspx (中文版)
http://www.microsoft.com/technet/security/bulletin/MS09-002.mspx (英文版)

Microsoft 安全性公告 MS09-003

公告標題: Microsoft Exchange 的弱點可能會導致遠端程式碼執行 (959239)
摘要:

這個安全性更新能解決兩個未公開的 Microsoft Exchange Server 弱點。當蓄意製作的 TNEF 訊息傳送至 Microsoft Exchange Server 時,第一個弱點會導致遠端程式碼執行。若攻擊者能成功利用這個弱點,即能使用 Exchange Server 服務帳戶權限,完全控制受影響的系統。當蓄意製作的 MAPI 命令傳送至 Microsoft Exchange Server 時,第二個弱點會導致拒絕服務。若攻擊者能成功利用這個弱點,即能讓使用 EMSMDB32 提供者的 Microsoft Exchange System Attendant 服務和其他服務停止回應。

這個安全性更新修改了 Microsoft Exchange Server 解譯 TNEF 訊息和 MAPI 命令的方法,以解決這些弱點。

嚴重性等級: 對於支援的 Microsoft Exchange 2000 Server、Microsoft Exchange Server 2003 和 Microsoft Exchange Server 2007 版本而言,這個安全性更新的嚴重性等級為「重要」。
受影響的軟體: Microsoft Exchange Server。如需詳細資訊,請參閱以下連結中公告的<受影響的軟體和不受影響的軟體>章節。
弱點的影響: 遠端執行程式碼
CVE 和弱點攻擊指數:
CVE-2009-0098:[2] 可能出現一致的惡意探索程式碼。
CVE-2009-0099:[2] 可能出現一致的惡意探索程式碼。這是拒絕服務弱點,當攻擊者利用這個弱點進行攻擊時,只會導致拒絕服務而不會出現遠端程式碼執行。
重新開機需求: 可能需要重新開機(依照每台系統狀況回應不同而定)。
移除資訊:

使用 [控制台] 中的 [新增或移除程式] 工具或 Spuninst.exe 公用程式。

這個更新取代的公告 MS08-039 Exchange Server 2007 套件。如需詳細資訊,請參閱以下連結中公告的<常見問題集>章節。
完整詳細資訊: http://www.microsoft.com/taiwan/technet/security/bulletin/ms09-003.mspx (中文版)
http://www.microsoft.com/technet/security/bulletin/ms09-003.mspx (英文版)

Microsoft 安全性公告 MS09-004

公告標題: Microsoft SQL Server 的弱點可能會導致遠端程式碼執行 (959420)
摘要:

這個安全性更新能解決一項未公開的 Microsoft SQL Server 弱點。當不受信任的使用者存取受影響的系統,或有資料隱碼 (SQL Injection) 攻擊受影響的系統時,這個弱點就會導致遠端執式碼執行。系統若有安裝 SQL Server 7.0 Service Pack 4、QL Server 2005 Service Pack 3 和 SQL Server 2008 就不會出現這個問題。

此安全性更新會驗證傳入至擴充預存程序的參數,以解決這項弱點。

嚴重性等級: 對於支援的 SQL Server 2000、SQL Server 2005 Service Pack 2、Microsoft SQL Server 2000 Desktop Engine (MSDE 2000)、SQL Server 2005 Express Edition、Microsoft SQL Server 2000 Desktop Engine (WMSDE) 和 Windows Internal Database (WYukon) 版本而言,這個安全性更新的嚴重性等級為「重要」。
受影響的軟體: Microsoft SQL Server。如需詳細資訊,請參閱以下連結中公告的<受影響的軟體和不受影響的軟體>章節。
弱點的影響: 遠端執行程式碼
CVE 和弱點攻擊指數: CVE-2008-5416[1] 可能出現一致的惡意探索程式碼。已公佈驗證後期之功能型惡意探索程式碼。
已知問題: 有關此公告中任何已發現並確認的問題將列於 Microsoft 知識庫文件 957173中。這份文件也會針對已確認的任何新問題列出建議解決方案。
重新開機需求: 可能需要重新開機(依照每台系統狀況回應不同而定)。
移除資訊: 使用 [控制台] 中的 [新增或移除程式] 工具。

注意1:當移除這個 WMSDE 的安全性更新時,會完全移除系統中的 WMSDE 執行個體。

注意2:當移除這個 WYukon 的安全性更新時,會完全移除系統中的 WYukon 執行個體。WYukon 在 [新增或移除程式] 中顯示為 [Windows Internal Database]。

取代的安全性公告: MS08-040 和 MS08-052
完整詳細資訊: http://www.microsoft.com/taiwan/technet/security/bulletin/MS09-004.mspx (中文版)
http://www.microsoft.com/technet/security/bulletin/MS09-004.mspx (英文版)

Microsoft 安全性公告 MS09-005

公告標題: Microsoft Office Visio 的弱點可能會導致遠端程式碼執行 (957634)
摘要:

這個安全性更新能解決三個未公開的 Microsoft Office Visio 弱點,如果使用者開啟蓄意製作的 Visio 檔,此弱點可能會允許遠端程式碼執行。成功利用此弱點的攻擊者可以取得受影響系統的完整控制權。攻擊者接下來將能安裝程式;檢視、變更或刪除資料;或建立具有完整使用者權限的新帳戶。在系統上帳戶使用者權限較少的使用者受到的影響,比擁有系統管理使用者權限的使用者小。

這個安全性更新修改了 Microsoft Office Visio 在使用者開啟 Visio 檔時執行驗證的方式,以解決這些弱點。

嚴重性等級: 對於 Microsoft Office Visio 2002 Service Pack 2、Microsoft Office Visio 2003 Service Pack 3 和 Microsoft Office Visio 2007 Service Pack 1 而言,這個安全性更新的嚴重性等級為「重要」。
受影響的軟體: Microsoft Office。如需詳細資訊,請參閱以下連結中公告的<受影響的軟體和不受影響的軟體>章節。
弱點的影響: 遠端執行程式碼
CVE 和弱點攻擊指數:
CVE-2008-4260:未初始化記憶體損毀弱點
CVE-2009-0095:[2] 可能出現一致的惡意探索程式碼。
CVE-2009-0096:[2] 可能出現一致的惡意探索程式碼。
CVE-2009-0097:[2] 可能出現一致的惡意探索程式碼。
重新開機需求: 可能需要重新開機(依照每台系統狀況回應不同而定)。
移除資訊: 使用 [控制台] 中的 [新增或移除程式] 工具。

注意:移除此更新時,系統可能會提示您在光碟機中插入 Microsoft Office 光碟片。此外,您可能無法使用 [控制台] 的 [新增或移除程式] 工具來解除安裝程式。導致這個問題的可能性有數種。如需有關移除作業的詳細資訊,請參閱 Microsoft 知識庫文件 903771 (http://support.microsoft.com/kb/903771)。

取代的安全性公告: MS08-019
完整詳細資訊: http://www.microsoft.com/taiwan/technet/security/bulletin/MS09-005.mspx (中文版)
http://www.microsoft.com/technet/security/bulletin/MS09-005.mspx (英文版)
 
若要取消訂閱這份電子快訊,請在主旨欄位中輸入「UNSUBSCRIBE」一字,然後回覆此訊息。您也可以在 Microsoft.com 網站上取消訂閱。您可以在這個網站上管理您所有的 Microsoft.com 通訊喜好設定。

法律資訊

這份電子報是由台灣微軟股份有限公司發送
台北市 110 信義區松仁路 7 號 8 樓
2009 年 2 月份
Microsoft 安全反應中心
公告發行

全球資安禍首之一殭屍網路助長垃圾郵件!微軟進行全面清除

據研究單位與安全公司分析,Win32/Srizbi殭屍惡意程式從現身以來,已發送了相當大量的垃圾郵件,全球約46%的垃圾郵件,均是由這支惡意程式所發送。而Win32/Srizbi更可以向控制端發送訊息確認哪些郵件地址是正確的,哪些是錯誤的,讓攻擊行為更為準確,造成的損失也就更大。因此,微軟於本月特別將Win32/Srizbi加入惡意軟體移除工具的名單之中,希望可以有效控制並遏止相關行為發生。

下列網頁將提供新發行之公告的摘要資訊:

2009 年 2 月份 Microsoft 安全性公告摘要  (中文版)
2009 年 2 月份 Microsoft 安全性公告摘要 (英文版)

Microsoft Windows
惡意軟體移除工具

Microsoft 於 Windows Server Update Services (WSUS)、Windows Update (WU) 及下載中心發行新版的 Microsoft Windows 惡意軟體移除工具。請注意,本工具將不會經由 Software Update Services (SUS) 散發。請參閱以下網址,取得有關 Microsoft Windows 惡意軟體移除工具的資訊:

惡意軟體移除工具
惡意軟體移除工具可清除的威脅

非安全性高優先順序更新

下列知識庫文件會詳細說明 Microsoft 在 Microsoft Update (MU)、Windows Update (WU) 或 Windows Server Update Services (WSUS) 中發行以提供使用者使用的非安全性高優先順序更新:
說明 2008 年 Software Update Services 和 Windows Server Update Services 的內容變更

注意事項和免責聲明

關於本頁所列和本安全性公告中的受影響軟體:

本清單所列出之軟體版本已經過測試,判斷版本是否受到影響。其他版本已不再包含安全性更新支援,同時也不一定會受到影響。請瀏覽 Microsoft 技術支援週期網站,以瞭解您的產品及版本的支援生命週期:

關於資訊一致性:

我們會致力於透過靜態 (郵件型式) 和動態 (網頁式) 內容為您提供精確的資訊。公佈於本網站中的 Microsoft 資訊安全佈告欄內容會臨時根據最新資訊予以更新。這裡和 Microsoft 網頁式資訊安全佈告欄的資訊若發生不一致情形,Microsoft 網頁式資訊安全佈告欄內容為已授權的資訊。

請瀏覽 此頁 以取得有關這些警示的最新訊息。

關於資安嚴重性的等級定義:

更多關於資安嚴重性的等級定義

Binding (2): netTcpBinding

netTcpBinding
<netTcpBinding>
   <binding 
      closeTimeout="TimeSpan"
     hostNameComparisonMode="StrongWildCard/Exact/WeakWildcard"
      listenBacklog="Integer"
      maxBufferPoolSize="integer"
      maxBufferSize="Integer"
      maxConnections="Integer" 
      maxReceivedMessageSize="Integer"
            name="string"
      openTimeout="TimeSpan"
      portSharingEnabled="Boolean"
      receiveTimeout="TimeSpan"
      sendTimeout="TimeSpan"
      transactionFlow="Boolean" 
      transactionProtocol="OleTransactions/WSAtomicTransactionOctober2004" 
            transferMode="Buffered/Streamed/StreamedRequest/StreamedResponse"

      <reliableSession ordered="Boolean"
            inactivityTimeout="TimeSpan"
            enabled="Boolean" />
      <security mode="None/Transport/Message/Both">
            <message clientCredentialType="None/Windows/UserName/Certificate/CardSpace"
                defaultProtectionLevel="None/Sign/EncryptAndSign" 
                     algorithmSuite="Basic128/Basic192/Basic256/Basic128Rsa15/Basic256Rsa15/TripleDes/TripleDesRsa15/Basic128Sha256/Basic192Sha256/TripleDesSha256/Basic128Sha256Rsa15/Basic192Sha256Rsa15/Basic256Sha256Rsa15/TripleDesSha256Rsa15" />
                        <transport clientCredentialType="None/Windows/Certificate"
                protectionLevel="None/Sign/EncryptAndSign" />
      </security>
       <readerQuotas maxDepth="integer" 
            maxStringContentLength="integer"
            maxByteArrayContentLength="integer"
            maxBytesPerRead="integer"
            maxNameTableCharCount="integer" />
   </binding>
</netTcpBinding>
  1. 當Client 是在 intranet 環境時,使用 netTcpBinding 是一個對效能最好的選擇,而且可以host 在 Windows Service 上。IIS5 或 IIS6 只能使用 HttpBinding。IIS7 則可以使用 WAS 方式來支援 netTcpBinding。
  2. netTcpBinding 使用 TCP protocol 並且完全支援 SOAP security, transactions, 與 reliability。
  3. 由於此 netTcpBinding 支援 .net 平台,因此並不適合跨平台如.NET + JAVA。我認為此將取代原本的 .net Remoting.
  4. 使用三個 binding elements. 第一個是 BinaryMessageEncodingBindingElement ,負責將訊息轉換成將來傳輸用的二進位格式。
  5. 第二個是TransactionFlowBindingElement ,只有一個 TransactionProtocol 屬性,定義交易(transactions) 如何從 clinet 流向 service。預設值是 TransactionProtocol.OleTransactions, 意思就是不支援 WS-AtomicTransaction。如果要支援 WS-AtomicTransaction,就設成 TransactionProtocol.WSAtomicTransaction11TransactionProtocol.WSAtomicTransactionOctober2004。注意到需要使用 WS-AtomicTransaction 組態公用程式 (wsatConfig.exe) 來設定該台伺服器。
  6. 第三個是 TcpTransportBindingElement, 負責傳輸的工作。

97資訊委外服務人員計價參考要點

參考自 中華民國資訊軟體協會

注意到 97 年、96年、與 95年的比較分析後,趨勢為

1. 專案管理類的金額下降了

2. 系統分析、資料庫管理、資訊安全管理、系統整合、品質保證 類金額提昇了

3. 系統管理類的金額下降了

可見得之前專案管理在台灣大熱門,但到後來,國內仍然以實務為主。

第 一 類 系 統

計費類別

95

96

97

職 別

主 管

專案經理

專案負責人

計畫主持人

199,836

229,320

199,836

專案管理

173,628

170,352

160,524

系統分析

資料庫管理

資訊安全管理

系統整合

品質保證

157,248

170,352

167,076

程式設計

134,316

134,316

137,592

系統管理

140,868

121,212

117,936

機器操作

網頁設計

客戶服務

104,832

111,384

104,832

2009年2月11日 星期三

Binding (1) : BasicHttpBinding

WCF 中,最複雜的,我認為應該是 Binding 了。
要選擇適當的 binding, 通常要了解一堆的 WS-* 的標準,配合客戶需求,剔除不必要的選項後,才是我們適合的 binding.

那什麼是 Binding 呢?
Binding 定義了客戶端與伺服器端的「溝通方式」,主要有下列三大類(但不限)

  1. Transport Protocol: Http, Tcp, Msmq, etc
  2. Message format: Xml, Mtom, Json, binary, etc
  3. Message protocols: Soap, WS-*, none, etc

WCF 內建提供的 Binding, 目前已達12 種了。如果都不適用,還可以自訂 CustomBinding

那要如何選擇呢?有沒一個建議的流程呢?在 patterns & practices Improving Web Services Security Guide 中有簡略描述。以下就嘗試翻譯並整理一下!

<basicHttpBinding>
<binding
allowCookies="Boolean"
bypassProxyOnLocal="Boolean"
closeTimeout="TimeSpan"
envelopeVersion="None/Soap11/Soap12"
hostNameComparisonMode="StrongWildCard/Exact/WeakWildcard"
maxBufferPoolSize="Integer"
maxBufferSize="Integer"
maxReceivedMessageSize="Integer"
messageEncoding="Text/Mtom"
name="string"
openTimeout="TimeSpan"
proxyAddress="URI"
receiveTimeout="TimeSpan"
sendTimeout="TimeSpan"
textEncoding="UnicodeFffeTextEncoding/Utf16TextEncoding/Utf8TextEncoding"
transferMode="Buffered/Streamed/StreamedRequest/StreamedResponse"
useDefaultWebProxy="Boolean"
<security mode="None/Transport/Message/TransportWithMessageCredential/TransportCredentialOnly">
<transport clientCredentialType="None/Basic/Digest/Ntlm/Windows/Certificate"
proxyCredentialType="None/Basic/Digest/Ntlm/Windows"
realm="string" />
<message
algorithmSuite="Basic128/Basic192/Basic256/Basic128Rsa15/Basic256Rsa15/TripleDes/TripleDesRsa15/Basic128Sha256/Basic192Sha256/TripleDesSha256/Basic128Sha256Rsa15/Basic192Sha256Rsa15/Basic256Sha256Rsa15/TripleDesSha256Rsa15"
clientCredentialType="UserName/Certificate"/>
</security>
<readerQuotas maxDepth="Integer"
maxStringContentLength="Integer"
maxByteArrayContentLength="Integer"
maxBytesPerRead="Integer"
maxNameTableCharCount="Integer" />
</binding>
</basicHttpBinding>


basicHttpBinding



  1. 與 ASMX web service 相容,即WS-I Basic Profile 1.1

  2. 預設沒有實作安全相關標準。如果需要安全,則需要設定 Security.Mode

  3. 在沒有安全性的要求下,(即 <scurity mode=’none’> 或 Security.Mode 設為 BasicHttpSecurityMode.None),basicHttpBinging使用了 TextMessageEncodingBindingElementHttpTransportBindingElement 這兩個 binding element。TextMessageEncodingBindingElement 將訊息格式化為與 SOAP 相容。HttpTransportBindingElement 則將訊息以 http protocol 傳送。因此,在basicHttpBinding 中,可以看到TextMessageEncodingBindingElementHttpTransportBindingElement 相關的 configuration schema.

  4. 若要使用 SSL, 即要以 HTTPS 來傳送訊息,則需設定<scurity mode=’Transport’>,此時 HttpTransportBindingElement會被 HttpsTransportBindingElement 所取代。事實上HttpsTransportBindingElement 繼承HttpTransportBindingElement,所以只有多了一些功能。

  5. BasicHttpBinding 可以使用於 IIS5 或 IIS6 上

  6. messageEncoding=”Mtom” 時,會將 TextMessageEncodingBindingElementMtomMessageEncodingBindingElement 取代。MTOM 編碼方式 實作了 W3C SOAP Message Transmission Optimization Mechanism, 用於以SOAP格式傳輸 binary 資料如附件、圖片,以降低訊息的大小。


 

2009年2月10日 星期二

Microsoft SQL Server 2008 Books Online (January 2009)

可到這裡下載。不過只有英文的版本,中文還是去年8月。

2009年2月9日 星期一

WCF: 使用 Header 傳遞訊息

在使用 WCF 時,自訂訊息內容自然是免不了的設計。因此使用 DataContract, 已經是 WCF 中經典中的經典了。
如果需要 WCF client 多傳一些訊息回來,就必須在Service上更改 DataContract, 然後Client 再更新程式…..

等一下,DataContract 是一個 Contract,怎麼能說改就改?
話又說回來,面對各式各樣的客戶,常常見到不同的需求需要傳遞不同的訊息。此時該怎麼辦?

原來,WCF 內建有個傳遞訊息的方法,且不需要修改 DataContract。

步驟1:修改 WCF Client 的 config。

        <client>
          <endpoint address="http://localhost:8081/test/service1.svc" binding="basicHttpBinding"
              bindingConfiguration="BasicHttpBinding_IService1" contract="ServiceReference1.IService1"
              name="BasicHttpBinding_IService1" >
            <!--  use header to pass message  -->
            <headers>
              <MyHeader xmlns="http://sample.org/test">
                This is my test data
              </MyHeader>
            </headers>
          </endpoint>
        </client>

步驟2: 修改 Service, 使用 OperationContext 讀取 header

      int myHeaderIndex = OperationContext.Current.RequestContext.RequestMessage.Headers.FindHeader("MyHeader", "http://sample.org/test");
      string result;
      if (myHeaderIndex != -1)
      {
        result = OperationContext.Current.RequestContext.RequestMessage.Headers.GetHeader(myHeaderIndex);
      }
      else
        result = OperationContext.Current.RequestContext.RequestMessage.Headers.Action;
      return string.Format("You entered: {0}, Header: {1}", value, result);

需要注意的是, Client config 中,可以傳不同的訊息,由 Service 來搜尋header。這樣一來,就不需要修改 DataContract 了。
當然,這樣也是有相當大的壞處,這樣會造成設計人員各自傳遞不同格式的訊息。假以時日,一堆不同的自訂訊息,最終難以維護。

sample download

2009年2月5日 星期四

Enterprist Library: 寫到同一個 log file

也是寫 log 的問題。
當 log application block (LAB) 和 exception handling application block (EHAB) 寫訊息到同一個檔案時,會因 file 已被 open 的關係,產生一個 (GUID)log.log 類似的檔案。
這一點很不好,因為我想將所有的訊息(記錄訊息和錯誤訊息)同到相同的檔案,以方便觀察程式的實際運作行為。

原來這一點,已在 V4.0 版被修正了.

在 EHAB 的 logging handler  上,取得 property

image

property 上,有個新的 UseDefaultLogger,預設值為 false, 將它改為 True。就完成了。

image

 

see http://msdn.microsoft.com/en-us/library/cc511712.aspx

Enterprise Library Logging Application Block: Timespan format

Enterprise Library 大概是我相當堅持要使用的 open source library 吧。
尤其是 logging 與 exception handling 這兩個。

當要記錄訊息時,最常用的就是 rolling flat file trace listener

image

然而,記錄的檔案,時間標記的格式,預設卻是UTC  時間,根台北時間差8小時。
怎麼辦呢?google 大神又發揮了神蹟,原來在 Text Formatter 有東西可以改。

image

改成 [{timestamp(local:yyyy-MM-dd HH:mm:ss)}] {message} , 就符合我的需求了

image

 

see also http://blogs.msdn.com/tomholl/archive/2006/01/22/516055.aspx

Web Services Architecture

我個人十分喜歡 WCF。因為

  1. 可以實作出高重複使用性的元件(re-use)
  2. 依靠設定(configuration)而非程式碼。
  3. 實作出許多 WS-* 。

第三點,較難一次說完,而且WS-* 的標準也愈來愈多。
想要說服同事使用 WCF 的技術,可得花費一番功夫。

下圖是 Web Services Architecture, 是我在 2006 年聽 Web cast 時抓的圖。

Web Service Architecture

裡頭有相當多的標準我還不了解呢。使用 WCF的最大好處,就是 WCF 已經幫我們實作許多這些標準,而且隨著版本昇級,WCF也將實作更多的 WS-* 檔準。
我們需要的就是「看文件」+「設定」而已。

See also An Introduction to the Web Services Architecture and Its Specifications , Web Services Architecture

2009年2月4日 星期三

ThickBox

今日無意間發現了一個好用的 jquery extension library, ThickBox

可用來顯示圖片,model dialog 等。
試試該 demo 吧!(在ThickBox網頁的下方)

2009年2月3日 星期二

Private Accessor for functionXXX is not found. Please rebuild the containing project or run the Publicize.exe manually.

在寫單元測試時,發生了這樣的錯誤。

Private Accessor for functionXXX is not found. Please rebuild the containing project or run the Publicize.exe manually.

原來,當單元測試的程式碼 compile 失敗時,記得不再硬要 Visual Studio 再建立單元測試,就會發生這樣的錯誤。

先讓單元測試的 Class library 先 compile 過了再說。

2009年2月2日 星期一

適用於 Windows Vista 和 Windows Server 2008 的 Windows Internet Explorer 8 版本選擇 1

IE 8 RC1 出來了。

中文英文

還是下載英文的吧。這已經是我的習慣了。

Share with Facebook