MaxDB 7.7 Patch / Upgrade Error: IO Error

[Former Member]

Hi Experts,

we are running a MaxDB Version 7.7.07.14 on Windows 2003 x64 (Development system). More than 2 years ago the database was patched from 7.7.6.10 to 7.7.7.14 without errors (according to the install.log) and is currently running fine (as far as we can tell).

During a MaxDB Patch Installation (up to 7.7.07.42) or a Upgrade (up to 7.8.02.30) I receive an IO Error during db_online. db_admin is working fine. The DATA-Files are located on a normal (VMware-) hard drive (no NFS or similar), so I do not see why a volume should be inaccessible.

The following is contained in the knldiag-File:

<MSG _NO="2" _TYPE="Error" _ID="3" _COMP="IOMan" _TEXT="An error
occurred while accessing a volume">
     _FILE="IOMan_Volume.cpp"
     _LINE="873"
     _TIME="2012-09-05 16:49:09.259"
     _MESSAGEVERSION="1"
     VOLUME_TYPE="data"
     VOLUME_ID="6"
     BLOCK_NO="2"
     NUMBER="2"
     ERRORTEXT="io error"
     NUMBER1="7"

What I did as preparation:

1. Delete BW TMP Views
2. Checked for BAD Indices: None
3. DB_CHECK in DB13, RC=0
4. Stop SAP System (NW 7.01 BW)
5. DB_CHECK in Admin-Mode, RC=0
6. Deleted volumes / created fewer bigger ones (because I already tried patching some time ago and I received the same error in a different volume; so the erroneous data (if I may say so) is moved within the volumes)
7. Started SDBUPD

I'd like to know what I can do to get rid of this error.

The error is reproducible as it always occurs during update/upgrade on this system. I can always reset the system to the original state.

I read something in a SAP Note about x_diagnose to analyze defined sectors but I don't know how to use it or how to get the information I need out of the error description. I also hold the diag_pack.tar.gz containing the different files for diagnosis in case you need more (specific) info.

Regards

Michael

[former_member229109 · Accepted solution]

Hello Michael,

it will be helphul to check the converted KnlMsg file.

As you are able to see the SAP notes, you are SAP customer. Correct?

Did you create SAP message where this issue reported?

Regards, Natalia Khlopina

[Former Member · Accepted solution]

Hi Natalia,

I am a SAP Customer.

I already opened a SAP message (No 811102) but as experience teaches it is also very helpful to ask the SAP Community

As I said I created the diagpkg.tar after the unsuccessful update and have access to the KnlMsg File.

The lines after successful db_admin do not explicitly show errors, except maybe:

Rst           11:	672 redo transactions readable and 13 redo tasks available.
	DESCRIPTION:
	It may not be a problem if fewer redo tasks are available for a restart than user tasks are possible. However if it is a problem, then the parameter MAXSERVERTASKS must be increased.
	ACTION:
	The parameter MAXSERVERTASKS should be increased.If the problem remains then contact development support.

The error message itself comprises of the following:

RTEIO         15:	I/O job 6 reported status failed during synchronous execution,_FILE=RTEWrapper_VolumeIO.cpp,_LINE=915
RTEIO         26:	synchronized I/O returns result code:87,ERRORTEXT=The parameter is incorrect.
	DESCRIPTION:
	A synchronized I/O provided the result 87 (The parameter is incorrect.).
DBCRASH 18196:	vabort:Emergency Shutdown, IOMan_Volume.cpp: 667
TASKING 19821:	Thread 2060 starting
IOMan 20029:	EMERGENCY SHUTDOWN,_FILE=IOMan_Volume.cpp,_LINE=667
IOMan          3:	An error occurred while accessing a volume,NUMBER1=5,ERRORTEXT=io error,NUMBER=2,BLOCK_NO=8,VOLUME_ID=4,VOLUME_TYPE=data,_FILE=IOMan_Volume.cpp,_LINE=713
	DESCRIPTION:
	An error occurred during a write or read access to the 'data ' volume with the ID '4' at position '8' with ' 2' page(s). The reported cause of the error was ' io error '.
RTEKernel     61:	rtedump written to file 'rtedump'
RunTime        3:	State changed from ADMIN to ABORT

As you can imagine I'm sitting on a lot of information

Regards

Michael

[Former Member · Accepted solution]

Okay, I have more inormation:

I made a complete Backup of the database because I wanted to have a copy of the database for testing.

During import of the backup into a fresh install of MaxDB 7.7.07.15 on Win2003 x64 I got a different, but somehow related error message and even a related file "Recoveryxxxxx.bad" was created.

RESTORE

52024:  3472200 pages <- "F:\SID_DATA"

ERR RESTORE

52014:  bad page type 91

ERR RESTORE

52015:  bad page (wrong page type) 999298360

So I guess we have corrupt data within the database... I just wonder why a .bad-file is not created during DB-Upgrade as it might help for x_diagnose (according to Note 839333)

Any comments, good or bad news on this?

Regards

Michael

[former_member229109 · Accepted solution]

Hello Michael,

First case:

Could you restart the database online after you will change the value of the parameter

UseFilesystemCacheForVolume from YES to NO.

I would recommend the operation of the database without the file system cache.

Usually the database runs with a better I/O speed and more secure.

Check the recommendation in SAP note 1004886 < 32. >.

Second case - last reported:

I recommend to create new message & attach new  diag_pack.tar.gz set of the database target logs.

Give more details on steps you run.

Attach the dbm.knl - backup history -  of source and target DB.

I understood that backup created successfuly in source database. Correct?

What is the type of backup?

Was you able to move the backup from one server to another server successfully?

Did you create the same backup template to use for restore as you had for the backup creation?

Regards, Natalia Khlopina

[Former Member · Accepted solution]

Hi Natalia,

Note 1004886 mentions this parameter in UNIX-section; that's why I disregarded it.

After setting this parameter to NO the upgrade to 7.8.02.30 runs fine. Thank you

btw, the backup seems also faster now (...CacheForBackup)

The second case was maybe due to several problems at once:

1. corrupt backup after copy over network (solved by split rars with checksum)

2. possibly different backup template parameters (double checked)

after that the recovery worked fine.

thank you. problem solved, sap note closed

BR

Michael