IT 專業技術分享

How To - Foglight Agent Manager 功能畫面無法顯示Foglight Agent Manager清單? 有時候，明明Foglight Agent Manager啟動狀態正常，卻無法在Foglight的Agent Manager功能畫面看到目前啟動中的Foglight Agent Manager，此時，需要重新啟用部份與Foglight Agent Manager的Cartridge功能。 請注意，以下設定僅適用於Foglight version 5.9.4及更舊的版本。 1.依序切換到左邊選單下方的Dashboard | Administration | Cartridges | Cartridges Inventory 接著選擇Core Cartridges: FglAM-Adapter 與 FglAM-Common 2. 選擇Core  Cartridges: FglAM-Adapter 與 FglAM-Common項目之後，按下上方按鈕Disable。 3. 請耐心等候Disable上方兩個選定的Cartridges。 4.已Disable Cartridge完成，按下OK關閉訊息視窗。 5.接著要enable剛剛停用的Cartridges: FglAM-Adapter 與 FglAM-Common。 i.請先點選下方的checkbox項目 Only display enabled cartridges。 ii.再點選Cartridges: FglAM-Adapter 與 FglAM-Common(請注意點選的版本編號)。 iii.最後點選Enabled按鈕。 6.接著顯示下方的訊息視窗，請按下OK按鈕繼續。 7.啟動剛剛點選的cartridge進行中，請耐心等候。 8. FglAM-Adapter 與 FglAM-Common兩個Cartridge已經enable完成。 9. 已可以在Foglight的Agent Manager功能畫面看到目前啟動中的Foglight Agent Manager。  希望以上步驟能解決Foglight  Agent Manager 功能畫面無法顯示Foglight A

How To - Foglight PI for Oracle - 設定ASM監控 前言 Foglight PI for Oracle - 設定ASM監控   前言  Foglight PI for Oracle除了可以設定Oracle資料庫監控，在其監控畫面，我們還可以看到Oracle Instance, Data Guard, CRS, ASM及Exadata等項目，今天來讓大家了解如何在Foglight 設定ASM監控。   設定ASM監控條件 1.資料庫使用者名稱 ：名稱只可以是 ASMSNMP 或 SYS 2.資料庫使用者類別 ：連線資料庫使用者類別需為 SYSASM 或 SYSDBA 3.OS連線帳號：需有查看ASM硬體資訊的OS連線使用者帳號 Foglight 設定ASM監控步驟 1. 切換到Oracle Dashboard的tab ASM，執行下方tab ASM的選單Monitor 2. 選定要設定監控的Foglight Agent Manager，按下Set按鈕後，畫面會回到原本的ASM監控設定畫面。 3. 如下圖，點選項目Host前面的radio button。 4. 設定ASM的DB連線帳密項目如下: 5. 設定ASM的OS監控如下: 如下圖，OS帳密輸入完成後，按下Apply套用。 6.按下Monitor設定ASM及其OS的監控 7.新增監控ASM設定進行中 8.驗證OS連線進行中 9. 完成ASM監控設定 10. 以下是Oracle ASM監控範例畫面。 希望以上步驟對您設定Oracle ASM監控能有幫助。

Fogligt監控Liunx OS的CPU Usage與top指令查出的結果為什麼不一樣? 我們利用Fogligt監控Liunx OS的CPU Usage的時候，使用者發現為何有時候在Host的CPU Usage Dashboard查到的CPU Usage比利用top指令查到的CPU Usage還要低呢? Foglight CPU Usage顯示(某一查詢時間區間的資料) Top指令查詢結果差異 1.  Cpu(s) 所有目前使用者的process佔用全部cpu的平均值，由於每個核心佔用的百分比不同，所以按平均值來計算較有參考價值。(下圖當下的top指令查詢到的結果) 2.  %CPU(CPU使用率)-上次更新到現在的CPU時間佔用百分比 顯示的是某process佔用一個core的百分比，當CPU為多核心時，該數值可能大於100，主要因為process啟用了多執行緒佔用多個核心(core)，所以有時候我們看%CPU該值的時候會超過100%，但不會超過總core數*100。(下圖當下的top指令查詢到的結果) 指令top查詢的 CPU usage 與Foglight Host CPU usage差異說明 1. 在Foglight的Host  OS中的CPU usage與top 的%CPU不一樣，應該說該數值其實較接近Cpu(s) 的數值。 2.  因為Foglight只取Top N筆的Top CPU的資訊，且顯示在網頁上的數字資訊會隨著查詢時間區間(default 1小時)被平均。 所以Foglight的CPU Usage加總後的數值會小於top指令查到的Cpu(s) 的數值。

