在SQL SERVER 2005 建立Linked Server To PostgreSQL

今天在SQL SERVER 2005 建立Linked Server To PostgreSQL有發生奇妙的錯誤!!
我建立的方式是OLE DB Provider for ODBC+psqlodbc_09_00_0200~~
當SQL SERVER 2005都還沒做SP升級前OLE DB Provider for ODBC+psqlodbc_09_00_0200這樣openquery是可以正常執行的!!
可是當我SQL SERVER 2005升級到SP3時執行openquery就會發生錯誤!!!
Error code:
訊息 7399，層級 16，狀態 1，行 1
連結伺服器 "XXX" 的 OLE DB 提供者 "MSDASQL" 報告了錯誤。提供者報告了未預期的重大錯誤。
訊息 7350，層級 16，狀態 2，行 1
無法從連結伺服器 "XXX" 的 OLE DB 提供者 "MSDASQL" 取得資料行資訊。
去GOOGLE找了一下也沒發現這個問題的解決方式~~之後有發現解決方法在來補上!!
============================================================

所以我換了連結方式為PostgreSQL Native Provider (PGNP)~~
當把這個東東裝完後會在SSMS>伺服器物件>連結的伺服器>提供者裡面有多一個PGNP的~~這樣就代表裝完可以用了~~!!

PGNP如何建立Linked Server 底下有手冊可以參考!!!!!!
補充:後來發現PGNP是要錢的~~試用版每次傳回筆數只能是100行!!
所以後來改用psqlodbc~~不然PGNP真是好物一個~~速度比PGNP快好多!!!
First commercial PostgreSQL OLEDB provider:
http://www.postgresql.org/about/news.895
PGNP-1.3.0.2190.exe:
http://www.pgoledb.com/index.php?option=com_filecabinet&task=download&cid[0]=10&Itemid=68
使用手冊(第14頁有介紹Linked Server 及相關使用方法):
http://www.pgoledb.com/downloads/Developer%20Manual.pdf

============================================================
補上解決方法:
方法1:
原來我找的psqlodbc_09_00_0200這個版本與我的PostgreSQL版本(8.4.4)不同~~
所以我重新安裝 psqlodbc_08_04_0200~~這樣就不會再跑ERROR出來了!
psqlodbc下載網址:
http://www.postgresql.org/ftp/odbc/versions/msi/

方法2:
跟allow in process這個選項有關~~這個控制項如果啟用, 就會把Access的process包在SQL process裡一起跑. 不啟用就是讓他分開跑.這樣access端有錯誤就不會丟回SQL Server. 我想您access端雖然有問題但是不影響執行, 因此只要讓它不丟回SQL Server就好了.
關於兩者效能的差別, 官方的部落格有提到如果不選allow in process可能效能會差一些.這個選項主要是給一些third party的provider, 例如 Oracle, 在做linked server的時候不能跟SQL Server分開跑, 因此必須設定這個選項.  在正常情況下, 勾或不勾都是可以執行的.
http://blog.csdn.net/haipingma/archive/2010/04/27/5535147.aspx

============================================================

SQL Server 中處理 Unicode 字串

ACCESS是用UNICODE來存儲內容的，因此往裡面存放各種UNICODE 字符都不會出問題。 而如果向MSSQL 中存放的話有可能變成???難道MSSQL不支持UNICODE ，並非如此。而如果向SQL Server 有支援Unicode字。必須符合以下兩個條件。
1. 使用支援Unicode字元的資料型別來儲存資料。
在Microsoft SQL Server 中 ，以下資料型別支援Unicode資料：在Microsoft SQL Server 中 ，以下資料型別支援Unicode資料：
nchar nchar
nvarchar nvarchar
ntext ntext
2. 您在SQL Server 中處理Unicode字串常數時，必須在所有Unicode字串之前加上大寫字母N。
請參考以下文件：請參考以下文件： 
參考資料:http://support.microsoft.com/kb/239530/zh-tw

INF：SQL Server 中的Unicode字串常數需要N 前置詞 INF：SQL Server 中的Unicode字串常數需要N前置詞
當您在SQL Server 中處理Unicode字串常數時，必須在所有Unicode字串之前加上大寫字母N。 「N」這個前置詞代表的是SQL-92 標準中的「國際語言」(National Language)，並且必須為大寫。 如果您沒有在Unicode字串常數前面加上N 作為前置詞，則SQL Server 會在使用字串之前將它轉換成SQL Server 所安裝的字碼頁。同時您不能使用無法傳遞Unicode的程式來Insert Unicode字串 . 另外您的Server也必須有該相關的codepage, 否則無法顯示字串 。

About MDF與LDF的blocks

有人跟我講SQL SERVER 放MDF File的磁碟格式化時最好用64K下去分割~~~
LDF File的磁碟格式化用預設4K就可以~~
那為什麼會這樣子呢??我有去幾個論壇及GOOGLE大神上找一下答案!!
答案應該如下:

SQL Server 一個 page 是 8Kb~~所以 1Mb 的資料相當於有 128 個 pages!!
NTFS 預設 cluster 分割為 4Kb
若是撈 10Mb 的資料時，相當於撈 1280 個 pages，要讀 2560 個 cluster
若改 cluster 分割為 64 Kb，相當於一個 cluster 可放 8 個 pages，所以只要讀 160 個 cluster
磁碟 I/O 量相對降低，效能可提升一些些
但相對地，面對交易紀錄檔或是同詞曲上的零碎檔案會付出使用額外磁碟空間的代價
其實 DB 的結構設計、正規化、索引、...、也都是影響效能的因素之一，並非分割 cluster 成 64Kb 就跟吃大補丸一樣有顯著的提升


參考資料：http://msdn.microsoft.com/zh-tw/library/ms190969(v=SQL.100).aspx
                    http://www.dbworld.com.tw/

