Yup, this is Bug 2391334 which has been around for long time, and probably will not be fixed in the near future.
One way of working around this is "know" the path for scripts without actually hard coding that path. To do this in SQLPlus requires a trick - if you try to run a non-existent file, then you'll get an error message that includes the path name.
So here's a demo of that in action. To mimic your scenario I've got:
c:\temp\demo
script.sql
maindir
subdir
call_script.sql
script.sql
What we can do is add some commands to the front of call_script.sql which will pick up the path. It looks a little odd, but you should not need to change it - its just a fixed thing you paste in
set termout off
spool _path_finder.sql
@@_nonexistent_script.sql
spool off;
var path varchar2(100);
set serverout on
declare
output varchar2(1000) := regexp_replace(replace(q'{
@_path_finder.sql
}',chr(10)),'.*"(.*)".*','\1');
begin
:path:=substr(output,1,length(output)-24);
end;
/
col path new_val path
select :path path from dual;
set termout on
What's happening here, is we're running a non-existent script, which returns:
"SP2-0310: unable to open file "path\_nonexistent_script.sql"
so with a little regexp we can extract the path, store it in a SQLPlus variable and then use from that point on.
So the final version of your call_script.sql would look like this
set termout off
spool _path_finder.sql
@@_nonexistent_script.sql
spool off;
var path varchar2(100);
set serverout on
declare
output varchar2(1000) := regexp_replace(replace(q'{
@_path_finder.sql
}',chr(10)),'.*"(.*)".*','\1');
begin
:path:=substr(output,1,length(output)-24);
end;
/
col path new_val path
select :path path from dual;
set termout on
prompt path was &path
@@&path\script.sql
@&path\script.sql
and when we run that, we get the following
SQL> @maindir\mainsubdir\call_script
path was maindir\mainsubdir
script in subdir
script in subdir
and there you go :-)
You don't want them to be running with the same parameters in the first place. Very likely that you want to enable the 11g features. Things that you might want to make sure to be at least equal size are the memory footprint, temp tablespaces and undo tablespaces.
In Oracle 11g you might be tempted to use Autmatic Memory Management. There are some issues with it so it might be smarter to configure your shared pool and database buffer according to the 10g database. In the run check if you are not over or undersized.
Best is to hire a dba to help you with the setup, next best is to dive into Oracle® Database 2 Day DBA 11g Release 2 (11.2) There is a lot to learn from.
Best Answer
To get the size of
TEMP
, in bytes (obviously divide by a few 1024s to get Gigabytes):Doc link for the view here.