cstat

There are several versions of "crsctl status resource" command. You can see the most cool version in [1].

In any case I made my personal output.

crsctl status resource  -v |\

      egrep -w "NAME|TYPE|TARGET|STATE|STATE_DETAILS"|\

      awk 'BEGIN {FS="=";

                    printf "%-35s %-20s %-25s %-10s %30s\n", "HA Resource", "Resource Type", "Target", "State", "Details";                    printf "%-73s \n", "---------------------------------   --------------       ---------------------     --------   --------------------------------------------------";}

                  {

switch ($1){
  case "NAME"         :  resname=$2; break;
  case "TYPE"         :  restyp=$2;  break;
  case "STATE"        :  resst=$2;   break
  case "TARGET"       :  restrg=$2;  break;
  case "STATE_DETAILS": {resdet=$2
    idx1=index(restyp , "."); subtyp=substr(restyp , idx1+1);
    idx2=index(subtyp, "."); typ=substr(subtyp, 1, idx2-1)
    # following if is added for grid 12.2
    if (typ=="database" && length($3)!=0) { resdet=resdet"="$3 }
    #
    switch (typ){
      case "appvipx"         : typ="App VIP";       break;
      case "diskgroup"       : typ="Diskgroup";     break;
      case "scan_listener"   : typ="SCAN Listener"; break;
      case "listener"        : typ="Listener";      break;
      case "asm"             : typ="ASM";           break;
      case "cvu"             : typ="CVU";           break;
      case "acfs"            : typ="ASM FS";        break;
      case "oc4j"            : typ="OC4J";          break;
      case "mgmtdb"          : typ="MGMT DB";       break;
      case "cluster_vip_net1": typ="Cluster VIP";   break;
      case "network"         : typ="Network (VIP)"; break;
      case "database"        : typ="Database";      break;
      case "ons"             : typ="Ora Notif Svc"; break;
      case "scan_vip"        : typ="SCAN VIP";      break;
      case "service"         : typ="Service";       break;
      case "volume"          : typ="Volume";        break;
      case "mgmtlsnr"        : typ="MGMT Listener"; break;
     }
     printf "%-35s %-20s %-25s %-10s %-10s\n", resname, typ , resst, restrg, resdet
                                  }; break; }

}'

Because of switch command, it works with awk version >= 4.0.2. If you are using an early version, then you have to change switch command with a if-then-else

crsctl status resource  -v |\
      egrep -w "NAME|TYPE|TARGET|STATE|STATE_DETAILS"|\
      /bin/gawk 'BEGIN {FS="=";
                    printf "%-35s %-20s %-25s %-10s %30s\n", "HA Resource", "Resource Type", "Target", "State", "Details";
                    printf "%-73s \n", "---------------------------------   --------------       ---------------------     --------   --------------------------------------------------";}
                  {
if ($1=="NAME")  resname=$2; else
if ($1=="TYPE")   restyp=$2; else
if ($1=="STATE")   resst=$2; else
if ($1=="TARGET") restrg=$2; else
if ($1=="STATE_DETAILS") { resdet=$2
    idx1=index(restyp , "."); subtyp=substr(restyp , idx1+1);
    idx2=index(subtyp, "."); typ=substr(subtyp, 1, idx2-1);
    # following if is added for grid 12.2
    if (typ=="database" && length($3)!=0) { resdet=resdet"="$3 }
    #
      if (typ=="appvipx" )               typ="App VIP"; else
      if (typ=="diskgroup " )          typ="Diskgroup"; else
      if (typ=="scan_listener " ) typ="SCAN Listener "; else
      if (typ=="listener" )             typ="Listener"; else
      if (typ=="asm" )                   typ="App VIP"; else
      if (typ=="cvu")                        typ="CVU"; else
      if (typ=="acfs")                    typ="ASM FS"; else
      if (typ=="oc4j")                      typ="OC4J"; else
      if (typ=="mgmtdb")                 typ="MGMT DB"; else
      if (typ=="cluster_vip_net1")   typ="Cluster VIP"; else
      if (typ=="network")          typ="Network (VIP)"; else
      if (typ=="database" )             typ="Database"; else
      if (typ=="ons")              typ="Ora Notif Svc"; else
      if (typ=="scan_vip" )             typ="SCAN VIP"; else
      if (typ=="service")                typ="Service"; else
      if (typ=="volume")                  typ="Volume"; else
      if (typ=="mgmtlsnr")         typ="MGMT Listener";
        printf "%-35s %-20s %-25s %-10s %-10s\n", resname, typ , resst, restrg, resdet}
}'

