❶ 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实例。