Since I didn't get a response, I tried one of the suggestions here. See my response to
it below.
Additionally, I've turned on the environment variables DBI_TRACE and PERL_DBI_DEBUG,
both to level '8'. This produces voluminous, but not particularly illuminating,
output. If anyone has a suggestion as to what I should be looking for in the output
that would indicate the source of the problem, please feel free to share that
information.
If you have any additional suggestions as to things I should try I would be grateful.
FWIW, I have identified how to 'make the errors go away.' Unfortunately, this comes
solely from no longer performing the inserts into the database. That's not
particularly
useful.
Derrell Durrett wrote:
> walt wrote:
>
> > Derrell Durrett wrote:
> >
> > > I'm running server version: 3.22.32, on SunOS 5.6 Generic_105181-17.
> > > The code is perl 5.6.1, using DBI and DBD::mysql as the interface. We
> > > have code that prepares a group of statement handles for use in doing
> > > various queries and inserts in a loop that is executed anywhere from
> > > 1-30000 times per use of this program. Another program drives this one,
> > > calling it about 150 times.
> > >
> > > Last week (after I filled the local hard disk on the server), we began
> > > to suffer disconnects from the database in these queries and inserts.
> > > There is no obvious pattern to the disconnections, and they appear at
> > > arbitrary times during the connections, but at approximately the same
> > > time for each set of data (some of the shorter datasets are inserted
> > > completely).
> > >
> > > The admin for this db is certain the problem is in the code. However
> > > I can't understand this since that code is unchanged.
> > >
> > > What should I look for, what should he look for, or what additional
> > > information do I need to supply in order to pursue resolving this issue?
> >
> > Derrell,
> > There are a few things I'd check.
> > 2. In your perl code, are you running ->finish on each query?
>
> No. If I understand the docs correctly, finish is only useful when all data has
> been read from/written to the statement handle. As the program exits almost
> immediately when done with the batch of inserts/queries for a given dataset, this
> seems appears unnecessary. Is my understanding flawed?
I've now added these. There is no effect. By this I mean that the same errors
continue
to occur, at the same location in the process. There is nothing unusual (that I can
see) in the output from DBI_TRACE.
> > 4. What error message does perl give you from the db?
>
> "No Database Selected" is the most common one, though it occaisionally returns "Lost
> connection to MySQL server during query".
>
> > 5. What is the load avg on the db and application server when query/update fails?
>
> Don't know. Not likely very high. The host is a Sun Ultra 2.
>
> > 6. If the query or update fails, what happens if the perl app sleeps for a few
> > seconds and trys again?
>
> Haven't tried this, as it would result in unacceptably long-running programs.
I'm going to try to implement this next, even though it cannot be a part of the
production version. As the errors indicate that the statement handle doesn't connect
to
the database any longer, I fail to see how that will produce different results, but I'm
getting desperate here.
Derrell
--
Derrell Durrett Xilinx, Inc. Productivity Engineering
Longmont, Colorado
720.652.3843
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
