SYBASE 日志空间满了的几种情况

1、在数据库执行SQL语句时,执行不成功,报错:日志空间已满(***log full**)的错误

解决方法:执行 dump transaction DB_TASK with truncate_only   即可

2、在java项目运行时控制台报错:Space available in the log segment has fallen critically low in database ‘DB_TASK_R11‘.  All future modifications to this database will be aborted until the log is successfully dumped and space becomes available.

这个时候再用1的方法就不可以了,可以用一下方法:

sp_helpdb ‘DB_TASK_R11‘   -----在【device_fragments】字段查到对应日志文件的名称,例如:DEV_TASK_LOG01_R11

sp_helpdevice ‘DEV_TASK_LOG01_R11‘  ------查看原来日志文件存储的物理位置,查看查询结果的【physical_name】字段 结果为:C:\sybase\data\DEV_TASK_LOG01_R11.dat

disk init name = ‘DEV_TASK_LOG02_R11‘,
physname = ‘C:\sybase\data\DEV_TASK_LOG02_R11.dat‘,
size = ‘150M‘, dsync = false
go              --------在同样的物理位置上,参照日志文件1的名字创建日志文件2,大小视数据库的情况而定,一般不要超过DATA的大小

ALTER DATABASE DB_TASK_R11
log ON DEV_TASK_LOG02_R11 = 150
go                      ----------将新建的日志挂到对应数据库上

百度查询的是需要重启数据库才会生效,但是我没有重启数据库,重新运行java的web项目也没有在报这个错误,如果还报错可以重启一下数据库应该就好了。

PS:SELECT COUNT(*) FROM DB_TASK_R11..syslogs      ---这个语句可以查看数据库的日志里面的记录数

时间: 2024-11-05 06:47:34

SYBASE 日志空间满了的几种情况的相关文章

Redo丢失的4种情况及处理方法

Redo丢失的4种情况及处理方法 转载:http://blog.itpub.net/23135684/viewspace-626935/ 一.说明:1.以下所说的当前日志指日志状态为CURRENT,ACTIVE,非当前日志指日志状态为INACTIVE2.不用考虑归档和非归档模式,2种模式下的Redo丢失情况一样. 二.丢失Redo的4种情况:第一种情况:非当前日志,正常关闭.第二种情况:非当前日志,非正常关闭.第三种情况:当前日志,正常关闭.第四种情况:当前日志,非正常关闭. 三.处理方法:第一

MySQL删除数据几种情况以及是否释放磁盘空间【转】

MySQL删除数据几种情况以及是否释放磁盘空间: 1.drop table table_name 立刻释放磁盘空间 ,不管是 Innodb和MyISAM ; 2.truncate table table_name 立刻释放磁盘空间 ,不管是 Innodb和MyISAM .truncate table其实有点类似于drop table 然后creat,只不过这个create table 的过程做了优化,比如表结构文件之前已经有了等等.所以速度上应该是接近drop table的速度; 3.delet

ORACLE模拟临时文件、日志成员、口令文件丢失情况与恢复【weber出品】

一.临时表空间文件.日志文件和口令文件都属于非关键性文件,因为这些文件丢失后并不会影响到整个数据库的完整性. 但是,当这些文件丢失后我们需要快速的找回这些文件.接下来我将模拟临时表空间文件.日志文件和口令文件丢失的情况. 二.如果属于 TEMP 表空间的临时文件丢失或损坏,则 TEMP 表空间将不可用.例如:在执行需要 TEMP 空间进行排序的 SQL 语句过程中,此问题将声明其为错误. 一般会用到临时表空间的场景有: 索引create或rebuild Order by 或 group by D

基于Cordys C3版平台应用系统维护经验一则——Oracle数据库表空间满了

某日中午,有用户陆续反映系统问题,说流程送出异常.待办不消失.待办打不开等等.维护工程师开始分析问题,后台较为清晰的现象是流转日志记录插入数据失败,人工测试表插入成功,其它现象五花八门,没有规律,经过多位维护工程师的努力,终于由Oracle数据库管理工程师在16:01排除故障,系统基本恢复"正常". 故障原因是"应用系统Oracle数据库中Cordys用户所对应的表空间"满了,导致应用无法正常向数据库写入数据,造成业务数据不完整. 第二日,维护人员根据用户反馈,逐个

磁盘空间满了之后MySQL会怎样

大多数用户在对于磁盘进行分区的时候都是习惯性的不给系统盘预留很大空间,其实这并不是一个好习惯.因为系统分区并不像我们想象的那样会仅仅安装一个操作系统,系统分区多数还是会承载操作系统主要应用软件安装任务.那么当磁盘空间爆满后,MySQL会发生什么事呢?又应该怎么应对? 会发生什么事 当磁盘空间写满了之后,MySQL是无法再写入任何数据的,包括对表数据的写入,以及binlog.binlog-index等文件. 当然了,因为InnoDB是可以把脏数据先放在内存里,所以不会立刻表现出来无法写入,除非开启

DB2表空间管理的两种方式

下文将为您介绍DB2(DB2认证 DB2培训 ) 的表空间按管理方式,并附上相关问题的实例,供您参考,如果您对DB2表空间按管理方式感兴趣的话,不妨一看,会对您有所帮助. DB2 的表空间按管理方式分为两种:系统管理空间(System Management Space,SMS)和数据库管理空间(Database Management Space,DMS). 按类型分为:规则表空间.长整数表空间.系统临时表空间.用户临时表空间.其中长整数表空间只能是DMS的. 规则表空间中包含用户数据的表.默认用

DOM中关于脱离文档流的几种情况分析

所谓的文档流,指的是元素排版布局过程中,元素会自动从左往右,从上往下的流式排列.并最终窗体自上而下分成一行行, 并在每行中按从左至右的顺序排放元素.脱离文档流即是元素打乱了这个排列,或是从排版中拿走. 当前所知的脱离文档流的方式有两种:浮动和定位. a.定位属性positon 先看一下定位.看一段对定位各个字段的描述,有助于理解 值 描述 absolute 生成绝对定位的元素,相对于 static 定位以外的第一个父元素进行定位. 元素的位置通过 "left", "top&q

如何截断SQL Server2008+事务日志空间

SQL数据库事务日志记录数据库的任何更改,用户可回滚事务日志来恢复数据,但随着数据库使用时间变长,日志文件也会变得很大. 若要避免数据库的事务日志被填满,例行备份至关重要.做了日志备份后,会释放不活跃的VLF,增加日志的可用空间.但默认情况下备份日志,其日志文件的大小并未变化,如下图 备份前,总大小24.13MB 备份后,总大小仍然为24.13MB,但已用空间占比从93.1%降至11.0% 也就是,已使用日志空间是减小了,但未使用日志空间并未释放.其实,如果磁盘空间足够的话,可以不用收缩空间 那

PgSQL · 追根究底 · WAL日志空间的意外增长

问题出现 我们在线上巡检中发现,一个实例的pg_xlog目录,增长到4G,很是疑惑.刚开始怀疑是日志归档过慢,日志堆积在pg_xlog目录下面,未被清除导致.于是检查归档目录下的文件,内容如下.但发现新近完成写入的日志文件都被归档成功了(即在pg_xlog/archive_status里面,有对应的xxx.done文件). ls -lrt pg_xlog ... -rw------- 1 xxxx xxxx 16777216 Jun 14 18:39 0000000100000035000000