I see two solutions. I did not test them but I hope they are userful.
In contrast to table mode export both user mode and tablespace mode export take care of the dependencies between tables so that the tables are imported in the right order. Both methods import the production table stuctures to dev. Tablespace mode export/import in ORacle 8i or 9i can be done only beteen database systems on the same operating system. On can handle this restriction by importing the data using user mode import into a intermediate schema or database on the same operating system as the target sytem.
Method 1: Using TablespaceMode export/import:
1) Put the tablespace(s) of prod in read only mode
2) TablespaceMode-Export the tablespace(s) and datafile copy from prod
3) Put the tablespaces of prod in read/write mode again
4) Drop the Tablespaces in dev (leaves procedures, views from dev)
5) TablespaceMode-Import the tablespaces in Target (includes tables, triggers , indexes, constraints of prod)
6) Put the tablespace(s) of dev in read/write mode
Maybe there are some problems you have to copy with changes in table structure, missing grants or that sequences have to be adjusted
Method 2: replace procedures by an export
1) UserMod-Export of the prod schema
2) UserMod-Export of the dev schema
3) drop the dev schema
4) import the prod schema (to dev)
5) import the dev-schema (to dev)
the second import schould replace the prod objects (procedures, views) by the dev objects but leave the tables and
table related objects.
Parameters with * are alredady set during the export. Maybe one must not set them during import.
If you set
IGNORE=N then you will get a lot of error messages but maybe there are some other advantages.
It will happen hat you import tables from dev that are not in prod. Changes to the table structure must be handled mynually.
I would prefere a method that extracts the procedures from the dev schema before it is replaced by the prod schema. Tools like Toad from Quest (as mentioned by @r.m in a comment) that can compare schemas an create scripts to implement the differences may help.
1) UserMode-Export from prod
2) Extract the procedures from dev into sql-scripts
3) drop dev schema
4) UserMode-Import to dev
5) drop procedures in dev
6) run the scripts created by the extraction process
7) compile all procedures
The following method leaves the dev structures and only imports the data from production. You will get errors during import of data if the column of a table has been renamed or removed in dev. Adding columns with constraints in dev tables or altering contraints in dev may also make the import of data fail for this tables. If some tables aren`t imported because of this errors dependent tables that were not changed in dev can also have problems when the data is imported. So a lot of complicated problems can arise. The basic idea is:
*) remove the data from the dev tables
*) disable contraints, triggers and indexes on the dev tables
*) import the data only from the prod tables to the dev tables
*) enable the constraints, triggers and indexes on the dev tables
*) import the data to the new dev tables and enable their constaints, triggers and indexes
1)user mode export the dev schema without triggers
2) user mode export the dev schema again
3) table mode export of dev tables not found on prod
4) drop the schema on dev
5) create the empty schema on dev again
6) import the empty dev schema without triggers, constraints and indexes
7) import the indexes in a script
8) user mode export the prod schema
9) table import the prod table dataTABLES=*
10) create the indexes using index.sql with sqlplus
11) import table constraints and triggers
12) import the dev tables you need