How to - 修正Database Dashboard的Agent Status沒有顯示SQL PI icon的問題 若您的SQL PI圖示沒有因啟動PI之後顯示出來，請用下列步驟設定，恢復SQL PI圖示顯示。 【方式一】 1.如下圖的SQL Server DB Instance有設定PI功能，卻沒有顯示PI icon。 SQL Server DB Instance有設定PI功能   2.如下圖，切換到左邊選單Dashboard | Tooling | Script Console | Tooling，然後按下Add按鈕新增Groovy script。 在Toolsing新增script，貼上下列字串。 def out = new StringBuilder(); def agentService = server.get("AgentService"); def configService = server.get("ConfigService"); def agents = []; agents.addAll(agentService.findByAdapterAndType("FglAM", "DB_SQL_Server")); for (agent in agents) {     def primaryASP = configService.getAgentInstancePrimaryAsp(agent.getAgentNamespace(), agent.getTypeId(), agent.getId());     if (primaryASP && primaryASP.getBoolean("paecEnable")) {          primaryASP.setValueByString("paecPaused", "0");          configService.saveConfig(primaryASP);          out.append(String.format("%s %

問題 : SharePlex event_log 突然大量 Queue 出現 ORA-12520 ，該怎麼辦 ?  Error    2019-08-15 11:10:05.302005 3659 2994657120 Poster: 12032 - OCIServerAttach failed with ORA-12520   (posting from o.CARDPROD, queue pq7, to o.CARDPROD) [module osp] Notice   2019-08-15 11:10:05.302634 3659 2994657120 Poster:   (posting from o.CARDPROD, queue pq7, to o.CARDPROD) [module osp] Error    2019-08-15 11:10:05.302721 3659 2994657120 Poster: Unexpected Oracle error:  in ../src/opst_mt/connection.cpp:330  (posting from o.CARDPROD, queue pq7, to o.CARDPROD) [module osp] Info     2019-08-15 11:10:05.306953 3593 1111730016 Poster exited with code=1, pid = 3659  (posting from o.CARDPROD, queue pq7, to o.CARDPROD) Error    2019-08-15 11:10:05.762734 3655 1684195168 Poster: 12032 - OCIServerAttach failed with ORA-12520   (posting from o.CARDPROD, queue pq3, to o.CARDPROD) [module osp] Notice   2019-08-15 11:10:05.763042 3655 1684195168 Poster:   (posting from o.CARDPROD, queue pq3, to o.CARDPROD) [module osp

問題 : 當 SharePlex event_log 出現如下訊息，代表 Capture process 不能讀 Redo/archive log 。 Error    2019-08-11 11:15:19.830412 5062 1624037120 Capture stopped: Internal error encountered; cannot continue  (capturing from SPORBIT) Error    2019-08-11 11:15:19.824759 5062 1624037120 Capture: [SP-OCT01001] Unable to find archivelog with sequence#: 46819 (thread: 4).  <CAUSE> SharePlex was unable to locate the redo/archive log for sequence 46819 in the database location or under the directory defined by SP_OCT_ARCH_LOC parameter.  <ADVICE> Restore this archivelog to archive location if missing or set the file's location using SP_OCT_ARCH_LOC.  Make sure it is not compressed then restart capture.  See 'http://advice.shareplex.com/SP-OCT01001' for additional advice and support.   (capturing from SPORBIT) [module oct] 解決方法 1.       如果 Oracle Archive log 有備份，則設定 SharePlex SP_OCT_ARCH_LOC 參數指定 Archive log 位置，只要能成功讀取，就能追上資料。 2.       跳過讀不到的 Archive log 號碼，讓 Capture 啟

2019 年 7 月來自 oracle 的重要告警訊息 請參考下面官網網址說明 https://www.oracle.com/technetwork/security-advisory/cpujul2019verbose-5072838.html 請參考CVE官方說明 • https://nvd.nist.gov/vuln/detail/CVE-2018-11058 建議盡快更新 Oracle 相關 Patch

2019 年 7 月 MySQL 的重要告警訊息 !! 請參考下面官網網址說明 https://nvd.nist.gov/vuln/detail/CVE-2019-3822 The version of MySQL running on the remote host is 5.7.x prior to 5.7.27 . It is, therefore, affected by multiple vulnerabilities, including three of the top vulnerabilities below, as noted in the July 2019 Critical Patch Update advisory: - An unspecified vulnerability in the 'Server: Packaging (cURL)' subcomponent could allow an unauthenticated attacker to gain complete control of an affected instance of MySQL Server. (CVE-2019-3822) - An unspecified vulnerability in the 'Server: Parser' subcomponent could allow a high privileged attacker to cause the server to hang or to, via a frequently repeatable crash, cause a complete denial of service. (CVE-2019-2805) - An unspecified vulnerability in the 'Server: XML' subcomponent could allow a high privileged attacker to cause the server to hang or to, via a frequently repeatable crash, cause a compl

問題 : 當 SharePlex event_log 出現如下訊息，代表 Read process 不能運作。 Error     2019-08-10 20:51:29.291526 19220 547252064 Reader: RouteDB load for actid 41 failed: routes file does not exist for actid    (from o.PXPROD) [module ord] Info      2019-08-10 20:51:29.297165 18892 2226095968 Reader exited with code=1, pid = 19220   (from o.PXPROD) Info      2019-08-10 20:51:58.049938 19436 2226095968 Reader launched, pid = 19436   (from o.PXPROD) Notice    2019-08-10 20:51:58.105539 19436 2958284640 Reader: Replicating according to target compatibility of "9.1.3"   (from o.PXPROD) [module sys] Error     2019-08-10 20:51:59.304181 19436 2958284640 Reader: RouteDB load for actid 41 failed: routes file does not exist for actid    (from o.PXPROD) [module ord] Info      2019-08-10 20:51:59.309003 18892 2226095968 Reader exited with code=1, pid = 19436   (from o.PXPROD) 原因 : 新的 cache file 和 Route file 並沒有產生。 解決方法 步驟一 : Shutdown SharePlex 和重新執行 ora_setup 。