Debug stored procedure

Question

hi all, please help in writing this procedure. The cursor should take two variables and those variables are passed by using two different FOR loops. Finally, different tables should be based on IF condition.
(1) there are some errors ( PLS-00103 ) while creating procedure.
(2) is there any other way to write this logic by considering performance as it required to handle millions of records.
===========================================
create or replace procedure udprim
is
v_a number;
v_b varchar2(2000);
cursor c1 (vid varchar2(5), vfeat number) is select gid, listagg(vindex, ',') within group (order by tid) idx from table1 where idarpt=vid and feattype=vfeat group by gid;
begin
for irec in (select distinct idarpt from table2 order by 1) loop
for frec in (select distinct feattype from table3 order by 1) loop
if frec.feattype = 0 then
open c1 (irec.idarpt, frec.feattype);
loop
fetch c1 into v_a, v_b;
exit when c1%notfound;
update table4 set vindex=v_b where gid=v_a;
end loop;
close c1;
elsif frec.feattype = 1 then
open c1 (irec.idarpt, frec.feattype);
loop
fetch c1 into v_a, v_b;
exit when c1%notfound;
update table5 set vindex=v_b where gid=v_a;
end loop;
close c1;
elsif frec.feattype = 3 then
open c1 (irec.idarpt, frec.feattype);
loop
fetch c1 into v_a, v_b;
exit when c1%notfound;
update table6 set vindex=v_b where gid=v_a;
end loop;
close c1;
end if;
end loop;
end loop;
end udprim;
=====================================
regards

Answer 1

You are implementing a cross product and join by PL/SQL loops. That is not what PL/SQL is for.
For millions of records, I'd look at one MERGE statement per target table, i.e.
a) build a query, joining table 2, table 3 and table 1, that identifies the gid of rows in table 4 that need to be updated and the new vindex value
b) use that query in a MERGE INTO table4 statment.
c) repeat for table5 and table6.
That will perform much much better than the "slow by slow" loops of loops of query/update loops.
If you are updating a substantial fraction of rows in the table (more than 10%) you may find it is faster to create a new copy of the data via a "create table as select..." statement and then move it back (possibly by RENAME TABLE or truncate then insert /*+ append */).
Updating is often slow and can be disastrous if you are making the rows much longer (row chaining - you need PCTFREE large enough for there to be room for the new values in the existing data blocks).