cancel
Showing results for 
Search instead for 
Did you mean: 

Garbage Data area in R3<SID>400 , System not starting up

Former Member
0 Kudos

Hi Guys,

We are trying to start my R3 Production system after a weekly offline

backup. All of a sudden, the system does not start.

When I check the startup logs it shows :

Job 090237/PRD00/R3_PRD_00 submitted to job queue R3_00 in library

R3PRD400.

Instance 00 for system PRD started.

Data area R3_TJ in R3PRD400 not found.

Data area R3_TJ in R3PRD400 not found.

Also when on the main menu of <SID>OFR, we use option 1-->then option 2,

it shows us:

Output . . . . . . . . . . . . . * *, *PRINT

Additional Parameters

Subsystem . . . . . . . . . . . > R3_TJ Name, *ALL

+ for more values

We don't know from where it is picking up the default subsystem R3_TJ...When we try to start as well the system, it shows us the default

instance number as "TJ" and not as "00".

On further analysis, we found that somehow in the the WRKENVVAR LEVEL(*JOB).

The values for

SAPSYSTEM 'TJ'

SAPDBHOST ' MISC'

We are failing to understand how these value got changed by itself.

Last week the only people who worked on the OS on which this is installed were the MIMIX guys...they worked till Friday and then left and this weekend when our system went down for offline backup and tried to come back up , it failed...

They did some configuration, which we have no idea about..and now my system is not starting.....It is looking at a wrong Data area R3_TJ instead of R3_00, coz of which my system is not starting...

I tried chnaging the values for SAPSYSTEM and SAPDBHOST to the correct values and starting the system, but this time the message server came up, but the dispatcher died down within seconds of coming up...

SAP asked us to apply the latest pacth for the kernel (2307), which i did, but to no success...

The output of dev_disp is as shown:(not much help)

-


trc file: "dev_disp", trc level: 1, release: "46D"

-


Sun Apr 8 14:11:05 2007

relno 4640

patchlevel 0

patchno 2307

intno 0

pid 21072

***LOG Q00=> DpSapEnvInit, DPStart (00 21072) [dpxxdisp.c 923]

MtxInit: -2 0 0

DpIPCInit: start server >SAPPROD_PRD_00 <

MBUF state OFF

MBUF opmode USE

Just posting here, just in case , if anyone has seen this kind of error, as this is a Production system..

Thanks for any advice

Abhi

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

MIMIX V5 now uses the OS ability to enforce journaling at birth by using the QDFTJRN. In this version of MIMIX this is the standard best practice configuration and unfortunately we have found a case where this will not work due to the way SAP is retrieving the information for startup with this kernel.

It is true that there are not any "interesting tables" in the R3sid400 library, but this library could be part of many other libraries defined to a data group that need to be replicated and could benefit from the "journal at birth" OS abilities.

In a best practice configuration for SAP, any libraries that need to be replicated and do not have journaling already implemented would likely end up in the same data group. In this example the R3sid400 library is replicated by data group MISC, but the R3sidDATA library is replicated via a different data group named R3sid. In a MIMIX configuration, if something needs to be replicated and it is not already journaled, we do not journal the files to the R3sidDATA/QSQJRN journal. We do not add or remove files being journaled by the R3sidDATA/QSQJRN.

It can also be argued that the QDFTJRN data area is not needed in the R3sidDATA library as all files created by the SQL processes that SAP uses are already guaranteed to be journaled to the QSQJRN......but I have seen where clients put other files in the R3sidDATA library that do not follow the SQL rules, therefore as a best practice, we will create the QDFTJRN data area in the R3sidDATA library.

What this has taught us is that we should not replicate the R3sid400 library using what we have termed it the USRJRN method of replication, but instead, use the SYSJRN method of replication.

USRJRN = Use the database journal for activity such as authority changes, creation and deletion of files, and also the transactional data level activities such as R-PT, R-PX, R-UP, R-DL.....etc.

