Oracle ebs冲销凭证报错APP-SQLGL-08087

错误如图:

原因:

此种现象是因为之前对凭证做过冲销,但是在未过账的时候,将生成的冲销凭证删除,但是冲销的记录在凭证头表字段accrual_rev_period_name留下记录,记录的内容是报错界面默认的冲销期间(2019-10)。

解决方案:

直接更新gl_je_headers表中字段accrual_rev_period_name为空即可正常冲销动作(更新前一定要备份,更新后重新期间可选)。

Oracle 在线重定义(普通表变更为分区表)

–背景:cux_gl_interfacebak数据量过大(cux_gl_interfacebak有主键),需按accouting_date按年分区,以下命令直接在command窗口执行即可。
–1、检查需要在线冲定义的表是否
begin
dbms_redefinition.can_redef_table(‘apps’,’cux_gl_interfacebak’,dbms_redefinition.cons_use_pk);
end;
/

或验证是否可以通过rowid方式定义

begin
–dbms_redefinition.can_redef_table(‘scott’,’tb_cablecheck_equipment_bak’,2);
dbms_redefinition.can_redef_table(‘apps’,’cux_gl_interfacebak’,dbms_redefinition.cons_use_rowid);
end;
/

–2、创建中间表
create table CUX_GL_INTERFACEBAK_1
(
source_batch_id VARCHAR2(50) not null,
source_line_id NUMBER(10),
je_group_id VARCHAR2(50) not null,
ledger_id VARCHAR2(50) not null,
accounting_date DATE not null,
process_date DATE not null,
je_category_name VARCHAR2(25) not null,
je_source_name VARCHAR2(25) not null,
currency_code VARCHAR2(15) not null,
currency_conversion_date DATE,
currency_conversion_rate NUMBER(38,2),
currency_conversion_type VARCHAR2(30),
entered_dr NUMBER(38,2),
entered_cr NUMBER(38,2),
accounted_dr NUMBER(38,2),
accounted_cr NUMBER(38,2),
actual_flag VARCHAR2(25) not null,
import_flag VARCHAR2(1) not null,
import_date VARCHAR2(25),
gl_request_id NUMBER(30),
error_message VARCHAR2(255),
doc_seq_num VARCHAR2(100),
segment1 VARCHAR2(25),
segment2 VARCHAR2(25),
segment3 VARCHAR2(25),
segment4 VARCHAR2(25),
segment5 VARCHAR2(25),
segment6 VARCHAR2(25),
segment7 VARCHAR2(25),
segment8 VARCHAR2(25),
segment9 VARCHAR2(25),
segment10 VARCHAR2(25),
segment11 VARCHAR2(25),
segment12 VARCHAR2(25),
segment13 VARCHAR2(25),
line_description VARCHAR2(240),
attribute1 VARCHAR2(25),
attribute2 VARCHAR2(150),
attribute3 VARCHAR2(150),
attribute4 VARCHAR2(150),
attribute5 VARCHAR2(150),
attribute6 VARCHAR2(150),
attribute7 VARCHAR2(150),
attribute8 VARCHAR2(150),
attribute9 VARCHAR2(150),
attribute10 VARCHAR2(150),
attribute11 VARCHAR2(150),
attribute12 VARCHAR2(150),
attribute13 VARCHAR2(150),
attribute14 VARCHAR2(150),
attribute15 VARCHAR2(150),
source_key_id NUMBER(10) not null
)

partition by range(accounting_date)(
PARTITION tb_cablecheck_equipment_p1 VALUES LESS THAN (TO_DATE(‘2017-01-01′,’YYYY-MM-DD’)),
PARTITION tb_cablecheck_equipment_p2 VALUES LESS THAN(TO_DATE(‘2018-01-01’, ‘YYYY-MM-DD’)),
PARTITION tb_cablecheck_equipment_p3 VALUES LESS THAN(TO_DATE(‘2019-01-01’, ‘YYYY-MM-DD’)),
PARTITION tb_cablecheck_equipment_p4 VALUES LESS THAN(TO_DATE(‘2020-01-01’, ‘YYYY-MM-DD’)),
PARTITION tb_cablecheck_equipment_p5 VALUES LESS THAN(TO_DATE(‘2021-01-01’, ‘YYYY-MM-DD’)),
PARTITION tb_cablecheck_equipment_p6 VALUES LESS THAN(MAXVALUE)
);

