W1 1 traces are active!

[Former Member]

We are currently running MaxDB 7.7.04.29 on Red Hat Linux 5.1 for our BW instance.

The output of DBAN.prt gives me "W1 traces are active!" message.

I looked at the Database Trace settings via tx: DB50 and they all say trace is switched off.

I also reviewed OSS Note 837385 under item 11, to deactivate.

Any ideas ?

[roland_mallmann]

Hi,

can you please show us the output of the following DBMCLI command:

dbmcli -d <DBSID> -u <dbm-user>,<pw> info STATE -d

Regards,

Roland

[Former Member]

See below ...

dbmcli -d BWP -u control,<pw> info STATE -d

OK

END

SSNNNNNNNNNNNNNNNNNNNNNSSSSSSNSNNN

Name | Value

Data (KB) = 87358024

Perm Data (KB) = 87355608

Temp Data (KB) = 2416

Data (Pages) = 10919753

Perm Data (Pages) = 10919451

Temp Data (Pages) = 302

Data (%) = 90

Perm Data (%) = 90

Temp Data (%) = 0

Log (KB) = 6888

Log (Pages) = 861

Log (%) = 0

Sessions = 35

Sessions (%) = 47

Data Cache (%) = 100

Converter Cache (%) = 0

Data Max (KB) = 96597648

Log Max (KB) = 1996096

Data Max (Pages) = 12074706

Log Max (Pages) = 249512

Sessions Max = 75

Database Full = No

Connect Possible = Yes

Command Monitoring = Off

Database Monitoring = On

Kernel Trace = Off

Autosave = On

Bad Indexes = 0

Log Full = No

Bad Devspaces = 0

Data Cache OMS (%) = 0

Data Cache OMS Log (%) = 0

[roland_mallmann]

Ok, thanks!

Can you now please show me the entry (including date & time) from the dban.prt interval 0 from today?

Regards,

Roland

[Former Member]

Ok, this is a bit irksome ... looks like the trace message went away. I suspect it must have been cleared

because we bounced our MaxDB and SAP instance yesterday in order to affect an increase in cache memory size via MaxDB parameter CacheMemorySize.

So this leads me to believe that although we turned off tracing it doesn't reflect in the DBAN.prt log file until we bounce MaxDB. Is that a correct assumption ?

===== #44 at 2009-06-11 00:09:26

• I Database Analyzer configuration file dbanalyzer77.cfg, version 7.7.04 Build 029-123-196-543

CON: 1 == 1

VAL: 1 == 1

• I Number of logical CPUs: 16, physical CPUs: 8, processor type: x86_64

CON: NUM_LOGICAL_CPU > 0 && NUM_PHYSICAL_CPU > 0

VAL: 16 > 0 && 8 > 0

• I Configuration: number of CPUs (MAXCPU): 8, max user tasks: 75

CON: 1

VAL: 1

• I Physical memory 31696 MB, virtual memory 20481 MB, memory allocated from instance: 4877 MB

CON: PHYSICAL_MEMORY > 0

VAL: 31696 > 0

• I Operating system: Linux 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT 2007

CON: 1

VAL: 1

• I Kernel version: Kernel 7.7.04 Build 029-123-196-543

CON: 1

VAL: 1

• I Instance BWP (sdcbw03) is up since 2009-06-10 13:04:42

CON: 1

VAL: 1

• I Number of data volumes: 11

CON: 1

VAL: 1

• I SQL commands executed: 4067

CON: SQL_Cmds > 0

VAL: 4067 > 0

• W1 Number of tables where update statistics is required: 8

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SAPBWP, table: /BIC/B0000533000

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SAPBWP, table: /BIC/B0000583000

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SAPBWP, table: /BI0/PMATERIAL

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SAPBWP, table: /BI0/PPRODUCT

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SAPBWP, table: /BIC/EZIC_CA1

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SAPBWP, table: /BIC/B0000156000

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SAPBWP, table: /BIC/FZIC_C01

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• W1 Owner: SUPERDBA, table: AUTHORIZATION

CON: NUM_SYSUPDSTATWANTED > 0

VAL: 8 > 0

• I Size of data cache 3855.06 MB, used data size in instance 85378.3 MB

CON: DATA_CACHE_SIZE > 1

VAL: 3947584 > 1

• I Number of clustered tables: 595

CON: NUM_CLUSTERED_TABLES > 0

VAL: 595 > 0

===== #44 at 2009-06-11 00:09:26

• I CPU utilization: instance BWP: 0.55% (usr: 0.44%, sys: 0.11%) host: 23.45% (usr: 15.71%, sys: 7.74%, idle: 1496.57%)

CON: ProcUserTimeSec + ProcSystemTimeSec >= 0

VAL: 4 + 1 >= 0

[roland_mallmann]

Hi,

well, the first DBAnalyzer interval ('0') collects general information of the db instance and will also display whether the database trace is active. This first interval is triggered either daily or whenever the DBAnalyzer is restarted.

The most obvious reason would be that the database trace was still active during the DBAnalyzer collection of interal 0 on that specific day. After you switched off the trace, only the subsequent interval 0 will not show the message again (that the trace is active).

Regards,

Roland