oracle所在磁盘空间不足导致了数据库异常.需要减小数据文件的大小来解决. 1.检查数据文件的名称和编号 select file#,name from v$datafile; 2.看哪个数据文件所占的空间最大,根据该数据文件的编号查看该数据文件的最大数据块数 select max(block_id) from dba_extents where file_id=8; 查询结果 3.计算该表空间的实际占用空间.(不是物理文件的大小) 查看每个数据块的大小 show parameter db_bl

回滚环境: 1.源库版本: Grid Infrastructure:11.2.0.3.15 Database:11.2.0.3.15 2.目标库版本: Grid Infrastructure:11.2.0.3.13 Database:11.2.0.3.13   执行步骤: 1.备份源库(root & grid & oracle) 在待回滚的节点执行备份,以防止回滚失败后导致软件故障. a.备份 ASM 实例参数文件(grid) 以 / as sysasm 身份进入 sqlplus 环境,执

升级环境: 1.源库版本: Grid Infrastructure:11.2.0.3.13 Database:11.2.0.3.13 2.目标库版本: Grid Infrastructure:11.2.0.3.15 Database:11.2.0.3.15   执行步骤: 1.备份源库(root & grid & oracle,每个节点) 在待升级的节点执行备份,以防止升级失败后导致软件故障. a.备份 ASM 实例参数文件(grid) 以 / as sysasm 身份进入 sqlplus

持续原创输出,点击上方蓝字关注我 目录 前言 什么是AOF? 三种写回策略 日志文件太大怎么办? AOF重写会阻塞主线程吗? AOF的缺点 总结 什么是RDB? 给哪些数据做快照? 快照时能够修改数据吗? 多久做一次快照? 增量快照 AOF和RDB混合使用 总结 总结 前言 Redis作为内存型的数据库,虽然很快,依然有着很大的隐患,一旦「服务器宕机」重启,内存中数据还会存在吗? 很容易想到的一个方案是从后台数据恢复这些数据,如果数据量很小,这倒是一个可行的方案.但是如果数据量过大,频繁的从后台

问题描述:oracle服务器硬盘磁盘空间满了,没有空间写入数据: 解决思路: a.服务器是虚拟机还是实体机? 虚拟机,->物理机上有空间直接给它扩容,再给数据库的相关表空间添加文件就可: 实体机,->确定是否还有oracle收缩磁盘硬盘插槽,能新增物理硬盘,买+接入: b.删数据以及降低高水位: 通常思路是:找占用磁盘最大的表空间TS_1,找该表空间下巨大的表tableA,删除历史数据,降低高水位(table move),缩小表空间文件,腾出空间: 1.查询 表空间各文件 --找出占用磁盘最大

首先按照网友说的shutdown immediately,结果hang了半个小时也么反应. 然后检查日志,全盘搜索.trc,发现 (D:\app\oracle\diag\rdbms\cms1u\cms1u\trace) 进过分析,怀疑是由于归档已满导致数据库宕机,从而shutdown 无法生效. 再次google,手动删除了 归档文件 ,保留了最后一天的目录,文件位置: D:\app\oracle\flash_recovery_area\cms1u\ARCHIVELOG 再次百度 需要RMAN

在一次测试中,由于导入的数据量过大导致事务一直提交失败因为磁盘空间不够用了,一检查发现是undo表空间不够用,于是重新创建了一个表空间,准备把之前的undo表空间删除,删除时却发现一直删不掉,因为它一直在使用,于是关闭数据库,手动的删掉.然后重启数据库,于是乎各种问题来了 1 使用SYS 账号登录时报错:ORA-09817: Write to audit file failed 然后在使用df -h命令系统检查一下,发现Oracle安装目录所对应的磁盘空间已满,于是删除3天以前的trace文件,

一.现象 数据库突然断掉,无法响应,. 二.分析 查看日志发现错误如下(日志路径:D:\app\Administrator\diag\rdbms\orcl\orcl\trace\alert_hrpdev.log): Mon Jan 15 13:16:00 2018 Thread 1 cannot allocate new log, sequence 8 Checkpoint not complete Current log# 1 seq# 7 mem# 0: D:\APP\ADMINISTRAT

简介 ORA-10458: standby database requires recovery ORA-01196: 文件 1 由于介质恢复会话失败而不一致 ORA-01110: 数据文件 1: 'XXXXXXXXXXXXXXXXXX\XXXXX1.DBF' 一个项目做了Oracle主从数据库同步,通过Dataguard实现,从库服务器宕机,再开机的时候,从库无法启动,报"ORA-01196: 文件 1 由于介质恢复会话失败而不一致"这个错误,具体日志信息如下: ORA-10458:

系统:redhat 6.6 oracle版本: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production 问题描述:宕机后,使用 sqlplus   登陆发现: Oracle ORA-01033: ORACLE initialization or shutdown in progress 即,数据库未正常打开. 问题排查: 由于非正常关机,数据库需要恢复.遂Bd一下: https://www.cnblogs.co

