DBA:Verify and dbanalyzer

[Former Member]

hello friends,

affect does that switch off “dbanalyzer” during the activity “verify”?

####

Datenbankversion Kernel 7.6.01 Build 016-121-149-948

DBM-Server-Version DBMServer 7.6.01 Build 016-121-149-948

Betriebssystem Windows Server 2003 family

thanks.

christoph

[lbreddemann · Accepted solution]

Hi Christoph,

I'm not actually sure what the question is.

Anyhow, the DBAnalyzer is a external monitoring application that has no impact to a CHECK DATA operation within the maxdb.

It will run when you do the CHECK DATA, it will run when a backup is done and also when statistics are gathered. It just takes its snapshots every now and than and that's it.

Hope that answers your question.

KR Lars

[Former Member · Accepted solution]

hi lars,

ok - thanks. why dban one starts automatically, if sap is started? how can I avoid this? In DB59 / integration data - i see the point "activate with the start sap system" i can't disable this point. i think the performance is better without dban. we dont need it necessarily. with db transactions lasts that determine the version data for a very long time. what can I do?

thanks,

christoph

[lbreddemann · Accepted solution]

Hi Christoph,

to answer your questions briefly:

- Yes, the Automatic Start of DBAnalyzer is setup in the DB59 Integration Data. You can change this if your user has the correct permissions and if you are in change mode.

- Actually the Performance of the database should not suffer too much from the DBAnalyzer. With the default snapshot intervall it gathers performance data every 900 secs (15 mins). Since the queries are well defined and do only access special internal views they should not impact the system performance too much.

On the other hand, there is NO WAY to get performance data in a easy to read overview like the one provided with DBAnalyzer. So changes are that you have performance issues and don't realize it because you cannot measure it correctly.

So I would definitively have the DBAnalyzer active all the time on productive instances. I'd rather know where the bottlenecks are than flying blind folded just for the small chance to save a few I/Os and CPU cycles by switching it off.

- The long running determination of the dbversion when you use the DB50/DB59/LC10 transaction are likely NOT database performance issues, but due to the fact that this data is gathered via a dbmrfc-call in the background. This call makes it necessary that the logon data is reread, a rfc connection is started, a dbm-logon to the database is done and finally the data is given back to the SAP transaction. Usually this only takes long the first time you open the transaction.

Anyhow - this is not done when just using standard SAP transactions so it's not performance relevant at all for your business users.

Ok, hope that helps.

Best regards,

Lars

[Former Member · Accepted solution]

> Hi Christoph,

>

> to answer your questions briefly:

> - Yes, the Automatic Start of DBAnalyzer is setup in

> the DB59 Integration Data. You can change this if

> your user has the correct permissions and if you are

> in change mode.

Hm, sorry - this works not. i am in change mode and i am superdba.

>

> - Actually the Performance of the database should

> not suffer too much from the DBAnalyzer. With the

> default snapshot intervall it gathers performance

> data every 900 secs (15 mins). Since the queries are

> well defined and do only access special internal

> views they should not impact the system performance

> too much.

> n the other hand, there is NO WAY to get performance

> data in a easy to read overview like the one provided

> with DBAnalyzer. So changes are that you have

> performance issues and don't realize it because you

> cannot measure it correctly.

>

> So I would definitively have the DBAnalyzer active

> all the time on productive instances. I'd rather know

> where the bottlenecks are than flying blind folded

> just for the small chance to save a few I/Os and CPU

> cycles by switching it off.

yes, i agree with you, but DEV- systems are small sized in this case. there is not so important.

>

> - The long running determination of the dbversion

> when you use the DB50/DB59/LC10 transaction are

> likely NOT database performance issues, but due to

> the fact that this data is gathered via a dbmrfc-call

> in the background. This call makes it necessary that

> the logon data is reread, a rfc connection is

> started, a dbm-logon to the database is done and

> finally the data is given back to the SAP

> transaction. Usually this only takes long the first

> time you open the transaction.

thanks for the info, but db13, Db50 calls always take a long time. I have a patch SP for Max DB executed. now, is the actually version on the system.

Source(MaxDB): 7.6.01 Build 016 Kernel wie auch DBM Server

Target(MaxDB): Build 008(-123-159-187) Kernel wie auch DBM Server

This has brought some points.

>

> Anyhow - this is not done when just using standard

> SAP transactions so it's not performance relevant at

> all for your business users.

thats right.

>

> Ok, hope that helps.

> Best regards,

> Lars

i wish you a nice weekend.

christoph