• [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (11) 创建侦听
    35. 为可用性组添加侦听器,选择静态 IP 6641664236. 端口选择1433 664337. 监听创建完毕 664438. 使用监听登录 SQL Server 6645Windows Server 2012 SP1 + SQL Server 2014 AlwaysOn 可用性组,到此配置完成!
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (11) 创建可用性组
    24. 在“Alwayson高可用性”节点上右键选择“新建可用性组向导注意:加入到AlwaysOn可用性组的数据库必须符合下面要求 (1) 数据库的恢复模式必须是“完整”恢复模式 (2) 数据库已进行了一次完整备份 (3) 需要是用户库,系统库不能加入可用性组 (4) 数据库可以读写,只读库不能加入到可用性组 (5) 数据库处于多用户模式 (6) 数据库没有使用AUTO_CLOSE (7) 不属于任何其他的可用性组 (8) 数据库没有配置数据库镜像 (9) 一个可用性组最大支持100个数据库 662725. 输入一个可用性组名称 662826. 选中可用性组数据库 662927. 点击添加副本添加其他节点(这里我用域用户远程登录另一个节点超时了好几次,但是用 SQL Server 验证就很快) 663028. 同步提交模式,第二个节点设为只读副本 663129. 选择 Endpoing 使用 IP 格式,服务账户是域账户 663230. 选择初始数据同步,这里选择“仅联接”模式 663331. 点击“下一步”来验证配置,对应侦听器配置警告可以忽略,后期来添加侦听器 因为使用的是“仅联接”数据库初始化方式,验证跳过像可用磁盘空间这样的检查 6634、6635 32. 创建成功,监听还没配 663633. 测试数据同步,在主副本上**一条 testAG, Success,可以看到只读副本同步了这条数据 6637663834. 查看故障转移集群管理器,可用性组变为一个角色 66396640
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (10) 创建同步数据库
    17. 创建数据库,创建表,**数据,然后确认数据库的恢复模式为 FULL 661718. 在 MSSQL01上进行数据库完整备份,日志完整备份 66186619662019. 将备份文件拷贝到在另一个节点 MSSQL02 的相同路径下 662120. 还原 MSSQL02 数据库 662221. 检查备份文件 662322. 还原数据库和日志,一定要用 non recovery mode 来还原 6624662523. 确认两各节点拥有相同的数据结构6626
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (9) 启用 AlwaysOn 可用性组
    10. 将DCADMIN 域用户加入到 SQL Server 的登录用户中 660666076608660911. 赋予 sysadmin 权限 661012. 两个节点都以 DCADMIN 用户登录 661113. 启用 SQL Server AlwaysOn 可用性组 661214. 需要重启服务才能变更生效 661315. 重启 SQL Server 服务,在服务器属性里可以看到启用HADR为True 6614661516. 验证各节点的投票数SELECT * FROM sys.dm_hadr_cluster_members;6616
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (8) 安装 SQL Server
    1. 切换到 Administrator 登录到 MSSQL01,安装 .Net Framework 3.5 (两个节点都需要这一步操作),需要从微软官网下载 Windows Server 2012 iso 以后安装 6597如果不安装 .net framework 3.5 的话会在SQL Server 安装过程中报如下错误 65982. 解压 iso 文件,拷贝解压后的路径 65993. 指定路径后安装,安装成功 66004. 安装完后重启计算机 5. 在各个节点上独立安装SQL Server 2014(不能使用群集方式安装),保证各个节点中使用相同的安装目录结构和排序规则! 66016. 默认下一步,安装成功 66027. 使用 DCADMIN 登录,将 SQL Server 服务和 SQL Server 代理服务的启动账户设为 DCADMIN,重启服务 66038. 设置完登录用户之后重启服务,启动用户为域用户 DCADMIN,两个节点都需要做同样的操作 66049. 安装 SQL Server ManagementStudio (SSMS) 6605
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (7) 创建仲裁见证共享文件夹
    21. 由于我们是两个节点的故障转移集群,所以需要加上共享文件夹,在域控上建立一个共享文件夹,让两个集群节点都可以访问 注意:如果是奇数节点,这一步是不需要做的! 生产环境请不要把共享文件夹放在域控上! 故障转移集群管理 -> 右键 -> 更多操作 -> 配置集群仲裁设置 658622. 选择仲裁见证 658723. 在域控上的C盘新建一个quorumshare文件夹作为共享文件夹 quorumshare文件夹的权限为everyone完全控制和DCADMIN域用户的读写权限(保险起见) 6588658924. 回到故障转移集群管理器,填写文件共享路径:\\WSFC\quorumshare 6590659165926593659425. 共享仲裁文件夹下生成两个文件 659526. 故障转移集群配置完成 6596 到此仲裁见证共享文件夹创建完毕,下一章节开始,我们将介绍如何配置 SQL Server AlwaysOn 可用性组
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (6) 创建故障转移集群
    9. 在其中一个节点,切换用户,使用域用户DCADMIN 登录 657210. 服务器管理器 -> 工具 -> 故障转移集群管理 657311. 故障转移集群管理 -> 验证配置 657412. 把所有的要添加到集群的服务器都加进来 657513. 做一下集群测试 657614. 查看集群测试报告,这里不能出现失败,警告可以看一下处理一下 657715. 点击完成 657816. 开始创建集群 657917. 输入集群名称,集群 VIP 658018. 下一步 658119. 创建集群 6582658320. 群集创建完成,可以在域控的AD用户和计算机里看到集群 65846585 到此故障转移集群创建完毕
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (5) 安装故障转移集群组件
    1. 为每台Windows Server安装故障转移集群功能启动“服务器管理器” 65652. 在“管理”菜单上,单击“添加角色和功能” 65663. 在“选择安装类型”页面上,单击“基于角色或基于功能的安装”,然后单击“下一步” 65674. 在“选择目标服务器”页面上,单击你想要安装该功能的服务器,然后单击“下一步” 65685. 在“选择功能”页面上,选中“故障转移群集”复选框 65696. 若要安装故障转移群集管理工具,请单击“添加功能”,然后单击“下一步” 65707. 在“确认安装选择”页上,单击“安装” 65718. 在每一台Windows Server 上重复上面的操作,安装故障转移集群功能。
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (4) 配置 SQL Server 服务器
    1. IP 设置,勾掉IPv6 65552. 禁用NetBIOS 6556 3. 查看域节点是否能ping通 65574. 加域,填写域名jhn.com,并输入刚刚在 AD域用户(DCADMIN)和密码 65585. 加入域后需要重启,重启后需要重新设置密码,以Administrator 登陆之后,计算机管理 -> 本地用户和组 ->组 -> 选中Administrators组 -> 右键 -> 添加到组 65596. 点击添加 65607. 点击高级->输入用户名密码 65618. 添加 DCADMIN 65629. DCADMIN 添加到 Administrators 组里 656310. 另一台机器重复上面的操作。 11. 最后在域控里查看DNS和AD Computers容器,两个节点都已经添加成功 6564
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (3) 安装域控
    本帖最后由 jimmy 于 2017-12-12 16:38 编辑10. 重启之后,会按照域用户登录 JHN\Administrator,首次登录需要重新设置登录密码,登录后,打开DNS管理器 654211. 可以看到域控制器wsfc.jhn.com已经将主机名(wsfc)和IP地址(192.168.1.198)注册到DNS服务器内 654312. 在_tcp文件夹内,_ldap记录和_gc记录说明这台服务器已经正确注册为域控制器和担当全局编录服务器 654413. 检查AD域服务和Netlogon服务是否正常启动 654514. 创建DCADMIN 用户 65466547654815. 域用户DCADMIN创建完毕 654916. 将这个域用户加入到域计算机组和域管理员组 65506551655217. DCADMIN用户已经添加到域计算机组和域管理员组 655318. 将系统自动更新关闭掉6554 到此,域控服务器安装配置完毕,下一章我们要配置 SQL Server 服务器 IP,加入到域里
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (2) 安装域控
    本帖最后由 jimmy 于 2017-12-12 16:38 编辑1. 设置 WSFC IP,勾选掉 IPv6,因为DNS服务器就安装在域控上,所以首选DNS服务器填写:127.0.0.1 回环地址 65332. 安装 AD DS 和 DNS Server 65343. 安装成功 65354. 点击服务器管理器右上角的小旗帜,弹出对话框,点击“将此服务器提升为域控制器”以提升为域控 65365. 添加新域名 65376. 设置DSRM密码,默认林中的第一棵域树的根域的域控制器必须担当全局编录服务器和必须安装DNS服务,不能是只读域控制器 65387. 下一步,NetBIOS 不需要设置 65398. AD DS 数据库采用默认路径 65409. 在安装之前,系统会预检一下,通过之后点击安装。安装完AD DS 之后系统会自动重启 6541
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (1) 准备阶段
    本帖最后由 jimmy 于 2017-12-12 16:09 编辑准备创建三台 Microsoft Windows Server 2012 SP1 虚拟机1台作为域名控制服务器2台作为 SQL Server 实例 6520 IP 规划 节点主机名Public IPPrivate IP节点1MSSQL01192.168.1.103192.168.1.101节点2MSSQL02192.168.1.197192.168.1.102域控WSFC192.168.1.198VIP-Cluster(JHN_CLUSTER)192.168.1.200AlwaysOn VIP192.168.1.201节点1和节点2需要各安装两个网卡,一个提供数据库连接服务,一个提供内网通信。
  • [技术干货] 一张图读懂 SQL Server 高可用解决方案之 AlwaysOn 可用性组
    惯例,先熟悉几个术语 可用性组 一个容器,用于一组共同实现故障转移的数据库(“可用性数据库”)。可用性数据库 属于可用性组的数据库。 对于每个可用性数据库,可用性组将保留一个读写副本(“主数据库”)和一个到八个只读副本(“辅助数据库”)。主数据库 可用性数据库的读写副本。辅助数据库 可用性数据库的只读副本。 话不多说,什么是AlwaysOn可用性组。 简单来说就是提供代替镜像的一种高可用性和灾难恢复的解决方案。 相比较于 AlwaysOn 故障转移集群实例,可用性组内的各个数据库副本不共享存储, 故障转移在各个数据库副本之间发生, 主数据库提供读写服务,辅助数据库提供只读服务, 最多可以支持八个只读实例。 支持异步提交模式(容灾方案)和同步提交模式(可用性方案)。5051
  • [技术干货] 一张图读懂 SQL Server 高可用解决方案之 AlwaysOn 故障转移群集实例
    首先明确几个概念 WSFC 群集 (WSFC cluster) “Windows Server 故障转移群集”(WSFC) 群集是一组独立的服务器,它们共同协作以提高应用程序和服务的可用性。 故障转移群集实例 (Failover cluster instance) 一个 Windows 服务实例,用于管理 IP 地址资源、网络名称资源和运行一个或多个应用程序或服务所需的其他资源。 每个 FCI 上运行一个 SQL Server 实例。 资源组 (Resource group) 作为单个群集对象管理的群集资源集合。 通常,资源组包含运行特定应用程序或服务所需的所有群集资源。 故障转移和故障回复始终作用于资源组。 在 FCI 中,一次只能有一个节点拥有 WSFC 资源组。 好吧,那么什么是故障转移集群实例? 话不多说,上图 4797 在一个 WSFC 集群内,2个或多个 FCI 实例共享一套存储。同一时间点只有一个 FCI 可以 获得资源组,提供数据库服务。当一个 FCI 出现故障不可提供服务的时候,该资源组会转移 到 WSFC 内的其他 FCI 节点,该节点的 SQL Server 实例启动,提供持续的服务。 优点 通过冗余提供实例级的保护 在出现故障(硬件故障、操作系统故障、应用程序或服务故障)时自动进行故障转移 支持多种存储解决方案,包括 WSFC 群集磁盘(iSCSI、光纤信道等)和服务器消息块 (SMB) 文件共享。 使用多子网 FCI 或在可用性组中运行 FCI 托管数据库的灾难恢复解决方案。 故障转移过程中无需重新配置应用程序和客户端 用于实现自动故障转移的针对具体触发器事件的灵活的故障转移策略 通过使用专用和持久的连接执行定期的详细运行状况检测,实现可靠的故障转移 通过间接后台检查点在故障转移期间实现可配置性和可预测性 故障转移期间限制对资源的使用 缺点 因为使用共享存储,如果存储级别发生故障,服务将会中断 以上:)
  • [技术干货] 快速了解 SQL Server 2017
    本帖最后由 jimmy 于 2017-11-14 22:42 编辑首先一张图带大家了解一下 SQL Server 的的市场地位这个是 SQL Server 2017 workshop 微软官方的演示图概括如下1. 基于 Gartner 魔力四象限图,行业地位稳居Top 3,在领导力方面超越 Oracle 现居第一2. 连续七年被美国国家标准与技术研究所 NIST 评为漏洞最少的数据库3. 业界领先的 OLTP, OLAP 性能表现,留下许多性能记录4. 商业数据库中提供最优秀性价比5. 集成机器内置学习服务 4790 简而言之,要性能有性能,要性价比有性价比,要地位有地位,要安全又安全,就问你用不用。 言归正传,2017年10月2日,微软正式商用 SQL Server 2017 for Linux,算是一个里程碑意义的产品,微软终于甩掉了这么多年的 Windows 包袱,投入到了开源大家庭的怀抱。 那么什么是 SQL Server 2017 for Linux?带大家看一下下面的 SQL Server 架构图 4791 简单来说,数据库引擎位于一个叫做 SQL PAL 的一个抽象层的上面,这个抽象层就是以前的 SQL OS 层,微软只是实现了 Linux Host 扩展这一部分,就实现了 SQL Server for Linux。再说通俗点,SQL Server for Linux 跟 SQL Server for Windows 是一套内核。所以期待 SQL Serverfor Linux 在性能上有所提升的同学们,你们可以散了。 那么SQL Server for Linux 有什么现实意义呢?1. 讨厌Windows 的同学可以有更多的选择了,目前支持 Redhat,SUSE,Ubuntu2. 可以部署Docker 了 下面是一个简单的基于容器的 CI/CD4792 SQLServer 2017 给我们带来了什么新鲜的东西? 1. 图数据库,带来了全新的语法支持4793 图数据库可以将复杂的关系,简单化,降低开发难度,减少代码量,便于后期维护,但是!!!!在优化器端,这个图数据库本身没有做任何优化,引擎需要将新引入的语法转化为传统的语法然后再执行,所以就效率而言对于传统的语法格式,只慢不快。 2. 自适应查询4794 统计情报不准确,往往会带来 SQL 语句性能的严重下降,而这种统计情报的不准确性,在有些场景是不可避免的。针对这类统计情报不准确导致的性能下降问题,微软引入了自适应查询功能。简单来说就是SQL 跑起来了发现被忽悠了,基于错误的统计情报导出的执行计划太不合理,跑死都跑不完,优化器一拍脑袋,换执行计划….这套方案让优化器可以在实际数据跟现存统计情报出现严重偏差的时候让 SQL 不至于出现严重性能下降。 3. 机器学习服务4795 这个一句话概括下来就是 SQL Server 原生支持 R 和 Python 语言,除此之外别无其他 4. 可恢复在线重建索引4796 简单来说,rebuildindex 语句可以做断点续传,在暂停状态下,SQL Server 会同时维护现有和新建的索引,当重新执行 rebuild index 语法的时候, SQL Server 会从上次暂停的位置继续执行,对于大型索引重建来说这个功能非常给力。但是,敲黑板!!! 这个功能只支持rebuild 语法, 对于create 语法暂时不支持。另外,暂停状态下,如果对索引或者依存的表发行 DDL 语句,索引重建操作不可恢复。 以上:)
总条数:108 到第
上滑加载中