MaxDB 7.7 - "I want my knldiag back"

[Former Member]

Is there any way in MaxDB 7.7 to switch back to the normal logging? Having to deal with external programs and/or dbmcli syntax to check logfiles is VERY inconvenient and counterproductive to the propagated "easy" database administration.

XML may be nice for programmers to "parse" but a human readable file is far easier to handle.

And no, I don´t think it´s just a thing to get used to. If one deals with different versions (7.3, 7.5, 7.6 and now 7.7) it´s something that will confuse only, especially if there´s more than one person affected.

No offense but that decision is certainly not a good one.

Markus

[ivan_schreter]

Hi,

There was a question about checking progress of long-running tasks like volume formatting.

FYI, there is a new console command "SHOW IOPENDING" (at least since 7.7.04), which displays currently-running and shortly completed I/O operations, including progress. So when formatting, you see the formatting is currently at block X out of total Y. If several volumes are formatted in parallel, you see several entries. For already-completed formats (when formatting serially), you'll see couple of completed format I/Os as well. This is much easier to use than looking into log files and I hope you'll like it

Regards,

Ivan

[torsten_strahl]

Hello Markus,

Yes of course it is worth to do it!

I can understand your antipathy for the new KnlMsg layout, because itu2019s something new and you have to convert this pseudo XML (pseudo because itu2019s no valid and well-formed XML) to get a human readable version. So itu2019s more difficult than in the past.

But you should think about the new opportunities we have with this layout.

Lars mentioned the BadDataPage handling which is a good example. Caused by the structured output we are able to search for runtime parameters like a root page number and then we can provide the name of the table or the index which should be checked. Maybe be can execute a check statement immediately if this feature is configured by the customer.

Do you remember all the discussions in the past about the quality of the messages within knldiag file? The guys complain about the bad English and about the short messages. From my own experiences I can tell you that itu2019s very hard to describe in 40 characters that a temporary defect occurs in the data cache and how to react on that. And itu2019s nearly impossible to provide all important runtime variables to be able to analyze the situation.

And do you remember all the discussion about the parsing of the knldiag file and the people who complained about the changed layout of a short text or about two or three additional blanks in a message text which let their parser run into nirvana?

I am tired about all these log files like knlmsg, dbm.prt, trace.prt, xserver.prt appldiag etc. Who on earth should know all these files and when I have to take a look into which file? I want a database viewer which combine all these files and helps me to find the root cause of a problem independent were the needed information is stored. And if a defect is detected I want a detailed description and if possible a proposal how to solve the problem. Therefore I need a more structured log file!

If you really want to use your own scripts because you want to monitor the volume format process you have to search for the appropriate XML tags (_ID, _COMP) in the pseudo XML KnlMsg file and then you can search exactly for these tags within your script. In contrast to the old knldiag file we can guarantee the validity and uniqueness of these XML tags. But nevertheless my expectation is that the database UI shall support such a progress indicator for all long running tasks within MaxDB like CheckData, CreateIndex, DropDataVolume etc.

Of course we are at the beginning of that process and there will be errors in the future and people will say u2018thatu2019s all shitu2019 but finally I really think that we are on the right track.

Nevertheless I have to say that the rollout process was not so good and therefore we decide a couple of month ago to write a special SDN article about the new format and all the open questions like how can I transform a KnlMsg file and were come the detailed messages from shall be covered. Then you will understand why itu2019s no good idea to have a database configuration parameter to switch on the old knldiag style. Unfortunately we are still writing.

Regards,

Torsten

[markus_doehr2]

Hi Torsten,

thank you for your time commenting on this.

I can understand your antipathy for the new KnlMsg layout, because itu2019s something new and you have to convert this pseudo XML (pseudo because itu2019s no valid and well-formed XML) to get a human readable version. So itu2019s more difficult than in the past.

Well - as I said, it´s not a "get-used-to-it" thing, it´s plain ugly. Thanx God one doesn´t need (yet) a .dtd to read it...

But you should think about the new opportunities we have with this layout.

<...>

I am tired about all these log files like knlmsg, dbm.prt, trace.prt, xserver.prt appldiag etc. Who on earth should know all these files and when I have to take a look into which file? I want a database viewer which combine all these files and helps me to find the root cause of a problem independent were the needed information is stored. And if a defect is detected I want a detailed description and if possible a proposal how to solve the problem. Therefore I need a more structured log file!

I have seen that (sorry) crap in Web-As Java (just start a logviewer on any AS-Java) and it would be the first thing I would "rm -rf". "Logs" should just be that - text human readable logfiles, not something that need to be "parsed" through whatever interpreter. You´re telling me I need to install a 250+ MB RAM consuming application to read a logfile? Imagine if every application in the SAP world do that...

I´ve not yet been able to install DBStudio. We use central terminal servers for those management applications and that doesn´t work either so until now I´m pretty lost with our scripts...

But nevertheless my expectation is that the database UI shall support such a progress indicator for all long running tasks within MaxDB like CheckData, CreateIndex, DropDataVolume etc.

That would be nice - but would this work also when the task is started "externally"? Remember: Customers use in most cases sapinst to e g. install the instances, not any kind of DB(M)-whatever...

Of course we are at the beginning of that process and there will be errors in the future and people will say u2018thatu2019s all shitu2019 but finally I really think that we are on the right track.

Maybe... but until then one should not have switched knldiag off and tell customers to "live with it until..." (just my personal opinion).

