cancel
Showing results for 
Search instead for 
Did you mean: 

Un-stable MAX DB after defrag

Former Member
0 Kudos

My NWDI 2004s's MAXDB has become unstable after doing the defrag on my PC; Windows XP Pro with 2GB RAM. NWDI starts but the MAXDB stops after a while. Is there anyone with same issues? While doing the defrag, the database for MAXDB wasn't able to be defrag. It will skip the files, DISKD0001and DISKD0002, in the folder C:\sapdb\J7E\sapdata. So I shut down the database but the defrag still will not work. Is there anyother way to defrag the MAXDB? Or does anyone know hot fix this issue?

Accepted Solutions (0)

Answers (1)

Answers (1)

lbreddemann
Active Contributor
0 Kudos

Hi Kyo,

what exactly do you mean with "unstable"?

Are there any error messages in the knldiag(.err) file?

Concerning reorgnization:

It's clear that the DATAVOLUMES cannot be defragmented while the database is up and running. We lock the files - that's why.

As soon as the database is down, the VOLUMES are not locked anymore; at least not by the database.

Anyhow, defragmenting the DATAVOLUMES is rather unlikely to provide any benefit.

All pages in the DATAAREA are striped evenly over all files and (with the exception of liveCache and BW-featurepack) the biggest continuous allocated area is: 1 page (8K).

So with a standard NTFS Cluster size of 4K you will at worst end up with 2 I/Os for one page instead of 1 and that can only happen, if the "breakline" between two file fragments is just within such a 8K page.

Please save your time and I/O capacity and don't defragment the database on file system level.

KR Lars

Former Member
0 Kudos

Thanks for your reply. It's very informative. The status of my J2EE goes into "Starting framework" from "Running". This happens when I try to log into SLD or DEVINF or Visual Admin.

And when I check the config tool the DB is down. Using services, I re-start the DB then I can re-login to config tool and re-start the J2EE.

Here's the developer trace where I've found the following section to check the Java VM and a OSS note. Maybe this will fix it.

"Suspend Checker Thread" prio=10 tid=0x00f010c0 nid=0x2d64 runnable

[Thr 11084] JLaunchIExitJava: exit hook is called (rc = 666)

[Thr 11084] **********************************************************************

      • ERROR => The Java VM terminated with a non-zero exit code.

      • Please see SAP Note 943602 , section 'J2EE Engine exit codes'

      • for additional information and trouble shooting.

**********************************************************************

[Thr 11084] JLaunchCloseProgram: good bye (exitcode = 666)

Former Member
0 Kudos

Finally figure it out. The MAX DB's data was Max'ed. Createing a new data volumn fixed the issue.