cancel
Showing results for 
Search instead for 
Did you mean: 

DBMonitor fails; resolution involves stop/re-start

Former Member
0 Kudos

As information/background, I had been the Basis analyst for our 4.0B

installation in the late 1990's/early 2000's. I was away from SAP and

basis for about five years and then returned to it a little over 2

years ago.

While I was away, our SAP system was upgraded from version 4.0B to SAP

R/3 ENTERPRISE 47X110. I was not a part of the upgrade and have no

details as to how it was accomplished.

We are ABAP only, no java.

For the past two weeks, we are experiencing issues where some of the

work processes (WPs) will end abruptly and the instance becomes

unusable. The symptoms are similar to those addressed in Note 1000468

wherein the developer trace files list an error in *LIBL/DBSLDB4RMT.

For now, when the problem occurs (and it only occurs sporadically a few

times a week), we are stopping the instance, issuing command

CALL PGM(QQQCSDBM) PARM('*RESET' '' '')

as per solution 1 in the note, and then re-starting the SAP instance.

This is our production instance so this downtime is impacting our

productivity.

This workaround is, of course, not ideal and we would like to change

the profile parameter as4/dbmon/enable = 0 as per solution 2 in the

note.

(As information, solution 3 is not possible at this time because we are

using the 6.20 kernel. I'm aware that it is old/defective/no longer

supported and we are working on upgrading to kernel 6.40 but it isn't

possible just yet and we must use what we have.)

I haven't changed a profile parameter in many, many years and it

appears to have changed significantly since the 4.0B days. At that

time, the very first thing we would do is save a copy of the profile to

be changed at the operating system level. Then, we would make the

changes using EDTF, import the changed profile and activate it, and

bounce the instance.

My first caution is that the people who performed our upgrade placed a

comment in the profile that as4/dbmon/enable = 1 is a required value

for 6.20.

QUESTION: Is this a true statement?

If 'yes', then we will have to deal with the WPs failing and use the

workaround that we have.

If 'no', keep readingu2026

My second caution is that there are actually five streamfiles listed

in /usr/sap/PRD/sys/profile, two of which are symbolic links:

Object link Type

DEFAULT.PFL STMF

PRD_DVEBMGS00 SYMLNK->STMF

PRD_DVEBMGS00_SERV > STMF

START_DVEBMGS00 SYMLNK->STMF

START_DVEBMGS00_SE > STMF

When issuing RZ10>Utilities>Check all profiles-->Of active servers,

only three are listed:

DEFAULT.PFL

PRD_DVEBMGS00

START_DVEBMGS00_SERVER01

Notice that PRD_DVEBMGS00 is actually a symbolic link!

QUESTION: Will this be a problem when I attempt to make the change to

parameter as4/dbmon/enable?

If 'yes', I will need some guidance on how to correct it.

If 'no', keep readingu2026

I have reviewed the documentation on profiles at

http://help.sap.com/saphelp_470/helpdata/en/c4/3a610f505211d189550000e829fbbd/frameset.htm

The page entitled 'Changing and Switching Profile Parameters' states:

"u2026Changes to profiles are adopted when you save them to the database.

You can subsequently change and switch SAP profile parameters for

instance profiles without having to restart the system."

However, the page entitled 'Saving, Checking and Activating Profiles'

states:

"The profile maintenance tool ensures that changes to profiles are

activated when the corresponding SAP instance is restarted. You cannot

make changes to an SAP instance during active operation."

QUESTION: Which is it? Must the instance be restarted or not?

After reading through all of this "help" data, I'm more confused than

ever. There appears to be a database within SAP that keeps copies of

the profiles and the profile files at the OS level appear to be

superfluous or only backup copies?

Can anyone give me a step-by-step methodology of how to change this

profile parameter?

Any assistance is greatly appreciated.

Robert

Accepted Solutions (0)

Answers (3)

Answers (3)

0 Kudos

Hi Robert,

for the first part you are correct: The names don't have to be lower case, but the names must match when looking at them in a case-sensitive way.

As for SAP Note 82655, I cannot say much. The SAP Note was created in 1997 and did not change much since then. It is even possible that the assigned owner is no longer responsible for the component. If you think the note text is incorrect, you could try to open a ticket for that with the same component as the note (BC-CCM-CNF-PFL). However, it is possible that SAP is considering that kind of question chargeable remote consulting.

Kind regards,

Christian Bartels.

0 Kudos

Hi Robert,

