数据和日志文件分开存放在不同磁盘上
数据文件和日志文件的 *** 作会产生大量的I/O 在可能的条件下 日志文件应该存放在一个与数据和索引所在的数据文件不同的硬盘上以分散I/O 同时还有利于数据库的灾难恢复
tempdb数据库单独存放在不同磁盘上
tempdb数据库是其他所有数据库都有可能使用的临时数据库 当使用select into 在没建立索引的列上执行Orderby时就会在tempdb数据库中产生临时表来存储中间数据 由于建立和填充临时表会严重降低系统性能 所以在尽可能的情况下应该为要排序的列建立索引 同时 tempdb数据库是为所有的用户和应用程序共享 所以如果一个用户占据了tempdb数据库的所有空间 则其他数据库将不能再使用 在可能的情况下 tempdb数据库应该单独放置在一个速度更快的硬盘或者RAID阵列上 分离tempdb数据库的I/O *** 作以加快性能 tempdb数据库应该有适当的容量 以满足用户的需要 应该允许tempdb数据库的空间自动增长 如果设置为不允许自动增长 当查询 *** 作建立了超过tempdb数据库容量的临时表时 *** 作将无法完成
适当设置tempdb数据库的增长幅度 过小的增长幅度会产生更多的外部碎片 会占用更多的资源
避免热点数据的发生
在SQLServer 之前 对于没有聚集索引的表（堆集表） 新插入的数据行总是放置在磁盘中表的物理结尾处 如果并发的用户很多 同时在对表执行插入或者更新数据的 *** 作 这将使得十分繁忙的表的末尾有可能产生数据热点 并发的I/O *** 作集中对少数页面进行 *** 作 将导致数据库性能的下降
在SQLServer中 新的数据行的物理存储空间的分配是通过PFS页面来进行的 PFS页面的管理算法将插入 *** 作进行分散来尽量避免产生数据热点
在设计应用系统和数据库时 要避免在自然增长的列上建立主键 这样有可能导致热点数据的发生
数据类型要少
在设计表时 尽可能少用数据类型 这样一个数据页面上可以保存最多的信息 数据页面就少 检索数据页面的I/O *** 作就少 所以效率会高
监控和整理空间碎片
文件空间的自动增长提高了自动管理性 但可能导致空间碎片 物理空间与数据的逻辑空间不再连续 定期的监控和空间碎片整理有利于提高I/O性能
使用主数据文件和次要数据文件
每个数据库的一个主数据文件属于主文件组 对于 GB左右规模的数据库 一个数据文件就够了 如果有次要数据文件 主数据文件中有管理次要数据文件的指针
采用多个数据文件时 主数据文件用于存储系统对象和表 次要数据文件用于存储用户数据和索引 在可能的情况下 主数据文件和次要数据文件可以单独存放在不同的磁盘上以分散I/O
如果采用多个数据文件 推荐主数据文件存储系统数据 次要数据文件存放用户数据和索引 这样会有助于提高I/O性能
利用文件组改善性能
在大型数据库系统中 可以考虑建立文件组来管理数据文件 将表和索引通过存放在不同的物理磁盘上进行性能监控比较 最后得出优化的存储方案
重视自动增长和自动收缩可能导致的性能问题
数据库文件的自动增长和自动收缩功能对于小型数据库的管理十分有用 但可能导致大型数据库的性能问题 因为文件的自然增长的同时会导致存储碎片的发生 当文件空间变大时 新分配的空间不一定和原来的空间连续 当文件空间收缩时 释放了部分空间 然而当文件又需要增长存储空间却不能利用原先释放的空间 也会导致碎片的发生
分离系统数据和用户数据
将系统数据库和用户数据库分开存放在不同的物理磁盘上有助于改善I/O性能 有助于数据库备份和恢复
优化索引设计
索引的设计对数据库的性能十分重要 具体不再阐述 可参见本博相关文章
定期更新统计信息
SQLServer默认使用基于代价的优化 所以统计信息的及时更新对于查询优化十分重要
定期的一致性检查
lishixinzhi/Article/program/SQLServer/201311/22434
由二台或更多物理上独立的服务器共同组成的"虚拟"服务器称之为集群服务器 一项称做MicroSoft集群服务(MSCS)的微软服务可对集群服务器进行管理 一个SQL Server集群是由二台或更多运行SQL Server的服务器(节点)组成的虚拟服务器 如果集群中的一个节点发生故障 集群中的另一个节点就承担这个故障节点的责任
认为一个 SQL Server集群能够给集群中的两个节点带来负载平衡 这是一种常见的误解 虽然这似乎很有用 但却是不正确的 这也意味着集束SQL Server不能真正提高性能 集束SQL Server只能提供故障转移功能 故障转移就是当系统中的一台机器发生故障失去其功能时 另一台机器将接手运行它的SQL Server实例 这种功能失效可能是由于硬件故障 服务故障 人工故障或各种其它原因
为何要集束SQL Server环境
在实用性方面 集群SQL Server环境令人满意 在进行故障转移时 将数据库实例由一台服务器转移到另一台服务器的时间非常短暂 一般只需要 至 秒钟 虽然需要重建连接 但对数据库的终端用户而言 故障转移处理通常是透明的 低廉的故障转移成本还可帮助你对集群中的节点进行维护 而不会造成服务器完全无法访问
SQL Server集群类型
一共有两种类型的SQL Server集群 主动/被动集群和主动/主动集群 下面分别对它们进行说明(说明以两个节点的SQL Server集群为基础)
主动/被动集群
在这种类型的集群中 一次只有一个节点控制SQL Server资源 另一个节点一直处于备用模式 等待故障发生 进行故障转移时 备用的节点即取得SQL Server资源的控制权
优点 由于服务器上只有一个实例在运行 所以在进行故障转移时 不需要另外的服务器来接管两个SQL Server实例 性能也不会因此降低
缺点 由于虚拟服务器上只有一个SQL Server实例在运行 另一台服务器总是处理备用模式与空闲状态 这意味着你并没有充分利用你购买的硬件
主动/主动集群
在这种类型的集群中 集群中的每个节点运行一个独立且主动的SQL Server实例 发生节点故障时 另一个节点能够控制发生故障节点的SQL Server实例 然后这个正常的节点将运行两个SQL Server实例 它自己的实例和发生故障的实例
优点 通过这种配置 你能够充分利用你的硬件 在这样的系统中 两个服务器都在运行 而不是只有一台服务器运行 而另一台处于等待故障发生的备用模式 因此你能够充分利用你购买的机器
缺点 如果进行故障转移 一台服务器运行两个SQL Server实例 性能就会受到不利影响 然而 性能降低总比虚拟服务器完全失灵要强得多 这种配置的另一故障在于它要求购买的许可要比主动/被动集群多一些 因为集群在运行两个主动SQL Server实例 这要求你购买两个单独的服务器许可 在某些情况下 这也可能对你形成阻碍
集群考虑
在高实用性方面 集群SQL Server环境有一定的优势 然而 高实用性也确实伴随某种折衷
首先 建立一个集群SQL Server环境非常昂贵 这是因为集群中的节点必须遵照集群节点的兼容性列表 而且 还需要建立一个复杂的网络 机器的配置必须几乎相同 同时需要实现数据库文件磁盘子系统共享 存储区网络(SAN)是建立这种子系统的不错选择 但SAN并非必要 而且十分昂贵 另外 如果你正在运行一个主动/主动集群 你需要为集群中运行SQL Server实例的每台机器的处理器购买一个许可
lishixinzhi/Article/program/SQLServer/201311/22276
SQL Server 1069 错误（由于登录失败而无法启动服务）解决方法
1
我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"本地系统帐户"
或:
2
我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"此帐户"--密码和确认密码中输入你修改后的administrator密码
两者的区别:
选择第一种方式,以后修改了administrator密码,不用再调整(但要求登陆 *** 作系统的是系统管理员)
选择第二种方式,以后修改了administrator密码,还要再重复做上面的 *** 作
以下摘自泡泡网
SQLServer2000发生错误1069（由于登陆失败而无法启动服务）的解决方案
下面我们依次介绍如何来解决这三个最常见的连接错误。
第一个错误“SQL Server 不存在或访问被拒绝“通常是最复杂的，错误发生的原因比较多，需要检查的方面也比较多。一般说来，有以下几种可能性：
1、SQL Server名称或IP地址拼写有误；
2、服务器端网络配置有误；
3、客户端网络配置有误。
要解决这个问题，我们一般要遵循以下的步骤来一步步找出导致错误的原因。
首先，检查网络物理连接：
ping ＜服务器IP地址＞
或者
ping ＜服务器名称＞
如果 ping ＜服务器IP地址＞失败，说明物理连接有问题，这时候要检查硬件设备，如网卡、HUB、路由器等。还有一种可能是由于客户端和服务器之间安装有防火墙软件造成的，比如 ISA Server。防火墙软件可能会屏蔽对 ping、telnet 等的响应，因此在检查连接问题的时候，我们要先把防火墙软件暂时关闭，或者打开所有被封闭的端口。
如果ping ＜服务器IP地址＞ 成功而 ping ＜服务器名称＞失败，则说明名字解析有问题，这时候要检查 DNS 服务是否正常。有时候客户端和服务器不在同一个局域网里面，这时候很可能无法直接使用服务器名称来标识该服务器，这时候我们可以使用HOSTS文件来进行名字解析，具体的方法是：
1、使用记事本打开HOSTS文件（一般情况下位于C:\WINNT\system32\drivers\etc）
2、添加一条IP地址与服务器名称的对应记录，如：
1721681024 myserver
也可以在 SQL Server 的客户端网络实用工具里面进行配置，后面会有详细说明。
其次，使用 telnet 命令检查SQL Server服务器工作状态：
telnet ＜服务器IP地址＞ 1433
如果命令执行成功，可以看到屏幕一闪之后光标在左上角不停闪动，这说明 SQL Server 服务器工作正常，并且正在监听1433端口的 TCP/IP 连接；如果命令返回“无法打开连接“的错误信息，则说明服务器端没有启动 SQL Server 服务，也可能服务器端没启用 TCP/IP 协议，或者服务器端没有在 SQL Server 默认的端口1433上监听。
接着，我们要到服务器上检查服务器端的网络配置，检查是否启用了命名管道，是否启用了 TCP/IP 协议等等。我们可以利用 SQL Server 自带的服务器网络使用工具来进行检查。
点击：程序 -＞ Microsoft SQL Server -＞服务器网络使用工具，打开该工具后看到的画面如下图所示：
从这里我们可以看到服务器启用了哪些协议。一般而言，我们启用命名管道以及 TCP/IP 协议。
点中 TCP/IP 协议，选择“属性“，我们可以来检查 SQK Server 服务默认端口的设置，如下图所示：
一般而言，我们使用 SQL Server 默认的1433端口。如果选中“隐藏服务器“，则意味着客户端无法通过枚举服务器来看到这台服务器，起到了保护的作用，但不影响连接。
检查完了服务器端的网络配置，接下来我们要到客户端检查客户端的网络配置。我们同样可以利用 SQL Server 自带的客户端网络使用工具来进行检查，所不同的是这次是在客户端来运行这个工具。
点击：程序 -＞ Microsoft SQL Server -＞ 客户端网络使用工具，打开该工具后看到的画面如下图所示：
从这里我们可以看到客户端启用了哪些协议。一般而言，我们同样需要启用命名管道以及 TCP/IP 协议。
点击 TCP/IP 协议，选择“属性“，可以检查客户端默认连接端口的设置，如下图所示。
该端口必须与服务器一致。
单击“别名“选项卡，还可以为服务器配置别名。服务器的别名是用来连接的名称，连接参数中的服务器是真正的服务器名称，两者可以相同或不同。如下图中，我们可以使用myserver来代替真正的服务器名称sql2kcn-02，并且使用网络库 Named Pipes。别名的设置与使用HOSTS文件有相似之处。
通过以上几个方面的检查，错误 1 发生的原因基本上可以被排除。下面我们再详细描述如何来解决错误 2。
当用户尝试在查询分析器里面使用sa来连接SQL Server，或者在企业管理器里面使用sa来新建一个SQL Server注册时，经常会遇到如图 2 所示的错误信息。该错误产生的原因是由于SQL Server使用了“仅 Windows“的身份验证方式，因此用户无法使用SQL Server的登录帐户（如 sa ）进行连接。解决方法如下所示：
1、 在服务器端使用企业管理器，并且选择“使用 Windows 身份验证“连接上 SQL Server；
2、 展开“SQL Server组“，鼠标右键点击SQL Server服务器的名称，选择“属性“，再选择“安全性“选项卡；
3、 在“身份验证“下，选择“SQL Server和 Windows “。
4、 重新启动SQL Server服务。
在以上解决方法中，如果在第 1 步中使用“使用 Windows 身份验证“连接 SQL Server 失败，那么我们将遇到一个两难的境地：首先，服务器只允许了 Windows 的身份验证；其次，即在以上解决方法中，如果在第 1 步中使用“使用 Windows 身份验证“连接 SQL Server 失败，那么我们将遇到一个两难的境地：首先，服务器只允许了 Windows 的身份验证；其次，即使使用了 Windows 身份验证仍然无法连接上服务器。这种情形被形象地称之为“自己把自己锁在了门外“，因为无论用何种方式，用户均无法使用进行连接。实际上，我们可以通过修改一个注册表键值来将身份验证方式改为 SQL Server 和 Windows 混合验证，步骤如下所示：
1、点击“开始“-“运行“，输入regedit，回车进入注册表编辑器；
2、依次展开注册表项，浏览到以下注册表键：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer]
3、在屏幕右方找到名称“LoginMode“，双击编辑双字节值；
4、将原值从1改为2，点击“确定“；
5、关闭注册表编辑器；
6、重新启动SQL Server服务。
此时，用户可以成功地使用sa在企业管理器中新建SQL Server注册，但是仍然无法使用Windows身份验证模式来连接SQL Server。这是因为在 SQL Server 中有两个缺省的登录帐户：BUILTIN\Administrators 以及＜机器名＞\Administrator 被删除。要恢复这两个帐户，可以使用以下的方法：
1、打开企业管理器，展开服务器组，然后展开服务器；
2、展开“安全性“，右击“登录“，然后单击“新建登录“；
3、在“名称“框中，输入 BUILTIN\Administrators；
4、在“服务器角色“选项卡中，选择“System Administrators“ ；
5、点击“确定“退出；
6、使用同样方法添加 ＜机器名＞\Administrator 登录。
以下注册表键
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\LoginMode
的值决定了SQL Server将采取何种身份验证模式。该值为1，表示使用Windows 身份验证模式；该值为2，表示使用混合模式（Windows 身份验证和 SQL Server 身份验证）。
看完如何解决前两个错误的方法之后，让我们来看一下如图 3 所示的第三个错误。
如果遇到第三个错误，一般而言表示客户端已经找到了这台服务器，并且可以进行连接，不过是由于连接的时间大于允许的时间而导致出错。这种情况一般会发生在当用户在Internet上运行企业管理器来注册另外一台同样在Internet上的服务器，并且是慢速连接时，有可能会导致以上的超时错误。有些情况下，由于局域网的网络问题，也会导致这样的错误。
要解决这样的错误，可以修改客户端的连接超时设置。默认情况下，通过企业管理器注册另外一台SQL Server的超时设置是 4 秒，而查询分析器是 15 秒（这也是为什么在企业管理器里发生错误的可能性比较大的原因）。具体步骤为：
1、在企业管理器中，选择菜单上的“工具“，再选择“选项“；
2、在d出的“SQL Server企业管理器属性“窗口中，点击“高级“选项卡； 3、在“连接设置“下的“登录超时（秒）“右边的框中输入一个比较大的数字，如 20。
查询分析器中也可以在同样位置进行设置。
在windows控制面版-->管理工具-->服务-->MSSQLSERVER-->属性-->改为你的新的 *** 作系统密码！
或
在windows控制面版-->管理工具-->服务-->MSSQLSERVER-->属性-->改为本地登陆！
以下这些组件：1：SQL ServerSQL Server在 *** 作系统中，以服务的形式实现，具体表现为：MS SQL Server Service，它是数据库管理系统的核心数据库引擎。该服务随系统启动运行；管理着整个SQL Server2000系统拥有的所有问题，是系统中唯一可以直接读取和修改数据的组件。客户对数据库的所有请求，最终会体现成一组Transact-SQL命令。
2：SQL Server Agent 一直以来都不知道Agent用来干什么，今天查看了一些资料，解释如下：SQL Server Agent（SQL服务器代理）在 *** 作系统中以服务的形式运行，体现为：SQL Server Agent Service。SQL Server Agent为SQL Server提供调度服务，能够自动执行数据库管理员预先安排好的作业，监视SQL Server事件并根据事件触发警报或运行实现安排好的程序。
3：MS DTC（分布式事物协调器）MS DTC也是以服务的形式存在和运行，MS DTC是一个事物管理器，它允许客户的应用程序在一个事物中对分布在多个服务器上的数据源进行 *** 作。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）