John,
Its just the execute that takes a long time. The commit is instant
in DBD::Oracle.
Let me check with the DBA about those indexes. It might take a day
or two.
John Scoles
12/09/2010 11:52 AM
To
cc
Subject
Re: DBD::Oracle dbd_st_execute slow speed
On 09/12/2
On 09/12/2010 12:24 PM, Martin J. Evans wrote:
On 09/12/10 16:52, ericbamba...@discover.com wrote:
Martin,
do() takes 4 seconds as well. Sorry about the SQL_INTEGER junk. I
was testing things. It takes the same amount of time if I leave off the
types. I remember seeing the trace show
Martin,
Most peices of the information you request are in my original
email and in the trace file in my original e-mail. Perhaps it was too
information dense.
-Oracle database version
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit
Production
With the Partitioning, O
On 09/12/10 16:52, ericbamba...@discover.com wrote:
> Martin,
>
> do() takes 4 seconds as well. Sorry about the SQL_INTEGER junk. I
> was testing things. It takes the same amount of time if I leave off the
> types. I remember seeing the trace show it bind as VARCHAR or something
> when
Recently as in several days ago and the delete finished in about 5
minutes.
I'm not sure how that would affect DBD::Oracle and not my 2 other tools
though.
Let me double check with my DBA about that table.
John Scoles
12/09/2010 11:13 AM
To
cc
,
Subject
Re: DBD::Oracle dbd_st_execute s
On 09/12/2010 11:59 AM, ericbamba...@discover.com wrote:
List,
I'm not sure if this is relevant but I recently loaded 2 million
rows into a parent table NDE_DATA_HIST then issued a DELETE FROM to delete
all of the rows. I dont have access to TRUNCATE(). The table now has only
about 200
List,
I'm not sure if this is relevant but I recently loaded 2 million
rows into a parent table NDE_DATA_HIST then issued a DELETE FROM to delete
all of the rows. I dont have access to TRUNCATE(). The table now has only
about 200 rows. However, the 2 other tools are still fast, its just
Martin,
do() takes 4 seconds as well. Sorry about the SQL_INTEGER junk. I
was testing things. It takes the same amount of time if I leave off the
types. I remember seeing the trace show it bind as VARCHAR or something
when I leave off the type and it was still slow.
Here is the
John,
Thanks. Please let me know if you need anyting else. I've attached
two gzipped files - a level 15 trace and my affected perl code module. The
trace should show the prepare then a single execute before die() ing. The
progam is a daemon and will run forever unless I die(). The sub w
On 09/12/10 15:37, ericbamba...@discover.com wrote:
> DBI Users,
>
> I'm having trouble with DBD::Oracle and very simple insert
> statements into tables with less than 200 records only 2 FKs and no
> indexes taking over 4 seconds. Inserts to other tables seem unaffected. I
> can run the
On 09/12/2010 10:37 AM, ericbamba...@discover.com wrote:
Sounds odd really
We will have to know the version of DBD::Oracle and DBI for starters
Send me the output from the dbd_verbose=>15 so I can check a few things
cheers
John
DBI Users,
I'm having trouble with DBD::Oracle and ve
Confirmed. I double checked and they're both there, normal, and valid.
Even so MJMC.ABI_FL_SYS_FMT has about a dozen rows, MJMC.NDE_DATA_HIST has
about 200, and other tools can insert and commit lightning quick. So
unfortunately I'm not sure how the indexes might be relevant here. They
certainl
Confirm that there are supporting indexes on the table columns that the
FKs reference. If not, that can definitely slow down your inserts as
the tables grow larger.
There should be indexes on:
MJMC.ABI_FL_SYS_FMT (ABI_FMT_ID)
MJMC.NDE_DATA_HIST (DATA_COLL_ID)
Regards,
Mike Towery
DBI Users,
I'm having trouble with DBD::Oracle and very simple insert
statements into tables with less than 200 records only 2 FKs and no
indexes taking over 4 seconds. Inserts to other tables seem unaffected. I
can run the exact same statement from SQLPlus or SQL Developer with no
spe
14 matches
Mail list logo