I think you should have a closer look at SAP Note 82655 despite of the fact that it primarily refers to UNIX and NT. On IBM i, we were not used to case-sensitive names, so people did not care to much about upper/lower case in directory and file names. However, SAP does simple string comparison here, so the comparison of profiles is case-sensitive.

Besides the file and directory names, please also check the host name. The "true" host name used by SAP is taken from the setting in CFGTCP option 12 - Change TCP/IP Domain (CHGTCPDMN). If the host name there is specified in lower case, it should also be lower case in the file name of the start and instance profiles. Some more implications are described in SAP Note 60252.

Kind regards

Christian Bartels.

Former Member
0 Kudos

Hi, Christian

I checked note 60252 and we are in compliance insomuch as we have entered the host server name in all uppercase everywhere. The note doesn't suggest that it be specified in lowercase, just that the case be consistent. So, I think we are okay in that respect. Please advise if you agree.

Back to the operations mode: will I need to worry about deleting/recreating it based on the new profiles? The note 82655 is very ambiguous. It uses the word 'instance' but it is unclear as to whether it is referring to the SAP instance or the operations mode instance. Can you clarify this?

Thanks for your help!

Robert

0 Kudos

Hi Robert,

let me try to answer the questions:

Q1: Is it a true statement that as4/dbmon/enable = 1 is a required value for 6.20?

A1: No, this is not a true statement. You can set as4/dbmon/enable = 0. As a result, you will not see any data in transaction ST04 "iSeries: Performance Monitor Overview(new DBMON)"

Q2: ... Notice that PRD_DVEBMGS00 is actually a symbolic link! Will this be a problem when I attempt to make the change to parameter as4/dbmon/enable?

A2: The setup of your profile directory looks a little bit unusual. Usually, the directory /usr/sap/<sid>/SYS/profile is a symbolic link to /sapmnt/<sid>/profile, and the files within the directory are stream files. If your host name is SERVER01, the SID is PRD, and the instance is 00, you should see the following files in that directory (you get the complete name by specifying WRKLNK DETAIL(*EXTENDED) and specifying option 12 in front of the names):

DEFAULT.PFL

PRD_DVEBMGS00_SERVER01

START_DVEBMGS00_SERVER01

optional you can also have:

DEFAULT.BAK

PRD_DVEBMGS00_SERVER01.BAK

START_DVEBMGS00_SERVER01.BAK

For the SAP instance, it does not really matter whether these files are STMF or symbolic links to STMF as long as it can access them. It may only cause some confusion when trying to upgrade the system at some point in time.

Q3: ... Which is it? Must the instance be restarted or not?

A3: Profile parameter as4/dbmon/enable controls whether the database monitor is being activated when the instance starts. Changing the profile parameter to as4/dbmon/enable = 0 controls that the database monitor is not started when the instance is started for the next time. Changing the parameter does not turn off the monitor for work processes that are currently active. In later releases, functions were built into the code to ignore any invalid condition of the database monitor, but at the 6.20 kernel, these are not available.

A general remark: Changes to profile parameters should always be made through RZ10 in order to keep the profiles in a consistent state. Editing profiles directly in the file system (EDTF) should only be done in emergency cases when the instance won't start, so that you cannot access RZ10. When you change parameters directly in the files and later change the same or other parameters through RZ10, all changes that were made in the files directly are lost, because RZ10 maintains a copy of the files in the database. If you are not sure, you could first import the existing files into RZ10, and then make all future changes there. Once in a while you get error messages in RZ10 that profile parameters are "not known", but these can usually be ignored. Many profile parameters are known to the kernel and evaluated there, so it is not really necessary to define them in ABAP. However, if they are not defined in ABAP, you will get an error message in RZ10. This happens quite often for profile parameters that were introduced as some kind of "hack" (quick workaround), but turned out to be useful in general.

Kind regards,

Christian Bartels.

Former Member
0 Kudos

Thanks for the information, Christian. It is very helpful.

Now, I must make an action plan to correct the profile file errors AND modify the profile parameter

'as4/dbmon/enable', changing the value from 1 to 0.

To avoid further confusion now and confusion in the future, I would rather NOT use the symbolic links to the streamfiles. I think it would be best to use the streamfiles themselves, i.e.:

DEFAULT.PFL

PRD_DVEBMGS00_SERVER01

START_DVEBMGS00_SERVER01

This also requires that we change the data within file PRD_DVEBMGS00_SERVER01 to reference the correct file START_DVEBMGS00_SERVER01 rather than its associated symbolic link (START_DVEBMGS00), i.e., change the lines

with $(DIR_PROFILE)/PRD_DVEBMGS00

