Data Domain: Povolení protokolování rozhraní API funkce DD Boost – protokoly předběžného certifikátu

Otázka: Co je protokolování DD Boost Precert? 
Odpověď: DD Boost Precert Logging je funkce diagnostického protokolování, která zaznamenává transakce rozhraní API DD Boost mezi klientem DD Boost a systémem Data Domain. Běžně se používá k řešení problémů s výkonem, selhání, latencí a komunikací.

Otázka: Co zaznamenává protokolování Precert? 
Odpověď: Protokolování Precert zachycuje aktivitu rozhraní API funkce DD Boost, včetně operací čtení, zápisu, zálohování, obnovení, interakcí knihoven DD Boost, informací o časování volání rozhraní API a indikátorů latence na straně klienta. Poskytuje podrobný přehled o chování rozhraní DD Boost API pro odstraňování problémů a analýzu výkonu.

Otázka: Proč se negenerují žádné protokoly předběžného certifikace? 
Odpověď: Ověřte, zda soubor ddboost_precert.ini existuje, nachází se v kořenovém adresáři operačního systému, zda existuje adresář protokolu, do kterého lze zapisovat data a zda byla zahájena nová operace zálohování nebo obnovení. Nejčastějšími příčinami jsou chybějící konfigurace, nesprávné umístění, problémy s oprávněními nebo nedostatečná aktivita nové funkce DD Boost.

Otázka: Vygeneruje povolení protokolování před certifikátem protokoly okamžitě? 
Odpověď:  Ne, soubory protokolu se generují pouze při přijetí nových požadavků rozhraní API DD Boost. Konfigurace povoluje pouze možnost protokolování.

Otázka: Proč aktuálně spuštěná záloha negeneruje protokoly precert? 
Odpověď: Protokolování před certifikátem zachycuje pouze aktivitu rozhraní API iniciovanou po zjištění konfigurace. Stávající úlohy zálohování nebo obnovení pokračují bez generování protokolů předběžného certifikace.

Otázka: Musím restartovat úlohu zálohování nebo obnovení? 
Odpověď: Ano, k vygenerování protokolů precert je vyžadována nová úloha zálohování nebo obnovení.  Pokud byla úloha již spuštěna, když bylo povoleno protokolování, spusťte novou operaci.

Otázka: Jaký je nejčastější důvod, proč protokolování precert nefunguje? 
Odpověď: Mezi běžné příčiny patří ddboost_precert.ini není na kořenové úrovni, je omylem pojmenován ddboost_precert.ini.txt, chybějící adresář protokolu nebo nedostatečná oprávnění. Nejčastějšími příčinami jsou problémy s konfigurací a souborovým systémem.

Otázka: Kam by měl být soubor ddboost_precert.ini umístěn? 

Linux: /ddboost_precert.ini. Windows: C:\ddboost_precert.ini.

Odpověď: Soubor musí být umístěn v kořenovém adresáři operačního systému.

Otázka: Může být soubor ddboost_precert.ini uložen v jiné složce? 
Odpověď: Ne, soubor musí být uložen v kořenovém adresáři. Zásuvný modul DD Boost kontroluje pouze kořenový adresář operačního systému.

Otázka: Jak mohu ověřit, že soubor ve skutečnosti není

ddboost_precert.ini.txt

Otevřete Průzkumník souborů, povolte Přípony názvů souborů a ověřte název souboru.
Odpověď: Ujistěte se, že je soubor pojmenován 

ddboost_precert.ini and not ddboost_precert.ini.txt.

Otázka: Proč je DDLog Adresář prázdný po povolení protokolování?
Odpověď: Spusťte nové zálohování, obnovení nebo DDPCONNCHK Otestujte, abyste vygenerovali aktivitu.  Mezi možné příčiny patří žádná nová aktivita DD Boost, problémy s oprávněními nebo konfigurační soubor, který nebyl rozpoznán.

Otázka: Co je to DDPCONNCHK A proč je to užitečné? 
Odpověď: DDPCONNCHK je nástroj pro ověření konektivity softwaru DD Boost. Dokáže generovat aktivitu rozhraní DD Boost API a rychle potvrdit, že protokolování před certifikátem funguje.

Otázka: Umět DDPCONNCHK použít k otestování mé konfigurace?
Odpověď:  Inženýři často DDPCONNCHK Po povolení protokolování. Ano, jedná se o běžný způsob, jak ověřit, zda se protokoly generují před reprodukcí problému.

Otázka: Proč se moje protokoly precert tak rychle zvětšují?
Odpověď:  Protokolování Precert zaznamenává každé volání rozhraní API DD Boost. Velká zálohovací prostředí mohou v krátké době vygenerovat významný objem protokolů.

Otázka: Kolik místa na disku mám přidělit? Běžným doporučením je 

num_log_files=3 and log_file_size=500.

Odpověď: To poskytuje přibližně 1,5 GB úložiště protokolů, než dojde k rotaci.

