Sybase_926数据库挂起、3414错误解决方法
Sybase_926数据库挂起、3414错误解决方法
Sybase 926数据库挂起、3414错误解决方法(Error: 926 Error: 3414)一、查看错误日志 errorlog 发现了这段记录00:00000:00001:2009/04/28 16:13:36.46 server Error: 926, Severity: 14, State: 100:00000:00001:2009/04/28 16:13:36.46 server Database 'FD_JXC' cannot be opened. An earlier attempt at recovery marked it 'suspect'. Check the SQL Server errorlog for information as to the cause.00:00000:00002:2009/04/28 16:13:36.46 kernel network name200.100.101.100, type ether, port 5000, filter NONE00:00000:00003:2009/04/28 16:13:36.48 kernel network name yzserver, type ether, port 5000, filter NONE00:00000:00001:2009/04/28 16:13:36.48 server Unable to proceed with the recovery of dbid <4> because of previous errors. Continuing with the next database.明显的 926 数据库挂起错误,即先将数据库状态修改为 -32768 然后再修改为0/* 1、将 'allow updates' 从 0 改为 1 允许修改系统表*/sp_configure "allow updates", 1/* 2、将数据库状态修改为 -32768 即 bypass recovery */update sysdatabases set status = -32768 Where name="FD_JXC"这时需要停止Sybase服务并且重新启动Sybase/* 3、将数据库状态修改为正常 status=0 */update sysdatabases set status=0 where name="FD_JXC"sp_configure "allow updates", 0第二次停止Sybase服务并且重新启动Sybase这步完成后一般重新设置数据库选项(例如"select into","trunc log on chkpt"等)exec sp_dboption FD_JXC, 'select into/bulkcopy' ,trueexec sp_dboption FD_JXC, 'trunc. log on chkpt' ,true运行dbcc命令检查数据库的一致性dbcc checkdb(FD_JXC)备份用户数据库dump database FD_JXC to "D:\backup\FD_JXC0428.dump"晕死，眼看胜利在望，服务器蓝屏,无语，破机器，只好非法关机重新启动，启动好后数据库还是无法正常使用，再查看错误日志 errorlog ,我的神啊，竟然变成3414错误了，肯定是刚才蓝屏的时候，数据库在恢复日志被中断了，这样就要重建数据库日志了190197: Master device size: 30 megabytes, or 15360 virtual pages. (A virtual page is 2048 bytes.)00:00000:00001:2009/04/28 16:40:14.75 server Error: 3414, Severity: 21, State: 100:00000:00001:2009/04/28 16:40:14.75 server Database 'FD_JXC' (dbid 4): Recovery failed. Check the SQL Server errorlog for further information as to the cause.Error: 3414, Severity: 21, State: 1 Database 'FD_JXC' (dbid 4): Recovery failed. Check the SQL Server errorlog for further information as to the cause.解决办法: 重建数据库日志,方法如下:/* 1、赋予sa用户sybase_ts_role的角色 (这步最重要，我一开始没搞，费了不少工夫) */sp_role "grant","sybase_ts_role",sa/* 2、将数据库状态修改为 -32768 即 bypass recovery */sp_configure "allow updates",1update master..sysdatabases set status =-32768 Where name="FD_JXC" 这时需要停止Sybase服务并且重新启动Sybase/* 3、rebuild数据库日志 */dbcc rebuild_log(FD_JXC,1,1)第二次停止Sybase服务并且重新启动Sybase/* 4、将数据库状态修改为正常 status=0 */update master..sysdatabases set status=0 Where name="FD_JXC"sp_configure "allow updates", 05、还要第三次停止并重启Sybase服务,如果数据库恢复正常，rebuild log工作将会成功完成，否则要恢复数据库备份，使用dump database或bcp命令。
数据库连接异常的解决过程
数据库连接异常的解决过程嘿，朋友们！咱今儿就来唠唠这数据库连接异常的事儿。
你说这数据库啊，就好比是一个大宝藏，咱得想法子和它顺利搭上关系，才能拿到里面的宝贝呀。
可有时候呢，它就闹起脾气来，连接就异常啦！就好像你要去一个特别重要的地方，结果路给堵住了，你着急不着急？这时候咱就得冷静下来，好好找找解决办法。
咱先看看是不是网络的问题呀。
就跟你走路一样，路不通畅，你咋能到目的地呢？检查检查网络连接，看看是不是有啥地方松了呀，或者是不是被啥东西给干扰啦。
再想想是不是账号密码的事儿。
这就好比是开门的钥匙，你钥匙不对，咋能进得去那扇门呢。
仔细核对核对，可别马虎了。
还有啊，数据库的配置也得瞅瞅。
这就像是给宝藏设置的规则，规则不对，那肯定不行呀。
看看各种参数啥的，是不是都整对了。
要是这些都没问题，那咱就得往深了挖一挖了。
是不是服务器那边出啥状况啦？这服务器就像是宝藏的守护者，它要是不舒服了，那咱也不好办呀。
有时候啊，解决这个问题就跟解谜一样，得一层一层地剥开，才能找到真正的原因。
你说这像不像玩一个特别有挑战性的游戏？咱得有耐心，有细心，才能通关呀。
比如说，我之前就遇到过一次数据库连接异常。
哎呀，那可把我急坏了。
我就按照上面说的这些方法，一个一个地排查呀。
先看网络，没问题；再看账号密码，也对；然后检查配置，嘿，还真发现了个小错误。
我赶紧给它修正了，嘿，你猜怎么着，连接成功啦！当时那心情，就跟找到了宝藏的入口一样兴奋。
所以啊，朋友们，遇到数据库连接异常别慌张，咱一步一步来，肯定能找到解决办法的。
就像那句话说的，办法总比困难多嘛！咱可不能被这点小困难给打倒了，咱得和这数据库好好较较劲，让它乖乖听话，为咱服务！你说是不是这个理儿？反正我是这么觉得的，大家也都好好琢磨琢磨吧！。
Sybase编程中出现的错误及其解决办法-电脑资料
Sybase编程中出现的错误及其解决办法-电脑资料SYBASE 数据库是当今在UNIX环境下最为流行的大型数据库之一，本人在SYBASE下开发和维护软件的过程中，发现了一些SYBASE 的内部规则，在程序设计中极易造成误解，而达不到预期的目的，。
下文将本人所发现的几个问题及其解决办法叙述如下：1、在sybase11.5中，组合两个定长的char(x)="aaa",char (y)="bbb"; char(x)+char(y)!="aaabbb"declare @val_1 char(8)declare @val_2 char(1)select @val_2 = 'x'select @val_1 = "0000"select @var_1= @val_1 + @val_2select @var_1我们期望的结果为0000x，而实际上其结果为0000。
解决方法一：当我们将"select @var_1=@val_1+@val_2"，改为"select @var_1=rtrim(@var_1)+@var_2"时，我们便看到了我们所期望的结果。
为什么呢？在有的SYBASE版本中存储一个char(n)时，在其真实值后补上了相应数量的空格，在本例中，存储在@var_1中的是0000 （在0000后有四个空格）。
你可以加上如下两句来验证：declare @val3 char(10)select @val3 = @val_1 + @val_2select @val3这时你会得到的结果为0000 x （在0000后有四个空格）。
解决方法二：将char 改为 varchar 也可以达到预期的目的，电脑资料《Sybase编程中出现的错误及其解决办法》(https://www.)。
2、用alter table 增加表结构时，虽然用sp_recompile tablename 重编译了所影响的数据库对象，但在运行某些包含"select * from tablename"的存储过程时，存储进程仍不认识用alter table 增加的列。
数据库故障排除方法与常见问题解决
数据库故障排除方法与常见问题解决数据库是现代应用程序的关键组成部分。
它们存储和管理应用程序的数据，确保数据的安全性、可靠性和一致性。
然而，由于各种原因，数据库可能会出现故障，导致应用程序停止工作或数据丢失。
在本文中，我们将探讨一些常见的数据库故障和排除方法。
常见的数据库故障包括数据库服务器崩溃、硬件故障、网络问题和错误的配置。
这些问题可能会导致数据库无法启动、应用程序无法访问数据库或数据库性能下降。
以下是一些排除这些问题的方法：1. 检查日志文件：数据库通常会生成日志文件，记录发生的事件和错误。
检查日志文件可以帮助我们确定故障的原因。
日志文件通常位于数据库服务器的特定目录中，根据数据库管理系统的不同而有所不同。
通过查看日志文件，我们可以找到与故障相关的错误消息，例如数据库连接错误或索引损坏。
2. 检查数据库连接：数据库连接问题是常见的故障原因之一。
确保应用程序正确配置和使用正确的连接字符串。
还可以尝试使用数据库管理工具连接到数据库。
如果连接成功，那么问题可能在应用程序中，否则可能是数据库服务器配置或网络问题。
3. 检查硬件和网络：硬件故障和网络问题可能导致数据库故障。
确保数据库服务器的硬件正常运行，并且没有任何故障指示灯。
检查网络连接是否正常，并且没有丢包或延迟。
在特定的网络故障条件下，可能需要联系网络管理员以解决问题。
4. 检查数据库配置：如果数据库无法启动，可能是由于配置错误。
检查数据库服务器的配置文件，确保数据库的基本设置以及应用程序所需的设置正确配置。
这些设置可能包括存储路径、内存分配和并发连接数。
5. 数据库备份和恢复：数据库备份是应对数据丢失的重要措施。
如果数据库发生故障且无法修复，则可以尝试从最近的备份中恢复数据。
确保定期进行数据库备份，并且备份文件存储在不同的位置以防止数据丢失。
6. 数据库优化：数据库性能下降可能是由于查询慢、索引丢失或数据库结构不良引起的。
通过重新设计查询、重建索引、优化数据库结构等方法，可以提高数据库的性能和响应能力。
Sybase服务故障的分析及解决办法
Sybase服务故障的分析及解决办法一、问题的起因国库业务系统用DELL服务器原为国库核算系统、国库统计系统、国库综合业务报表系统、国债兑付管理系统四套业务系统的工作机，自2003年以来就投入运行，因使用时间较长，期间做过不少次系统配置更改及业务系统升级换代，因此运行速度越来越慢，且常出现些小问题，为此笔者新装了一台HP DX2000计算机作为生产机，而把DELL服务器改作备份机，以便于有充裕的时间对其进行系统的整理维护，提高其整体性能。
前些天，国库业务人员因为业务问题需要使用备份机，发现国库综合业务系统无法正常登录，查询服务功能，发现NTRS服务没有启动，如是采用手工启动的方法，结果出现如下错误提示：“在本地计算机，无法启动Sybse SQLServer_ntrs服务并未返回错误。
这可能是一个Windows内部错误或服务内部。
如果问题持续存在，请与您的系统管理员联系。
”二、处理的过程为解决此故障，笔者反复多次启动服务，乃至重新启动机器，但问题依然如此，联想到新装HP DX2000计算机更改IP地址时也出现过如此问题，而且Sybase Config也经常出现启动错误，需要到Sybase 系统目录中找到对应文件直接执行才能解决问题，因此认为Sybase本身可能存在某些问题，需要手工更改其他配置。
如是笔者打电话咨询总行信息技术支持中心，答复这个问题咨询的电话较多，每周都有好几个，这属于Sybase系统本身的不完善问题，而总行已经解除了与Sybase公司的服务协议，因此没有办法解决，只能删除NTRS服务再重建。
辛辛苦苦建立的NTRS服务，怎忍心一删了事，而且国库统计系统、国库综合业务报表系统、国债兑付管理系统三套系统都使用此服务，到时恢复起来也较费事。
抱定不到黄河心不死，见到棺材也不落泪的心里，笔者广泛查找资料，多方电话咨询Sybase方面的专家，经过连续数天的实践摸索，终于查明是Sybse服务配置的冲突所至，需要通过Sybase Dsedit更改系统配置或手工清理、修改SQL.ini文件。
Sybase 错误代码
错误消息按Sybase 错误代码进行索引Sybase 错误代码是一组错误代码集，用于所有Sybase 产品，包括Adaptive Server Enterprise。
Adaptive Server Anywhere 所返回的每个Sybase 错误代码，都有与之匹配的Adaptive Server Anywhere 错误代码。
在许多情况下，Adaptive Server Anywhere 错误代码比对应的Sybase 错误代码更详细，因此，下表中的某些Sybase 错误代码并不是唯一的。
Sybase 错误代码Adaptive Server AnywhereSQLCODE错误消息0 –631 RAISERROR 被执行：%1102 –171 打开游标时出错102 –199 在游标上的INSERT/_delete 只能修改一个表102 –933 IQ 数据库需要日志102 –275 在运行时服务器中不支持触发器和过程102 –273 在触发器动作中不允许执行COMM IT/ROLLBACK 102 –131 '%1' 附近有语法错误%2102 –687 语法错误，未指定IQ PATH 时不能指定IQ 特定选项102 –875 无法连接到'%1'102 –145 未找到外键名'%1'102 –271 触发器定义与现有触发器冲突102 –272 触发器定义中的REFERENCES 子句无效102 –635 不允许在视图上对列权限GRANT102 –151 子查询只允许一个选择列表项102 –269 不能删除或重命名触发器定义中引用的列103 –250 标识符'%1' 过长104 –854 ORDER BY 子句中对'%1' 的函数或列引用无效108 –152 ORDER BY 说明无效133 –262 未找到标签'%1'134 –261 已有名为'%1' 的变量137 –260 未找到变量'%1'154 –623 过程或触发器中不允许数据定义语句155 –200 无效的选项'%1' —不存在PUBLIC 设置174 –154 函数'%1' 的参数数目错误176 –611 不支持的Transact-SQL 功能176 –148 未知函数'%1'182 –159 无效的列号201 –639 调用过程'%1' 时参数名遗失201 –615 在过程'%2' 中未找到参数'%1'201 –737 签名'%1' 与过程参数不匹配205 –153 UNION、INTERSECT 或EXCEPT 中的_select 列表长度不匹配207 –124 从表'%1' 中删除的列多于定义的列207 –143 未找到列'%1'208 –142 未找到相关名'%1'209 –144 在多个表中找到列'%1' —需要相关名209 –163 派生表'%1' 没有列%2 的名称213 –207 _insert 的值数目错误217 –274 过程或触发器调用嵌套太深220 –158 值%1 超出了目标的范围230 –191 无法修改表'%2' 中的列'%1'230 –190 不能更新表达式233 –195 表'%2' 中的列'%1' 不能为NULL233 –733 已超出所允许的NULL 的列数限制257 –157 无法将%1 转换为%2257 –705 从过程'%1' 返回的void 类型不能在任何表达式中使用262 –121 权限被拒绝：%1264 –637 重复的插入列285 –708 READTEXT 或WRITETEXT 语句无法引用视图301 –147 出现多种将'%1' 连接到'%2' 的方法301 –680 Transact-SQL 外连接的WHERE 子句中的表达式无效301 –146 无法将'%1' 连接到'%2'305 –681 Transact-SQL 外连接中使用的连接类型无效311 –295 无法唯一标识游标中的行314 –122 操作将引起组循环315 –136 表'%1' 在外连接循环中315 –137 表'%1' 需要唯一的相关名401 –134 未实现功能'%1'401 –135 语言扩充401 –156 '%1' 附近的表达式无效401 –994 函数或过程'%1' 的参数过多404 –890 语句大小或复杂程度超过服务器限制409 109 集合函数中的空值已删除409 –90 过程'%2' 的参数'%1' 不能为空504 –265 未找到过程'%1'509 –140 用户ID '%1' 不存在512 –186 子查询不能返回多个行518 103 无效的数据转换532 104 上次读取后行已更新532 106 表'%2' 中列'%1' 的值已更改538 –627 在'%1' 附近的语法中检测到不允许的语言扩充546 –194 表'%2' 中的外键'%1' 没有主键值547 –198 表'%1' 中行的主键被表'%3' 中的外键'%2' 引用547 –677 表'%1' 有带参照动作的外键548 –196 表'%2' 的索引'%1' 将不唯一548 –209 违反了约束'%1'：表'%3' 中列'%2' 的值无效549 –729 无法强制使用指定的外键(%1)550 –632 在基表'%1' 中插入/更新时违反了WITH CHECK OPTION553 –264 FETCH 中的变量数错误554 –208 上次读取后行已更改—操作被取消557 –853 游标未处于有效状态557 –170 尚未声明游标558 –172 游标已打开559 –180 游标未打开560 100 未找到行560 –197 没有当前的游标行573 –738 口令至少必须有%1 个字符590 111 语句无法执行601 –642 无效的SQL 描述符名708 –80 无法启动数据库服务器708 –86 没有足够的内存来启动708 –679 分配给Java 虚拟机用于远程访问的内存不足709 –996 找不到指定的本地连接。
3414解决办法
SQL(MSSQLSERVER)服务启动错误代码3414
由于服务器突然断电重启，会造成Mssql在启动服务的时候出现SQL(MSSQLSERVER)服务启动错误代码3414，这里提供解决方法，这都是我们在运营虚拟主机过程中遇到的并且已经解决的问题，下面交流一下经验：
解决方法：
1、在安装有SQL电脑上并且正常使用，运行-输入services.msc找到SQL Server (MSSQLSERVER)停止服务，找到你的数据库安装路径，比如我的安装的是c盘，找到数据库存放的位置，复制：C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data下复制model.mdf和modellog.ldf；
数据库故障处理总结
数据库故障处理总结在当今数字化的时代，数据库作为企业和组织存储和管理关键信息的核心组件，其稳定运行至关重要。
然而，由于各种原因，数据库故障不可避免。
及时、有效地处理这些故障，对于保障业务的连续性和数据的完整性具有重要意义。
接下来，我将对数据库故障处理的相关内容进行总结。
一、常见的数据库故障类型1、硬件故障硬件故障是数据库故障中较为严重的一种。
例如，服务器的硬盘损坏、内存故障、电源故障等。
这些问题可能导致数据库服务突然中断，数据丢失或损坏。
2、软件故障数据库软件本身可能存在漏洞或错误，如数据库系统的崩溃、补丁安装失败、升级过程中的问题等。
3、网络故障网络连接不稳定、网络延迟过高或网络中断都可能影响数据库的正常访问和数据传输。
4、人为操作失误这是比较常见的故障原因之一。
例如，误删除数据、错误的配置更改、未遵循标准操作流程等。
5、数据损坏数据可能由于病毒攻击、存储介质老化、系统错误等原因而损坏。
二、数据库故障的监测与预警为了能够及时发现数据库故障，我们需要建立有效的监测与预警机制。
1、性能指标监控定期监控数据库的关键性能指标，如 CPU 使用率、内存利用率、磁盘 I/O 速度、连接数等。
当这些指标超过预设的阈值时，及时发出警报。
2、日志分析仔细分析数据库的日志文件，包括错误日志、事务日志等。
通过对日志的分析，可以提前发现潜在的问题。
3、数据备份与恢复验证定期对数据备份进行恢复验证，确保备份数据的可用性和完整性。
4、监控工具的使用利用专业的数据库监控工具，如 Nagios、Zabbix 等，它们可以提供更全面、实时的监控和报警功能。
三、数据库故障处理的流程1、故障报告与确认当发现数据库故障时，相关人员应及时报告。
负责处理故障的人员需要对故障进行确认，明确故障的类型、影响范围和严重程度。
2、紧急处理对于严重影响业务的故障，应采取紧急措施，如暂时切换到备用系统、暂停相关业务操作等，以减少损失。
3、故障分析对故障进行深入分析，查找故障的根本原因。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Sybase 926数据库挂起、3414错误解决方法(Error: 926 Error: 3414)一、查看错误日志 errorlog 发现了这段记录
00:00000:00001:2009/04/28 16:13:36.46 server Error: 926, Severity: 14, State: 1
00:00000:00001:2009/04/28 16:13:36.46 server Database 'FD_JXC' cannot be opened. An earlier attempt at recovery marked it 'suspect'. Check the SQL Server errorlog for information as to the cause.
00:00000:00002:2009/04/28 16:13:36.46 kernel network name
200.100.101.100, type ether, port 5000, filter NONE
00:00000:00003:2009/04/28 16:13:36.48 kernel network name yzserver, type ether, port 5000, filter NONE
00:00000:00001:2009/04/28 16:13:36.48 server Unable to proceed with the recovery of dbid <4> because of previous errors. Continuing with the next database.
明显的 926 数据库挂起错误,即先将数据库状态修改为 -32768 然后再修改为0
/* 1、将 'allow updates' 从 0 改为 1 允许修改系统表*/
sp_configure "allow updates", 1
/* 2、将数据库状态修改为 -32768 即 bypass recovery */
update sysdatabases set status = -32768 Where name="FD_JXC"
这时需要停止Sybase服务并且重新启动Sybase
/* 3、将数据库状态修改为正常 status=0 */
update sysdatabases set status=0 where name="FD_JXC"
sp_configure "allow updates", 0
第二次停止Sybase服务并且重新启动Sybase
这步完成后一般重新设置数据库选项(例如"select into","trunc log on chkpt"等)
exec sp_dboption FD_JXC, 'select into/bulkcopy' ,true
exec sp_dboption FD_JXC, 'trunc. log on chkpt' ,true
运行dbcc命令检查数据库的一致性
dbcc checkdb(FD_JXC)
备份用户数据库
dump database FD_JXC to "D:\backup\FD_JXC0428.dump"
晕死，眼看胜利在望，服务器蓝屏,无语，破机器，只好非法关机重新启动，启动好后数据库还是无法正常使用，再查看错误日志 errorlog ,我的神啊，竟然变成3414错误了，肯定是刚才蓝屏的时候，数据库在恢复日志被中断了，这样就要重建数据库日志了
190197: Master device size: 30 megabytes, or 15360 virtual pages. (A virtual page is 2048 bytes.)
00:00000:00001:2009/04/28 16:40:14.75 server Error: 3414, Severity: 21, State: 1
00:00000:00001:2009/04/28 16:40:14.75 server Database 'FD_JXC' (dbid 4): Recovery failed. Check the SQL Server errorlog for further information as to the cause.
Error: 3414, Severity: 21, State: 1 Database 'FD_JXC' (dbid 4): Recovery failed. Check the SQL Server errorlog for further information as to the cause.
解决办法: 重建数据库日志,方法如下:
/* 1、赋予sa用户sybase_ts_role的角色 (这步最重要，我一开始没搞，费
了不少工夫) */
sp_role "grant","sybase_ts_role",sa
/* 2、将数据库状态修改为 -32768 即 bypass recovery */
sp_configure "allow updates",1
update master..sysdatabases set status =-32768 Where name="FD_JXC" 这时需要停止Sybase服务并且重新启动Sybase
/* 3、rebuild数据库日志 */
dbcc rebuild_log(FD_JXC,1,1)
第二次停止Sybase服务并且重新启动Sybase
/* 4、将数据库状态修改为正常 status=0 */
update master..sysdatabases set status=0 Where name="FD_JXC"
sp_configure "allow updates", 0
5、还要第三次停止并重启Sybase服务,如果数据库恢复正常，rebuild log工作将会成功完成，
否则要恢复数据库备份，使用dump database或bcp命令。
6、重新设置数据库选项(例如"select into","trunc log on chkpt"等)
exec sp_dboption FD_JXC, 'select into/bulkcopy' ,true
exec sp_dboption FD_JXC, 'trunc. log on chkpt' ,true
运行dbcc命令检查数据库的一致性
dbcc checkdb(FD_JXC)
备份用户数据库
dump database FD_JXC to "D:\backup\FD_JXC0428.dump"。