paul white

Hi Cecil,

Check out the dba guide. Ch 5.
I had a similar problem when copying a tables between production and test.
I'd get E_US14E4 going one way but not the other.

The instructions for performing a bulk copy (in the DBA Guide), say the
table must have the following three characteristics:
* The table has no secondary indexes.
* The table is not journaled.
* The table is either a heap table OR it is empty and less than 18 pages in
size.

In my case, the production tables were created with journaling by default. I
had to explicitly set nojournaling in order to use bulk copy parameters.

Also, you may like to consider changing the order of the steps
From: create, modify, copy from
To: create, copy from, modify.

In the second case, the copy from can perform a bulk load on a heap table,
then modify after.

Paul

-----Original Message-----
From: info-ingres-admin@cariboulake.com
[mailto:info-ingres-admin@cariboulake.com]On Behalf Of Cecil Westerhof
Sent: Sunday, 8 October 2006 5:17 PM
To: info-ingres@cariboulake.com
Subject: [Info-ingres] Re: Problem with copy.in


Cecil Westerhof schreef:


I found the problem. The through copydb generated code had
with allocation = 16,
row_estimate = 934136
at the end of the copy command. When I remove that I can import the
data into the table. But it seems to take much longer then.

_______________________________________________
Info-ingres mailing list
Info-ingres@cariboulake.com
http://mailman.cariboulake.com/mailm...py/info-ingres

roy hann

If that's all it says, then the manual fails to mention that the table must
not have any system maintained logical key columns either (table_key or object_key).


I have always thought the installation default of default_journaling ON is
wrong. I can understand the temptation to ship the product that way, but it
causes as many problems as it solves IMO. Generally, once you've created
the durable production tables owned by the DBA, any further tables probably
should not be journaled, or not by default anyway.

Roy

paul white

or object_key).

One of your favourite subjects :-)

I found it frustrating to have perfectly good copy.in scripts run in
test conditions, then on D-day they would fail in production in the
middle of hours of processing. I would have preferred the copy to
ignore the syntax "error", report a warning, and get on with the job
anyway. I raised an issue which turned into a DAR which provided a fix
to part of my problem. See "copydb -journal".


On the other hand, it is nice to know if someone loads data with copydb
it will be journalled from day one and not have to wait until the next
checkpoint. Doesn't apply to really large imports which run slow, and
eat up lots space in the journals. I do these ones after hours and with
nojournaling, followed by checkpoint.

Paul


_______________________________________________
Info-ingres mailing list
Info-ingres@cariboulake.com
http://mailman.cariboulake.com/mailm...py/info-ingres

roy hann

I don't disagree, and one always has the option to create the table WITH
JOURNALING. My objection is that for most installations almost every table
that is created after the system is commissioned really needn't be journaled
so it is absurd to journal by default.

Of course the option to use session global temporary tables makes it less of
an issue.

Roy