SYSJRN = Use the system QAUDJRN for transactions other than pure data level activites. We would still use the database journal for the R-xx activities, but would use "Object Replication" for all other activities.

USRJRN is more efficient, but SYSJRN still has its place.

Had the SAP startup processed the proper data area, there would not have been an issue as seen in the other environments that were at a different kernel level which processed the proper data area for startup.

Former Member
0 Kudos

Hi William,

Thanks a lot for the great explanation. It really helps me/us in understanding what exactly happened and what is being used with MIMIX.

hopefully I will pick this stuff pretty soon... )

and also, I am glad you bought the point where this problem occured only with a specific type of kernel library, something which can be looked into.

Thanks again for the great info.

Abhi

Former Member
0 Kudos

Hi Abhi,

I would say, you are really in bad luck now ...

sorry for that - but from that distance I do not have any clou on the issue.

If you need immediate support, please let me know via mail. Then I would have to logon, because I really not not have a clou here.

The only idea I would think is:

/usr/sap/trans/config/SID/...

There need to be 2 files in - you can compare this one with the other systems and should rename them properly and REALLY delete the other ones, that I expect there ...

Good luck,

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Hi Volker,

Thanks for the response.

I checked in usr/sap/trans/config/PRD and there are only two file there..

1)SAPPROD_00

contents of SAPPROD_00 is :

  1. Created on 20020206120214

#

SAPSYSTEMNAME = PRD

INSTANCE_HOST = SAPPROD

SAPSYSTEM = 00

#

INSTANCE_ROLE = DVEBMGS

#

db4/kernel = R346DEPRD

2)SYSTEM.

Content of SYSTEM is:

  1. Created on 20061209115403

#

SAPSYSTEMNAME = PRD

SAPDBHOST = SAPPROD

SAPMSHOST = SAPPROD

#

db4/kernel = R346DEPRD

db4/dbasp = 1

db4/jrnrcvasp = 2

I have checked the contents and they look fine to me...and are in tune with the other system on my production box.

I have no idea right now...SAP is making me applying kernel patches, which I am pretty sure is not the cause...coz it was running fine till last week( i mean the start up) . This week, if anything would have changed is the MIMIX implementation...

apart from that..i am out of ideas...

Thanks

Abhi

Former Member
0 Kudos

Hi,

as I said, I'm running out of ideas without having a look there :-((

But one for sure: The kernel patch is not the solution - but you still have to do that as you want to participate from the further SAP support.

all the best,

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Hi Volker,

How do we contact you on the email?

what is your email ID??

Thanks

Abhi

Former Member
0 Kudos

Hi Abhi,