–3、进行冲定义命令
begin
dbms_redefinition.start_redef_table(‘apps’,’CUX_GL_INTERFACEBAK’,’CUX_GL_INTERFACEBAK_1′,null,2);
end;
/

–4、复制依赖对象
declare
num_errors pls_integer;
begin
dbms_redefinition.copy_table_dependents(‘apps’, ‘CUX_GL_INTERFACEBAK’,’CUX_GL_INTERFACEBAK_1′,
dbms_redefinition.cons_orig_params, true, true, true, true, num_errors);
end;
/

–5、同步中间表,保证数据的一致性
begin
dbms_redefinition.sync_interim_table(‘apps’,’CUX_GL_INTERFACEBAK’,’CUX_GL_INTERFACEBAK_1′);
end;
/

–6、完成重定义命令
begin
dbms_redefinition.finish_redef_table(‘apps’,’CUX_GL_INTERFACEBAK’,’CUX_GL_INTERFACEBAK_1′);
end;
/
–7、验证冲定义是否正常
select * from CUX_GL_INTERFACEBAK partition(tb_cablecheck_equipment_p4);

select *
from cux_gl_interfacebak partition(tb_cablecheck_equipment_p3)
where 1 = 1
and segment3 = ‘6031010101’

–8、删除表
drop table apps.CUX_GL_INTERFACEBAK_1;

oracle数据库报错:ORA-01555: 快照过旧: 回退段号 10 (名称为 “_SYSSMU10_3550978943$”) 过小

前缀:

比较奇怪的是,请求爆这个错误后,我在程序里面加了个when others的异常,然后就正常了。

oracle undo表空间

undo表空间用于存放undo数据,当执行DML操作(insert、update、delete)时,oracle会将这些操作的旧数据写入到undo段。

undo数据的作用

1.回退事务

当执行DML操作修改数据后,旧数据被存放在undo段中。只要数据为提交、回滚段未写满或者回滚段为超时的情况下,旧数据都能被回滚回来。

2.读一致性

通过DML操作后的数据没有提交之前,其他用户读取的数据都是回滚段里面的旧数据。

使用undo参数

1.undo_management

该初始化参数用于指定undo数据的管理方式。如果要使用自动管理模式,必须设置为auto,如果使用手工管理模式必须设置该参数为manual,使用自动管理模式时,oracle会使用undo表空间管理,使用手工管理模式时,oracle会使用回滚段管理undo数据。需要注意,使用自动管理模式时,如果没有配置初始化参数UNDO_TABLESPACE,oracle会自动选择第一个可用的UNDO表空间存放UNDO数据,如果没有可用的UNDO表空间,oracle会使用SYSTEM回滚段存放UNDO记录,并在ALTER文件中记载警告。

2,UNDO_TABLESPACE

该初始化参数用于指定例程所要使用的UNDO表空间,使用自动UNDO管理模式时,通过配置该参数可以指定例程所要使用的UNDO表空间.

在RAC(Real Application Cluster)结构中,因为一个UNDO表空间不能由多个例程同时使用,所有必须为每个例程配置一个独立的UNDO表空间.

3,UNDO_RETENTION

该初始化参数用于控制UNDO数据的最大保留时间,其默认值为900秒,从9i开始,通过配置该初始化参数,可以指定undo数据的保留时间,从而确定倒叙查询特征(Flashback Query)可以查看到的最早时间点.

手工管理回滚段的规划:

SQL> show parameter  undo;

NAME                                 TYPE        VALUE

———————————— ———– ——————————

undo_management                string      AUTO

undo_retention                       integer    900

undo_tablespace                    string      UNDOTBS1

SQL> show parameter  transactions;

NAME                                 TYPE        VALUE

———————————— ———– ——————————

transactions                         integer     187             ———-系统准备支持的事务连接数量。

transactions_per_rollback_segment    integer     5       ————–每个回滚段支持的事务连接数量。回滚段数=187/5

SQL> show  parameter rollback;

NAME                                 TYPE        VALUE

———————————— ———– ———-

fast_start_parallel_rollback         string      LOW

rollback_segments                      string ———————-设置回滚段的数量

transactions_per_rollback_segment    integer     5

错误原因:

SQL语句执行时间太长,或者UNDO表空间过小,或者事务量过大,或者过于频繁的提交,导致执行SQL过程中进行一致性读时,SQL执行后修改的 前镜像(即UNDO数据)在UNDO表空间中已经被覆盖,不能构造一致性读块(CR blocks)。  这种情况最多。

