SQL Server错误收集#7

错误#1 09:31 2015/1/26上班查看ERRORLOG发现下面错误信息
字面上理解是有内存压力,中午的时候ERRORLOG频繁报下面错误
问题核实,一台服务器上安装两个实例,其中一台设置了最大服务器内存,而另一台没有设置。重新分配最大内存,错误日志不再收到类似信息。
错误#2 09:31 2015/1/27上班查看ERRORLOG发现下面错误信息

2015-01-27 07:10:19.790    spid9s    Recovery is complete. This is an informational message only. No user action is required.
2015-01-27 07:10:19.420    spid9s    Recovery is writing a checkpoint in database ‘DBV2‘ (6). This is an informational message only. No user action is required.
2015-01-27 07:10:19.420    spid9s    0 transactions rolled back in database ‘DBV2‘ (6). This is an informational message only. No user action is required.
2015-01-27 07:10:19.310    spid29s    444 transactions rolled forward in database ‘DBV2‘ (6). This is an informational message only. No user action is required.
2015-01-27 07:10:18.890    spid9s    Recovery completed for database DBV1(database ID 5) in 3 second(s) (analysis 452 ms, redo 2685 ms, undo 134 ms.) This is an informational message only. No user action is required.
2015-01-27 07:10:18.890    spid9s    Recovery is writing a checkpoint in database ‘DBV1‘ (5). This is an informational message only. No user action is required.
2015-01-27 07:10:18.890    spid9s    0 transactions rolled back in database ‘DBV1‘ (5). This is an informational message only. No user action is required.
2015-01-27 07:10:18.410    spid28s    4255 transactions rolled forward in database ‘DBV1‘ (5). This is an informational message only. No user action is required.
2015-01-27 07:10:18.170    登录    Login failed for user ‘Login1‘. 原因: 无法打开明确指定的数据库。 [客户端: xxx.xxx.xxx.xxx]
2015-01-27 07:10:18.170    登录    错误: 18456,严重性: 14,状态: 38。
2015-01-27 07:10:15.260    spid9s    Recovery is writing a checkpoint in database ‘msdb‘ (4). This is an informational message only. No user action is required.
2015-01-27 07:10:15.260    spid9s    0 transactions rolled back in database ‘msdb‘ (4). This is an informational message only. No user action is required.
2015-01-27 07:10:15.170    spid12s    114 transactions rolled forward in database ‘msdb‘ (4). This is an informational message only. No user action is required.
2015-01-27 07:10:14.560    spid29s    Starting up database ‘DBV2‘.
2015-01-27 07:10:14.560    spid28s    Starting up database ‘DBV1‘.
2015-01-27 07:10:14.560    spid12s    Starting up database ‘msdb‘.
2015-01-27 07:10:14.460    spid12s    A new instance of the full-text filter daemon host process has been successfully started.
2015-01-27 07:10:13.520    登录    Login failed for user ‘Login2‘. 原因: 无法打开明确指定的数据库。 [客户端: xxx.xxx.xxx.xxx]
2015-01-27 07:10:13.520    登录    错误: 18456,严重性: 14,状态: 38。
2015-01-27 07:10:13.110    登录    Login failed for user ‘Login1‘. 原因: 无法打开明确指定的数据库。 [客户端: xxx.xxx.xxx.xxx]
2015-01-27 07:10:13.110    登录    错误: 18456,严重性: 14,状态: 38。
2015-01-27 07:10:13.010    登录    SQL Server is not ready to accept new client connections. Wait a few minutes before trying again. If you have access to the error log, look for the informational message that indicates that SQL Server is ready before trying to connect again.  [客户端: xxx.xxx.xxx.xxx]
2015-01-27 07:10:13.010    登录    错误: 17187,严重性: 16,状态: 1。
2015-01-27 07:10:12.910    服务器    SQL Server is now ready for client connections. This is an informational message; no user action is required.
2015-01-27 07:10:12.910    服务器    The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x54b, state: 3. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.
2015-01-27 07:10:12.900    服务器    Dedicated admin connection support was established for listening locally on port 12345.
2015-01-27 07:10:12.900    服务器    Server is listening on [ 127.0.0.1 <ipv4> 12345].
2015-01-27 07:10:12.900    服务器    Server is listening on [ ::1 <ipv6> 12345].
2015-01-27 07:10:12.900    服务器    Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$INSTANCE\sql\query ].
2015-01-27 07:10:12.900    服务器    Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\INSTANCE ].
2015-01-27 07:10:12.900    服务器    Server is listening on [ ‘any‘ <ipv4> 1234].
2015-01-27 07:10:12.900    服务器    Server is listening on [ ‘any‘ <ipv6> 1234].

服务器是27号早上重启的,刚好是重启后,数据库还没完全恢复时新的连接进来。正常重启一般按照,先禁用数据库端口->备份还原验证->停数据库服务->重启开端口。从信息看来,应该是没有禁用数据库端口,直接重启服务器了。

时间: 2024-10-20 23:59:12

SQL Server错误收集#7的相关文章

