• SQL Server 首次登陆 Linux 平台
    近日,微软 SQL Server 最近达成一个新的里程碑,最新版SQL Server 2017 除了支持 Windows 平台,将首次登陆 Linux 平台,并且还支持 Docker。此举让用户(特别是企业用户)有了更多选择。2016 年 6 月份,微软就提前预告 SQL Server 将支持 Linux 平台近年来, SQL Server 正在一直演化,除了想一改 DMS(数据库管理系统)的角色,还想介入到数据分析、机器学习和数据科学领域。2017 年 4 月份, SQL Server 发布了一个重要组件,支持在 SQL Server 中用 Python 运行机器学习负载。借助这个特性,数据科学家直接操作处理储存在 SQL Server 的数据,不用数据迁移了。机器学习/数据科学领域内的另一种编程语言 R,SQL Server 在去年就整合了。更多细节,见 SQL Server 官方:https://www.microsoft.com/en-us/sql-server/sql-server-2017参考:VentureBeta、SQL Server
  • [技术干货] 跟我一起学 MS SQL Server (一)
    关于 Microsoft SQL ServerMicrosoft SQL Server 是由美国微软公司所推出的关系数据库解决方案,最新的版本是 SQL Server 2016, 已经在 2016 年 6 月 1 日发布。数据库的内置语言原本是采用美国标准局(ANSI)和国际标准组织(ISO)所定义的 SQL 语言,但是微软公司对它进行了部分扩充而成为作业用 SQL(Transact-SQL)。 几个初始版本适用于中小企业的数据库管理,但是近年来它的应用范围有所扩展,已经触及到大型、跨国企业的数据库管理。数据库服务的启动数据库结构物理结构逻辑结构数据库命名规则数据库分类[/td][/tr][/table] 创建数据库时需要指定的属性数据库的创建方法命令行创建数据库范例数据库的删除方法命令行删除数据库范例
  • [技术干货] 跟我一起学 MS SQL Server (二) -- 了解数据库状态
    数据库状态数据库总是处于一个特定的状态中,例如,这些状态包括 ONLINE、OFFLINE 或 SUSPECT。若要确认数据库的当前状态,请选择 sys.databases 目录视图中的 state_desc 列或 DATABASEPROPERTYEX 函数中的 Status 属性。状态 定义ONLINE 可以对数据库进行访问。即使可能尚未完成恢复的撤消阶段,主文件组仍处于在线状态。OFFLINE 数据库无法使用。数据库由于显式的用户操作而处于离线状态,并保持离线状态直至执行了其他的用户操作。 例如,可能会让数据库离线以便将文件移至新的磁盘。然后,在完成移动操作后,使数据库恢复到在线状态。RESTORING 正在还原主文件组的一个或多个文件,或正在脱机还原一个或多个辅助文件。数据库不可用。RECOVERING 正在恢复数据库。恢复进程是一个暂时性状态,恢复成功后数据库将自动处于在线状态。如果恢复失败,数据库将处于可疑 状态。数据库不可用。RECOVERY PENDING SQL Server 在恢复过程中遇到了与资源相关的错误。数据库未损坏,但是可能缺少文件,或系统资源限制可能导致无法启 动数据库。数据库不可用。需要用户另外执行操作来解决问题,并让恢复进程完成。 SUSPECT 至少主文件组可疑或可能已损坏。在 SQL Server 启动过程中无法恢复数据库。数据库不可用。需要用户另外执行操作来 解决问题。EMERGENCY 用户更改了数据库,并将其状态设置为 EMERGENCY。数据库处于单用户模式,可以修复或还原。数据库标记为 READ_ONLY,禁用日志记录,并且仅限 sysadmin 固定服务器角色的成员访问。EMERGENCY 主要用于故障排除。例如, 可以将标记为“可疑”的数据库设置为 EMERGENCY 状态。这样可以允许系统管理员对数据库进行只读访问。只有 sysadmin 固定服务器角色的成员才可以将数据库设置为 EMERGENCY 状态。数据库文件状态在 SQL Server 中,数据库文件的状态独立于数据库的状态。文件始终处于一个特定状态,例如 ONLINE 或 OFFLINE。若要查看文件的当前状态,请使用 sys.master_files 或 sys.database_files 目录视图。如果数据库处于离线状态,则可以从 sys.master_files 目录视图中查看文件的状态。状态 定义ONLINE 文件可用于所有操作。如果数据库本身处于在线状态,则主文件组中的文件始终处于在线状态。如果主文件组中的文件 处于离线状态,则数据库将处于离线状态,并且辅助文件的状态未定义。 OFFLINE 文件不可访问,并且可能不显示在磁盘中。文件通过显式用户操作变为离线,并在执行其他用户操作之前保持离线状态。 注意 当文件已损坏时,该文件仅应设置为离线,但可以进行还原。设置为离线的文件只能通过从备份还原才能设置为在线。RESTORING 正在还原文件。文件处于还原状态(因为还原命令会影响整个文件,而不仅是页还原),并且在还原完成及文件恢复之前, 一直保持此状态。RECOVERY PENDING 文件恢复被推迟。由于在段落还原过程中未还原和恢复文件,因此文件将自动进入此状态。需要用户执行其他操作来解决 该错误,并允许完成恢复过程。SUSPECT 联机还原过程中,恢复文件失败。如果文件位于主文件组,则数据库还将标记为可疑。否则,仅文件处于可疑状态,而 数据库仍处于在线状态。在通过以下方法之一将文件变为可用之前,该文件将保持可疑状态: 1. 还原和恢复 2. 包含 REPAIR_ALLOW_DATA_LOSS 的 BCC CHECKDB DEFUNCT 当文件不处于在线状态时被删除。删除离线文件组后,文件组中的所有文件都将失效。
  • [技术干货] 快速了解 SQL Server 2017
    首先一张图带大家了解一下 SQL Server 的的市场地位这个是 SQL Server 2017 workshop 微软官方的演示图概括如下1. 基于 Gartner 魔力四象限图,行业地位稳居Top 3,在领导力方面超越 Oracle 现居第一2. 连续七年被美国国家标准与技术研究所 NIST 评为漏洞最少的数据库3. 业界领先的 OLTP, OLAP 性能表现,留下许多性能记录4. 商业数据库中提供最优秀性价比5. 集成机器内置学习服务 简而言之,要性能有性能,要性价比有性价比,要地位有地位,要安全又安全,就问你用不用。 言归正传,2017年10月2日,微软正式商用 SQL Server 2017 for Linux,算是一个里程碑意义的产品,微软终于甩掉了这么多年的 Windows 包袱,投入到了开源大家庭的怀抱。 那么什么是 SQL Server 2017 for Linux?带大家看一下下面的 SQL Server 架构图 简单来说,数据库引擎位于一个叫做 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/CD SQLServer 2017 给我们带来了什么新鲜的东西?1. 图数据库,带来了全新的语法支持图数据库可以将复杂的关系,简单化,降低开发难度,减少代码量,便于后期维护,但是!!!!在优化器端,这个图数据库本身没有做任何优化,引擎需要将新引入的语法转化为传统的语法然后再执行,所以就效率而言对于传统的语法格式,只慢不快。 2. 自适应查询统计情报不准确,往往会带来 SQL 语句性能的严重下降,而这种统计情报的不准确性,在有些场景是不可避免的。针对这类统计情报不准确导致的性能下降问题,微软引入了自适应查询功能。简单来说就是SQL 跑起来了发现被忽悠了,基于错误的统计情报导出的执行计划太不合理,跑死都跑不完,优化器一拍脑袋,换执行计划….这套方案让优化器可以在实际数据跟现存统计情报出现严重偏差的时候让 SQL 不至于出现严重性能下降。 3. 机器学习服务 这个一句话概括下来就是 SQL Server 原生支持 R 和 Python 语言,除此之外别无其他 4. 可恢复在线重建索引 简单来说,rebuildindex 语句可以做断点续传,在暂停状态下,SQL Server 会同时维护现有和新建的索引,当重新执行 rebuild index 语法的时候, SQL Server 会从上次暂停的位置继续执行,对于大型索引重建来说这个功能非常给力。但是,敲黑板!!!这个功能只支持rebuild 语法, 对于create 语法暂时不支持。另外,暂停状态下,如果对索引或者依存的表发行 DDL 语句,索引重建操作不可恢复。 以上:)
  • [技术干货] 一张图读懂 SQL Server 高可用解决方案之 AlwaysOn 故障转移群集实例
    首先明确几个概念WSFC 群集 (WSFC cluster)“Windows Server 故障转移群集”(WSFC) 群集是一组独立的服务器,它们共同协作以提高应用程序和服务的可用性。故障转移群集实例 (Failover cluster instance)一个 Windows 服务实例,用于管理 IP 地址资源、网络名称资源和运行一个或多个应用程序或服务所需的其他资源。 每个 FCI 上运行一个 SQL Server 实例。资源组 (Resource group)作为单个群集对象管理的群集资源集合。 通常,资源组包含运行特定应用程序或服务所需的所有群集资源。 故障转移和故障回复始终作用于资源组。在 FCI 中,一次只能有一个节点拥有 WSFC 资源组。好吧,那么什么是故障转移集群实例?话不多说,上图在一个 WSFC 集群内,2个或多个 FCI 实例共享一套存储。同一时间点只有一个 FCI 可以获得资源组,提供数据库服务。当一个 FCI 出现故障不可提供服务的时候,该资源组会转移到 WSFC 内的其他 FCI 节点,该节点的 SQL Server 实例启动,提供持续的服务。优点通过冗余提供实例级的保护在出现故障(硬件故障、操作系统故障、应用程序或服务故障)时自动进行故障转移支持多种存储解决方案,包括 WSFC 群集磁盘(iSCSI、光纤信道等)和服务器消息块 (SMB) 文件共享。使用多子网 FCI 或在可用性组中运行 FCI 托管数据库的灾难恢复解决方案。故障转移过程中无需重新配置应用程序和客户端用于实现自动故障转移的针对具体触发器事件的灵活的故障转移策略通过使用专用和持久的连接执行定期的详细运行状况检测,实现可靠的故障转移通过间接后台检查点在故障转移期间实现可配置性和可预测性故障转移期间限制对资源的使用缺点因为使用共享存储,如果存储级别发生故障,服务将会中断以上:)
  • [技术干货] 一张图读懂 SQL Server 高可用解决方案之 AlwaysOn 可用性组
    惯例,先熟悉几个术语可用性组一个容器,用于一组共同实现故障转移的数据库(“可用性数据库”)。可用性数据库属于可用性组的数据库。 对于每个可用性数据库,可用性组将保留一个读写副本(“主数据库”)和一个到八个只读副本(“辅助数据库”)。主数据库可用性数据库的读写副本。辅助数据库可用性数据库的只读副本。话不多说,什么是AlwaysOn可用性组。简单来说就是提供代替镜像的一种高可用性和灾难恢复的解决方案。相比较于 AlwaysOn 故障转移集群实例,可用性组内的各个数据库副本不共享存储,故障转移在各个数据库副本之间发生, 主数据库提供读写服务,辅助数据库提供只读服务,最多可以支持八个只读实例。支持异步提交模式(容灾方案)和同步提交模式(可用性方案)。
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (1) 准备阶段
    准备创建三台 Microsoft Windows Server 2012 SP1 虚拟机1台作为域名控制服务器2台作为 SQL Server 实例IP 规划节点1和节点2需要各安装两个网卡,一个提供数据库连接服务,一个提供内网通信。
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (2) 安装域控
    1. 设置 WSFC IP,勾选掉 IPv6,因为DNS服务器就安装在域控上,所以首选DNS服务器填写:127.0.0.1 回环地址 2. 安装 AD DS 和 DNS Server 3. 安装成功 4. 点击服务器管理器右上角的小旗帜,弹出对话框,点击“将此服务器提升为域控制器”以提升为域控 5. 添加新域名 6. 设置DSRM密码,默认林中的第一棵域树的根域的域控制器必须担当全局编录服务器和必须安装DNS服务,不能是只读域控制器 7. 下一步,NetBIOS 不需要设置 8. AD DS 数据库采用默认路径 9. 在安装之前,系统会预检一下,通过之后点击安装。安装完AD DS 之后系统会自动重启
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (3) 安装域控
    10. 重启之后,会按照域用户登录 JHN\Administrator,首次登录需要重新设置登录密码,登录后,打开DNS管理器 11. 可以看到域控制器wsfc.jhn.com已经将主机名(wsfc)和IP地址(192.168.1.198)注册到DNS服务器内 12. 在_tcp文件夹内,_ldap记录和_gc记录说明这台服务器已经正确注册为域控制器和担当全局编录服务器 13. 检查AD域服务和Netlogon服务是否正常启动 14. 创建DCADMIN 用户 15. 域用户DCADMIN创建完毕 16. 将这个域用户加入到域计算机组和域管理员组 17. DCADMIN用户已经添加到域计算机组和域管理员组 18. 将系统自动更新关闭掉到此,域控服务器安装配置完毕,下一章我们要配置 SQL Server 服务器 IP,加入到域里
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (4) 配置 SQL Server 服务器
    1. IP 设置,勾掉IPv6 2. 禁用NetBIOS 3. 查看域节点是否能ping通 4. 加域,填写域名jhn.com,并输入刚刚在 AD域用户(DCADMIN)和密码 5. 加入域后需要重启,重启后需要重新设置密码,以Administrator 登陆之后,计算机管理 -> 本地用户和组 ->组 -> 选中Administrators组 -> 右键 -> 添加到组 6. 点击添加 7. 点击高级->输入用户名密码 8. 添加 DCADMIN 9. DCADMIN 添加到 Administrators 组里 10. 另一台机器重复上面的操作。 11. 最后在域控里查看DNS和AD Computers容器,两个节点都已经添加成功
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (5) 安装故障转移集群组件
    1. 为每台Windows Server安装故障转移集群功能启动“服务器管理器” 2. 在“管理”菜单上,单击“添加角色和功能” 3. 在“选择安装类型”页面上,单击“基于角色或基于功能的安装”,然后单击“下一步” 4. 在“选择目标服务器”页面上,单击你想要安装该功能的服务器,然后单击“下一步” 5. 在“选择功能”页面上,选中“故障转移群集”复选框 6. 若要安装故障转移群集管理工具,请单击“添加功能”,然后单击“下一步” 7. 在“确认安装选择”页上,单击“安装” 8. 在每一台Windows Server 上重复上面的操作,安装故障转移集群功能。
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (6) 创建故障转移集群
    9. 在其中一个节点,切换用户,使用域用户DCADMIN 登录 10. 服务器管理器 -> 工具 -> 故障转移集群管理 11. 故障转移集群管理 -> 验证配置 12. 把所有的要添加到集群的服务器都加进来 13. 做一下集群测试 14. 查看集群测试报告,这里不能出现失败,警告可以看一下处理一下 15. 点击完成 16. 开始创建集群 17. 输入集群名称,集群 VIP 18. 下一步 19. 创建集群 20. 群集创建完成,可以在域控的AD用户和计算机里看到集群 到此故障转移集群创建完毕
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (7) 创建仲裁见证共享文件夹
    21. 由于我们是两个节点的故障转移集群,所以需要加上共享文件夹,在域控上建立一个共享文件夹,让两个集群节点都可以访问注意:如果是奇数节点,这一步是不需要做的!生产环境请不要把共享文件夹放在域控上!故障转移集群管理 -> 右键 -> 更多操作 -> 配置集群仲裁设置 22. 选择仲裁见证 23. 在域控上的C盘新建一个quorumshare文件夹作为共享文件夹quorumshare文件夹的权限为everyone完全控制和DCADMIN域用户的读写权限(保险起见) 24. 回到故障转移集群管理器,填写文件共享路径:\\WSFC\quorumshare 25. 共享仲裁文件夹下生成两个文件 26. 故障转移集群配置完成到此仲裁见证共享文件夹创建完毕,下一章节开始,我们将介绍如何配置 SQL Server AlwaysOn 可用性组
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (8) 安装 SQL Server
    1. 切换到 Administrator 登录到 MSSQL01,安装 .Net Framework 3.5 (两个节点都需要这一步操作),需要从微软官网下载 Windows Server 2012 iso 以后安装 如果不安装 .net framework 3.5 的话会在SQL Server 安装过程中报如下错误 2. 解压 iso 文件,拷贝解压后的路径 3. 指定路径后安装,安装成功 4. 安装完后重启计算机 5. 在各个节点上独立安装SQL Server 2014(不能使用群集方式安装),保证各个节点中使用相同的安装目录结构和排序规则! 6. 默认下一步,安装成功 7. 使用 DCADMIN 登录,将 SQL Server 服务和 SQL Server 代理服务的启动账户设为 DCADMIN,重启服务 8. 设置完登录用户之后重启服务,启动用户为域用户 DCADMIN,两个节点都需要做同样的操作 9. 安装 SQL Server ManagementStudio (SSMS)
  • [技术干货] [最佳实践] SQL Server 2014 搭建 AlwaysOn 可用性组 (9) 启用 AlwaysOn 可用性组
    10. 将DCADMIN 域用户加入到 SQL Server 的登录用户中 11. 赋予 sysadmin 权限 12. 两个节点都以 DCADMIN 用户登录 13. 启用 SQL Server AlwaysOn 可用性组 14. 需要重启服务才能变更生效 15. 重启 SQL Server 服务,在服务器属性里可以看到启用HADR为True 16. 验证各节点的投票数SELECT * FROM sys.dm_hadr_cluster_members;
总条数:92 到第
上滑加载中