SQL SERVER 数据库状态为“可疑”的解决方法 --MyDB为修复的数据名 USE MASTER GO SP_CONFIGURE RECONFIGURE WITH OVERRIDE GO ALTER DATABASE MyDB SET EMERGENCY GO sp_dboption 'MyDB', 'single user', 'true' GO DBCC CHECKDB('MyDB','REPAIR_ALLOW_DATA_LOSS') GO ALTER DATABASE MyDB SE

前段时间客户数据服务器断电,开机后发现数据库状态标记为可疑,可能是断电引起的数据库日志文件损坏,修复方法如下: 只有mdf文件,重建日志: --注:example为测试用数据库,相应的Example_log.ldf为测试用的日志文件 use master go alter database example set emergency go --置数据库为单用户模式 alter database example set single_user with rollback immediate go

今天打开数据库,发现连接不上,弹出错误提示: 打开SQLServer Configuration Manager,发现SQL Server状态已经停止,双击启动弹出错误提示: 打开SQL Server网络配置--MSSQLSERVER的协议--找到VIA协议,设置位禁用即可: 返回再次启动SQL Server服务: 成功进入数据库:

本文内容是采集的好几位博主的博文进行的一个整合,内容更为精准和详尽,以下是我参照的几篇博文地址: 微软官方文档:https://docs.microsoft.com/zh-cn/sql/linux/sql-server-linux-setup?view=sql-server-ver15 CallousMaster:https://blog.51cto.com/13770206/2429881 (机器空闲内存低于2G时的解决方案) 这就是Me:https://www.cnblogs.com/joh

  首先我们应该知道数据库总是处于一个特定的状态中,下面先来了解一下数据库的常见的三种状态:1,脱机:我们可以在Microsoft SQL Server Management中看到该数据库,但该数据库名称旁边有"脱机"的字样,说明该数据库现在虽然存在于数据库引擎实例中,但是不可以执行任何有效的数据操作,比如新增,修改,删除等,这就是脱机状态. 2,联机:该状态为数据库正常状态,也就是我们常看到的数据库的状态,该状态下的数据库处于可操作状态,可以对数据库进行任何权限内的操作. 3,可疑:

日常对Sql Server 2005关系数据库进行操作时,有时对数据库(如:Sharepoint网站配置数据库名Sharepoint_Config)进行些不正常操作如数据库在读写时而无故停止数据库,从而导致Sql Server 2005数据库不正常中断,当再次打开数据库时会发现某些数据库会被标记为“可疑”(suspect),即在数据库名旁加上了黄色的惊叹号,这时数据库就不能再被打开了,但数据库的结构及数据内容都还是存在的. 解决方法: 当数据库发生这种操作故障时,可以按如下操作步骤可解决此方法,

日常对Sql Server 2005关系数据库进行操作时,有时对数据库(如:Sharepoint网站配置数据库名Sharepoint_Config)进行些不正常操作如数据库在读写时而无故停止数据库,从而导致Sql Server 2005数据库不正常中断,当再次打开数据库时会发现某些数据库会被标记为“可疑”(suspect),即在数据库名旁加上了黄色的惊叹号,这时数据库就不能再被打开了,但数据库的结构及数据内容都还是存在的. 解决方法: 当数据库发生这种操作故障时,按如下操作步骤可解决此问题,打开

问题背景: 日常对Sql Server 2005关系数据库进行操作时,有时对数据库(如:Sharepoint网站配置数据库名Sharepoint_Config)进行些不正常操作如数据库在读写时而无故停止数据库,从而导致Sql Server 2005数据库不正常中断,当再次打开数据库时会发现某些数据库会被标记为"可疑"(suspect),即在数据库名旁加上了黄色的惊叹号,这时数据库就不能再被打开了,但数据库的结构及数据内容都还是存在的. 解决方法: 当数据库发生这种操作故障时,可以按如下

数据库状态 (database states) 查询数据库的当前状态 : 1.查询所有数据库的状态 ,通过sys.databases目录视图的state_desc列 user master go select state_desc ,[name] from sys.databases go 2.查询指定数据库的状态,通过DATABASEPROPERTYEX函数的Status属性 select DATABASEPROPERTYEX('demoData','status')go  状态: ONLIN

一.出错情况 有些时候当你重启了数据库服务,会发现有些数据库变成了正在恢复.置疑.可疑等情况,这个时候DBA就会很紧张了,下面是一些在实践中得到证明的方法. 在一次重启数据库服务后,数据库显示正在恢复,过了很久还是这个状态,离线时间不能太长,所以就想起了一个方法,就是把数据库服务停止了,把数据文件mdf和ldf拷贝出来,删除了ldf文件,按照之前的经验,好像是在没有ldf的情况下可以使用mdf来恢复数据库.创建了一个同名的数据库,停止数据库服务,覆盖mdf文件,再启动数据库服务,这个时候还是处于

