Error while performing database dump

[DilipVoora]

Hi Experts,

We have scheduled a full database backup everyday at 19:30 on SDA server. However, today it got failed with the below error.

Error:

version=221, API routine=syb_write(), Message=syb_write: Unable to write object.        Run "omnidb -session 2016/02/25 0118 -report"    to get error details.

Feb 25 19:46:33 2016: Backup Server: 4.188.1.1: Database SDA: 55614648 kilobytes (64%) DUMPED.

Feb 25 19:46:33 2016: Backup Server: 4.124.2.1: Archive API error for device='ob2syb::HEC_VLHECSDADB_SDA::000': Vendor application name=Data Protector A.09.00, Library version=221, API routine=syb_write(), Message=syb_write: Unable to write object.        Run "omnidb -session 2016/02/25 0118 -report"    to get error details.

Feb 25 19:46:34 2016: A00: SYBMULTBUF ERROR: Emulator interprocess communication failed with error state = 16, error code=32, system message=Broken pipe.

Feb 25 19:46:34 2016: D00: SYBMULTBUF ERROR: Emulator interprocess communication failed with error state = 9, error code=0, system message=Pipe I/O returned 0 bytes.

Please provide your valuable input on this to get out of this situation.

NOTE: My understanding on this error is "dump failed because the size of the database file become too large and it has to be dumped on stripes(as of now we are not using any stripe)

Regards,

Dilip Voora

SDA Backup error.txt.zip

[bart_van_kuijk]

Hi Dilip

When posting here, please always include the ASE version used as this provide vital information that is almost always relevant.

The output includes : "Data Protector" so it seems you use a HP backup utility and from that it seems feasible you are running ASE on HP OS with an SAP application.

The messages point to a known issue :

KBA 2099194 - SAP ASE Backup Server on HP-UX may die with error messages: A00: SYBMULTBUF ERROR: Emulator interprocess communication failed with error state = 1

http://service.sap.com/sap/support/notes/2099194

There is no workaround for this. Fixed from these releases :

SAP ASE 15.5 ESD 5.4

SAP ASE 15.7 SP63

SAP ASE 15.7 SP130

SAP ASE 16.0 SP01

KR

Bart van Kuijk

[DilipVoora]

Hi Bart van Kuijk,

We are using ASE-16_0 on Linux SuSE 11.3 but not on HP-UX. From the log we understood that it is unable to write the object on disk while performing database dump. So, with that we are under an impression that the write permissions on disk got disturbed while performing the action.

Can you please let me know whether our understanding is correct or not? If not is this issue going to get fixed in future?

Regards,

Dilip Voora

[bart_van_kuijk]

Hi Dilip

Ok, if that KBA is not that issue, then the most likely cause is simply that the dump process got interrupted. I don't think it is a write permission issue. This is indeed a large size database to dump to a single stripe. The longer it runs, the bigger the chance that something will happen, but this would be an external factor of some sort. Judging by the message, it is network related (Broken pipe) :

Emulator interprocess communication failed with error state = 16, error code=32, system message=Broken pipe.

The output also points to this command  to get error details :

Run "omnidb -session 2016/02/25 0118 -report" 

Does that provide any more clues to a cause ?

As this looks like a one-off , I do not believe there is an ASE / BS issue here.

Kind regards

Bart

[DilipVoora]

Yes, there is some connectivity issue at storage/ OS end and today our backups got completed successfully. Thanks a lot for your response.

-Dilip Voora

[Former Member]

Dilip,

I completely agree with Bart on this one. the "broken pipe" is usually sinonymous with an interrupted, or, more plainly put, terminated process.

So, it looks like the process got interrupted, and there can be a number of reasons why this would have occurred.

I would just monitor, and if this happens again, then, research more deeply. In the meantime read up on SYMULTNUF processes.

If I recall, Backup Server spawns one SYMULTBUF process per stripe per DB... I have not looked at the internals since 2002, so, my information might be dated, but it will give you something to look into in the documentation.

Usually when there are SYMULTBUF errors, it means that you are running out of file descriptors at the OS level to start another process? There were two many concurrent dumps, or you were stripping too agressively.

My two cents.

Regards,

Jean-Pierre

P.S. Of course, paranoid me, could think somebody just did a kill -9 on the thread! LOL