I checked this commands on Linux.


Following there is an output

HA Resource                         Resource Type        Target                    State                             Details
---------------------------------   --------------       ---------------------     --------   --------------------------------------------------
bck.dbCUSCTIp-bk.vip                App VIP              ONLINE on mdapora1d02     ONLINE
ora.DGCUSCTIPDB01.dg                Diskgroup            ONLINE on mdapora1d01     ONLINE
ora.DGCUSCTIPDB01.dg                Diskgroup            ONLINE on mdapora1d02     ONLINE
ora.DGCUSCTIPFS.LVCUSCTIPAK.advm    Volume               ONLINE on mdapora1d01     ONLINE     Volume device /dev/asm/lvcusctipak-156 is online
ora.DGCUSCTIPFS.LVCUSCTIPAK.advm    Volume               ONLINE on mdapora1d02     ONLINE     Volume device /dev/asm/lvcusctipak-156 is online
ora.LISTENER.lsnr                   Listener             ONLINE on mdapora1d01     ONLINE
ora.LISTENER.lsnr                   Listener             ONLINE on mdapora1d02     ONLINE
ora.LISTENER_CUSTCTIP.lsnr          Listener             ONLINE on mdapora1d01     ONLINE
ora.LISTENER_CUSTCTIP.lsnr          Listener             ONLINE on mdapora1d02     ONLINE
ora.LISTENER_SCAN1.lsnr             SCAN Listener        ONLINE on mdapora1d01     ONLINE
ora.LISTENER_SCAN2.lsnr             SCAN Listener        ONLINE on mdapora1d02     ONLINE
ora.LISTENER_SCAN3.lsnr             SCAN Listener        ONLINE on mdapora1d02     ONLINE
ora.MGMTLSNR                        MGMT Listener        ONLINE on mdapora1d02     ONLINE     169.254.62.41 10.52.254.20
ora.asm                             App VIP              ONLINE on mdapora1d01     ONLINE     Started
ora.asm                             App VIP              ONLINE on mdapora1d02     ONLINE     Started
ora.cusctip.db                      Database             ONLINE on mdapora1d01     ONLINE     Open
ora.cusctip.db                      Database             ONLINE on mdapora1d02     ONLINE     Open
ora.cvu                             CVU                  OFFLINE                   OFFLINE
ora.dggenmmpfs.lvgenmmpak.acfs      ASM FS               ONLINE on mdapora1d01     ONLINE     mounted on /dbGENMMp/akGENMMp01
ora.dggenmmpfs.lvgenmmpak.acfs      ASM FS               ONLINE on mdapora1d02     ONLINE     mounted on /dbGENMMp/akGENMMp01
ora.gencmpp.gencmpp_dem1.svc        Service              ONLINE on mdapora1d02     ONLINE
ora.gencmpp.gencmpp_dem1.svc        Service              ONLINE on mdapora1d01     ONLINE
ora.mdapora1d01.vip                 Cluster VIP          ONLINE on mdapora1d01     ONLINE
ora.mdapora1d02.vip                 Cluster VIP          ONLINE on mdapora1d02     ONLINE
ora.mdmcrp.db                       Database             ONLINE on mdapora1d01     ONLINE     Open
ora.mdmcrp.db                       Database             ONLINE on mdapora1d02     ONLINE     Open
ora.mgmtdb                          MGMT DB              ONLINE on mdapora1d02     ONLINE     Open
ora.net1.network                    Network (VIP)        ONLINE on mdapora1d01     ONLINE
ora.net1.network                    Network (VIP)        ONLINE on mdapora1d02     ONLINE
ora.net2.network                    Network (VIP)        ONLINE on mdapora1d01     ONLINE
ora.net2.network                    Network (VIP)        ONLINE on mdapora1d02     ONLINE
ora.oc4j                            OC4J                 ONLINE on mdapora1d02     ONLINE
ora.ons                             Ora Notif Svc        ONLINE on mdapora1d01     ONLINE
ora.ons                             Ora Notif Svc        ONLINE on mdapora1d02     ONLINE
ora.scan1.vip                       SCAN VIP             ONLINE on mdapora1d01     ONLINE
ora.scan2.vip                       SCAN VIP             ONLINE on mdapora1d02     ONLINE
ora.scan3.vip                       SCAN VIP             ONLINE on mdapora1d02     ONLINE
ora.sdcp.db                         Database             ONLINE on mdapora1d01     ONLINE     Open
ora.sdcp.db                         Database             OFFLINE                   OFFLINE