解决办法:

第1种情况解决的办法:

(1)增加UNDO表空间大小

(2)增加undo_retention 时间,默认只有15分钟

alter  system set undo_retention=14400 ;

undo_retention这个值可以根据情况调大一些。

(3)优化出错的SQL,减少查询的时间,首选方法

(4)避免频繁的提交

还有一种情况,可能是oracle BUG,官网说法ORA-01555BUG比较多,

其他参考:

https://www.cnblogs.com/Richardzhu/archive/2013/03/25/2981610.html

查看表空间使用情况
SELECT a.tablespace_name,
ROUND (a.total_size) “total_size(MB)”,
ROUND (a.total_size) – ROUND (b.free_size, 3) “used_size(MB)”,
ROUND (b.free_size, 3) “free_size(MB)”,
ROUND (b.free_size / total_size * 100, 2) || ‘%’ free_rate
FROM ( SELECT tablespace_name, SUM (bytes) / 1024 / 1024 total_size
FROM dba_data_files
GROUP BY tablespace_name) a,
( SELECT tablespace_name, SUM (bytes) / 1024 / 1024 free_size
FROM dba_free_space
GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name(+);

TABLESPACE_NAME                total_size(MB) used_size(MB) free_size(MB) FREE_RATE
—————————— ————– ————- ————- —————————————–
SYSAUX                                    900       835.687        64.313 7.15%
UNDOTBS1                                24576        53.875     24522.125 99.78%
USERS                                       5         1.312         3.688 73.75%
SYSTEM                                   4170      4160.687         9.313 .22%
USER_DATA                                 150       105.062        44.938 29.96%

计算所需undo表空间的大小:

1.计算业务高峰期每秒产生undo数据块的个数
SQL> select max(undoblks / ((end_time – begin_time)*24*3600)) from v$undostat;

MAX(UNDOBLKS/((END_TIME-BEGIN_
——————————
11.305

2.得到undo数据块在undo表空间中可以保留的最长时间
SQL> show parameter undo_retention;

NAME                                 TYPE        VALUE
———————————— ———– ——————————
undo_retention                       integer     86400

3.得到数据块大小
SQL> show parameter db_blo

NAME                                 TYPE        VALUE
———————————— ———– ——————————
db_block_buffers                     integer     0
db_block_checking                    string      FALSE
db_block_checksum                    string      TYPICAL
db_block_size                        integer     8192

4.将以上三者的数据相乘就是所需undo表空间的大小数
SQL> select (11.305*86400*8192)/1024/1024/1024 undoTablespace_GB from dual;

UNDOTABLESPACE_GB
—————–
7.4520263671875

发现undo表空间不够的时候,赶紧增加undo表空间的大小,执行语句如下:
alter tablespace undotbs1 add datafile ‘/u01/database/instance_name/undotbs02.dbf’ size 100M autoextend on next 128M maxsize 24G;
alter tablespace undotbs1 add datafile ‘/u01/database/instance_name/undotbs03.dbf’ size 100M autoextend on next 128M maxsize 24G;
alter tablespace undotbs1 add datafile ‘/u01/database/instance_name/undotbs04.dbf’ size 100M autoextend on next 128M maxsize 24G;

–查看会话数
select count(*) from v$session;

–查看进程数
select count(*) from v$process;

–查看数据库的并发连接数
select * from v$session where status=’ACTIVE’;

–查看当前数据库建立的会话
SELECT SID,SERIAL#,USERNAME,PROGRAM,MACHINE,STATUS FROM V$SESSION;

–查看数据库允许的最大连接数
SELECT value FROM V$PARAMETER WHERE NAME=’processes’

–查看数据库允许的最大会话数
SELECT value FROM V$PARAMETER WHERE NAME=’sessions’
–查看后台正在运行着的sql语句
select a.program,b.spid,c.sql_text from v$session a,v$process b,v$sqlarea c where a.paddr=b.addr and a.sql_hashvalue=c.hash_value and a.username is not null;

查询所有数据库的连接数
select schemaname,count(*)from v$session group by schemaname;

查询终端用户使用数据库的连接情况。
select osuser,schemaname,count(*) fromv $session group by schemaname,osuser;

查看当前不为空的连接
select * from v$session where username is not null

查看不同用户的连接数
select username,count(username) from v$session where username is not null group by username

转自:https://blog.csdn.net/qiuzhi__ke/article/details/78937078

 

Oracle数据库评估undo 表空间大小

如何估算Oracle数据库所需的UNDO表空间的大小:

How To Size UNDO Tablespace For Automatic Undo Management (文档 ID 262066.1)

要确定Oracle需要的UNDO 表空间的大小,需要以下三条信息:

UR 以秒为单位的UNDO_RETENTION

UPS 每秒生成的还原数据块的数量

DBS db_block_size

UndoSpace = [UR * (UPS * DBS)] + (DBS * 24)

UNDO_RETENTION是一个参数,此参数控制为提供读一致性而保留的还原数据量,以秒为单位定义,可以在初始化文件中设置,或使用 ALTER SYSTEM 命令来动态修改。

SQL>ALTER SYSTEM SET UNDO_RETENTION=900;

SQL> show parameter undo_retention

NAME TYPE VALUE

———————————— ———– ——————————

undo_retention integer 900

如果值为900,则可以使还原数据保留 15 分钟,当然需要足够的存储空间才行。

那么如何计算每秒生成的还原数据块的数量呢,可以通过v$undostat视图的begin_time、end_time和undoblks三个字段的值查询出来,计算的SQL语句如下:

SQL> SELECT (UR * (UPS * DBS)) + (DBS * 24) AS “Bytes” FROM (SELECT value AS UR  FROM v$parameter WHERE name = ‘undo_retention’),(SELECT (SUM(undoblks)/SUM(((end_time -begin_time)*86400))) AS UPS  FROM v$undostat),  (SELECT value AS DBS FROM v$parameter  WHERE name = ‘db_block_size’);

Bytes

———-

445814.844

详解:

一般应该在一天中数据库负载最繁重的时候进行计算。

对于UNDO表空间大小的定义需要考虑UNDO_RETNETION参数、产生的UNDO BLOCKS/秒、UNDO BLOCK的大小。undo_retention:对于UNDO表空间的数据文件属性为autoextensible,则undo_retenion参数必须设置,UNDO信息将至少保留至undo_retention 参数设定的值内,但UNDO表空间将会自动扩展。对于固定UNDO表空间,将会通过表空间的剩余空间来最大限度保留UNDO信息。如果FIXED UNDO表空间没有对保留时间作GUARANTEE(alter tablespace xxx retention guarantee;),则undo_retention参数将不会起作用。(警告:如果设置UNDO表空间为retention guarantee,则未过期的数据不会被复写,如果表空间不够则会导致DML操作失败或者transation挂起)

Oracle 10g 有自动Automatic Undo Retention Tuning 这个特性。设置的 undo_retention 参数只是一个指导值,,Oracle 会自动调整 Undo (会跨过 undo_retention 设定的时间) 来保证不会出现 Ora-1555 错误.。通过查询V$UNDOSTAT(该视图记录4天以内的UNDO表空间使用情况,超过4天可以查询DBA_HIST_UNDOSTAT视图) 的 tuned_undoretention (该字段在10G版本才有,9I是没有的)字段可以得到Oracle 根据事务量(如果是文件不可扩展,则会考虑剩余空间)采样后的自动计算出最佳的 retenton 时间.。这样对于一个事务量分布不均匀的数据库来说,,就会引发潜在的问题–在批处理的时候可能 Undo 会用光, 而且这个状态将一直持续, 不会释放。

SQL查询tuned_undoretention:

select to_char(begin_time,’DD-MON-RR HH24:MI’) begin_time,to_char(end_time,’DD-MON-RR HH24:MI’) end_time,tuned_undoretention from v$undostat order by end_time;

检查一天平均每秒产生的UNDO BLOCK

select (sum(undoblks)/sum((end_time-begin_time)*86400) from v$undostat;

生成的结果是UNDO BLOCK,如果需要计算出实际大小,则需要乘以db_block_size(通过show parameter db_block_size查出来)

如何计算合适的UNDO表空间大小:

select (UR*(UPS*DBS))+(DBS*24) as “bytes” from (select value as UR from v$parameter where name=’undo_retention’),(select (sum(undoblks)/sum(((end_time-begin_time)*86400))) as ups from v$undostat),(select value as DBS from v$parameter where name=’db_block_size’);

转自:http://blog.itpub.net/31397003/viewspace-2147515/

技术笔记(小潘的技术记录博客)