In the process of storage USES a merge into statements;
If v_cf & gt; 0 then
If cf> 0 then
The execute immediate 'alter table bdc_regn_cf drop primary key cascade';
end if;
The merge into (select t. *, t.r owid from bdc_regn_cf t where zrzid=v_qzrz) a
Using (select t. *, t.r owid from BDC_h t where zrzid=v_xzrz) b
On (al-qeada jzy=b.g jzy)
The when matched then update the set a. d. jkid=b. wid, a.z rzid=v_xzrz; ,
Execution times wrong as shown in figure:

CodePudding user response:

No complains in the process?

CodePudding user response:

reference 1st floor baidu_36457652 response:

no complains in the process?

In SQL executed directly is not an error, but there is an error in the process of

CodePudding user response:

refer to the second floor qq_34585555 response:

Quote: refer to 1st floor baidu_36457652 response:

No complains in the process?

In SQL executed directly is not an error, but there is an error in the process of

https://blog.csdn.net/z1729734271/article/details/52437856

CodePudding user response:

reference baidu_36457652 reply: 3/f

Quote: refer to the second floor qq_34585555 response:

Quote: refer to 1st floor baidu_36457652 response:

No complains in the process?

In SQL executed directly is not an error, but there is an error in the process of

https://blog.csdn.net/z1729734271/article/details/52437856

Thank you I go and see

CodePudding user response:

May be a BUG
Has no one was with:
The alter system set cursor_sharing=similar;
The alter system flush shared_pool;