[1] http://blog.enkitec.com/2011/10/my-crsstat-script-improved-formatting-of-crs_stat-on-10g-and-11g/

Update

2017/08/08 - Oracle Grid 12cR2 show some differences with the prvious release.

This is from Grid 12.1.0.2 on a Linux RAC 2 nodes

ora.mdmcrp.db                       Database             OFFLINE                  OFFLINE    Instance Shutdown
ora.mdmcrp.db                       Database             ONLINE on srvora1d02     ONLINE     Open
ora.sdcp.db                         Database             ONLINE on srvora1d01     ONLINE     Open
ora.sdcp.db                         Database             OFFLINE                  OFFLINE    Open

This is from a Grid 12.2.0.1 on Linux Oracle Restart:

ora.fosi.db                         Database             OFFLINE                  OFFLINE    Instance Shutdown
ora.pcii.db                         Database             ONLINE on srvora2d       ONLINE     Open,HOME=/sbRdbms/app/oracle/product/12.1.0.2/dbh01

The new version of Oracle Grid, show now the ORACLE_HOME with which the database is started. So I modified the above script

CPU count (ENG)

• HP-UX (B.11.11)

[oracle]$/usr/sbin/ioscan  -knfC processor |grep processor |wc -l
      8
 
[oracle]$/usr/sbin/ioscan  -knfC processor

Class       I  H/W Path  Driver    S/W State H/W Type  Description
===================================================================
processor   0  4/10      processor CLAIMED   PROCESSOR Processor
processor   1  4/11      processor CLAIMED   PROCESSOR Processor
processor   2  4/12      processor CLAIMED   PROCESSOR Processor
processor   3  4/13      processor CLAIMED   PROCESSOR Processor
processor   4  6/10      processor CLAIMED   PROCESSOR Processor
processor   5  6/11      processor CLAIMED   PROCESSOR Processor
processor   6  6/12      processor CLAIMED   PROCESSOR Processor
processor   7  6/13      processor CLAIMED   PROCESSOR Processor

• Solaris

[oracle]$/usr/sbin/psrinfo |wc -l
      32

[oracle]$/usr/sbin/psrinfo 
0       on-line   since 02/12/2016 09:57:19
1       on-line   since 02/12/2016 09:57:21
2       on-line   since 02/12/2016 09:57:21
3       on-line   since 02/12/2016 09:57:21
8       on-line   since 02/12/2016 09:57:21
9       on-line   since 02/12/2016 09:57:21
10      on-line   since 02/12/2016 09:57:21
11      on-line   since 02/12/2016 09:57:21
16      on-line   since 02/12/2016 09:57:21
17      on-line   since 02/12/2016 09:57:21
18      on-line   since 02/12/2016 09:57:21
19      on-line   since 02/12/2016 09:57:21
24      on-line   since 02/12/2016 09:57:21
25      on-line   since 02/12/2016 09:57:21
26      on-line   since 02/12/2016 09:57:21
27      on-line   since 02/12/2016 09:57:21
32      on-line   since 02/12/2016 09:57:21
33      on-line   since 02/12/2016 09:57:21
34      on-line   since 02/12/2016 09:57:21
35      on-line   since 02/12/2016 09:57:21
36      on-line   since 02/12/2016 09:57:21
37      on-line   since 02/12/2016 09:57:21
38      on-line   since 02/12/2016 09:57:21
39      on-line   since 02/12/2016 09:57:21
40      on-line   since 02/12/2016 09:57:21
41      on-line   since 02/12/2016 09:57:21
42      on-line   since 02/12/2016 09:57:21
43      on-line   since 02/12/2016 09:57:21
44      on-line   since 02/12/2016 09:57:21
45      on-line   since 02/12/2016 09:57:21
46      on-line   since 02/12/2016 09:57:21
47      on-line   since 02/12/2016 09:57:21

