SQL Server - 故障排除
文章平均质量分 68
吉普赛的歌
这个作者很懒,什么都没留下…
展开
-
解决分区表归档(switch)失败
错误信息:'ALTER TABLE SWITCH' 语句失败。表'dbName.dbo.tableName' 已分区,但 索引'IX_indexName' 未分区。网上找了很多都解决不了,摸索一番总算搞定了。解决方法:先删除这个表上除主键之外的所有索引, 然后添加索引(基于分区方案上的分区列)脚本:IF EXISTS(SE原创 2016-11-07 15:20:35 · 1241 阅读 · 1 评论 -
SQL Server处理损坏的表
症状:无法备份。在 drop table 时报错:Location: AllocPageRef.cpp:62Expression: aid == idSPID: 71Process ID: 4388 (这个是sqlserver 的进程) 消息 3624,级别 20,状态 1,第 1 行系统断定检查已失败。有关详细信息,请查看 SQL Server 错误日志消息 0,级别 20,状态...原创 2018-05-22 17:46:40 · 1987 阅读 · 2 评论 -
“正在恢复” 的数据库如何处理?
一般来说, 这是因为一个大事务, 让数据库卡着了, 如果数据库重要, 只能让它慢慢还原, 还原的进度可以用xp_readerrorlog 存储过程来看。 但是, 如果日志太大, 你又等不了, 那只能删除日志, 让数据库先跑起来了。下面模拟了这个场景,并作了修复:本人的另一篇相关文章:点击打开链接--注意:按序号分开执行--1. 创建测试库USE [master]GOIF EXISTS(SE...原创 2018-05-14 13:49:53 · 9452 阅读 · 0 评论 -
一次 Alwayson 故障处理
发现故障:主副本数据库显示 “未同步”, 主副本服务器上的集群服务无法启动。数据库已不可使用。在 SSMS 界面, 直接删除可用性组不可行, 改为在 Windows群集中删除应用程序后可以删除可用性组了:再执行RESTORE DATABASE dbName WITH RECOVERY;使数据库可正常使用, 应急。后来认为是 dns 解析不正常, 处理原创 2018-04-12 15:53:32 · 2380 阅读 · 5 评论 -
The transaction log for database 'dbname' is full due to 'LOG_BACKUP'.
The transaction log for database 'dbname' is full due to 'LOG_BACKUP'.xx库的事务日志已满,需要进行日志备份。看了一下, 是一个不太重要的库, 设置为了完整模式, 日志没有日常的备份计划, 但又限制了大小。处理方式:1. 先改恢复模式为简单;2. 收缩日志文件。为了便于操作, 将实例上所有的DB全原创 2018-03-27 09:22:54 · 11735 阅读 · 0 评论 -
windows故障转移集群 “群集事件” 经常出现 1135 错误的解决
以前一直以为是没有双网卡导致的,后来有个集群全是双网卡, 也有这个问题,所以排除了不是双网卡的原因。后来发现跟虚拟底层系统(ESXi)有关,底层系统连不上硬盘了,虚拟机自然也会有问题了,两者出问题的时间能对上(如下图)。将虚拟机迁移之后,问题解决。原创 2018-04-08 11:20:40 · 3122 阅读 · 1 评论 -
在 SA 和 Windows 等账户都被禁用的情况下如何登录?
所有 sysadmin 账户都不可用,或者忘记了或者被禁用的导致无法登录,这个偶尔还是能见到的。这个确实让人着急, 为了这么点事重装SQL Server 还是不值。那如何处理呢?下面以 Win10+SQL Server2017 为例来示范操作。------------------------------------------------ 分割线 -------------------------...原创 2018-03-21 13:08:54 · 4234 阅读 · 0 评论 -
一台执行缓慢CPU偏高的DB服务器的处理
一台生产环境的 Windows Server2008 的DB服务器, 数据库为 SQL Server2014 (无补丁), 经常发生 CPU 偏高(经常跳到80%,90%, 平均也有 45%左右 )。配置(虚拟机):但奇怪的是这台机基本上没有用户访问, 一天都不到一次, 主要是监控的SQL和同步的SQL, 一般来说这点SQL不足以将资源占尽。剩余内存大约只有 100MB原创 2018-03-09 15:38:13 · 471 阅读 · 2 评论 -
option 子句的威力
接报障, 短信页面分页超时(.net 中默认最长超时时间为 30秒 ), 语句如下:set statistics io onset statistics time onDECLARE @firstareaid BIGINT = 635098215722270914, @sendTime_Start DATETIME = '2017/10/20 0原创 2017-10-29 20:39:40 · 456 阅读 · 0 评论 -
Alwayson 同步模式的坑
一个生产库, 使用量不算特别大, 内存 64GB, 数据库 60 GB左右。IO 也非常不错,虽然是虚拟机,但性能很好。版本: SQL Server2014 企业版。 搭建了 Alwayson , 同步模式、自动故障转移。奇怪的是, 用扩展事件捕获到的慢SQL特别多(但占用CPU很低), 用户实际使用也比较慢, 连纯插入语句都很慢, 一天产生几万数据量的表插入居然要几秒(无更新和删除,原创 2017-10-26 15:39:20 · 4465 阅读 · 0 评论 -
用活动和监视器来优化数据库
活动和监视器是在 SQL Server 2008 及以上才有的功能。用这个可以快速找出数据库中消耗较大的SQL并优化, 可谓DBA之利器。1. 在连接上右键, 找到“活动和监视器”即可打开:2. 打开后点击 CPU 时间 列头,使之降序排列。 3. 找到消耗比较大的(前几行)SQL, 右键“显示执行计划”4. 在查看执行计划时, 如果有缺失索引会以绿色文原创 2017-10-09 20:42:47 · 1943 阅读 · 0 评论 -
模糊查询的参数嗅探
表 t , 有复合索引 ix_t_p1_p2,p1 的筛选性不是很高。无论加不加 option(recompile) , 执行计划走的都是索引查找,但不加时, 因为无法准确识别参数中的%, 导致执行计划错误。这个不用 option(recompile) 就无解了。因为毕竟是传入值,不能直接拼SQL(担心有注入风险)。试过末尾添加:OPTION (OPTIMIZE F原创 2017-09-20 17:09:18 · 511 阅读 · 0 评论 -
参数嗅探导致缓慢案例
日期: 2017-02-22症状:反馈网站登录超时缓慢;用活动监视器和 Proc_DBA_GetSlowSQL_ByCPU 都可以看到这条SQL占用了比较多的CPU时间;每隔一段时间(时间不定,一个月或几个月)可能就出现一次,重启SQL Server会恢复正常(如是存储过程加个空格修改一下也能恢复正常);实际在 SSMS 上执行很快。 专业上的说法叫:参数嗅探这种其实出原创 2017-02-22 17:48:43 · 1050 阅读 · 1 评论 -
一次归档引起的磁盘爆满
归档数据, 简单点来说就是将不需要的数据从源库转移到归档库(表)。一般来说, 最好是用分区表做归档, 因为分区表有 alter table xx switch 这个功能, 可以一次性将不需要的分区切到一个新表, 这个在速度上就是秒杀, 最方便不过了。不过, 临时需要归档数据, 就只能复制数据, 再删除不需要的数据了。我的步骤:一、将源库中的3个源表(两个3千万左右,一个1亿多)用导...原创 2018-07-19 22:16:05 · 331 阅读 · 0 评论