❶ sql，MySQL都分別有哪些認證
Oracle
認證有OCA、OCP、OCM。
OCA（Oracle Certified Associate），是入門級別的資格證書；
OCP（Oracle Certified Professionals），是專業證書；
OCM（Oracle Certified Master），是新的高級資格證書，授予擁有最高專業技術的甲骨文認證專家。
微軟MCSE sql 2012認證主要分為兩個方向：
1：Data Platform數據平台
2：MCSE: Business Intelligence商業智能
MySQL資料庫認證分開發和管理兩種，
開發認證：Certified MySQL 5.0 Developer (CMDEV)
需要通過兩門考試：003-*和004-*(*為任意考試號，現在為002)，即003-002，004-002
管理認證：Certified MySQL 5.0 DBA (CMDBA)
需要通過兩門考試：005-*和006-*(*為任意考試號，現在為002)，即005-002，006-002
現在還有一新的認證：Certified MySQL 5.1 Cluster DBA (CMCDBA)
該認證是MySQL資料庫集群管理認證
需要首先獲得CMDBA，然後再加考：009-*(*為任意考試號，現在為002)，即009-002就可獲得
❷ server2012 r2群集虛擬機遷移問題
首先，
虛擬機，，虛擬機網卡，有幾種連接方式，就是說，物理網卡，並非虛擬機的網卡
你要測試的，是虛擬機效果（要停就停用，虛擬機網卡）
❸ SQL server 2012 企業版 有人用過么 always on 這個功能怎麼樣適合工廠資料庫么
企業版一致在用。主要是因為我們不是特別在意License的費用。
Always on這個功能的實用性很強，在實時交易系統中，為了保證性能，我們總是通過讀寫分離的方式。以前主要是通過資料庫復制，現在可以使用Always On，當然，前提是已經有了Cluster環境，否則挺麻煩的。
❹ sql2012 alwayson高可用性有用嗎
故障轉移群集又稱為Failover Cluster。此技術使用的共享存儲技術，不涉及到底層數據的同步問題，因此可以認為群集的最大好處就是性能較高。正因為如此，存儲將成為整個群集技術中的單點故障。在短短的半年內，筆者遇到因為存儲單點故障而進行的群集故障操作已有四個，平均一個多月就要處理一個。群集技術的另一個弊端就是某一個時間點只有一個節點處於活動狀態，其他節點處於閑置不可用狀態，造成了硬體資源的浪費。
❺ 如何部署sql alwayson with cluster share volume
至少需要三台機器（我創建了三台虛擬機，一台是作為DC,DNS伺服器，兩台Nod3）
（備註：為啥一定要3台，因為SQL SERVER 的 Cluster服務不能安裝在域伺服器上。Windows2008 R2 和SQL SERVER 2012 一定要打上sp1.否則有不可預知的錯誤）
機器名
角色
OS
IP Address
DC
Domain Controller
Windows 2008R2
192.168.1.10
Node1
Cluster Node 1
Windows 2008R2
192.168.1.11 Public
192.168.2.1
心跳線
Node2
Cluster Node 2
Windows 2008R2
192.168.1.12 Public
192.168.2.2
心跳線窗體底端
首先配置Windows集群：
1. 安裝.NETFramework 3.5.1 Features和Failover Clustering
2. 安裝Windows KB 2494036
3.新建集群
4.選擇加入集群的伺服器：
5.檢測配置：
6.不需要選擇檢測共享磁碟（AlwaysOn不需要）
7.開始檢測：
8.檢測內容（檢測完成後可以導出Report）：
9.之後輸入Cluster名字和IP點擊下一步創建成功，成功後打開Server Manager查看集群配置(可以看到並沒有共享磁碟，跟傳統的集群還是有區別的)：
現在我們集群已經配置後了，下一步是安裝SQLServer並且配置Always On.
我們已經配置了Cluster,Part2 我們安裝SQL Server 2012 評估版（要使用64位的SQLServer, X86不支持Always On）並且配置Alaways On Group.
1. 以管理員身份安裝
2.選擇單機安裝（不是集群安裝）
3.SQL Server 2012的新功能，可以在安裝的時候搜索最新的補丁，將補丁也以前安裝（這個是可選項）
4.規則檢測
5.選擇安裝組件
6.實例名：
7.計算需要的磁碟空間：
8.Service賬戶（域賬戶）：
9.排序規則（可以根據自己需要選擇）：
10.設置許可權，資料庫文件備份地址以及Filestream選項：
11.安裝後需要重新啟動（可以查看安裝日誌）：
12.在ConfigurationManager中對SQL Server開啟Always OnHigh Availability(可以自動檢測到前面我們創建的Cluster名字)
設置更改後需要重啟Service.現在一切都具備了，我們可以配置Always On group了。
1.創建新的可用性組（可用性組向導，也可以用下面的選型）：
2.輸入可用性組的名字：
3.選擇組中的資料庫：
4.Replica 選擇Node2（選擇自動Failover/可讀資料庫）:
5.點擊下一步，Node1將會備份資料庫到Share Folder然後還原到Node2做同步 (Node1為主,Node2為輔助)
下一步就是測試Node2數據可讀已經Failover.
可用性組我們已經創建成功了，現在測試一下Node2 上讀取數據以及Failover.
1. 數據測據：Node1上創建表test插入記錄
在Node2上訪問test資料庫，數據可以查到（在Mirror中是不可以查詢的，而且數據同步不會導致Node2的連接斷掉）：
2. Failover測試：
連接到Node2:
Failover後（Primary已經變成Node2）：
可以看到Always On group 既保證了高可用性，有可以實現同步資料庫的只讀訪問，提供了硬體的利用率，非常給力的一個功能。
最後，建議在 「AlwaysOn 高可用性 」下-》 「可用性組」 中，增加一個可用性組偵聽器，在偵聽器中可以設定一個IP，對外用此IP提供服務。這樣，SQL服務的IP可以不同於windows集群的IP。兩項服務有可能會在兩台不同的機器上。
❻ SqlServer 2012 Cluster 可以實現雙活嗎
Windowscluster要求同一個cluster中的所有windows版本都是相同的，這樣就出現一個問題，當我們要將對windows進行升級時，(例如從windows2008R2升級到windows2012)不得不搭建一套新的windowscluster。你可以選擇使用新的硬體搭建，或者將現有windowscluster中的節點一台一台的evict掉，重裝/升級系統後加入到新的windowscluster中。具體的cluster升級方案我就不在這里討論。馬上進入主題：(後文簡稱為AG)的一個要求是：所有的replica都要求隸屬於同一個windowscluster。所以當我們對windowscluster進行升級時，無法在新的windowscluster和現有的windowscluster之間建立AG。那麼在遷移過程中會有一段時間內AG無法對外提供服務。從資料庫的角度上說，我們需要做下面的事情接下來停止應用並刪除cluster1中的Listener，確保沒有外界來接使用SQLSERVER.BackupdatabaseBackuptaillog將備份文件到新的伺服器Restore到各個伺服器然後重新建立AG創建Listener重啟應用我們需要將資料庫備份並還原到新的primaryreplica和secondaryreplica。相應的downtime時間就是1+2+3+4+5+6+7+8想要的時間。或許你想到了在新舊cluster之間創建一個mirroring，但遺憾的是，創建了AG的資料庫是不再允許創建mirroring的.那應當如何進行遷移呢?從SQLServer2012SP1開始，允許在兩套不同的windowscluster之間創建AG。下面用一個例子說明一下有一個三個節點的windowscluster,windows版本為Windows2008R2Domain:liweiyin3.labClustername::Listener1三個節點上裝有SQLServer2012SP1的standalone實例。均為默認實例。之間建立了AG.拓撲圖如下：現在創建一套兩個節點的windows2012的windowsclusterDomain:liweiyin3.labClustername:cluster2Server005Server006對cluster1上的AG資料庫進行備份，包含fulldatabasebackup和logbackup兩個cluster中間創建AG：將第一步得到的文件在cluster2的節點上進行還原，指定為withnorecovery.接下來在cluster2的三個資料庫上執行下面的語句='cluster1.liweiyin3.lab'這條語句執行完畢後，這台資料庫的clustercontext就會切換為cluster1了。這個結果可以從下面的DMV中檢查到selectcluster_namefromsys.dm_hadr_cluster接下就可以在cluster1和cluster2之間建立AG。我們可以使用UI或者T-SQL語句。需要注意的是，請將cluster2中的至少一個SQLServer的同步模式設置為Synchronouscommit,以保證遷移是沒有數據損失的。這樣，我們就建立了一套既包含win2008R2，也包含win2012的AG環境了。並且也可以正常地向外界提供服務，整個流程不需要downtime.但需要注意的是，這種情況下是不允許在兩個cluster之間進行failover的。相應的提示信息如下.(WSFC)clustercontext.Underaremoteclustercontext,.接下來停止應用並刪除cluster1中的Listener，確保沒有外界來接使用SQLSERVER在Cluster1將AG進行offline操作將cluster2中所有sqlserver的CLUSTERCONTEXT切換回來=local在cluster2中重新創建AG在cluster2中創建新的listener重啟應用這樣所涉及的downtime就是5+6+7+8+9+10和之前的解決方案相比，省去了backup，文件和restore的時間。其餘的操作都是句操作，很大程度地減少了downtime。更多信息===遷移之前，Cluster2中的sqlserver不允許創建任何AG。遷移之前需要授予cluster2中的sqlserver啟動賬號訪問cluster1注冊表的許可權(SQLServer)
❼ SQLServer 2012 Alwayson 是否能實現熱備
SQL Server2012所支持的AlwaysOn技術集中了故障轉移群集、資料庫鏡像和日誌傳送三者的優點，但又不相同。故障轉移群集的單位是SQL實例，資料庫鏡像和日誌傳送的單位是單個用戶資料庫，而AlwaysOn支持的單位是可用性組，每個組中可以包括一個或者是多個用戶資料庫。也就是說，一旦發生切換，則可用性組中的所有數據組會作為一個整體進行切換。
AlwaysOn底層依然採用Windows 故障轉移群集的機制進行監測和轉移，因此也需要先建立Windows Cluster，只不過可用性組中的資料庫不一定非要再存放在共享存儲上了。可以是存儲在本地磁碟上。
❽ SQL Server 補丁版本的 CU與GDR有什麼區別
常見問題
對我的 SQL Server 版本提供了 GDR 和/或 CU（累積更新）更新。我如何知道該使用哪個更新？
首先，確定 SQL Server 的版本號。有關確定 SQL Server 版本號的更多信息，請參閱 Microsoft 知識庫文章321185 - 如何確定 SQL Server 及其組件的版本、版本類別和更新級別。
其次，在下表中，找出你的版本號及其所屬的版本范圍。相應的更新指您需要安裝的更新。
GDR 更新 – 累積僅包含適用於給定基線的安全更新。
CU 更新 – 累積包含適用於給定基線的所有功能修復程序和安全更新。
如果 SQL Server 安裝了基線版本，則可以選擇 GDR 或 CU 更新。
如果 SQL Server 安裝有意只安裝了過去的 GDR 更新，則選擇安裝 GDR 更新包。
如果 SQL Server 安裝有意只安裝了以前的 CU 更新，則選擇安裝 CU 安全更新包。
注意：您僅有一次機會可以將 GDR 更新更改為 CU 更新。一旦 SQL Server CU 更新應用於 SQL Server 安裝，將無法返回到 GDR 更新路徑。
注意如果您的 SQL Server 版本號未列在下表中，則說明此 SQL Server 版本不再受支持。請升級到最新的 Service Pack 或 SQL Server 產品，以便使用本次和未來的安全更新。
什麼是 GDR 和 CU 更新名稱，兩者有何差別？
GDR（General Distribution Release，普通分發版本）和 CU（Cumulative Update，累積更新）對應於兩種不同的可用於 SQL Server 基線版本的服務選項。基線可以是 RTM 版本或 Service Pack 版本。
對於任何給定基線，GDR 或 CU 更新均為可選項（見下文）。
詳情參見：網頁鏈接
❾ SQL Server 2012 標准版是否能搭建alwayson
SQLServer 2012 Always on是針對高可用性和災難恢復的新解決方案。可以配置一個或多個輔助副本以支持對輔助資料庫進行只讀訪問，並且可以將任何輔助副本配置為允許對輔助資料庫進行備份。 這樣就提供了硬體的使用效率。
「可用性組」針對一組離散的用戶資料庫（稱為「可用性資料庫」，它們共同實現故障轉移）支持故障轉移環境。一個可用性組支持一組主資料庫以及一至四組對應的輔助資料庫。可用性組在可用性副本級別進行故障轉移。故障轉移不是由諸如因數據文件丟失或事務日誌損壞而使資料庫成為可疑資料庫等資料庫問題導致的。
每組可用性資料庫都由一個「可用性副本」承載。有兩種類型的可用性副本：一個「主副本」和一到四個「輔助副本」。前者用於承載主資料庫，後者則承載一組輔助資料庫並作為可用性組的潛在故障轉移目標。主副本使主資料庫可用於客戶端的讀寫連接。此外，它在稱為「數據同步」的過程中使用，在資料庫級別進行同步。主副本將每個主資料庫的事務日誌記錄發送到每個輔助資料庫。每個輔助副本緩存事務日誌記錄（「硬化」日誌），然後將它們應用到相應的輔助資料庫。主資料庫與每個連接的輔助資料庫獨立進行數據同步。因此，一個輔助資料庫可以掛起或失敗而不會影響其他輔助資料庫，一個主資料庫可以掛起或失敗而不會影響其他主資料庫。
或者，您可以配置一個或多個輔助副本以支持對輔助資料庫進行只讀訪問，並且可以將任何輔助副本配置為允許對輔助資料庫進行備份。部署 AlwaysOn可用性組需要一個 Windows Server故障轉移群集 (WSFC)群集。
圖顯示一個可用性組，該組包含最大數目的可用性副本，即一個主副本和四個輔助副本。
來自：http://msdn.microsoft.com/zh-cn/library/ff877884.aspx
雖然2012 Always on是基於WSFC的，但是並不需要共享存儲，所以配置就非常簡單。
下面是我的安裝步驟：
至少需要三台機器（我創建了三台虛擬機，一台是作為DC,DNS伺服器，兩台Nod3）
（備註：為啥一定要3台，因為SQL SERVER 的 Cluster服務不能安裝在域伺服器上。Windows2008 R2 和SQL SERVER 2012 一定要打上sp1.否則有不可預知的錯誤）
機器名
角色
OS
IP Address
DC
Domain Controller
Windows 2008R2
192.168.1.10
Node1
Cluster Node 1
Windows 2008R2
192.168.1.11 Public
192.168.2.1
心跳線
Node2
Cluster Node 2
Windows 2008R2
192.168.1.12 Public
192.168.2.2
心跳線窗體底端
首先配置Windows集群：
1. 安裝.NETFramework 3.5.1 Features和Failover Clustering
2. 安裝Windows KB 2494036
3.新建集群
4.選擇加入集群的伺服器：
5.檢測配置：
6.不需要選擇檢測共享磁碟（AlwaysOn不需要）
7.開始檢測：
8.檢測內容（檢測完成後可以導出Report）：
9.之後輸入Cluster名字和IP點擊下一步創建成功，成功後打開Server Manager查看集群配置(可以看到並沒有共享磁碟，跟傳統的集群還是有區別的)：
現在我們集群已經配置後了，下一步是安裝SQLServer並且配置Always On.
我們已經配置了Cluster,Part2 我們安裝SQL Server 2012 評估版（要使用64位的SQLServer, X86不支持Always On）並且配置Alaways On Group.
1. 以管理員身份安裝
2.選擇單機安裝（不是集群安裝）
3.SQL Server 2012的新功能，可以在安裝的時候搜索最新的補丁，將補丁也以前安裝（這個是可選項）
4.規則檢測
5.選擇安裝組件
6.實例名：
7.計算需要的磁碟空間：
8.Service賬戶（域賬戶）：
9.排序規則（可以根據自己需要選擇）：
10.設置許可權，資料庫文件備份地址以及Filestream選項：
11.安裝後需要重新啟動（可以查看安裝日誌）：
12.在ConfigurationManager中對SQL Server開啟Always OnHigh Availability(可以自動檢測到前面我們創建的Cluster名字)
設置更改後需要重啟Service.現在一切都具備了，我們可以配置Always On group了。
1.創建新的可用性組（可用性組向導，也可以用下面的選型）：
2.輸入可用性組的名字：
3.選擇組中的資料庫：
4.Replica 選擇Node2（選擇自動Failover/可讀資料庫）:
5.點擊下一步，Node1將會備份資料庫到Share Folder然後還原到Node2做同步 (Node1為主,Node2為輔助)
下一步就是測試Node2數據可讀已經Failover.
可用性組我們已經創建成功了，現在測試一下Node2 上讀取數據以及Failover.
1. 數據測據：Node1上創建表test插入記錄
在Node2上訪問test資料庫，數據可以查到（在Mirror中是不可以查詢的，而且數據同步不會導致Node2的連接斷掉）：
2. Failover測試：
連接到Node2:
Failover後（Primary已經變成Node2）：
可以看到Always On group 既保證了高可用性，有可以實現同步資料庫的只讀訪問，提供了硬體的利用率，非常給力的一個功能。
最後，建議在 「AlwaysOn 高可用性 」下-》 「可用性組」 中，增加一個可用性組偵聽器，在偵聽器中可以設定一個IP，對外用此IP提供服務。這樣，SQL服務的IP可以不同於windows集群的IP。兩項服務有可能會在兩台不同的機器上。
❿ Windows Server 2012 R2中集群共享卷功能有哪些升級
需要說明的是我們搭建的SQL Server故障轉移集群（SQL Server Failover Cluster）是可用性集群，而不是負載均衡集群，其目的是為了保證服務的連續性和可用性，而不是為了提高服務的性能。
SQL Server始終在負載均衡集群方面都缺少自己的產品，多由第三方廠家提供，但SQL Server故障轉移集群卻由來已久，在SQL Server 2012還提供了一個可用性組（AlwaysOn High Availability Groups）的新特性，我們知道微軟的故障轉移集群（Windows Server Failover Clustering , WSFC）一般需要共享存儲，SQL Server故障轉移集群也是建立在WSFC的基礎之上，可用性組卻可以不依賴於共享存儲實現SQL Server的故障轉移，這為沒有共享存儲的環境提供了一個實現SQL Server高可用的解決方案，關於AlwaysOn特性可以參閱相關文檔，這里我們實現的是仍是基於共享存儲的包含兩個節點的SQL Server故障轉移集群。
一、搭建Windows故障轉移集群（WSFC）
SQL Server故障轉移集群是基於WSFC的，因而我們需要事先在兩個節點中搭建一個WSFC，這里需WSFC僅是一個容器，可以放置多個角色以實現這些角色的故障轉移。為搭建一個WSFC，除了需要域環境，還需要在節點，存儲，網路等方面做准備。
Cluster
1、在各節點中添加Failover Clustering伺服器功能。
image
2、確保各節點操作系統的更新一致，新安裝的系統要麼更新到最新，要麼暫不更新。
3、在各節點中配置管理網路和心跳網路，雖然一個可用網路既可以搭建集群，但是最佳實踐還是分開。
4、在各節點中配置共享存儲磁碟，初始化並格式化磁碟，分配盤符。這里的共享存儲磁碟可以是基於IP SAN和FC SAN的磁碟，也可以是基於文件伺服器的虛擬磁碟，具體可以參考Windows Server 2012 虛擬化測試：存儲。在節點中可見磁碟如下：
image
為搭建SQL Server故障轉移集群，至少需要准備兩塊共享磁碟：集群見證磁碟Q、為存儲SQL Server資料庫和日誌文件准備的集群磁碟S。另外我們需要為SQL Server的集群實例配置分布式事務協調器（Distributed Transaction Coordinator, DTC），因而需要為DTC准備磁碟M。微軟建議將SQL Server各類文件分開存儲，最佳實踐需准備兩塊以上共享磁碟，分別存儲User Database、Backup和User Database Log文件，這就至少需要另一個集群磁碟L。綜上我們對存儲做如下配置：
集群見證磁碟Q
DTC磁碟M
SQL Server程序：本地磁碟C
User Database文件：集群磁碟S
User Database Log文件：集群磁碟L
TempDB文件：本地磁碟D，SQL Server 2012支持將Temp DB文件可以放在本地快速磁碟中。
Backup文件：集群磁碟S
另外值得一提的是到SQL Server 2014才提供了對集群共享卷的支持，因而這里只能使用集群磁碟。
5、使用Failover Cluster Manager驗證並創建集群。完成後的集群磁碟視圖如下：
image
二、安裝SQL Server故障轉移集群
Windows故障轉移集群（WSFC）搭建成功後即完成了SQL Server故障轉移集群的基礎，接下來我們繼續完成SQL Server部分。先在一個節點上安裝SQL Server Failover Cluster，然後再另一個節點安裝加入集群節點。
image
SQL Server集群部分，先通過驗證，這里的警告主要是搭建Windows故障轉移集群存在警告的警告，升級警告以及防火牆警告，可以繼續。
image
選擇Database Engine Services和管理組件，注意這里只有Database Engine Services和Analysis Services支持集群，其他服務都不支持。其他組件如需要也可以隨後再添加，但是添加其他組建時選擇Add features to an existing installation，然後選擇Perfom a new installation of SQL Server 2012，而不是Add features to an existing instance of SQL Server 2012，否則最後會出現Existing clustered or cluster-prepared instance的錯誤，具體參考Installing SQL Integration Services after SQL Cluster Setup has Completed。
image
配置一個網路名稱，類似於計算機名稱，今後將通過該名稱訪問資料庫實例。
image
三、配置DTC和SQL Server 集群
分布式事務協調器（Distributed Transaction Coordinator, DTC）在Windows中是默認安裝並運行的服務。DTC的主要目的是為了實現分布式事務，確保跨進程通信的一致性，這里的進程可以是同一計算機中的兩個進程，也可以是不同計算機中的進程。因而在微軟的世界裡，常常看到DTC的身影。
如果只是獨立安裝SQL Server資料庫引擎則無需配置DTC。但是在同時運行SQL Serve集成服務（SQL Server Integration Services, SSIS）或者搭建SQL Sever故障轉移集群等需要分布式事務的場景中，則需要配置DTC。不配置DTC並不影響SQL Server集群的安裝，但是DTC沒能正確配置，SQL Server集群的功能將受到影響。
Windows Server 2008及以後版本在一個Windows集群中可以有多個DTC實例，這些DTC實例可以是集群實例也可以是本地實例（這里「實例」概念的類似於SQL Server資料庫引擎實例，是作為操作系統服務運行的，是同一個可執行程序的副本，在Windows集群中運行的各類服務都是以實例的形式存在，這些實例依賴Windows集群實現故障轉移），甚至可以為SQL Server集群中每個SQL Server實例配置一個專屬的DTC實例。SQL Server集群實例按照如下的是順序選擇DTC實例：
使用SQL Server實例專屬的DTC實例，該DTC實例作為SQL Server實例以來的資源，如果DTC實例失敗，將造成SQL Server實例的失敗。SQL Server 2008及以後版本才有此項。
使用映射給SQL Server實例的DTC實例，使用命令msdtc可以為SQL Server實例映射DTC實例。
使用默認的DTC集群實例，SQL Server 2008及以後版本可以在Windows集群中創建多個DTC實例，第一個創建的DTC實例為默認實例，DTC集群實例並未指定給SQL Server實例專用，因而其他應用程序也可以使用該實例。
使用安裝在本地計算機上DTC實例。
由於SQL Server集群實例做出選擇之後是不會自動重新選擇的，比如SQL Server集群實例選擇了專屬的DTC實例，即使該實例失敗，也不會更換下一個可用的DTC實例，除非手動刪除專屬的DTC實例，因而微軟建議在SQL Server 2008及以後版本要麼為SQL Server集群中的每個SQL Server實例創建專屬的DTC實例，要麼就不要在SQL Server集群中創建任何DTC實例（這里的DTC實例都是集群實例，即可以實現DTC故障轉移），這時SQL Server集群實例會選擇實例所在節點的本地DTC實例。關於DTC的更多信息，可以查閱這里。當然這里我們不會什麼也不做，下面我們將為SQL Server實例配置專屬的DTC實例。