DBEXPORT is not successful

[mjldba]

dbexports have always been a 100% successful-all-the-time until now, a real crashtest dummy no-brainer.

I get this error message (25587 Network Receive Failed) when doing a dbexport using IDS 9.30.UC6 on an IBM model 630, OS is AIX 5.1.

Problem is not caused by logical logs filling up, this is a dbexport not a dbimport like some other posts I broused, so what should I look for? I opened a case with Informix/IBM and they do not have an answer for me.

It can fail in 3 minutes or it can fail in 1 hr 15 minutes.

It can fail with the 25587 error message (command line prompt is displayed) or it can fail with a hung telnet session (no keyboard) that must be killed from another telnet session.

In either case, there are no messages in the online.log.

It can fail when unloading a populated table or it can fail when unloading an unpopulated table.

It has failed when dbexporting indexes which amounts to unloading the index definition part of the table schema.

Any help would be appreciated .... thanks.

 

[vpshriyan]

Hi,

Is it a case that you are trying to dump the data into a networked / remote tape or disk? If so, network pitfalls may be one of the culprit, in that case you may think of using local resources for data export.

To which media are you exporting the data into? Disk or tape? Does the normal OS data files backup using unix utility into existing tape drive completes without any problem? A freaky hardware level fault in a tape drive could also land the dbexport job into disarray. If several data packets are sent in a faster rate into a much slower or too old tape drive controller, the data sending utility may interpret a situation as problematic, should it fail in getting the acknowledge message.

Regards,
Shriyan
"Man who knows, knows, he knows nothing!"

 

[mjldba]

Thank you for responding Shriyan.

The dbexport is being executed in what I would consider standard format using dbexport -ss -c <db-name> and let the dbexport process create a db_name.exp dir on disk for the flatfiles and SQL script. We are a PeopleSoft shop so the number of dbexported flatfiles are many & the SQL scripot is huge.

We have been leaning towards viewing this as a hardware problem but I thought it was worth a try running it past some experts.

For all the housekeeping information that gets dumped in the online.log it would be nice if Informix would complain about a problem like the one you described & give me a clue as to where to start looking.

This is really frustrating.

Thanks for your help - Mike

 

[vpshriyan]

Hi Mike,

First, would please knock off a very obvious mistake if any? You say that you direct the dbexport into a disk. A correct syntax would in that case look like:

dbexport <dbname> -ss -o </dirname>

Make sure that </dirname> directory, is existing and read & writable for the user firing the dbexport job.

Regards,
Shriyan
&quot;Failure is only a temporary change in direction to set you straight on the path to your next success.&quot;

 

[mjldba]

HI Shriyan,

The syntax I indicated is the syntax that I've always used, I got it from the &quot;IBM Informix Migration Guide&quot; doc.

dbexport then &quot;options&quot; then dbname <cr>

If the -o option is omitted, it will create a dbname.exp dir in the current directory.

So If I'm exporting a DB called JACK, I'll create a dir called JACK and I'll cd to JACK. I'll execute dbexport in the JACK dir and, because I did not use the -o option, dbexport will create a dir called JACK.exp.

I'll give it a try using the syntax that you suggest but I don't think it's my solution because the export will abend in 5 minutes, after 30 minutes, or after an hour of writing in JACK.exp.

It's entirely arbitrary when it abends.

Regards - Mike

 

[vpshriyan]

Hi Mike,

You are right about the syntax part. Thanks for your enlightenment on this subject. I am bit wary about the -c switch perhaps you may try to export without specifying it, so that if any non-fatal related issues are involved let it come to the surface.

Here is what guide says about the -c switch:
-c Makes dbexport complete exporting unless a fatal error occurs. Even if you use the -c option, dbimport interrupts processing if one of the following fatal errors occurs:
. Unable to open the tape device specified
. Bad writes to the tape or disk
. Invalid command parameters
. Cannot open database or no system permission

Regards,
Shriyan
&quot;The hidden flaw never remains hidden.&quot;

 

[mjldba]

Hi Shriyan,

Thanks for your input.

Hope I did not offend you with my reply, it was not my intention. You're a great source of information & you're always ready to generously share your knowledge.

The IDS training I've had is limited to strictly what I've read & that which others have shared with me, otherwise I learn the hard way by making mistakes. A little knowledge is always more dangerous than no knowledge at all because it gives you the confidence to plow-ahead & usually make matters worse.

If the docs say &quot;do it this way&quot; who am I do doubt the IBM/Informix IDS documentation.

Anyhow, I tried your suggested syntax and executed dbexport four times & it failed all four times in the usual fashion; sometimes with a 25587 error & sometimes with a hung telnet session but nothing is written to online.log.

Regards - Mike

 

[vpshriyan]

Hi Mike,

Humm... I did not found offended with your reply in the first place itself, so the rest is very clear. We are all here to share the knowledge, information, help each other and solve problems etc. I really appreciated your sensitivity and recognize it with gratitude.

One more exercise I would suggest that you to fire the dbexport from the server console instead from a telnet session of a client machine. Also you may divert the output to a different location lying at a different disk.

Please also lookout for the system status while export is in progress using OS level utilities like sar, iostat, netstat etc. Look for any bottlenecks at the results from these utilities. Perhaps you may need to change system call and network related kernel configuration parameters at OS level. You may have to take guidance/opinion from an OS admin in this respect.

Regards,
Shriyan