to $(DIR_PROFILE)/PRD_DVEBMGS00_SERVER01.

I will create a new subdirectory, '/sapmnt/PRD/profile/BACKUP'

1. Adjust the ownership of the new subdirectory to PRDOFR

2. Adjust the primary group of the new subdirectory to PRDGROUP

3. Adjust the authorities of the new subdirectory

I will copy the current streamfiles to the new BACKUP directory. I don't see a need to copy the symbolic links or create new ones.

At this point, we will have backups of the three current profile files at the OS level.

From that point, I don't remember what to do (it HAS been almost eight years since I made any profile changes and that was at a different/lower SAP version).

I know that I need to use transaction RZ10 but beyond that, I am at a loss for direction.

Could you please advise?

Thanks again for your help!

Robert

0 Kudos

Hi Robert,

in RZ10, you have to select a profile name first. You can prompt this selection, based on your information I assume that you have the following names (or similar) available:

DEFAULT

PRD_DVEBMGS00_SERVER01

START_DVEBMGS00_SERVER01

Note that these names do not necessarily match the file names at the operating system level. The following actions need to be repeated for all three of them.

First, you should verify (and change, if necessary) the Administration data of each profile. Here you can set the profile type (instance, default, startup profile) through a radio button, and you can specify the file name at the operating system level.

We don't know if all profile parameter changes in the past have been done through RZ10, or if some changes were done only at the operating system level (EDTF). We know that your system is running more or less fine with the settings at the operating system level, because that is what matters when you start the SAP system. That's why I would suggest to first import the files from the operating system into RZ10. You to that through the RZ10 entry screen by using the Import button. I don't know all the screens that may show up here, but I think it should be pretty self-explaining.

After importing all profiles, you can change some parameters individually by choosing "Extended maintenance" in the RZ10 entry screen. After changing or adding the parameter as4/dbmon/enable = 0, make sure that you save and activate the profile. By activating the profile, the data gets written to the stream file at the operating system level, so that the SAP system can read the data when it is started for the next time. Warnings about incorrect profile parameters can usually be ignored, at least if they affect parameters that you did not change.

I hope this helps.

Kind regards,

Christian Bartels.

Former Member
0 Kudos

Thanks for the information, Christian.

I have one issue, though.

I am showing FOUR profiles in RZ10 that are all showing as "saved, activated":

DEFAULT

PRD_DVEBMGS00_SERVER01

START_DVEBMGS00

START_DVEBMGS00_SERVER01

Obviously, I'll need to remove the START_DVEBMGS00 profile using Profile>Delete>Individual profile. Can you see any problems with doing that considering that it isn't even the current Start profile (it is one of the symbolic links mentioned earlier)?

Thank you for all of your help!

Robert

0 Kudos

Hi Robert,

to be on the save side, you should compare the contents of START_DVEBMGS00 and START_DVEBMGS00_SERVER01 and keep a copy of START_DVEBMGS00 (not the symbolic link, but the file behind it). I think it is a leftover from a previous release, so it should be obsolete in your new system. The name of the startup profile to be used is specified in the STARTSAP command. If the default value (*DFT) is used in 6.20, STARTSAP will first try to resolve /usr/sap/PRD/SYS/profile/START_DVEBMGS00_SERVER01, and if that is not found it will use /usr/sap/PRD/SYS/profile/START_DVEBMGS00.

Kind regards,

Christian Bartels.

Former Member
0 Kudos

Hi, Christian

The data in the START profile files is equivalent because file START_DVEBMGS00 is a symbolic link to file START_DVEBMGS00_SERVER01.

I think that I have another related issue that needs to be considered before I make any changes.

In CCMS, I have the following information:


RZ20
SAP CCMS Technical Expert Monitors
 System / All Monitoring Segments / All Monitoring Contexts 

  System Configuration
    Operation Mode Status
      System Correctly Configured?
        No - All instances active, configuration incorrect
    Instance Status
      SERVER01_PRD_00
        Status
          Active - Inst. opmode, start prof- config differ from spec 

I have found Note 82655 but it doesn't necessarily indicate that it is applicable to OS/400. Should I make this note part of my action plan?

RZ04 shows this information:

                                                               
 Productive operation modes (normal operation)                                                                                
Operation mode         Time             Text                                                                                
24_hr_no_opmode_chg    00:00 - 23:59    24 hour operation mode
                                                                                Operation modes for test or exception operation                                                                                
DUMMY                Self-Configured Operation Mode           
                                                               

Thanks for your patience and your help!

Robert