obviously you are not reading the yahoo mail, that is attached with your SDN account :-((

You can find my mail adress at:

http://www.4soi.de/gueldenpfennig.php

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Hi

For every command executed as PRDOFR when we use "call qcmd", it shows:

Data area R3_TJ in R3PRD400 not found

When we do an F1 on the above message, it shows the following:

Message ID . . . . . . : CPF1015 Severity . . . . . . . : 40

Message type . . . . . : Escape

Date sent . . . . . . : 04/08/07 Time sent . . . . . . : 16:07:11

Message . . . . : Data area R3_TJ in R3PRD400 not found.

Recovery . . . : Either correct the data area name or change the library

name (DTAARA parameter). Then try the request again.

How do we change the above message(correct data area) so that it looks at data area R3_00 in R3PRD400 & not R3_TJ in R3PRD400....

Any ideas??

Thanks

Abhi

Former Member
0 Kudos

Hi Abhi,

might it be possible, that you overlooked my reply from above ?

...

obviously you are not reading the yahoo mail, that is attached with your SDN account :-((

You can find my mail adress at:

http://www.4soi.de/gueldenpfennig.php

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

0 Kudos

Hi Abhi,

The job environment is set by R3INLPGM on basis of the information in library R3<SID>400. It scans for objects of type *DTAARA and reads their content. Therefore, I suppose you have some data area there which containts the substrings you find in your environment. If so, get rid of it.

If not it would be helpful to see what data areas are in R3<SID>400 and what content they have.

HTH,

Thomas

Former Member
0 Kudos

Hi Thomas,

The only Data area apart from the R3_00 data area in the library R3PRD400 is the MIMIX data area, which was set up this week by the MIMIX guys..and they left on friday....

The data area is

QDFTJRN *DTAARA CREATED BY MIMIX MISC SAPPROD SAPMIMIX

I guess itR3INLPGM maybe looking on this data area and picking up the garbage values as this is mentioned before the R3_00 data area...

Could it be a reason....

Should I delete that...as right now MIMIX is the last thing on my mind....

I have been looking on that data area since today morning but since I do not have any idea about MIMIX... I was not touching it...

But still have been think and compaared it to other systems..and this data area QDFTJRN is the odd man out...

Pls advice it that is the case...

SAP has not answered anything apart from applying patches & transferring me from one support person to the other...going from Gernmany to India to USA...:((

Thanks all

Abhi

Former Member
0 Kudos

Hi Thomas,

I took a back up of this Data area QDFTJRN onto another tmp library and tried deleting it...it goes away and shows me the message that the data area QDFTJRN deleted....after that I log off and log back on..and again this QDFTJRN reappears...

It does get deleted for a while...but guess there is something which makes it reappear...

Mysterious..MIMIX lakeviewtech stuff....:((

Anyway...Thanks for the update...let see If SAP comes up on this and says anything..

Thanks

Abhi

Former Member
0 Kudos

Hi Abhi,

that sounds really interesting ...

This DTAARA is at least desigened for moving all DB journaling to one specific journal and not to lib/qsqjrn ... therefore it is recommended for some DB libararies even from SAP - but definetely NOT for R3sid400 - as there are no interesting tables in.

I have never heard on a technique, that you can configure this somewhere - but this might be a - bad part - of the latest Mimix version ...

See you,

Volker

Former Member
0 Kudos

Hi,

@Thomas & @ Volker:

Thanks a lot for the help...The culprit was that very MIMIX variable , which i have been looking since morning....QDFTJRN (Data Area)...

Once I got the authorization to kill all the MIMX jobs and then go and delete the data area QDFTJRN from r3PRD400...

everything returned back to normal.........the SAPSYSTEM & SAPDBHOST etc...

no garbage character...

Surprisingly, The lakeviewtech Guys also did not return my call....the very ones who did this a couple of days ago...and they call it HA...:))

Thanks a lot guys for all the guidance...

SAP did not have supposedly today any DB2 guys on call, was what the SAP manager told me..:))

But no complaints...happens...evrerything is golden now...supposedly they implemented the latest version of MIMIX(version 5.0)..at our place...

So i would advice everyone to look out for this configuration...

Thanks guys

Had a long day...

Abhi

Former Member
0 Kudos

Hi Guys,

Just an interesting observation on the whole episode..

The Data area QDFTJRN causes probelm only in a 4.6C kernel...because I have two other systems as well, which are 6.20 & 6.40 both running a 640 kernel...and they did not have any issues starting up, inspite of the fact that they did have multiple data areas in R3<SID>400 library...Their environment still got initialized properly...

Don't know why..but just a thing to ponder about...

Will let you guys know if I hear anything from lakeviewtech...

Thanks again all

Abhi

Former Member
0 Kudos

Hi Guys,

Did I mention that I got a call from Lakeviewtech(MIMIX guys) that very night on Sunday...They were of great help in understanding the issue I went thru and they have made a point to incorporate those changes in future.

Right now the product is running absolutely fine...and we are loving it...

The MIMIX or Lakeviewtech tech has been superb in helping us out resolving the problem...The new product really rocks!!!

Thanks

Abhi