forked from darold/ora2pg
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME
2735 lines (2182 loc) · 130 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
NAME
Ora2Pg - Oracle to PostgreSQL database schema converter
DESCRIPTION
Ora2Pg is a free tool used to migrate an Oracle database to a PostgreSQL
compatible schema. It connects your Oracle database, scans it
automatically and extracts its structure or data, then generates SQL
scripts that you can load into your PostgreSQL database.
Ora2Pg can be used for anything from reverse engineering Oracle database
to huge enterprise database migration or simply replicating some Oracle
data into a PostgreSQL database. It is really easy to use and doesn't
require any Oracle database knowledge other than providing the
parameters needed to connect to the Oracle database.
FEATURES
Ora2Pg consist of a Perl script (ora2pg) and a Perl module (Ora2Pg.pm),
the only thing you have to modify is the configuration file ora2pg.conf
by setting the DSN to the Oracle database and optionally the name of a
schema. Once that's done you just have to set the type of export you
want: TABLE with constraints, VIEW, MVIEW, TABLESPACE, SEQUENCE,
INDEXES, TRIGGER, GRANT, FUNCTION, PROCEDURE, PACKAGE, PARTITION, TYPE,
INSERT or COPY, FDW, QUERY, KETTLE, SYNONYM.
By default Ora2Pg exports to a file that you can load into PostgreSQL
with the psql client, but you can also import directly into a PostgreSQL
database by setting its DSN into the configuration file. With all
configuration options of ora2pg.conf you have full control of what
should be exported and how.
Features included:
- Export full database schema (tables, views, sequences, indexes), with
unique, primary, foreign key and check constraints.
- Export grants/privileges for users and groups.
- Export range/list partitions andi sub partitions.
- Export a table selection (by specifying the table names).
- Export Oracle schema to a PostgreSQL 8.4+ schema.
- Export predefined functions, triggers, procedures, packages and
package bodies.
- Export full data or following a WHERE clause.
- Full support of Oracle BLOB object as PG BYTEA.
- Export Oracle views as PG tables.
- Export Oracle user defined types.
- Provide some basic automatic conversion of PLSQL code to PLPGSQL.
- Works on any plateform.
- Export Oracle tables as foreign data wrapper tables.
- Export materialized view.
- Show a detailled report of an Oracle database content.
- Migration cost assessment of an Oracle database.
- Migration difficulty level assessment of an Oracle database.
- Migration cost assessment of PL/SQL code from a file.
- Migration cost assessment of Oracle SQL queries stored in a file.
- Generate XML ktr files to be used with Penthalo Data Integrator (Kettle)
- Export Oracle locator and spatial geometries into PostGis.
- Export DBLINK as Oracle FDW.
- Export SYNONYMS as views.
- Export DIRECTORY as external table or directory for external_file extension.
- Full MySQL export just like Oracle database.
- Dispatch a list of SQL orders over multiple PostgreSQL connections
- Perform a diff between Oracle and PostgreSQL database for test purpose.
Ora2Pg does its best to automatically convert your Oracle database to
PostgreSQL but there's still manual workxs to do. The Oracle specific
PL/SQL code generated for functions, procedures, packages and triggers
has to be reviewed to match the PostgreSQL syntax. You will find some
useful recommendations on porting Oracle PL/SQL code to PostgreSQL
PL/PGSQL at "Converting from other Databases to PostgreSQL", section:
Oracle (http://wiki.postgresql.org/wiki/Main_Page).
See http://ora2pg.darold.net/report.html for a HTML sample of an Oracle
database migration report.
INSTALLATION
All Perl modules can always be found at CPAN (http://search.cpan.org/).
Just type the full name of the module (ex: DBD::Oracle) into the search
input box, it will brings you the page for download.
Releases of Ora2Pg stay at SF.net
(https://sourceforge.net/projects/ora2pg/).
Under Windows you should install Strawberry Perl
(http://strawberryperl.com/) and the OSes corresponding Oracle clients.
It seems that compiling DBD::Oracle from CPAN on Windows can be a
struggle and there be little documentation on that (mostly outdated and
not working). Installing the free version of ActiveState Perl
(http://www.activestate.com/activeperl) could help as they seems to have
an already packaged DBD::Oracle easy to install.
Requirement
You need a modern Perl distribution (perl 5.10 and more). To connect to
a database and proceed to his migration you need the DBI Perl module >
1.614. To migrate an Oracle database you need the DBD::Oracle Perl
modules to be installed. To migrate a MySQL database you need the
DBD::MySQL Perl modules. These modules are used to connect to the
database but they are not mandatory if you want to migrate DDL input
files.
To install DBD::Oracle and have it working you need to have the Oracle
client libraries installed and the ORACLE_HOME environment variable must
be defined.
If you plan to export a MySQL database you need to install the Perl
module DBD::mysql which requires that the mysql client libraries are
installed.
On some Perl distribution you may need to install the Time::HiRes Perl
module.
Optional
By default Ora2Pg dumps export to flat files, to load them into your
PostgreSQL database you need the PostgreSQL client (psql). If you don't
have it on the host running Ora2Pg you can always transfer these files
to a host with the psql client installed. If you prefer to load export
'on the fly', the perl module DBD::Pg is required.
Ora2Pg allows you to dump all output in a compressed gzip file, to do
that you need the Compress::Zlib Perl module or if you prefer using
bzip2 compression, the program bzip2 must be available in your PATH.
Installing Ora2Pg
Like any other Perl Module Ora2Pg can be installed with the following
commands:
tar xjf ora2pg-x.x.tar.bz2
cd ora2pg-x.x/
perl Makefile.PL
make && make install
This will install Ora2Pg.pm into your site Perl repository, ora2pg into
/usr/local/bin/ and ora2pg.conf into /etc/ora2pg/.
On Windows(tm) OSes you may use instead:
perl Makefile.PL
dmake && dmake install
This will install scripts and libraries into your Perl site installation
directory and the ora2pg.conf file as well as all documentation files
into C:\ora2pg\
Packaging
If you want to build the binary package for your preferred Linux
distribution take a look at the packaging/ directory of the source
tarball. There is everything to build RPM, Slackware and Debian
packages. See README file in that directory.
Installing DBD::Oracle
Ora2Pg needs the Perl module DBD::Oracle for connectivity to an Oracle
database from perl DBI. To get DBD::Oracle get it from CPAN a perl
module repository.
After setting ORACLE_HOME and LD_LIBRARY_PATH environment variables as
root user, install DBD::Oracle. Proceed as follow:
export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
export ORACLE_HOME=/usr/lib/oracle/11.2/client64/
perl -MCPAN -e 'install DBD::Oracle'
If you are running for the first time it will ask many questions; you
can keep defaults by pressing ENTER key, but you need to give one
appropriate mirror site for CPAN to download the modules. Install
through CPAN manually if the above doesn't work:
#perl -MCPAN -e shell
cpan> get DBD::Oracle
cpan> quit
cd ~/.cpan/build/DBD-Oracle*
export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
export ORACLE_HOME=/usr/lib/oracle/11.2/client64/
perl Makefile.PL
make
make install
Installing DBD::Oracle require that the three Oracle packages:
instant-client, SDK and SQLplus are installed as well as the libaio1
library.
CONFIGURATION
Ora2Pg configuration can be as simple as choosing the Oracle database to
export and choose the export type. This can be done in a minute.
By reading this documentation you will also be able to:
- Select only certain tables and/or column for export.
- Rename some tables and/or column during export.
- Select data to export following a WHERE clause per table.
- Delay database constraints during data loading.
- Compress exported data to save disk space.
- and much more.
The full control of the Oracle database migration is taken though a
single configuration file named ora2pg.conf. The format of this file
consist in a directive name in upper case followed by tab character and
a value. Comments are lines beginning with a #.
There's no specific order to place the configuration directives, they
are set at the time they are read in the configuration file.
For configuration directives that just take a single value, you can use
them multiple time in the configuration file but only the last
occurrence found in the file will be used. For configuration directives
that allow a list of value, you can use it multiple time, the values
will be appended to the list. If you use the IMPORT directive to load a
custom configuration file, directives defined in this file will be
stores from the place the IMPORT directive is found, so it is better to
put it at the end of the configuration file.
Values set in command line options will override values from the
configuration file.
Ora2Pg usage
By default Ora2Pg will look for /etc/ora2pg/ora2pg.conf configuration
file, if the file exist you can simply execute:
/usr/local/bin/ora2pg
or under Windows(tm) run ora2pg.bat file, located in your perl bin
directory. Windows(tm) users may also find a template configuration file
in C:\ora2pg
If you want to call another configuration file, just give the path as
command line argument:
/usr/local/bin/ora2pg -c /etc/ora2pg/new_ora2pg.conf
Here are all command line parameters available when using ora2pg:
Usage: ora2pg [-dhpqv --estimate_cost --dump_as_html] [--option value]
-a | --allow str : Comma separated list of objects to allow from export.
Can be used with SHOW_COLUMN too.
-b | --basedir dir: Set the default output directory, where files
resulting from exports will be stored.
-c | --conf file : Set an alternate configuration file other than the
default /etc/ora2pg/ora2pg.conf.
-d | --debug : Enable verbose output.
-D | --data_type STR : Allow custom type replacement at command line.
-e | --exclude str: Comma separated list of objects to exclude from export.
Can be used with SHOW_COLUMN too.
-h | --help : Print this short help.
-g | --grant_object type : Extract privilege from the given object type.
See possible values with GRANT_OBJECT configuration.
-i | --input file : File containing Oracle PL/SQL code to convert with
no Oracle database connection initiated.
-j | --jobs num : Number of parallel process to send data to PostgreSQL.
-J | --copies num : number of parallel connection to extract data from Oracle.
-l | --log file : Set a log file. Default is stdout.
-L | --limit num : Number of tuples extracted from Oracle and stored in
memory before writing, default: 10000.
-m | --mysql : Export a MySQL database instead of an Oracle schema.
-n | --namespace schema : Set the Oracle schema to extract from.
-N | --pg_schema schema : Set PostgreSQL's search_path.
-o | --out file : Set the path to the output file where SQL will
be written. Default: output.sql in running directory.
-p | --plsql : Enable PLSQL to PLPGSQL code conversion.
-P | --parallel num: Number of parallel tables to extract at the same time.
-q | --quiet : Disable progress bar.
-s | --source DSN : Allow to set the Oracle DBI datasource.
-t | --type export: Set the export type. It will override the one
given in the configuration file (TYPE).
-T | --temp_dir DIR: Set a distinct temporary directory when two
or more ora2pg are run in parallel.
-u | --user name : Set the Oracle database connection user.
ORA2PG_USER environment variable can be used instead.
-v | --version : Show Ora2Pg Version and exit.
-w | --password pwd : Set the password of the Oracle database user.
ORA2PG_PASSWD environment variable can be used instead.
--forceowner : Force ora2pg to set tables and sequences owner like in
Oracle database. If the value is set to a username this one
will be used as the objects owner. By default it's the user
used to connect to the Pg database that will be the owner.
--nls_lang code: Set the Oracle NLS_LANG client encoding.
--client_encoding code: Set the PostgreSQL client encoding.
--view_as_table str: Comma separated list of view to export as table.
--estimate_cost : Activate the migration cost evalution with SHOW_REPORT
--cost_unit_value minutes: Number of minutes for a cost evalution unit.
default: 5 minutes, correspond to a migration conducted by a
PostgreSQL expert. Set it to 10 if this is your first migration.
--dump_as_html : Force ora2pg to dump report in HTML, used only with
SHOW_REPORT. Default is to dump report as simple text.
--dump_as_csv : As above but force ora2pg to dump report in CSV.
--dump_as_sheet : Report migration assessment one CSV line per database.
--init_project NAME: Initialise a typical ora2pg project tree. Top directory
will be created under project base dir.
--project_base DIR : Define the base dir for ora2pg project trees. Default
is current directory.
--print_header : Used with --dump_as_sheet to print the CSV header
especially for the first run of ora2pg.
--human_days_limit num : Set the number human-days limit where the migration
assessment level switch from B to C. Default is set to
5 human-days.
--audit_user LIST : Comma separated list of username to filter queries in
the DBA_AUDIT_TRAIL table. Used only with SHOW_REPORT
and QUERY export type.
--pg_dsn DSN : Set the datasource to PostgreSQL for direct import.
--pg_user name : Set the PostgreSQL user to use.
--pg_pwd password : Set the PostgreSQL password to use.
--count_rows : Force ora2pg to perform a real row count in TEST action.
--no_header : Do not append Ora2Pg header to output file
See full documentation at http://ora2pg.darold.net/ for more help or see
manpage with 'man ora2pg'.
ora2pg will return 0 on success, 1 on error. It will return 2 when a
child process has been interrupted and you've gotten the warning
message: "WARNING: an error occurs during data export. Please check
what's happen." Most of the time this is an OOM issue, first try
reducing DATA_LIMIT value.
For developers, it is possible to add your own custom option(s) in the
Perl script ora2pg as any configuration directive from ora2pg.conf can
be passed in lower case to the new Ora2Pg object instance. See ora2pg
code on how to add your own option.
Note that performance might be improved by updating stats on oracle:
BEGIN
DBMS_STATS.GATHER_SCHEMA_STATS
DBMS_STATS.GATHER_DATABASE_STATS
DBMS_STATS.GATHER_DICTIONARY_STATS
END;
Generate a migration template
The two options --project_base and --init_project when used indicate to
ora2pg that he has to create a project template with a work tree, a
configuration file and a script to export all objects from the Oracle
database. Here a sample of the command usage:
ora2pg --project_base /app/migration/ --init_project test_project
Creating project test_project.
/app/migration/test_project/
schema/
dblinks/
directories/
functions/
grants/
mviews/
packages/
partitions/
procedures/
sequences/
synonyms/
tables/
tablespaces/
triggers/
types/
views/
sources/
functions/
mviews/
packages/
partitions/
procedures/
triggers/
types/
views/
data/
config/
reports/
Generating generic configuration file
Creating script export_schema.sh to automate all exports.
Creating script import_all.sh to automate all imports.
It create a generic config file where you just have to define the Oracle
database connection and a shell script called export_schema.sh. The
sources/ directory will contains the Oracle code, the schema/ will
contains the code ported to PostgreSQL. The reports/ directory will
contains the html reports with the migration cost assessment.
If you want to use your own default config file, use the -c option to
give the path to that file. Rename it with .dist suffix if you want
ora2pg to apply the generic configuration values otherwise, the
configuration file will be copied untouched.
Once you have set the connection to the Oracle Database you can execute
the script export_schema.sh that will export all object type from your
Oracle database and output DDL files into the schema's subdirectories.
At end of the export it will give you the command to export data later
when the import of the schema will be done and verified.
You can choose to load the DDL files generated manually or use the
second script import_all.sh to import those file interactively. If this
kind of migration is not something current for you it's recommended you
to use those scripts.
Oracle database connection
There's 5 configuration directives to control the access to the Oracle
database.
ORACLE_HOME
Used to set ORACLE_HOME environment variable to the Oracle libraries
required by the DBD::Oracle Perl module.
ORACLE_DSN
This directive is used to set the data source name in the form
standard DBI DSN. For example:
dbi:Oracle:host=oradb_host.myhost.com;sid=DB_SID;port=1521
or
dbi:Oracle:DB_SID
for the second notation the SID should be declared in the well known
file $ORACLE_HOME/network/admin/tnsnames.ora or in the path given to
the TNS_ADMIN environment variable.
ORACLE_USER et ORACLE_PWD
These two directives are used to define the user and password for
the Oracle database connection. Note that if you can it is better to
login as Oracle super admin to avoid grants problem during the
database scan and be sure that nothing is missing.
USER_GRANTS
Set this directive to 1 if you connect the Oracle database as simple
user and do not have enough grants to extract things from the
DBA_... tables. It will use tables ALL_... instead.
Warning: if you use export type GRANT, you must set this
configuration option to 0 or it will not works.
TRANSACTION
This directive may be used if you want to change the default
isolation level of the data export transaction. Default is now to
set the level to a serializable transaction to ensure data
consistency. The allowed values for this directive are:
readonly: 'SET TRANSACTION READ ONLY',
readwrite: 'SET TRANSACTION READ WRITE',
serializable: 'SET TRANSACTION ISOLATION LEVEL SERIALIZABLE'
committed: 'SET TRANSACTION ISOLATION LEVEL READ COMMITTED',
Releases before 6.2 used to set the isolation level to READ ONLY
transaction but in some case this was breaking data consistency so
now default is set to SERIALIZABLE.
INPUT_FILE
This directive did not control the Oracle database connection or
unless it purely disable the use of any Oracle database by accepting
a file as argument. Set this directive to a file containing PL/SQL
Oracle Code like function, procedure or full package body to prevent
Ora2Pg from connecting to an Oracle database and just apply his
conversion tool to the content of the file. This can be used with
the most of export types: TABLE, TRIGGER, PROCEDURE, VIEW, FUNCTION
or PACKAGE, etc.
ORA_INITIAL_COMMAND
This directive can be used to send an initial command to Oracle,
just after the connection. For example to unlock a policy before
reading objects or to set some session parameters. This directive
can be used multiple time.
Data encryption with Oracle server
If your Oracle Client config file already includes the encryption
method, then DBD:Oracle uses those settings to encrypt the connection
while you extract the data. For example if you have configured the
Oracle Client config file (sqlnet.or or .sqlnet) with the following
information:
# Configure encryption of connections to Oracle
SQLNET.ENCRYPTION_CLIENT = required
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256, RC4_256)
SQLNET.CRYPTO_SEED = 'should be 10-70 random characters'
Any tool that uses the Oracle client to talk to the database will be
encrypted if you setup session encryption like above.
For example, Perl's DBI uses DBD-Oracle, which uses the Oracle client
for actually handling database communication. If the installation of
Oracle client used by Perl is setup to request encrypted connections,
then your Perl connection to an Oracle database will also be encrypted.
Full details at
https://kb.berkeley.edu/jivekb/entry.jspa?externalID=1005
Testing connection
Once you have set the Oracle database DSN you can execute ora2pg to see
if it works:
ora2pg -t SHOW_VERSION -c config/ora2pg.conf
will show the Oracle database server version. Take some time here to
test your installation as most problems take place here, the other
configuration steps are more technical.
Troubleshooting
If the output.sql file has not exported anything other than the Pg
transaction header and footer there's two possible reasons. The perl
script ora2pg dump an ORA-XXX error, that mean that your DSN or login
information are wrong, check the error and your settings and try again.
The perl script says nothing and the output file is empty: the user
lacks permission to extract something from the database. Try to connect
to Oracle as super user or take a look at directive USER_GRANTS above
and at next section, especially the SCHEMA directive.
LOGFILE
By default all messageis are sent to the standard output. If you
give a file path to that directive, all output will be appended to
this file.
Oracle schema to export
The Oracle database export can be limited to a specific Schema or
Namespace, this can be mandatory following the database connection user.
SCHEMA
This directive is used to set the schema name to use during export.
For example:
SCHEMA APPS
will extract objects associated to the APPS schema.
When no schema name is provided and EXPORT_SCHEMA is enabled, Ora2Pg
will export all objects from all schema of the Oracle instance with
their names prefixed with the scham name.
EXPORT_SCHEMA
By default the Oracle schema is not exported into the PostgreSQL
database and all objects are created under the default Pg namespace.
If you want to also export this schema and create all objects under
this namespace, set the EXPORT_SCHEMA directive to 1. This will set
the schema search_path at top of export SQL file to the schema name
set in the SCHEMA directive with the default pg_catalog schema. If
you want to change this path, use the directive PG_SCHEMA.
CREATE_SCHEMA
Enable/disable the CREATE SCHEMA SQL order at starting of the output
file. It is enable by default and concern on TABLE export type.
COMPILE_SCHEMA
By default Ora2Pg will only export valid PL/SQL code. You can force
Oracle to compile again the invalidated code to get a chance to have
it obtain the valid status and then be able to export it.
Enable this directive to force Oracle to compile schema before
exporting code. When this directive is enabled and SCHEMA is set to
a specific schema name, only invalid objects in this schema will be
recompiled. If SCHEMA is not set then all schema will be recompiled.
To force recompile invalid object in a specific schema, set
COMPILE_SCHEMA to the schema name you want to recompile.
This will ask to Oracle to validate the PL/SQL that could have been
invalidate after a export/import for example. The 'VALID' or
'INVALID' status applies to functions, procedures, packages and user
defined types.
EXPORT_INVALID
If the above configuration directive is not enough to validate your
PL/SQL code enable this configuration directive to allow export of
all PL/SQL code even if it is marked as invalid. The 'VALID' or
'INVALID' status applies to functions, procedures, packages and user
defined types.
PG_SCHEMA
Allow you to defined/force the PostgreSQL schema to use. By default
if you set EXPORT_SCHEMA to 1 the PostgreSQL search_path will be set
to the schema name exported set as value of the SCHEMA directive.
The value can be a comma delimited list of schema name but not when
using TABLE export type because in this case it will generate the
CREATE SCHEMA statement and it doesn't support multiple schema name.
For example, if you set PG_SCHEMA to something like "user_schema,
public", the search path will be set like this:
SET search_path = user_schema, public;
forcing the use of an other schema (here user_schema) than the one
from Oracle schema set in the SCHEMA directive.
You can also set the default search_path for the PostgreSQL user you
are using to connect to the destination database by using:
ALTER ROLE username SET search_path TO user_schema, public;
in this case you don't have to set PG_SCHEMA.
SYSUSERS
Without explicit schema, Ora2Pg will export all objects that not
belongs to system schema or role:
CTXSYS,DBSNMP,EXFSYS,LBACSYS,MDSYS,MGMT_VIEW,OLAPSYS,ORDDATA,OWBSYS,
ORDPLUGINS,ORDSYS,OUTLN,SI_INFORMTN_SCHEMA,SYS,SYSMAN,SYSTEM,WK_TEST,
WKSYS,WKPROXY,WMSYS,XDB,APEX_PUBLIC_USER,DIP,FLOWS_020100,FLOWS_030000,
FLOWS_040100,FLOWS_010600,FLOWS_FILES,MDDATA,ORACLE_OCM,SPATIAL_CSW_ADMIN_USR,
SPATIAL_WFS_ADMIN_USR,XS$NULL,PERFSTAT,SQLTXPLAIN,DMSYS,TSMSYS,WKSYS,
APEX_040200,DVSYS,OJVMSYS,GSMADMIN_INTERNAL,APPQOSSYS,MGMT_VIEW,
ODM,ODM_MTR,TRACESRV,MTMSYS,OWBSYS_AUDIT,WEBSYS,WK_PROXY,
OSE$HTTP$ADMIN,AURORA$JIS$UTILITY$,AURORA$ORB$UNAUTHENTICATED,
DBMS_PRIVILEGE_CAPTURE
Following your Oracle installation you may have several other system
role defined. To append these users to the schema exclusion list,
just set the SYSUSERS configuration directive to a comma-separated
list of system user to exclude. For example:
SYSUSERS INTERNAL,SYSDBA,BI,HR,IX,OE,PM,SH
will add users INTERNAL and SYSDBA to the schema exclusion list.
FORCE_OWNER
By default the owner of the database objects is the one you're using
to connect to PostgreSQL using the psql command. If you use an other
user (postgres for exemple) you can force Ora2Pg to set the object
owner to be the one used in the Oracle database by setting the
directive to 1, or to a completely different username by setting the
directive value to that username.
USE_TABLESPACE
When enabled this directive force ora2pg to export all tables,
indexes constraint and indexes using the tablespace name defined in
Oracle database. This works only with tablespace that are not TEMP,
USERS and SYSTEM.
WITH_OID
Activating this directive will force Ora2Pg to add WITH (OIDS) when
creating tables or views as tables. Default is same as PostgreSQL,
disabled.
LOOK_FORWARD_FUNCTION
List of schema to get functions/procedures meta information that are
used in the current schema export. When replacing call to function
with OUT parameters, if a function is declared in an other package
then the function call rewriting can not be done because Ora2Pg only
know about functions declared in the current schema. By setting a
comma separated list of schema as value of this directive, Ora2Pg
will look forward in these packages for all
functions/procedures/packages declaration before proceeding to
current schema export.
Export type
The export action is perform following a single configuration directive
'TYPE', some other add more control on what should be really exported.
TYPE
Here are the different values of the TYPE directive, default is
TABLE:
- TABLE: Extract all tables with indexes, primary keys, unique keys,
foreign keys and check constraints.
- VIEW: Extract only views.
- GRANT: Extract roles converted to Pg groups, users and grants on all
objects.
- SEQUENCE: Extract all sequence and their last position.
- TABLESPACE: Extract storage spaces for tables and indexes (Pg >= v8).
- TRIGGER: Extract triggers defined following actions.
- FUNCTION: Extract functions.
- PROCEDURE: Extract procedures.
- PACKAGE: Extract packages and package bodies.
- INSERT: Extract data as INSERT statement.
- COPY: Extract data as COPY statement.
- PARTITION: Extract range and list Oracle partitions with subpartitions.
- TYPE: Extract user defined Oracle type.
- FDW: Export Oracle tables as foreign table for oracle_fdw.
- MVIEW: Export materialized view.
- QUERY: Try to automatically convert Oracle SQL queries.
- KETTLE: Generate XML ktr template files to be used by Kettle.
- DBLINK: Generate oracle foreign data wrapper server to use as dblink.
- SYNONYM: Export Oracle's synonyms as views on other schema's objects.
- DIRECTORY: Export Oracle's directories as external_file extension objects.
- LOAD: Dispatch a list of queries over multiple PostgreSQl connections.
- TEST: perform a diff between Oracle and PostgreSQL database.
Only one type of export can be perform at the same time so the TYPE
directive must be unique. If you have more than one only the last
found in the file will be registered.
Some export type can not or should not be load directly into the
PostgreSQL database and still require little manual editing. This is
the case for GRANT, TABLESPACE, TRIGGER, FUNCTION, PROCEDURE, TYPE,
QUERY and PACKAGE export types especially if you have PLSQL code or
Oracle specific SQL in it.
For TABLESPACE you must ensure that file path exist on the system
and for SYNONYM you may ensure that the object's owners and schemas
correspond to the new PostgreSQL database design.
Note that you can chained multiple export by giving to the TYPE
directive a comma-separated list of export type.
Ora2Pg will convert Oracle partition using table inheritance,
trigger and functions. See document at Pg site:
http://www.postgresql.org/docs/current/interactive/ddl-partitioning.
html
The TYPE export allow export of user defined Oracle type. If you
don't use the --plsql command line parameter it simply dump Oracle
user type asis else Ora2Pg will try to convert it to PostgreSQL
syntax.
The KETTLE export type requires that the Oracle and PostgreSQL DNS
are defined.
Since Ora2Pg v8.1 there's three new export types:
SHOW_VERSION : display Oracle version
SHOW_SCHEMA : display the list of schema available in the database.
SHOW_TABLE : display the list of tables available.
SHOW_COLUMN : display the list of tables columns available and the
Ora2PG conversion type from Oracle to PostgreSQL that will be
applied. It will also warn you if there's PostgreSQL reserved
words in Oracle object names.
Here is an example of the SHOW_COLUMN output:
[2] TABLE CURRENT_SCHEMA (1 rows) (Warning: 'CURRENT_SCHEMA' is a reserved word in PostgreSQL)
CONSTRAINT : NUMBER(22) => bigint (Warning: 'CONSTRAINT' is a reserved word in PostgreSQL)
FREEZE : VARCHAR2(25) => varchar(25) (Warning: 'FREEZE' is a reserved word in PostgreSQL)
...
[6] TABLE LOCATIONS (23 rows)
LOCATION_ID : NUMBER(4) => smallint
STREET_ADDRESS : VARCHAR2(40) => varchar(40)
POSTAL_CODE : VARCHAR2(12) => varchar(12)
CITY : VARCHAR2(30) => varchar(30)
STATE_PROVINCE : VARCHAR2(25) => varchar(25)
COUNTRY_ID : CHAR(2) => char(2)
Those extraction keywords are use to only display the requested
information and exit. This allow you to quickly know on what you are
going to work.
The SHOW_COLUMN allow an other ora2pg command line option: '--allow
relname' or '-a relname' to limit the displayed information to the
given table.
The SHOW_ENCODING export type will display the NLS_LANG and
CLIENT_ENCODING values that Ora2Pg will used and the real encoding
of the Oracle database with the corresponding client encoding that
could be used with PostgreSQL
Since release v8.12, Ora2Pg allow you to export your Oracle Table
definition to be use with the oracle_fdw foreign data wrapper. By
using type FDW your Oracle tables will be exported as follow:
CREATE FOREIGN TABLE oratab (
id integer NOT NULL,
text character varying(30),
floating double precision NOT NULL
) SERVER oradb OPTIONS (table 'ORATAB');
Now you can use the table like a regular PostgreSQL table.
See http://pgxn.org/dist/oracle_fdw/ for more information on this
foreign data wrapper.
Release 10 adds a new export type destined to evaluate the content
of the database to migrate, in terms of objects and cost to end the
migration:
SHOW_REPORT : show a detailled report of the Oracle database content.
Here is a sample of report: http://ora2pg.darold.net/report.html
There also a more advanced report with migration cost. See the
dedicated chapter about Migration Cost Evaluation.
ESTIMATE_COST
Activate the migration cost evaluation. Must only be used with
SHOW_REPORT, FUNCTION, PROCEDURE, PACKAGE and QUERY export type.
Default is disabled. You may want to use the --estimate_cost command
line option instead to activate this functionality. Note that
enabling this directive will force PLSQL_PGSQL activation.
COST_UNIT_VALUE
Set the value in minutes of the migration cost evaluation unit.
Default is five minutes per unit. See --cost_unit_value to change
the unit value at command line.
DUMP_AS_HTML
By default when using SHOW_REPORT the migration report is generated
as simple text, enabling this directive will force ora2pg to create
a report in HTML format.
See http://ora2pg.darold.net/report.html for a sample report.
HUMAN_DAYS_LIMIT
Use this directive to redefined the number of human-days limit where
the migration assessment level must switch from B to C. Default is
set to 10 human-days.
JOBS
This configuration directive adds multiprocess support to COPY,
FUNCTION and PROCEDURE export type, the value is the number of
process to use. Default is multiprocess disable.
This directive is used to set the number of cores to used to
parallelize data import into PostgreSQL. During FUNCTION or
PROCEDURE export type each function will be translated to plpgsql
using a new process, the performances gain can be very important
when you have tons of function to convert.
There's no limitation in parallel processing than the number of
cores and the PostgreSQL I/O performance capabilities.
Doesn't works under Windows Operating System, it is simply disabled.
ORACLE_COPIES
This configuration directive adds multiprocess support to extract
data from Oracle. The value is the number of process to use to
parallelize the select query. Default is parallel query disable.
The parallelism is built on splitting the query following of the
number of cores given as value to ORACLE_COPIES as follow:
SELECT * FROM MYTABLE WHERE ABS(MOD(COLUMN, ORACLE_COPIES)) = CUR_PROC
where COLUMN is a technical key like a primary or unique key where
split will be based and the current core used by the query
(CUR_PROC).
Doesn't works under Windows Operating System, it is simply disabled.
DEFINED_PK
This directive is used to defined the technical key to used to split
the query between number of cores set with the ORACLE_COPIES
variable. For example:
DEFINED_PK EMPLOYEES:employee_id
The parallel query that will be used supposing that -J or
ORACLE_COPIES is set to 8:
SELECT * FROM EMPLOYEES WHERE ABS(MOD(employee_id, 8)) = N
where N is the current process forked starting from 0.
PARALLEL_TABLES
This directive is used to defined the number of tables that will be
processed in parallel for data extraction. The limit is the number
of cores on your machine. Ora2Pg will open one database connection
for each parallel table extraction. This directive, when upper than
1, will invalidate ORACLE_COPIES but not JOBS, so the real number of
process that will be used is PARALLEL_TABLES * JOBS.
Note that this directive when set upper that 1 will also
automatically enable the FILE_PER_TABLE directive if your are
exporting to files.
FDW_SERVER
This directive is used to set the name of the foreign data server
that is used in the "CREATE SERVER name FOREIGN DATA WRAPPER
oracle_fdw ..." command. This name will then be used in the "CREATE
FOREIGN TABLE ..." SQL command. Default is arbitrary set to orcl.
This only concern export type FDW.
EXTERNAL_TO_FDW
This directive, enabled by default, allow to export Oracle's
External Tables as file_fdw foreign tables. To not export these
tables at all, set the directive to 0.
INTERNAL_DATE_MAX
Internal timestamp retrieves from custom type are extracted in the
following format: 01-JAN-77 12.00.00.000000 AM. It is impossible to
know the exact century that must be used, so by default any year
below 49 will be added to 2000 and others to 1900. You can use this
directive to change the default value 49. this is only relevant if
you have user defined type with a column timestamp.
AUDIT_USER
Set the comma separated list of username that must be used to filter
queries from the DBA_AUDIT_TRAIL table. Default is to not scan this
table and to never look for queries. This parameter is used only
with SHOW_REPORT and QUERY export type with no input file for
queries. Note that queries will be normalized before output unlike
when a file is given at input using the -i option or INPUT
directive.
FUNCTION_CHECK
Disable this directive if you want to disable check_function_bodies.
SET check_function_bodies = false;
It disables validation of the function body string during CREATE
FUNCTION. Default is to use de postgresql.conf setting that enable
it by default.
Limiting objects to export
You may want to export only a part of an Oracle database, here are a set
of configuration directives that will allow you to control what parts of
the database should be exported.
ALLOW
This directive allows you to set a list of objects on witch the
export must be limited, excluding all other objects in the same type
of export. The value is a space or comma-separated list of objects
name to export. You can include valid regex into the list. For
example:
ALLOW EMPLOYEES SALE_.* COUNTRIES .*_GEOM_SEQ
will export objects with name EMPLOYEES, COUNTRIES, all objects
beginning with 'SALE_' and all objects with a name ending by
'_GEOM_SEQ'. The object depends of the export type. Note that regex
will not works with 8i database, you must use the % placeholder
instead, Ora2Pg will use the LIKE operator.
This is the manner to declare global filters that will be used with
the current export type. You can also use extended filters that will
be applied on specific objects or only on their related export type.
For example:
ora2pg -p -c ora2pg.conf -t TRIGGER -a 'TABLE[employees]'
will limit export of trigger to those defined on table employees. If
you want to extract all triggers but not some INSTEAD OF triggers:
ora2pg -c ora2pg.conf -t TRIGGER -e 'VIEW[trg_view_.*]'
Or a more complex form:
ora2pg -p -c ora2pg.conf -t TABLE -a 'TABLE[EMPLOYEES]' \
-e 'INDEX[emp_.*];CKEY[emp_salary_min]'
This command will export the definition of the employee table but
will exclude all index beginning with 'emp_' and the CHECK
constraint called 'emp_salary_min'.
When exporting partition you can exclude some partition tables by
using
ora2pg -p -c ora2pg.conf -t PARTITION -e 'PARTITION[PART_199.* PART_198.*]'
This will exclude partitioned tables for year 1980 to 1999 from the
export but not the main partition table. The trigger will also be
adapted to exclude those table.
With GRANT export you can use this extended form to exclude some
users from the export or limit the export to some others:
ora2pg -p -c ora2pg.conf -t GRANT -a 'USER1 USER2'
or
ora2pg -p -c ora2pg.conf -t GRANT -a 'GRANT[USER1 USER2]'
will limit export grants to users USER1 and USER2. But if you don't
want to export grants on some functions for these users, for
example:
ora2pg -p -c ora2pg.conf -t GRANT -a 'USER1 USER2' -e 'FUNCTION[adm_.*];PROCEDURE[adm_.*]'
Advanced filters may need some learning.
Oracle doesn't allow the use of lookahead expression so you may want
to exclude some object that match the ALLOW regexp you have defined.
For example if you want to export all table starting with E but not
those starting with EXP it is not possible to do that in a single
expression. This is why you can start a regular expression with the
! character to exclude object matching the regexp given just after.
Our previous example can be written as follow:
ALLOW E.* !EXP.*
it will be translated into:
REGEXP_LIKE(..., '^E.*$') AND NOT REGEXP_LIKE(..., '^EXP.*$')
in the object search expression.
EXCLUDE
This directive is the opposite of the previous, it allow you to
define a space or comma-separated list of object name to exclude
from the export. You can include valid regex into the list. For
example:
EXCLUDE EMPLOYEES TMP_.* COUNTRIES
will exclude object with name EMPLOYEES, COUNTRIES and all tables
beginning with 'tmp_'.
For example, you can ban from export some unwanted function with
this directive:
EXCLUDE write_to_.* send_mail_.*
this example will exclude all functions, procedures or functions in
a package with the name beginning with those regex. Note that regex
will not works with 8i database, you must use the % placeholder
instead, Ora2Pg will use the NOT LIKE operator.
See above (directive 'ALLOW') for the extended syntax.
VIEW_AS_TABLE
Set which view to export as table. By default none. Value must be a
list of view name or regexp separated by space or comma. If the
object name is a view and the export type is TABLE, the view will be
exported as a create table statement. If export type is COPY or
INSERT, the corresponding data will be exported.
See chapter "Exporting views as PostgreSQL table" for more details.
GRANT_OBJECT
When exporting GRANTs you can specify a comma separated list of
objects for which privilege will be exported. Default is export for
all objects. Here are the possibles values TABLE, VIEW, MATERIALIZED
VIEW, SEQUENCE, PROCEDURE, FUNCTION, PACKAGE BODY, TYPE, SYNONYM,
DIRECTORY. Only one object type is allowed at a time. For example
set it to TABLE if you just want to export privilege on tables. You
can use the -g option to overwrite it.