Dan Grotjan, September 27, 2019 - 1:20 pm UTC
Thanks for the feedback. I'm using other SQL and shell scripts to generate the parfiles which contain long lists, and I'm using slightly different syntax.
Instead of using (e.g.);
tables=owner.table_1
tables=owner.table_2
tables=owner.table_3
....
tables=owner.table_n
I'm producing lists like this:
tables=('owner.table_1',
'owner.table_2',
'owner.table_3'
...
'owner.table_n')
I'm assuming that the datapump programs load a list of objects into an array (or some other structure) for processing, and my fear is that there might be a hard limit on the number of elements that can be placed into whatever structure is used.
I suppose I can test that by producing a parfile with a list of 25,000 objects that don't actually exist, and then run it and let them all error off, just to confirm that I'm not going to hit any such hard limits.
I just thought that you guys might have access to documentation that would specify any limits that datapump can't exceed.
Thanks again, and also, thanks for all the work you guys do. AskTom is very valuable resource for many people.
October 01, 2019 - 1:02 am UTC
I'm suggesting that you do NOT use
tables=(xxx,yyy,...)
Why Not?
A reader, October 10, 2019 - 8:09 pm UTC
Connor,
In your last update you suggest that I not use the:
tables=('xxxx',xxxx','xxxx','xxxx') syntax.
Why is that? Is there something inherently better about the following syntax?:
tables='xxxx'
tables='xxxx'
tables='xxxx'
Thanks in advance.
October 21, 2019 - 11:38 am UTC
I had problems with the *length* of a string when using the former version. In my case, it was listing files in a transportable tablespace, but I imagine there are limited for all parameters.
Also, the latter is typically easier to generate in SQL