Otázka: Mohou protokoly precert zaplnit systém souborů? 
Odpověď: Protokolování může spotřebovávat značné místo na disku, pokud není monitorováno. Ano, úplné systémy souborů mohou způsobit selhání zálohování, výpadky nebo přerušení služeb.

Otázka: Jaký je účel num_log_files? 
Odpověď: Tento parametr určuje počet zachovaných rotovaných souborů protokolu. Například, num_log_files=3 creates ddboost_precert.log, ddboost_precert.log.1, and ddboost_precert.log.2.

Otázka: Jaký je účel log_file_size? 
Odpověď: Tento parametr určuje maximální velikost každého souboru protokolu v MB. Například log_file_size=500 umožňuje, aby se každý soubor před otočením zvětšil na 500 MB.

Otázka: Co laňs ddcl_logs_include=true dělat?
Odpověď:  Umožňuje protokolování klientské knihovny DD Boost v rámci protokolů před certifikací. Doporučené nastavení je ddcl_logs_include=true.

Otázka: Co znamená ddcl_logs_sev=4 To znamená?
Odpověď:  Tento parametr řídí závažnost protokolování. Úroveň závažnosti 4 obsahuje podrobné informace o odstraňování problémů a ladění.

Otázka: Potřebuji BoostFS Ladění protokolování navíc k protokolování precert? 
Odpověď: Další protokolování není vždy vyžadováno. Pro BoostFS-specific problémy, povolení obou často poskytuje úplnější diagnostický obraz.

Otázka: Pro BoostFS, musím odpojit a znovu připojit? 
Odpověď: Odpojením a opětovným připojením se znovu inicializuje aktivita BoostFS. V mnoha případech ano, pomáhá to iniciovat novou aktivitu DD Boost.

Otázka: Jaká je správná syntaxe
protokolování ladění BoostFS?Odpověď:  Správná syntaxe je -o log-level=debug. NEPOUŽÍVEJTE, --o log-level=debug protože platí pouze jedna pomlčka.

Otázka: Proč se po opětovném připojení BoostFS náhle zobrazily protokoly precert? 
Odpověď: Opětovné připojení vytvoří nový cyklus inicializace pro BoostFS. Protokolování začne, když dojde k nové aktivitě rozhraní DD Boost API a doplněk zjistí konfigurační soubor.

Otázka: Je restartování aplikace ekvivalentní opětovnému připojení BoostFS? 
Odpověď: Obvykle ano, příklady zahrnují restartování RMAN, zálohovací software nebo spuštěný DDPCONNCHK. Protokolování může aktivovat jakákoli akce, která vytvoří novou aktivitu rozhraní DD Boost API.

Otázka: Umět RMAN Generovat protokoly precert bez odpojení BoostFS? 
Odpověď: Ano, začínáme s novým RMAN Provoz je obvykle dostačující. RMAN může přímo iniciovat nové požadavky rozhraní API funkce DD Boost.

Otázka: Jak zakážu protokolování precert?
Odpověď:  Odstraňte ddboost_precert.ini nebo jej přejmenujte na ddboost_precert.ini.disabled.

Otázka: Musím po odstranění souboru ini restartovat hostitele? 
Odpověď: Ne, restartování není nutné. 

Otázka: Jaká oprávnění by měla být použita v Linuxu? Mezi příklady oprávnění patří: 

mkdir /DDLog, chmod 777 /DDLog, and chmod 777 /ddboost_precert.ini.

Odpověď: Proces DD Boost musí být schopen číst konfigurační soubor a zapisovat jej do adresáře protokolu.

Otázka: Kde jsou protokoly BoostFS ve výchozím nastavení uloženy? 

Linux: /opt/emc/boostfs/log. Windows: C:\BoostFS\Log.

Odpověď: Tato umístění jsou oddělená od protokolů precert softwaru DD Boost.

Otázka: Jsou protokoly BoostFS a protokoly precert totéž? 
Odpověď: Ne, protokoly precert obsahují transakce rozhraní API DD Boost, komunikaci knihovny a data časování vstupně-výstupních operací. Protokoly BoostFS obsahují aktivitu připojení, operace systému souborů a události aplikací.

Otázka: Jaké protokoly mám poskytnout podpoře? 
Odpověď: Poskytnutí všech relevantních protokolů pomáhá urychlit odstraňování problémů. V závislosti na problému shromážděte ddboost_precert.log, rotované protokoly precert, protokoly BoostFS, DDPCONNCHK Výstup, protokoly aplikací a požadované balíčky podpory.

Otázka: Co mám dělat, pokud protokoly nejsou generovány ani po provedení tohoto KB? 
Odpověď: Shromažďujte důkazy, jako je umístění ddboost_precert.ini, výpis adresáře protokolu, DDPCONNCHK výstup, příkaz pro připojení BoostFS a informace o oprávněních. Odešlete shromážděné informace technické podpoře společnosti Dell k další analýze.