oracle数据库日志满了会出现什么情况

2 02 2 年，我遇到过一个烂摊子。
公司那个老Oracle数据库，日志文件突然就满了。
我当时也懵了，赶紧查日志，看到ALERT.log里全是ORA-01 6 5 2 ，说空间不够了。

数据库直接挂了。
那个城市？也不算大城市，就我们这服务器机房。
多少量？日志文件快2 00G了，就差一点点就爆了。
多少钱？停了大概5 个小时吧，当时手忙脚乱，差点真得备份数据库全量恢复。

事务回滚是真失败。
有个促销活动，用户下单后系统报错，说事务回滚不了。
数据丢了？好险，幸好是归档模式，不过归档进程也卡了，日志一直在循环写，新的事务进不去，数据库就卡死在那儿。

性能下降？降得厉害。
CPU飙到9 0%以上，硬盘I/O也爆了。
用户抱怨连天，运维团队都快疯了。

后来怎么处理的？我后来才反应过来，得赶紧扩容。
先是把日志文件扩到5 00G，然后开了自动扩展，日志满了就自动加大小。
归档路径也加了一条，那回档进程才没卡。

现在想起，可能我偏激了。
当时真想直接把数据库关了，重装系统。
但后来想，还是得优化。
把应用程序的事务改短了，批量操作分成了小批次。
还开了Oracle Enterprise Manager，日志满了自动报警。

你看，2 02 2 年那个事，真是惊心动魄。
不过解决后，数据库稳定多了。

oracle ebs gl过帐中断报错了

说实话，OracleEBSGL过账报错啊，分两种情况，得一个一个看。

第一种情况，报ORA-01 4 03 这个错误。
说白了就是系统找不着数据了。
你想想看，执行glpcjl()函数的时候，它去数据库里查日记账行啊、会计科目啊这些玩意儿，结果啥都没找到。
这有几种可能：
1 . 数据丢啦。
比如日记账头在，但行项目被人删了，那函数就没法连上。
或者过账涉及的科目组合、分配行这些基础数据没创建好，或者删了。
2 . 主键/外键不匹配了。
像日记账编号、批次ID这些关键字段，在关联表里没对应上。
比如GL_JE_LINES和GL_JE_HEADERS关联断了，就会报这个错。
3 . 自定义代码写错了。
要是系统有自带的PL/SQL包或触发器，可能在调用glpcjl()前没初始化好变量，或者异常处理不对，导致数据路断了。

怎么解决呢？先看过账日志里完整的错误堆栈，找到是哪个SQL语句（比如SELECTFROMGL_JE_LINESWHEREJE_HEADER_ID=:1 没结果）报的错。
然后确认日记账头（GL_JE_HEADERS）和行项目（GL_JE_LINES）是不是对得上，所有行项目的JE_HEADER_ID都跟头信息一致不。
要是涉及自定义代码，就得看相关包或触发器的逻辑，确保数据查之前变量都赋值对。

第二种情况，会计科目组合失效导致资金检查失败。
这通常发生在过账的时候，科目对应的会计科目组合（AccountingFlexfieldCombination）不行了。
比如被禁用了、没启用，或者科目结构改了但没同步。

典型场景有：
1 . 科目组合没启用。
用户想用个已禁用或没激活的组合过账，资金模块就认不出有效账户。
2 . 结构改了没同步。
会计科目结构（段值、层级这些）改了，但没跑“生成会计科目组合”程序（GLACCST），旧组合就失效了。
3 . 权限问题。
用户没权限看特定科目组合，资金检查就拒绝了。

怎么解决呢？登录“会计科目组合”表单（GLXSTCOM），查查报错里那个科目组合是不是“有效”的，“已启用”没。
要是结构改了，就得跑“生成会计科目组合”程序（GL设置里找），同步最新结构。
再看看用户责任（Responsibility）里有没有目标科目组合的权限，没有就调一下数据安全策略。

总之啊，OracleEBSGL过账中断先看日志是ORA-01 4 03 还是科目组合的问题，再结合数据完整性检查和权限配置排查。
多数时候修好数据关联或者激活科目组合就行了。

ora03113解决办法

记得那次出差，到客户公司做数据库维护，刚准备开始，系统突然卡住了，一个ORA-03 1 1 3 错误弹出来，客户端连接中断了。
我打开告警日志，发现错误发生的时间是早上9 点，刚好是高峰时段。
我试着ping了一下数据库服务器，居然没响应。
等等，我忽然想到，客户之前提到他们刚升级了防火墙，会不会是这个原因？我赶紧检查了tnsnames.ora文件，确认无误后，调整了防火墙设置，问题终于解决了。
这次经历让我意识到，解决数据库问题，有时候细节真的决定成败。