sql >> Databáze >  >> RDS >> Oracle

EM SQL Monitor dopad

V případě, že někdo potřebuje připomenutí, je vždy dobré určit dopad vašich monitorovacích nástrojů na samotnou databázi, kterou monitorujete. Některé monitorovací nástroje jsou lehké a jiné jsou rušivější. Používám Enterprise Manager 13c ke sledování konkrétního příkazu SQL při jeho běhu. V jiném monitorovacím nástroji (Lighty by Orachrome) jsem si všiml, že následující příkaz SQL spotřebovával značné množství zdrojů:

S MONITOR_DATA AS (
SELECT
INST_ID
,KEY
,NVL2 (
PX_QCSID
,NULL
,STATUS
) STATUS
,FIRST_REFRESH_TIME
,LAST_REFRESH_TIME
,REFRESH_COUNT
,PROCESS_NAME
,SID
,SQL_ID
,SQL_EXEC_START

Zbytek textu jsem odstřihl. Tento příkaz SQL má doslova několik tisíc řádků. Fuj! Ale to není problém. V Lighty jsem si všiml aktivity na tomto snímku obrazovky.

Nejvyšší příkaz SQL je moje prase CPU. Začernil jsem text SQL, abych ochránil potenciálně vlastněné informace. Všimněte si posledního příkazu SQL. Spotřebovává to značné množství zdrojů na pouhé sledování systému.

Zde je snímek obrazovky okna EM13c.

Když jsem vypnul automatické obnovení (výchozí nastavení je 15 sekund), aktivita v systému přestala. Když potřebuji aktualizaci, pak ručně stisknu tlačítko pro obnovení.
Určitě existují časy, kdy lze použít automatické obnovení, dokonce každých 15 sekund. Jen mějte na paměti potenciální negativní dopad na databázi.


  1. Říjen 2014CPU havaruje ArcGIS Desktop

  2. Jak připojit Python k serveru SQL pro automatizaci backendového procesu

  3. SQL nerozpozná alias sloupce v klauzuli where

  4. Hledání textu v rámci Oracle Stored Procedures