SQL Server错误收集#6

错误#1 22:26 2014-7-30 重置连接数对实例->属性->连接->最大并发连接数不是特别理解,昨天下午心血来潮,把连接数改成1,不断开启新的查询窗口,并没有按预想的出错(当时没有重启数据库服务).今天早上打开电脑,打开对象资源管理器,连接到服务器时报错. 查看ERRORLOG,错误信息很明显,超过最大并发连接数. 2014-07-30 09:35:37.12 登录 错误: 17809,严重性: 20,状态: 3. 2014-07-30 09:35:37.12 登录 Could

SQL Server错误收集#3

错误#1 16:50 2014-5-20安装好数据库(08R2),启动数据库代理服务失败,当时也没在意.后来装上SQL12,再次启动数据库代理依旧失败.不能再得过且过,该找找具体原因了.查看SQLAGENT代理日志: 2014-05-20 16:51:33 - ? [100] Microsoft SQLServerAgent 版本 11.0.2100.60 (内部版本号 x86 unicode 零售): 进程 ID 3076 2014-05-20 16:51:33 - ? [495] SQL S

SQL SERVER错误:已超过了锁请求超时时段。 (Microsoft SQL Server,错误: 1222)

在SSMS(Microsoft SQL Server Management Studio)里面,查看数据库对应的表的时候,会遇到"Lock Request time out period exceeded.(Microsoft SQL Server, 错误1222)",对应的中文错误提示为"已超过了锁请求超时时段. (Microsoft SQL Server,错误: 1222)",如下截图所示,不管是用一般权限的账号还是具有sysadmin角色的登录名都是如此. 这

sql连接错误(Microsoft SQL Server,错误:2)

昨天用SQL语句建表的时候写了一段代码,对于代码的逻辑和内容我不太肯定对不对,反正是毫不犹豫的让它执行了,过程中出现好几个错误,当时没有太在意,想着大不了出错了再重写一个,结果--玩坏了,从昨天到现在十几个小时,SQL Server毫无商量的给我罢工了!于是乎,漫长的"寻错"之路开始了. 先看下出错信息: 1.通过以往经验我先打开了SQL Server配置工具-->配置管理器,检查里边的协议是否开启,就在这时我又犯了一个错误.因为不知道那些协议到底是什么意思,索性干脆都启用了,结

[AlwaysOn Availability Groups]SQL Server错误日志(AG)

SQL Server错误日志(AG) SQL Server错误日志会记录影响AG的时间,比如: 1.和Windows故障转移集群交互 2.可用副本的状态 3.可用数据的状态 4.AG endpoint的状态 5.AG Listener的状态 6.SQL Server resource DLL和SQL Server实例的租用状态 7.AG的错误事件 出现以下状态就需要检查错误日志: 1.无法连接到可用性数据库 2.非预料的AG故障转移 3.AG的Resolving状态不可预期 4.AG在不其确定的

已超过了锁请求超时时段。 (Microsoft SQL Server,错误: 1222)

操作SQLServer数据库时,遇到这样的问题:已超过了锁请求超时时段. (Microsoft SQL Server,错误: 1222) 经过查找材料了解为资源抢占,照成死锁,杀死进程就OK了,具体操作如下: select spId from master..SysProcesses where db_Name(dbID) = '数据库名称' and spId <> @@SpId and dbID <> 0 上面语句是获取进程ID,下面就是根据ID杀死相应进程 exec ('Kil

SQL Server:错误处理及事务控制

目录: 解读错误信息 RAISERROR THROW 实例 使用 @@ERROR 使用 XACT_ABORT 使用TRY/CATCH 现实中的事务语句 删除 更新 银行取钱 解读错误信息 Msg 547, Level 16, State 0, Line 11 The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Products_Categories". The conflict occurred in

SQL Server自动化运维系列——监控磁盘剩余空间及SQL Server错误日志(Power Shell)

原文:SQL Server自动化运维系列--监控磁盘剩余空间及SQL Server错误日志(Power Shell) 需求描述 在我们的生产环境中,大部分情况下需要有自己的运维体制,包括自己健康状态的检测等.如果发生异常,需要提前预警的,通知形式一般为发邮件告知. 在所有的自检流程中最基础的一个就是磁盘剩余空间检测.作为一个高效的DBA不可能每天都要上生产机上查看磁盘剩余或者直到磁盘无剩余空间报错后才采取扩容措施. 当然,作为微软的服务器有着自己的监控软件:SCCM(System Center

sql server 错误日志errorlog

一 .概述 SQL Server 将某些系统事件和用户定义事件记录到 SQL Server 错误日志和 Microsoft Windows 应用程序日志中. 这两种日志都会自动给所有记录事件加上时间戳. 使用 SQL Server 错误日志中的信息可以解决SQL Server的相关问题. 查看 SQL Server 错误日志可以确保进程(例如,备份和还原操作.批处理命令或其他脚本和进程)成功完成. 此功能可用于帮助检测任何当前或潜在的问题领域,包括自动恢复消息(尤其是在 SQL Server 实