Bugs

Last week I published some code that demonstrated how a fast refresh of an aggregate materialized view could fail because of the internal use of the sys_op_map_nonnull() function. In some ways it was an easy problem to explain because all you had to do was trace the call to refresh and see what was going on. Today’s bug is completely different – it’s virtually impossible to see the connection between the failure and its cause. Here (as a cut-n-paste) is an example of what happens when the bug appears:

execute dbms_stats.gather_schema_stats(user)
*
ERROR at line 1:
ORA-01760: illegal argument for function
ORA-06512: at "SYS.DBMS_STATS", line 13336
ORA-06512: at "SYS.DBMS_STATS", line 13682
ORA-06512: at "SYS.DBMS_STATS", line 13760
ORA-06512: at "SYS.DBMS_STATS", line 13719
ORA-06512: at line 1

Now, when a called to dbms_stats fails, where are you supposed to look ? Since I had very few objects in the schema I tried collecting table stats for each object in turn (with cascade set to true) and found that the call to gather_table_stats() failed for just one of the tables; then I gathered stats on the table with cascade set to false and found that the call succeeded, so I finished off with a simple call to gather_index_stats on the one index on the table – and that failed.

In my case I had a clue about what to try next. I was running a test case for fast refresh of materialized join view. So I dropped the materialized view and all the calls to gather stats succeeded. So – a call to gather index stats on one of the indexes of a table involved in a materialized join view fails, but only after you’ve done a fast refresh on the view !

This was just an oddity that appeared while I was testing the basic options for non-trival fast refreshes, so I never got around to looking into it properly and didn’t send an SR and test case to Oracle, but if anyone wants to examine the problem, here’s a simple test case (with some of my debug code and minor variations stripped out).

create table orders(
	order_id	number(10) not null,
	customer_id	number(10) not null,
	store_id	number(10) not null,
	order_date	date not null,
	sales_rep	number(10) not null,
	total_value	number(8,2),
	total_tax	number(8,2),
	total_discount	number(8,2),
	constraint ord_pk primary key (order_id)
);

create table order_lines(
	order_id	number(10) not null,
	line_id		number(4)  not null,
	stock_code	number(10) not null,
	line_quantity	number(5)  not null,
	line_value	number(8,2),
	line_tax	number(8,2),
	line_discount	number(8,2),
	constraint orl_pk primary key (order_id, line_id),
	constraint orl_fk_ord foreign key (order_id) references orders
);

create materialized view log on orders
with
	rowid, primary key 
	(
		customer_id,
		store_id,
		order_date,
		sales_rep,
		total_value,
		total_tax,
		total_discount
	)
including new values
;

create materialized view log on order_lines
with
	rowid, primary key 
	(
		stock_code,
		line_quantity,
		line_value,
		line_tax,
		line_discount
	)
including new values
;

create materialized view orders_join
refresh fast on demand
enable query rewrite
as
select
	ord.rowid	ord_rowid,
	orl.rowid	orl_rowid,
	ord.order_id,
	orl.line_id,
	ord.store_id,
	ord.customer_id,
	ord.order_date,
	orl.stock_code,
	orl.line_quantity
from
	orders		ord,
	order_lines	orl
where
	orl.order_id = ord.order_id
;

prompt	========================================
prompt	A call to gather schema stats works here
prompt	========================================

execute dbms_stats.gather_schema_stats(user)

prompt	==============
prompt	Load some data
prompt	==============

insert into orders(
	order_id,
	customer_id,
	store_id,
	order_date,
	sales_rep,
	total_value,
	total_tax,
	total_discount
)
select
	rownum,
	trunc(dbms_random.value(1,5)),
	trunc(dbms_random.value(1,3)),
	trunc(sysdate),
	1,1,1,1
from
	all_objects
where
	rownum <= 5
;

insert into order_lines(
	order_id,
	line_id,
	stock_code,
	line_quantity,
	line_value,
	line_tax,
	line_discount
)
with line_ct as (
	select	--+ materialize
		rownum id 
	from dual 
	connect by 
		rownum <= 10
)
select
	ord.order_id,
	lct.id,
	trunc(dbms_random.value(1,10)),
	100 * lct.id,
	100 * lct.id,
	100 * lct.id,
	100 * lct.id
from
	line_ct	lct,
	orders	ord
;

commit;


prompt	========================================
prompt	A call to gather schema stats works here
prompt	========================================

execute dbms_stats.gather_schema_stats(user)

begin
	dbms_stats.gather_table_stats(
		ownname		 => user,
		tabname		 =>'ORDER_LINES',
		method_opt 	 => 'for all columns size 1',
		cascade		 => true
	);
end;
/

prompt	==============================
prompt	Refresh the materialized views
prompt	==============================

begin
	dbms_mview.refresh(
		list	=> 'test_user.orders_join',
		method	=> 'F'
	);
end;
/

prompt	=========================================
prompt	A call to gather schema stats fails here
prompt	on many versions of Oracle up to 11.2.0.3
prompt	=========================================

execute dbms_stats.gather_schema_stats(user)

begin
	dbms_stats.gather_table_stats(
		ownname		 => user,
		tabname		 =>'ORDER_LINES',
		method_opt 	 => 'for all columns size 1',
		cascade		 => true
	);
end;
/

begin
	dbms_stats.gather_table_stats(
		ownname		 => user,
		tabname		 =>'ORDER_LINES',
		method_opt 	 => 'for all columns size 1',
		cascade		 => false
	);
end;
/

begin
	dbms_stats.gather_index_stats(
		ownname		 => user,
		indname		 =>'ORL_PK'
	);
end;
/

I got the same behaviour on 10.2.0.3, 11.1.0.7 and 11.2.0.3 (although the line numbers in the PL/SQL error stack vary with version, of course).

Resolution of this problem is left as an exercise to the reader, but if I had to investigate further I think I’d start by checking MOS for anything similar, then sending in an SR with the demo, then run the code with sql_trace set to level 4 to see if any unexpected values were being passed in as bind variables to the various bits of recursive SQL called by dbms_stats.


By: [author-name]

This article was syndicated via RSS from: http://jonathanlewis.wordpress.com/2012/09/02/bugs-3/?utm_source=rss&utm_medium=rss&utm_campaign=bugs

No comments yet.

Leave a Comment

You must be logged in to post a comment.