• Linux 

[oracle]$cat /proc/cpuinfo|grep processor|wc -l
      16

[oracle]$/sbRdbms/oracle-$cat /proc/cpuinfo|grep processor
processor       : 0
processor       : 1
processor       : 2
processor       : 3
processor       : 4
processor       : 5
processor       : 6
processor       : 7
processor       : 8
processor       : 9
processor       : 10
processor       : 11
processor       : 12
processor       : 13
processor       : 14
processor       : 15

• AIX (6.1 verified)

[oracle]$/bin/lparstat |head -2| sed '/^$/d'| awk '{print $6}'
lcpu=16

[oracle]$/bin/pmcycles -m
CPU 0 runs at 3864 MHz
CPU 1 runs at 3864 MHz
CPU 2 runs at 3864 MHz
CPU 3 runs at 3864 MHz
CPU 4 runs at 3864 MHz
CPU 5 runs at 3864 MHz
CPU 6 runs at 3864 MHz
CPU 7 runs at 3864 MHz
CPU 8 runs at 3864 MHz
CPU 9 runs at 3864 MHz
CPU 10 runs at 3864 MHz
CPU 11 runs at 3864 MHz
CPU 12 runs at 3864 MHz
CPU 13 runs at 3864 MHz
CPU 14 runs at 3864 MHz
CPU 15 runs at 3864 MHz

• Update (15/Mar/2016)

From Oracle point of view, in order to obtains the CPU count, you have to query V$OSSTAT. This view exist from Oracle 10g onwards. Normally the value you use is NUM_CPUS

[Linux] select stat_name, value from  v$osstat where stat_name like '%CPU%';

STAT_NAME                           VALUE
------------------------------ ----------
NUM_CPUS                               16 <<< correct value
RSRC_MGR_CPU_WAIT_TIME                 43
NUM_CPU_CORES                          16
NUM_CPU_SOCKETS                        16

Anyway, on AIX platform, because the "Bug 14215038 : CPU_COUNT DOESN'T MATCH", you need to use different column

[AIX] select stat_name, value from  v$osstat where stat_name like '%CPU%';

STAT_NAME                           VALUE
------------------------------ ----------
NUM_CPUS                               44 <<< wrong value due to 14215038 Bug
OS_CPU_WAIT_TIME               3.3043E+10
RSRC_MGR_CPU_WAIT_TIME                  0
NUM_CPU_CORES                          10
NUM_VCPUS                              10 <<< correct Virtual CPU number
NUM_LCPUS                              20 <<< correct Logical CPU number

If you compare this output with the "AIX (6.1 verified)", you see that the NUM_CPUS column cointain a wrong value.

• Update 2016/Jun/13

Modified the /usr/sbin/ioscan output. It counted wrong the CPU processors number

• Reference

Physical - Virtual - Logical CPU

DB Time (3 di 3) (ITA)

DB Time (1 di 3)
DB Time (2 di 3)

Il “database time” è il tempo totale speso dall’utente o a lavorare “attivamente” oppure ad aspettare “attivamente” in una “database call” (una “db call” è una funzione C nel kernel di Oracle. Se abilitiamo il “training” di una sessione, osserviamo che il kernel stampa una stringa nel file di output, al completamento della “database call”. Le più comuni sono PARSE, EXEC e FETCH).

- Relazione tra “System Load” e “DB Time”
Più utenti => Più “DB call” => il “DB time” aumenta Grandi transazioni => “DB call” più lunghe => il “DB time” aumentA
 -> Il DB time aumenta, all’aumentare del carico di lavoro del sistema

- Relazione tra le performance di un sistema ed il "DB Time"
Le prestazioni di I/O degradano => il tempo di I/O aumenta => il DB time aumenta Le prestazioni applicative degradano => il Wait time aumenta => il DB time aumenta
-> Il DB time aumenta quando le prestazioni.

- Relazione tra le prestazioni di una macchina ed il “DB Time”
Se le CPU della macchina sono eccessivamente attive => i processi foregrounds accumulano “tempo attivo” in run-queue => i tempi di attesa so artificialmente gonfiati => il DB time aumenta
-> Il db Time aumenta quando il le CPU fanno un eccessivo lavoro