SQL Server 2008 on a Windows Server 2008 Cluster

PART1: http://www.mssqltips.com/tip.asp?tip=1687
PART2: http://www.mssqltips.com/tip.asp?tip=1698
PART3: http://www.mssqltips.com/tip.asp?tip=1709
PART4: http://www.mssqltips.com/tip.asp?tip=1721
問題一:
基本上按照以上步驟安裝即可~~!!
比較要注意的就是如果OS有裝賽門鐵克防毒那可能會出現一些問題!!
出現的問題就是當一節點重開後~另一節點就會有認不到的問題!!
此BUG現在不知道賽門鐵克是否有修復了!

問題二:
如果SQL Server 2008 是要安裝在Windows Server 2005上的話!!
要把SQL Server 2008 +SP1整合在一起!!這樣裝起來才不會出錯!
相關網址:
http://sharedderrick.blogspot.com/2010/01/sql-server-2008-with-sp1-slipstreaming.html

MSSQL Performance Dashboard Reports

微軟有針對SQL Server 2005 SP2 出了一個效能檢視工具---SQL Server 2005 Performance Dashboard Reports!!
這個工具是不用錢的~~只要有裝SQL Server 2005 SP2 以上的版本都能使用 (SQL Server 2008也可以用喔)~~
以下針對安裝方法及使用方法來介紹!!!

1.安裝方式:
 1-0:系統需求:
   安裝Performance Dashboard Reports需要SQL Server 2005 SP2以上的版本(SQL Server 2008也可以用喔)

 1-1:下載檔案:(SQL Server 2008需下載第二個載點的檔案)
   載點1: http://www.microsoft.com/downloads/details.aspx?FamilyId=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en
  
   載點2:http://blogs.technet.com/b/rob/archive/2009/02/18/performance-dashboard-reports-for-sql-server-2008.aspx

 1-2:開始安裝:
   SQL SERVER 2005 :     一直按NEXT就可以了!!!

   SQL SERVER 2008:
     A.更改預設安裝路徑:
        C:\Program Files\Microsoft SQL Server\100\Tools\PerformanceDashboard
     B.檔案取代:
        將載點2的檔案複製到安裝目錄取代檔案!!!(Performance_dashboard_main.rdl 和Setup.sql)

  1-3:SSMS執行Setup.sql         SSMS執行Setup.sql 前,建議修改datediff(ms, …) 變更為datediff(s, …)~~
         通常執行Setup.sql是不會遇到什麼問題!!

  1-4:SSMS新增效能報表

STEP1:
   

STEP2:
C:\Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard

安裝至此算是告一段落囉~~~不會太難!!!滑鼠點一點就裝完了!!
接下來可以開始使用囉!!
2.使用方法始用SSMS點開performance_dashboard_main這張報表就可以囉!
報表裏面有提供一些效能的資訊!Performance Dashboard Reports提供了以下以幾點功能:
1.CPU bottlenecks (and what queries are consuming the most CPU)
2.IO bottlenecks (and what queries are performing the most IO)
3.Index recommendations generated by the query optimizer (missing indexes)
4.Blocking
5.Latch contention 
以上這五點我覺得Index 建議這項最好用!!
他可以幫你檢查出該用INDEX卻沒用的欄位!!也可以看到有哪些INDEX被用到的機率極低!

MySQL Innodb 與 Binlog mode關係!!!

今天在做DB(innodb) table schema匯入後要異動資料時有發生下列錯誤
ERROR Log: binary logging not possible. message: transaction level 'read-committed' in innodb is not safe for binlog mode 'statement'
原因:當binlog_format 為statement時, read committed 會發生錯誤!!!
解決方法: (推薦方法4)
方法1.mysql> set session transaction isolation level REPEATABLE READ ; REPEATABLE READ ;
方法2. mysql>set session binlog_format=row;
方法3. mysql>set session binlog_format= mixed;
方法4. my.cnf 增加底下兩行~~在重啟MYSQL
binlog_format=mixed or row
innodb_locks_unsafe_for_binlog=1
所以以後要注意read committed與binlog格式的關係，否則會導致資料無法異動!!!
Binlog  format:
從 MySQL 5.1.12 開始，binlog_format可以用以下三種模式:
           1. STATEMENT: SQL語句的log(statement-based)
           2. ROW:資料行的log(row-based)
           3. MIXED: statement && row 混合使用,預設是statement
Binlog主要是做mysql replication或者是恢復某依段時間資料時會用到,也有人拿Binlog來做mysql 的差異備份~~~
所以對於Binlog format的選擇也是蠻重要的~~
如果對資料品質要求高一點的話可以選擇ROW層級的~~~
詳細Binlog format參考資料:
http://homeserver.com.tw/mysql/mysql-%e5%90%84%e7%a8%aebinlog_format%e5%84%aa%e7%bc%ba%e9%bb%9e%e6%af%94%e8%bc%83/

MySQL 讀寫分離 && Load Balance-MYSQL PROXY

這幾天在研究及測試MYSQL PROXY這個架構!

以下為研究之後的一些結果!!參考看看囉!!

MYSQL PROXY架構模型:

MYSQL PROXY優點:

1.Master / Slave讀寫分離

2.Slave DB Connection Load Balance

3.Slave DB Failover

           4.程式開發較簡單(不用考慮Connection)

MYSQL PROXY缺點:

1.目前尚是Alpha版!官方不保證他的穩定性!

2.當MYSQL PROXY這個服務掛掉後,client端就無法對Master / Slave DB 作存取

          

結論:

在對於資料及時性要求不高的環境上,可以考慮用看看!

如果有考慮要用這個solution的話,還需要用實體機器作一下壓力測試!

畢竟這個版本官方也不能保證穩定性!