产生问题的原因主要以下两点:1. 有较大的事务量让Oracle Undo自动扩展,产生过度占用磁盘空间的情况:2. 有较大事务没有收缩或者没有提交所导制:说明:本问题在ORACLE系统管理中属于比较正常的一现象,日常维护多注意对磁盘空间的监控. UNDO表空间介绍UNDO表空间用于存放UNDO数据,当执行DML操作(INSERT,UPDATE和DELETE)时,oracle会将这些操作的旧数据写入到UNDO段,在oracle9i之前,管理UNDO数据时使用(Rollback Segment)完成

随着互联网的快速发展,各行各业的数据量也是与日俱增,而数据库的数据量也是直线增长,但是,如果表DML太多,则可能会在高水位线以下出现太多空白. 因此,只能将数据文件缩小到高水位线,因为高水位线以下有一些空白.因此,在这种情况下(删除太多),要在数据文件上占用更多空间,首先,重组表,重置高水位线,然后再次缩小数据文件.这样我们可以在磁盘级别上释放更多的空间. 文档资料和脚本来自support文献编号: 2348230.1,1019709.6,1020182.6,186826.1等. 一.遇到的案例

https://blog.csdn.net/hiyachen/article/details/102131823 背景 在virtualbox中装好Linux以及Application之后,发现硬盘空间太小,怎样才能增加硬盘容量. 这里给出两个办法,其实是大同小易. 办法1 增加一个新的硬盘 办法2 扩大原来硬盘,然后在扩出来的空间创建新的分区 方法1:增加新的硬盘 关闭虚拟机 添加新硬盘 虚拟机 => 设置 => 存储 => SATA控制器 => 选择"添加虚拟硬盘&q

测试的时候向数据库中插入了大量的数据,测试完成后删除了测试用户以及其全部数据,但是数据文件却没有缩小.经查阅资料之后发现这是 Oracle “高水位”所致,那么怎么把这些数据文件的大小降下来呢?解决办法如下: 概念: 表空间的相关知识请见这里,详细的介绍了 Oracle 数据库的存储结构. 高水位:High Water Mark (HWM),是段(Segment)的一个指标,界定了段(Segment)曾经配置过的 block 水位. 据说,随着数据的 insert,所使用段(Segment)的数

--2013-09-16截取的数据-- 使用df-h命令查看系统磁盘空间 [root@erpdbs PROD]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda5 4.9G 241M 4.4G 6% / /dev/sda10 716G 432G 248G 64% /back /dev/sda1 4.9G 50M 4.6G 2% /boot /dev/sda9 481G 415G 42G 91% /data none 7.9G 0

oracle表空间相关常用命令小结: 1.ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;              //修改表空间数据文件类型 2.ALTER TABLESPACE 旧表空间名称 TO 新表空间名称;                      //修改表空间名称 3.select * from v$database;   show parameter db                                        

由于之前ESB是供应商部署的,且部署在C盘(C盘空间很小,还添加了很多ESB的windows服务日志在C盘,很容易把C盘空间占满,导致ESB服务运行宕机,几乎每隔几周发生一次事故,需要人工干预处理,不甚其烦), 因此前段时间对于基于RabbitMQ构建的ESB进行了综合优化,以确保ESB服务的稳定可靠,同时初步建立了自动化的ESB监控和运维体系,本文介绍一种其中用到技术之一,通过SSIS监控远程服务器磁盘空间并发送邮件报警,目的是当自动化ESB运维失效的时候,可以进行人工干预处理. 通过WMI可

我们之前了解了复制.扩展性,接下来就让我们来了解可用性.归根到底,高可用性就意味着 "更少的宕机时间". 老规矩,讨论一个名词,首先要给它下个定义,那么什么是可用性? 1 什么是可用性 我们常见的可用性通常以百分比表示,这本身就有其隐藏的意味:高可用性不是绝对的.换句话说,100% 的可用性是不可能达到的.没错,这里可以这么肯定的说. 我们一般用 "9" 的个数来描述可用性.X个9表示在数据中心运行1年时间的使用过程中,各系统可以正常使用时间与总时间(1年)之比.例

1.首先确定是否是磁盘满了 命令:   df -h 参数说明: -a:列出所有的文件系统,包括系统特有的/proc等文件系统 -k:以KB的容量显示各文件系统 -m:以MB的容量显示各文件系统 -h:以人们较易阅读的GB,MB,KB等格式自行显示 -H:以M=1000K替代M=1024K的进位方式 -T:连同该分区的文件系统名称(例如ext3)也列出 -i:不用硬盘容量,而以inode的数量来显示 结果参数说明: Filesystem:代表该文件系统是在哪个分区,所以列出设备名称 1k-bloc

一.Oracle 表空间的组成 Everoone knows Oracle数据库真正存放数据的是数据文件,Oracle表空间是逻辑上的概念,他在物理上是并不存在的,把多个DataFile合并到一起就是一个表空间. 左图是Oracle中DataBase和tablepspace和DataFile的关系 如果不理解上图,可以看下图: 表空间就好像是背景,而其中的土地就相当于是数据文件,北京就是由一块块土地构成. 大致的关系是: 1.一个DataBase实例包含多个tablespace,一个tables