Migliorare le prestazioni vuol dire fare lo stesso lavoro in meno “DB Time”, vuol dire cioè rimuovere l’ecceo di “DB Tme”.

Il “Database time” è semplicemente una misura de lavoro fatto dal database. Volendo fare un’analogia, possiamo dire che è l’equivalente dell’unita di misura “Joule” usata in Fisica nel Sistema Internazionale, per misurare l’energia (lavoro fatto da un sistema).

La velocità con cui il “Database Time” è consumato, è il “load average” del database analogo a quello del Sistema Operativo. L’unità di misura di tale velocità, ‘Database Time’/sec, è analoga al “Watt” o a “Joule/sec” nel SI, per misurare la potenza. Poiché l’obiettivo è quello di ridurre la quantità di tempo speso per un certo workload, questo è analogo al consumare meno energia per eseguire lo stesso compito.

• Update (16/Mar/2016)

Ho aggiunto nuovi documenti come riferimento

Riferimenti

• Back to Basics: DB Time Performance Tuning: Theory and Practice
• Interpreting Raw SQL_TRACE output (Doc ID 39817.1)
• Optimizing Oracle Performance [Millsap]
• Automatic Performance Diagnosis and Tuning in Oracle
• The Self-Managing Database: Automatic Health Monitoring and Alerting
• Oracle 10g Self-Management Framework Internals: Exploring the Automatic Workload Repository
• Oracle Database 10g: Intelligent Self-Management Infrastructure

DB Time (2 di 3)

DB Time (2 di 3) (ITA)

DB Time (1 di 3)
DB Time (3 di 3)

DB Time = CPU Time + Wait Time

è l’equazione che lega le principali componenti nel database:
- tempo di lavoro
- tempo di attesa

La stessa equazione possiamo anche riscriverla come (dividendo per DB Time e moltiplicando per 100)

100 = (CPU Time/DB Time)*100 + (Wait Time/DB time)*100

che è il modo in cui AWR ci presenta i Top Timed Events. Vediamo. Il seguente esempio è preso da un recente tuning che ho fatto proprio su una vecchia versione 10g.

Report AWR - Versione 10.2.0.5

 

 

 

DB Time = 440 mins = 26400 secs

Nelle versioni successive, la colonna contenente la percentuale (la seconda da destra) prende esplicitamente il nome di “%DB Time”

log file switch (checkpoint incoplete)	11908 / 26400 => 0,45106 => 45,1%
gc buffer busy	5376 / 26400 => 0,20363636 => 20,4
PX Deq Credit: send blkd	1537 / 26400 => 0,058219696 => 5,8%
buffer busy waits	1358 / 26400 => 0,0514393939 => 5,1%

Nelle versioni successive, la colonna contenente la percentuale (la seconda da destra) prende esplicitamente il nome di “%DB Time

Report AWR - Versione 11.2.0.4

 



DB Time = 498 mins = 29880 secs

db file sequential read	2736 / 29880 => 0,09156 => 9,15%
db file scattered read	1753 / 29880 => 0,05866 => 5,86%
log file sync	1500 / 29880 => 0,05020 => 5,02%
row cache lock	1096 / 29880 => 0,03668 => 3,67%

Report AWR - Versione 12.1.0.2

 

 

DB Time = 21 mins = 1260 secs

db file sequential read	57,5 / 1260 => 0,04563 => 4,56%
rdbms ipc reply	50,7 / 1270 => 0,04023 => 4,02%
DFS lock handle	18,2 / 1270 => 0,01433 => 1,43%
log file sync	13,6 / 1270 => 0,01070 => 1,07%

DB Time (1 di 3) DB Time (3 di 3)

DB Time (1 di 3) (ITA)

Qui la versione Inglese

DB Time (2 di 3)
DB Time (3 di 3)

Quando abbiamo a che fare con il “tuning“ dobbiamo sempre fare i conti con il tempo. L’utilizzatore finale di un database percepisce ogni tipo di problema sotto forma di tempo di risposta. Il tempo è ciò che mette in relazione l'esperienza utente con le prestazioni del database.

Nella ormai datata versione 10g, Oracle introdusse ciò chiamò “Intelligent Infrastructure”. Lo scopo di tale infrastruttura è triplice:
- self-monitor
- self-diagnostic
- self-tuning