Don´t take this personally or as offense. I´m just a bit mad about 7.7. Parameter names and (what´s worse) parameter semantics changed, now also the logfiles - all that makes administrating systems pretty cumbersome, it´s like learning a completely new software. It broke a lot of our scripts, it takes me 2 -3 times longer to get the system to a state, where I can tell users "I´m ready".

Markus

[thorsten_zielke]

Hi,

just adding to Torstens comment:

"Nevertheless I have to say that the rollout process was not so good and therefore we decide a couple of month ago to write a special SDN article about the new format and all the open questions like how can I transform a KnlMsg file and were come the detailed messages from shall be covered."

FAQ was finished some months ago, but I had not released it due to some HTML editor formatting issues. After reading this conversation I am gladly taking the opportunity of announcing the "HowTo - New knldiag Message File Format in MaxDB 7.7" guide to be available in SDNs MaxDB 'HowTo' section.

However, this will not help Markus in getting his knldiag back, it just describes the new additional steps necessary for converting the knldiag files to plain text...

Thorsten Zielke

[lbreddemann]

Hi Markus,

if you like this kind of development with MaxDB, you'll love the not-there-anymore-Alert.log of Oracle >=11g.

(see metalink 438148.1 on that...)

Anyway - full ack. I'm not keen on the new format either.

I just hope that the possibilities that come with this format can be turned into some nice features.

I'd really like to see that you get a nice dialog window in DB Studio for any error in KNLMSG including with some indication of what the error is about, what to do about it and where more information will be available.

E.g. the BAD PAGE error message that just prints out some dull root/file_id/page_no would be very easy to improve with an automatic lookup of the affected db object and an indication what to do with it.

just my two pence ...

regards,

Lars

[markus_doehr2]

Hi Lars,

if you like this kind of development with MaxDB, you'll love the not-there-anymore-Alert.log of Oracle >=11g.

(see metalink 438148.1 on that...)

I see there:

Beginning with Release 11g of Oracle Database, the alert log is written as both an XML-formatted file and as a text file, as in earlier releases

So see my comment to Natalias answer it would be GREAT.

I just hope that the possibilities that come with this format can be turned into some nice features.

I'd really like to see that you get a nice dialog window in DB Studio for any error in KNLMSG including with some indication of what the error is about, what to do about it and where more information will be available.

Well - until now I wasn´t able to install and use it but in a training at ISZ (Building 6?), all my installations here didn´t work for one or for another reason. It´s a huge bloated application with many nice features but I´m more a purist, I prefer much more the direct way instead of switching from keyboard to mouse back and forth

Markus

[former_member229109]

Hello Markus,

Please review the SAP Note No. 1167164.

The KnlMsg* could be displayed using the standard tools :

DBMGUI, Database Studio, LC10 or DB50 on SAP R/3 system.

And if you would like to review it without standard tools, you could convert the diagnosis files manually & have the knldiag file, as you wanted. For example, switch to the database RUNDIRECTORY &

run ' protconv -o knldiag.txt'. Tool protconv located in the <IndepPrograms>/bin.

Thank you & best regards, Natalia Khlopina

[markus_doehr2]

Hi Natalia,

And if you would like to review it without standard tools, you could convert the diagnosis files manually & have the knldiag file, as you wanted. For example, switch to the database RUNDIRECTORY &

run ' protconv -o knldiag.txt'. Tool protconv located in the <IndepPrograms>/bin.

Thank you for that Info - I wasn´t aware of that. I´m sure it´s "somewhere" in the documentation.

If that is so easy to do, why can´t there be a parameter to "EnableKnldiag" = YES who does that? How do I do things like

grep -10 current knldiag

if I need to do an additional step?

sigh

Regards,

Markus

[former_member229109]

Hello Markus,

1) So far I don't know about this parameter & will discuss your point with database developers.

2) But please let me know why you could not run in your script the command:

/sapdb/programs/protconv -o knldiag.txt

u2026 then run grep on knldiag.txt

< See 'protconv -h' >

3) Please also review the documentation:

http://maxdb.sap.com/doc/7_7/default.htm -> Glossary -> Kernel Log File

You could also use file_getfirst dbm command to display the KnlMsg file & write it to the knldiag file, if you wanted.

Thank you and best regards, Natalia Khlopina

[markus_doehr2]

1) So far I don't know about this parameter & will discuss your point with database developers.

That was a proposal Thank you!

2) But please let me know why you could not run in your script the command:

/sapdb/programs/protconv -o knldiag.txt

u2026 then run grep on knldiag.txt

If you want to do this repeatedly (such as checking the formatting progress when creating databases) it´s very cumbersome to first change the log format to something readable and then grep it. If you want to do this 20 - 30 times when you create huge databases it´s... well... not convenient

3) Please also review the documentation:

http://maxdb.sap.com/doc/7_7/default.htm -> Glossary -> Kernel Log File

Thank you!

My point is not, that it can´t be done but this rather seems to me like "why do it simple when it can be done complicated"?

I mean, I´m one customer who wondered where the logfiles were, imagine if only 10% of the other customers running MaxDB databases for a long time are also wondering, where their knldiag is. You will get lots of additional support calls because people are used to look for errors in that file. All current threads in the MaxDB forum point people to look in that file in case of a problem, in many notes that is written (as of now I find 202 notes which have to be potentially conditionalized) . Is it really worth that confusion?

Markus