Your db admin should know that ;)
Otherwise, you can do a
mysqladmin variables
and look at 'datadir' value.
In this directory, you should find a file named <hostname>.err
(see http://www.mysql.com/doc/en/Error_log.html).
Regards
--
Joseph Bueno
Derrell Durrett wrote:
> Joseph Bueno wrote:
>
>
>>Have you looked at mysql error log file on the server ?
>
>
> Where would I find that?
>
> Derrell
>
>
>>Derrell Durrett wrote:
>>
>>>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
>>>
>>>
>>>
>>
>
> --
> 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 <mysql-thread119215@stripped>
> To unsubscribe, e-mail
> <mysql-unsubscribe-joseph.bueno=trader.com@stripped>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
>