Questo avveniva nel 2004.

In questo documento è nei prossimi, parleremo di 2 strumenti che abbiamo a disposizione
- DB Time
- ASH

DB Time

È definito come la “somma del tempo speso all’interno del database nel processare una richiesta utente”.

È una grandezza misurata in microsecondi e la possiamo ottenere interrogando il dizionario dati. Le viste che espongono le informazioni sono:
- V$SYS_TIME_MODEL
- V$SESS_TIME_MODEL

Quando un processo non può consumare CPU, è costretto ad aspettare per poterla nuovamente impegnarla. Noi conosciamo questa attesa, come “wait event”. Detto in altre parole, quanto un processo non può utilizzare una CPU, ci avvisa dicendo che aspetterà ed il motivo dell’attesa è proprio il “wait event”.

Ma non sempre le attese hanno un impatto sulle prestazioni. In tal caso diciamo che gli eventi di attesa sono di tipo “Idle”. Quando invece l’evento di attesa influenza la risposta di uno statement diciamo che è di tipo “Non-Idle”.

Un processo attivo (che lavora) quindi o consuma CPU, oppure aspetta su un evento di tipo Non-Idle.

Tutto questo può essere espresso attraverso un’espressione matematica, nel seguente modo:

DB Time = CPU Time + Non Idle Wait Time

Quasi sempre il “Non-Idle” è sottinteso, così l’espressione diventa

DB Time = CPU Time + Wait Time

Volendo essere precisi, la relazione corretta è 

DB Time = CPU Time + Wait Time + gap

Il motivo è che quando le CPU di un sistema sono molto impegnate, aumenta il “CPU Queue Time”, ovvero il tempo di attesa che i processi impiegano prima di utilizzare una CPU. Oracle chiama questa particolare attesa,  “CPU Wait Time”, che ovviamente è una scelta piuttosto infelice come nome.

Maggiori dettagli su questa particolare tematica sono ottenibili nei link presenti nei riferimenti sotto indicati. In ogni caso, in questo articolo, siamo interessati al caso più comune:

DB Time = CPU Time + Wait Time

Riferimenti

• What Is Light Green Oracle Database CPU Wait Time
• How OS CPU Run Queue Time Relates To Oracle Database DB Time
• Oracle Wait Events Investigated with Extended Stack Profiling and Flame Graphs
• AWR Ambiguity: Performance reasoning when the numbers don't add up

DB Time (2 di 3)

Definizioni

E' fondamentale, ai fini di proseguire la nostra chiacchierata sulle prestazioni, fornire e/o chiarire alcune definizioni.

• Performance: il tempo impiegato per eseguire un "compito"
• Un "compito" è un'unità di lavoro

Esistono due strumenti che misurano le performance

• "Response Time" (tempo di rispota): la durata di esecuizione di un compito
• Throughput: il numero delle esecuzioni dei compiti, completati in uno specifico intervallo di tempo

Ma continuiamo con le definizioni

• Load (carico di lavoro) è la competizione per una risorsa indotta dall'eseczione concorrente di un compito.

Una delle misure del carico di lavoro è l' "utilizzo".

• Capacity (capacità): è la totalità di un risorsa
• Utilization (utilizzo): l'uso di una risorsa, rispetto alla sua capacità, in un certo intervallo di tempo
• Requirements (richiesta): l'esigenza di utlizzo di una risorsa

Matematicamente esprimiamo questa relazione come:

• U = R / C

All'aumentare dell'uso di una risorsa, aumenta anche il tempo di risposta che l'utente sperimenterà quado usufruisce di quella risorsa

• Bottleneck (collo di bottiglia) è la limitazione della capacità di una risorsa.
• Efficienza è la misura inversa dello spreco. Detta in termini leggermente più complessi, possiamo definirla come l'inverso di quella parte di tempo che può essere tolta dall'esecuzione di un compito senza aggiungere capacità e senza sacrificare richieste.

• Il Responce time consiste di due componeti

- Service time: il tempo impiegato impiegato consumando una certa risorsa
- Queueing time: il tempo impiegato in tattesa di una certa risorsa

ovvero

R = S + Q

• "Skew" (inclinato) è una lista non uniforme di valori.