今天遇到一个很奇怪的情况,发现一个会话异常,这个会话只是在执行一个简单的存储过程,里面使用了链接服务器(Linked Server)查询另外一台服务器数据(存储过程里面没有任何显性事务.UPDATE.DELETE操作,只有几个简单的SELECT查询,其中有两个查询使用了链接服务器Linked Server,由于生产环境,不好贴出SQL语句),在DPA监控工具里面,发现该会话引起了非常长的OLEDB等待时间,手工执行测试,发现并不耗费很长时间,KILL该会话后, 回滚状态已完成一直是0%, 估计剩

一.本文所涉及的内容(Contents) 本文所涉及的内容(Contents) 背景(Contexts) 实现代码(SQL Codes) 注意事项(Attention) 疑问(Questions) 参考文献(References) 二.背景(Contexts) DML触发器一般会运用在业务系统的逻辑处理上,在你对数据库用户权限控制不当的时候,这些DML触发器很可能莫名的被禁用或者删除了,你作为数据库管理员你想做冤大头嘛?背黑锅嘛?如果不想,下面给出4种解决方案: 1. 使用DDL触发器对服务级别

问题是这样的,最近因义务需要,公司更换了数据库服务器.数据库随之切换到新的服务器上. 服务器是 Windows Server 2012系统,数据库是SQL Server 2012 .上面有 多个数据库(dba,dbb,dbc,dbd,dbf). 我早上的时候跟踪某部分义务数据,执行SQL语句的时候发现有问题,错误信息提示如下 -> ↓ 我在dba(也就是我的会话是在dba库),执行了 这样一条查询SQL语句. SELECT TOP 10 * FROM dbb.dbo.user_info ORDE

选项 1. single_user(单用户),multi_user(多用户),restricted_user(受限用户); 描述数据库的用户访问属性,它们互斥,设置其中任何一个选项就会取消对其它选项的设置 single_user模式的数据库每次只能有一个连接. restricted_user模式可以有多个连接,前提是这些用户要是被认为是‘合格’的如 sysadmin,dbcreator,dbowner. multi_user任何有效的用户都可以连接. 例子: alter database stu

原文:4. SQL Server数据库状态监控 - 作业状态 有很多地方可以设置定时任务,比如:Windows的计划任务,Linux下的crontab,各种开发工具里的timer组件.SQL Server也有它的定时任务组件 SQL Server Agent,基于它可以方便的部署各种数据库相关的作业(job). 一. 作业历史纪录 作业的历史纪录按时间采用FIFO原则,当累积的作业历史纪录达到上限时,就会删除最老的纪录. 1. 作业历史纪录数配置 所有作业总计纪录条数默认为1000,最多为999

原文:2. SQL Server数据库状态监控 - 错误日志 无论是操作系统 (Unix 或者Windows),还是应用程序 (Web 服务,数据库系统等等) ,通常都有自身的日志机制,以便故障时追溯现场及原因.Windows Event Log和 SQL Server Error Log就是这样的日志, PS: SQL Server 中的错误日志 (Error Log) 类似于 Oracle中的alert 文件. 一. 错误日志简介 1. Windows事件日志与SQL Server 错误日志

原文:3. SQL Server数据库状态监控 - 可用空间 数据库用来存放数据,那么肯定需要存储空间,所以对磁盘空间的监视自然就很有必要了. 一. 磁盘可用空间 1. 操作系统命令或脚本.接口或工具 (1) DOS命令: fsutil volume diskfree C:\windows\system32>fsutil volume diskfree C: Total # of free bytes        : 9789493248 Total # of bytes           

最近发现在SQL Server数据库(目前测试过SQL Server 2008, 2012,2014,2016各个版本)中,即使数据库处于脱机(OFFLINE)状态,但是sys.master_files中依然显示是联机状态.本文测试环境为Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64) .具体测试过程如下所示:   USE master; GO ALTER DATABASE TEST SET OFFLINE WITH 

选项 1. single_user(单用户),multi_user(多用户),restricted_user(受限用户); 描述数据库的用户访问属性,它们互斥,设置其中任何一个选项就会取消对其它选项的设置 single_user模式的数据库每次只能有一个连接. restricted_user模式可以有多个连接,前提是这些用户要是被认为是'合格'的如 sysadmin,dbcreator,dbowner. multi_user任何有效的用户都可以连接. 例子: alter database stu

原文出处:http://www.cnblogs.com/kerrycode/archive/2013/06/10/3131360.html 当SQL SERVER数据库状态为质疑(SUSPECT)状态时,我们可以用以下方法来处理: 1. 修改数据库为紧急模式:ALTER DATABASE DBName SET EMERGENCY . 2. 检查数据库的完整性:DBCC  CHECKDB(‘DBName’) 3. 检查没有错误则恢复数据库为正常模式:ALTER DATABASE  DBName S