Concludo con la "Legge di Amdahl"
L'incremento delle prestazioni è proporzionale alla in cui un programma usa la cosa che stiamo migliorando



Riferimenti
* Thinking Clearly About Performance

Time Analysis (2 di 2) (ITA)

Time Analysis (2 di 2)

Quando un processo Oracle non counsuma CPU, aspetta (non smetterò mai di stressare su questa cosa. E' un concetto banale, ma spesso sfugge ai più). E noi conosciamo questa attesa come "wait time".

Qualche volta un processo che aspetta, non è a causa di un problema di performance, così noi chiamiamo questo "Idle Wait Time". Tipicamente ne sono affetti i processi di background. Quando invece un utente è in attesa che qualche operazione interna o esterna all'RDBMS si completi, ad esempio un lock o una lettura da disco, allora questa attesa viene chiamata "Non-Idle Wait Time".

Quando indaghiamo sulle prestazioni di un database, ovviamente ci concentriamo sugli eventi di attesa di tipo Non-Idle 

Per conoscere la numerosità e la loro classificazione, possiamo lanciare la seguente select 

(SYS)> col WAIT_CLASS for a20
(SYS)> select wait_class, count(*) from v$event_name group by wait_class;

WAIT_CLASS             COUNT(*)
-------------------- ----------
Concurrency                  38
User I/O                     56
System I/O                   35
Administrative               57
Other                      1186
Scheduler                     9
Configuration                26
Cluster                      64
Application                  17
Queueing                      9
Idle                        121
Network                      28
Commit                        4


Il "DB Time" è una statistica che somma il consumo dei processi di CPU e del Non-Idle wait time. Quando ottimizziamo un sistema tipicamente ci concentriamo per ridurre il tempo. Questo "tempo" è essenzialmente il "DB Time".

Il la statistica "DB Time" la troviamo nelle viste V$[SYS|SES]_TIME_MODEL

Riferimenti

• Which Is Better Time Model Or ASH Data
• What Is Oracle DB Time DB CPU Wall Time and Non Idle Wait Time
• The self-managing database Oracle 10g
• Database 10g: Intelligent Self-Management Infrastructure
• DB-Time based Oracle Performance Tuning

Time Analysis (1 di 2) (ITA)

Time Analysis (2 di 2)

Il tempo è un fattore importante perché le persone percepiscono le "performance" in termini di tempo e throughput. Per questo motivo, se la nostra analisi sulle prestazioni è di tipo quantitativo e basata sul "time model", possiamo sviluppare, almeno in parte, un collegamento tra ciò che l'utente osserva e la nostra analisi sulle performance.

Ma andiamo con ordine.

Quando una sessione lavora, delle due l'una: o consuma CPU oppure aspetta per consumarla. Per questo motivo ci sono due principali componenti che compongono il "database time": il tempo di CPU utilizzato (anche detto "CPU time") ed il tempo di attesa di tipo "non Idle" ("non-idle wait time").

Ho già parlato del tempo di attesa. Per maggiori informazioni leggi i precedenti post "Wait Event: Introduzione".

I dettagli di "CPU time" sono collezionati direttamente dal sistema operativo ed esportati attraverso le viste del dizionario dati V$[SYS|SES]_TIME_MODEL, mentre i "wait time" sono basati su "misure" (in inglese "instrumentetion"). In pratica gli sviluppatori Oracle hanno inserito del codice aggiuntivo per collezionare quanto tempo impiega uno step di "non-CPU".

E' a partire dalla versione 10g che abbiamo a disposizione questo nuovo approccio alle analisi prestazionali. Non che prima non fosse possibile, ma da questa release, Oracle ha messo a disposizione un vero e proprio framework construito direttamente nel kernel dell'RDBMS.

Dalla versione 10g l'approccio all'analisi prestazionale è possibile da due punti di vista: da un lato è basato sul tempo dall'altro sul campionamento. In successivi post vedremo quali differenze ci sono tra i due metodi. Ma soprattutto vedremo come in realtà il limite del secondo (il campionamento) collassa sul primo (il tempo).

Riferimenti

• Which Is Better Time Model Or ASH Data
• What Is Oracle DB Time DB CPU Wall Time and Non Idle Wait Time
• The self-managing database Oracle 10g
• Database 10g: Intelligent Self-Management Infrastructure