oracle iis coldfusion memo2

Last updated at 2025-02-25Posted at 2025-02-19

Oracleに関する対策

背景

CPUが100%の状態では、通常のSELECT文では応答が得られず、高負荷状態のSQLを直接取得するのは困難です。

対策案

事前モニタリングとデータのサンプリング

定期的なサンプリングの実施

v$session、v$sqlなどの動的パフォーマンスビューから定期的に情報を取得し、ログや別のテーブルに記録しておく。

Oracle Enterprise Manager（OEM）などのツールが利用可能であれば、リアルタイム監視を設定し、異常なSQL活動を事前にキャプチャする。

イベントトレースの設定

事前に10046イベントトレースを有効にしておき、負荷が高まった際に自動でトレースを開始するよう設定する。これにより、traceファイル内で高負荷のSQLを後から分析できる。

Oracleログの活用

Alertログの確認

CPU100%時にAlertログには、ORA-04030（メモリ不足）やORA-600/ORA-7445（内部エラー）、ORA-00060（デッドロック）などのエラーが記録される可能性がある。

これらのエラーメッセージを自動的に監視・抽出するスクリプトを用意し、発生時刻と負荷状況を対応付ける。

Traceログの分析

10046トレースやSQL Traceを活用し、負荷高騰時のSQL実行状況を追跡。SELECTが実行できない場合でも、traceファイル内の情報からどのSQLが高負荷を引き起こしていたかを特定する。

IISに関する対策

背景

IISのリクエストログはリクエスト完了後に記録されるため、CPUが100%の高負荷時には有効な情報が得にくい。

HTTP 4XXエラーはリソースが見つからない場合に発生し、CPU高負荷とは直接の関連は薄いが、HTTP 5XXエラーはサーバ内部の問題を示しており、負荷状況の変化とともにログの状態が変化する。

対策案

リアルタイム監視の強化

失敗要求トレース（FREB）の活用

IISのFREBを有効にしておくことで、HTTP 5XXなどのエラー発生時に詳細なリクエスト情報を即時にキャプチャできる。

パフォーマンスカウンターの監視

Windows Performance Monitorを利用して、リクエストキューの長さ、接続数、平均応答時間などの指標をリアルタイムで監視し、負荷の上昇を早期に察知する。

APMツールの導入

Application Insights、New Relicなどのツールを用いて、IISでのリクエストの開始時刻や中断、エラー発生時の詳細な状況を収集する。

ログ分析のアプローチ

CPU100%の間はHTTP 5XXが多発するため、負荷が低下した後にHTTP 2XXに戻るパターンが見られる。

高負荷時のリクエスト状況（タイムアウトや中断したリクエストなど）を、負荷低下後のログと比較し、どのパターンが高負荷と関連しているかを特定する。

各種ログのエラー対照表の作成

目的

Oracle、IIS、ColdFusion、Windowsシステムの各ログに記録される具体的なエラー情報をリスト化し、どのエラーがCPUまたはメモリ100%に直結しているのかを明確にする。

対象ログと具体的エラー情報

Oracleログ

Alertログ

ORA-04030：メモリ不足エラー

ORA-600 / ORA-7445：内部エラー

ORA-00060：デッドロックエラー

Traceログ

SQL Traceや10046トレースで、特に実行時間が長く、CPU使用率の高いSQLの情報を抽出する。

IISログ

HTTP 5XXエラー

例：HTTP500.100、HTTP500.19など、サーバ内部の問題を示すエラーコード。

応答時間

長時間（例：5秒以上、場合によっては10分以上）の応答遅延が記録されたリクエスト。

接続中断情報

高負荷時に発生するリクエスト中断、タイムアウトの情報。

ColdFusionログ

メモリ不足、スレッドプール枯渇、DB接続エラーなど、ColdFusionサーバがリソース不足に陥った際のエラーメッセージ。

異常な例外スタックトレースや未捕捉の例外の記録。

Windowsシステムログ

システムおよびアプリケーションログ

イベントID 2019 / 2020：メモリプール枯渇に関連するエラー。

ディスクI/Oやネットワーク、カーネルに関するエラー（例：Kernel-Powerエラー）。

対照表の運用方法

各エラーコードやメッセージの意味、原因、対処方法をドキュメント化し、発生時刻とシステムの負荷状況と照らし合わせる。

高負荷発生時に、各システムからのログスナップショットを取得し、事前に作成した対照表と比較することで、原因特定の迅速化を図る。

総括

Oracle対策

事前のモニタリングと10046トレースの設定を行い、AlertログやTraceログから高負荷時のSQLを追跡する。

IIS対策

FREBやパフォーマンスカウンター、APMツールを用いてリアルタイムにリクエスト状況を把握し、HTTP 5XXエラー発生時の詳細情報を記録する。

ログエラー対照表の整備

Oracle、IIS、ColdFusion、Windowsシステムの各ログから、CPUやメモリ100%に関係する具体的なエラーコードやメッセージを一覧化し、迅速な原因分析に役立てる。

これにより、高負荷発生時でも各システムから得られる情報をもとに、迅速かつ正確な原因特定と対策実施が可能となります。

关于 Oracle

问题背景

在 CPU 达到 100% 时，由于系统响应变慢，直接执行 SELECT 查询可能无法获取及时数据，从而难以通过常规查询发现高负载 SQL。

后续方案

提前采集数据

预置监控与采样：

配置 Oracle 的主动会话历史（ASH）或者定期轮询 v$session、v$sql 等视图，把采样数据保存到日志或另外的监控库中，以便在高负载时进行回溯分析。

如果有 Oracle Enterprise Manager（OEM），可以利用 OEM 的实时监控和诊断功能，提前捕捉异常活动。

设置事件跟踪：

可预先启用事件 10046 跟踪（或者扩展 SQL Trace），在负载突增前自动启动追踪，并在负载发生后生成 trace 文件，分析高负载时具体运行的 SQL 语句。

利用 Oracle 日志

Alert 日志检查：

在 CPU 达到 100% 时，Oracle 的 Alert 日志可能会记录一些内部错误或资源耗尽的提示，例如 ORA-04030（内存不足）、ORA-600 或 ORA-7445（内部错误）、ORA-00060（死锁）等。

建立监控脚本，定时分析 Alert 日志中是否出现这些异常信息，并与高负载时间段对应。

Trace 日志：

针对关键时刻，可以考虑配置后台自动触发 trace 日志（例如通过 DBMS_MONITOR 设置诊断采样），这样即使在 SELECT 无法响应时，也能从 trace 日志中查出高负载 SQL 的痕迹。

关于 IIS

问题背景

IIS 的请求日志在请求结束后才记录，所以在 CPU 100% 时，日志信息可能滞后且无法及时反映当前状态；同时，HTTP4XX 与 5XX 的现象也需要具体区分。

后续方案

实时监控与诊断

启用失败请求跟踪（FREB）：

配置 IIS 的 FREB，可以在请求失败时（例如返回 HTTP 5XX 错误时）即时捕捉详细请求信息，哪怕请求没有正常结束。

利用性能监控工具：

使用 Windows Performance Monitor 监控 IIS 相关计数器（如请求队列长度、当前连接数、平均响应时间等），以便在高负载期间实时掌握状况。

集成应用性能监控（APM）工具：

考虑部署 Application Insights、New Relic 或其他第三方监控工具，它们可以实时采集响应时间、状态码分布及异常请求情况。

日志分析思路

由于在 CPU 高负载时 HTTP 5XX 是服务器内部错误，建议对比 CPU 下降前后的日志：

记录高负载期间是否有大量未完成请求（长时间挂起）以及返回 HTTP 5XX 的请求数，待 CPU 回落后再与 HTTP 2XX 请求做对比，判断是否属于瞬时异常或请求超时后自动成功的情况。

可考虑在 IIS 中增加自定义日志字段，如实时记录请求开始时间、响应中断情况等，以便后续分析。

关于错误日志对照（Oracle、IIS、ColdFusion、Windows 系统）

目标

明确哪些具体的错误日志信息与 CPU 或内存达到 100% 直接相关，建立一个错误对照表，便于问题发生时快速比对与诊断。

建议的错误日志及关键信息

Oracle 日志

Alert 日志：关注

ORA-04030：内存不足错误。

ORA-600/ORA-7445：内部错误，通常提示存在异常执行情况。

ORA-00060：死锁错误，表明会话之间存在资源争夺。

Trace 日志：如果有启用 SQL Trace 或 10046 跟踪，检查 trace 文件中是否存在执行时间异常长或 CPU 占用特别高的 SQL。

IIS 日志

HTTP 5XX 错误：如 HTTP500.100、HTTP500.19 等，反映服务器内部错误。

响应时间异常：如果日志中能记录请求的响应时间，关注超过预设阀值（例如 5 秒甚至 10 分钟）的请求。

连接中断信息：有时高负载会导致请求被中断或连接超时，记录这些情况以便排查是否为服务器处理不过来。

ColdFusion 日志

应用/服务器日志：关注

“Out of Memory” 错误、线程池耗尽、资源竞争或数据库连接异常错误。

异常的异常堆栈或未捕获的异常信息，这些都可能指示高负载下资源调度问题。

Windows 系统日志

系统与应用程序日志：重点监控

Event ID 2019 / 2020（内存池耗尽类错误）。

与磁盘 I/O、网络连接或系统内核相关的错误，如 Kernel-Power 错误。

定时记录高负载时段内是否有重复出现的系统错误，作为系统资源瓶颈的指示。

建立对照表

将以上错误信息及错误码整理成文档，并明确每个错误可能对应的资源瓶颈类型（CPU、内存、I/O 等）。

在发生异常时，先采集当前各系统的日志快照，然后与对照表比对，初步判断问题的方向和可能原因。

最后，根据对照结果采取相应的调优或修复措施，例如增加资源、优化 SQL、调整 IIS 配置等。

总结

Oracle：采用预采样、启用 trace、利用 Alert 日志和预置监控工具，实现高负载时的 SQL 行为追踪；

IIS：通过失败请求跟踪、性能监控和 APM 工具，实时捕捉和记录高负载期间的请求详情；

错误日志对照：建立具体错误信息列表（包括 Oracle 的 ORA 错误、IIS 的 HTTP 5XX、ColdFusion 内存或线程错误、Windows 系统错误），作为后续对比分析的依据。

一、Oracle在CPU 100%时无法查询的应对方案

问题核心

当数据库CPU 100%导致会话无响应时，常规查询可能失效，需通过以下方法间接获取高负载SQL：

1. 利用Oracle日志和后台数据

Oracle告警日志（Alert Log）
路径：$ORACLE_BASE\diag\rdbms\<DB_NAME>\<INSTANCE_NAME>\trace\alert_<INSTANCE_NAME>.log
作用：
- 检查是否有 ORA-04030（内存不足）或 ORA-00060（死锁）错误。
- 分析日志中周期性出现的SQL语句（可能为高负载操作）。

自动工作负载仓库（AWR）历史快照
前提：Oracle SE2若未购买Diagnostics Pack，默认无法使用AWR，但可临时启用手动快照：

-- 手动创建快照（需DBA权限）
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- 生成AWR报告（需要两个快照ID）
SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(<db_id>, <instance_id>, <start_snap>, <end_snap>));

ASH（Active Session History）
即使实例暂时无响应，ASH可能保留故障前1小时的活跃会话数据：

SELECT sample_time, sql_id, event, session_state 
FROM v$active_session_history 
WHERE sample_time > SYSDATE - 1/24  -- 最近1小时
ORDER BY sample_time DESC;

2. 预先设置应急监控脚本

在数据库正常时部署脚本，定期采集关键性能数据（如每秒SQL执行量、TOP SQL），存储到外部文件：

-- 每隔10秒记录一次高CPU SQL（保存到OS文件）
BEGIN
  DBMS_SCHEDULER.CREATE_JOB(
    job_name        => 'CAPTURE_HIGH_CPU_SQL',
    job_type        => 'PLSQL_BLOCK',
    job_action      => 'BEGIN 
                          INSERT INTO high_cpu_sql_log 
                          SELECT sql_id, cpu_time, executions 
                          FROM v$sql 
                          ORDER BY cpu_time DESC 
                          FETCH FIRST 5 ROWS ONLY; 
                       END;',
    start_date      => SYSTIMESTAMP,
    repeat_interval => 'FREQ=SECONDLY;INTERVAL=10',
    enabled         => TRUE
  );
END;

二、IIS响应时间长的优化方案

问题核心

IIS日志在请求结束后才记录，CPU 100%时日志延迟，需通过其他手段实时捕获请求状态。

1. 实时监控工具

性能监视器（PerfMon）关键计数器：
- Web Service -> Current Connections：突增连接数可能引发CPU满载。
- ASP.NET -> Requests Executing：若数值持续高位，说明请求堆积。
- Process(w3wp)\% Processor Time：定位具体w3wp进程的CPU占用。
启用失败请求跟踪（Failed Request Tracing）：
作用：捕获处理超时的请求（如设置触发条件为“响应时间>5秒”）。
配置步骤：
1. IIS管理器 -> 站点 -> 失败请求跟踪 -> 启用。
2. 定义规则：状态码200-500，时间阈值5秒。
3. 日志路径：C:\inetpub\logs\FailedReqLogFiles。
动态调试工具
- DebugDiag：捕获w3wp进程的CPU高负载时的内存转储（dump），分析线程堆栈。
- ProcDump：命令行工具触发dump生成：
```
procdump -ma -c 90 -n 3 w3wp.exe  -- 当w3wp CPU超过90%时生成3个dump
```

2. 日志分析补充

筛选5XX错误的时间段关联性：
虽然5XX错误在CPU下降后可能变为2XX，但可统计故障时间段的5XX错误量，结合AP日志确认是否由资源耗尽引起。
示例命令（PowerShell）：
```
Select-String -Path "C:\inetpub\logs\LogFiles\*.log" -Pattern " 500 " | 
Group-Object -Property Line | 
Sort-Object -Property Count -Descending
```

三、错误日志与资源满载的关联表

以下是各组件日志中可能导致CPU/内存100%的关键错误类型及示例：

组件	错误日志特征	关联资源问题
Oracle	- `ORA-04030: out of process memory` - `ORA-04036: PGA memory used by the instance`	内存泄露或PGA不足
	`WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK`	字典缓存争用（CPU）
IIS	- `503 Service Unavailable`（应用池崩溃） - `500.19 - Configuration Error`	线程池耗尽或配置错误
ColdFusion	`java.lang.OutOfMemoryError: Java heap space`（ColdFusion应用日志）	JVM内存泄漏
	`Timeout occurred while processing request`	外部依赖（如DB）慢
Windows	- 事件ID 2004：虚拟内存不足 - 事件ID 1001：应用池崩溃（`WAS`源）	内存或线程泄漏
	事件ID 129：磁盘响应超时（`storport`源）	存储I/O瓶颈

日志分析建议

Oracle告警日志：搜索 ORA- 错误代码，优先关注内存和锁相关错误。
IIS日志：筛选 time-taken 大于阈值（如5000ms）的请求，检查对应URL是否关联高负载功能。
ColdFusion日志：检查 coldfusion-out.log 中的长事务或循环调用。
Windows事件查看器：过滤关键事件ID（如2004、1001、129），结合时间戳关联资源峰值。

四、长期预防措施

1. 自动化监控基线

Oracle：部署OEM（Oracle Enterprise Manager）或开源的Prometheus+Grafana监控，实时跟踪 CPU_TIME、BUFFER_GETS 等指标。
IIS/ColdFusion：配置SCOM（System Center Operations Manager）或AppDynamics，监控请求队列和JVM内存。

2. 压力测试与优化

数据库层：
- 对高频SQL绑定变量，减少硬解析（alter system set cursor_sharing=force; 临时方案）。
- 定期收集统计信息：
```
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCHEMA', tabname=>'TABLE', estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);
```
应用层：
- ColdFusion代码静态分析工具（如CFLint）检查N+1查询、死循环。
- IIS启用输出缓存（Output Caching）减少重复请求。

3. 快速响应手册

整理关键日志路径和错误代码对照表，形成排查清单，例如：

# Oracle CPU 100%快速检查清单
1. 检查告警日志：`alert_<SID>.log`，搜索ORA-04030/ORA-00060。
2. 查询ASH历史：`SELECT * FROM v$active_session_history WHERE sample_time > SYSDATE-1/24;`
3. 终止阻塞会话：`ALTER SYSTEM KILL SESSION 'sid,serial#';`

总结

Oracle CPU 100%：依赖预先采集的AWR/ASH数据、告警日志中的ORA错误，结合应急脚本捕获高负载SQL。
IIS响应延迟：通过PerfMon实时监控、失败请求跟踪、内存转储分析定位根源。
日志关联性：建立错误代码与资源问题的映射表，实现快速日志匹配。

在CPU使用率达到100%时，性能计数器的监视时长和日志保存需根据具体情况平衡资源消耗与数据完整性，以下为分步建议：

1. 初始快速捕获（1-5分钟）

目的：立即捕捉高负载瞬间的关键进程和资源争用。
配置：
- 采样间隔：1秒（高频率，确保捕捉瞬时峰值）。
- 计数器范围：
  - Processor(_Total)\% Processor Time（总CPU）。
  - Process(*)\% Processor Time（按进程细分）。
  - Memory\Available MBytes（内存压力）。
  - 关联IIS或数据库计数器（如Web Service\Current Connections、Oracle Process\% CPU）。
操作：
- 启动PerfMon并立即记录，持续1-5分钟。
- 保存日志后优先分析高负载进程（如w3wp.exe或oracle.exe）。

2. 持续监控（30分钟-1小时）

适用场景：CPU 100%持续存在，需定位周期性或累积性问题。
配置：
- 采样间隔：5-10秒（减少日志体积，避免磁盘I/O压力）。
- 关键计数器：
  - ASP.NET Applications\Requests/Sec（IIS请求吞吐量）。
  - LogicalDisk(*)\Avg. Disk Queue Length（存储延迟）。
  - TCPv4\Connections Established（网络连接数）。
操作：
- 持续记录30分钟至1小时，覆盖完整业务周期（如用户高峰时段）。
- 结合日志时间戳与AP/DB日志对比，定位关联事件。

3. 分段捕获（多次短时快照）

适用场景：CPU间歇性飙升至100%，需捕捉多次峰值。

配置：

采样间隔：1秒（峰值时） + 5秒（正常时）。

触发器：
使用脚本或工具（如Logman）在CPU超过95%时自动启动记录，持续2-3分钟。

logman create trace HighCPU -v mmddhhmm -o C:\PerfLogs\HighCPU.blg -f bincirc -max 500 -c "\Processor(_Total)\% Processor Time" "\Process(*)\% Processor Time"
logman start HighCPU

操作：
- 每次触发保存独立日志文件，避免单文件过大。
- 分析各次峰值共性（如相同进程或SQL）。

4. 日志保存与分析建议

保存时机：
- 立即保存：在CPU负载下降后立即停止记录，避免后续数据稀释问题特征。
- 分段保存：若高负载持续超1小时，每小时分割一次日志（如PerfLog_20231010_1300.blg）。
分析工具：
- 使用PerfMon内置的“数据收集器报告”生成图表，识别趋势。
- 用PAL工具（Performance Analysis of Logs）自动解析日志，生成异常标记。
- 关联事件查看器日志（筛选Event ID 1001/2004）确认资源耗尽事件。

5. 极端情况应对

服务器濒临无响应：
- 最小化计数器：仅监控 Processor 和 Process 计数器，采样间隔延长至15秒。
- 转储文件辅助：
```
procdump -ma -c 90 -s 10 -n 2 w3wp.exe  // CPU超90%持续10秒时生成dump
```
- 日志保存位置：优先写入SSD或内存盘（如RamDisk），避免机械磁盘延迟。

总结建议

短时高频（1-5分钟）：用于应急响应，快速定位进程级问题。
中长期监控（30分钟+）：用于分析根本原因（如内存泄漏、计划任务冲突）。
自动化触发：通过脚本实现条件化日志捕获，减少人工干预。

通过合理规划监控时长与粒度，可在资源消耗与问题诊断之间取得最优平衡。
（由于技术原因，联网搜索暂不可用）

在Windows系统中，logman 是一个用于管理性能监视器和事件跟踪日志的命令行工具。logman create trace 和 logman create counter 是两个不同的子命令，分别用于创建不同类型的日志收集器。以下是它们的核心区别和适用场景：

1. `logman create counter`（性能计数器日志）

用途

收集周期性采样的性能数据，例如：
- CPU使用率（\Processor(*)\% Processor Time）。
- 内存使用量（\Memory\Available MBytes）。
- 磁盘I/O（\LogicalDisk(*)\Disk Read Bytes/sec）。
- 网络流量（\Network Interface(*)\Bytes Total/sec）。

特点

定期采样：按固定间隔（如每1秒、每5秒）记录数据。
低开销：适合长期监控系统资源趋势。
数据格式：生成 .blg（二进制日志文件），可用性能监视器（PerfMon）或工具（如PAL）分析。

示例命令

logman create counter MyCounterLog -c "\Processor(*)\% Processor Time" "\Memory\Available MBytes" -si 5 -o C:\Logs\CounterLog.blg

-c: 指定计数器路径。
-si 5: 每5秒采样一次。
-o: 输出文件路径。

2. `logman create trace`（事件跟踪日志）

用途

记录事件驱动的系统活动，例如：
- 进程创建/终止（Windows内核事件）。
- 文件读写操作（文件系统跟踪）。
- 网络连接事件（TCP/IP活动）。
- 应用程序特定事件（如ColdFusion请求跟踪）。

特点

事件触发：仅在事件发生时记录数据（非周期性采样）。
高精度：捕获毫秒级延迟或事件链（如磁盘I/O延迟分析）。
高开销：可能占用较多资源（尤其是高频事件）。
数据格式：生成 .etl（事件跟踪日志文件），需用工具（如Windows Performance Analyzer）解析。

示例命令

logman create trace MyTraceLog -o C:\Logs\TraceLog.etl -p "Windows Kernel Trace" (process,thread,disk) -ets

-p: 指定事件提供程序（如Windows Kernel Trace）。
-ets: 无交互式提示直接启动跟踪。
常用事件提供程序：
- Microsoft-Windows-Kernel-Process（进程/线程事件）。
- Microsoft-Windows-Kernel-File（文件操作）。
- Microsoft-Windows-TCPIP（网络活动）。

3. 核心对比表

特性	`logman create counter`	`logman create trace`
数据收集方式	定期采样（如每5秒）	事件触发（实时记录）
数据类型	性能指标（CPU、内存、磁盘等）	系统事件（进程、文件、网络等）
文件格式	`.blg`（二进制性能日志）	`.etl`（事件跟踪日志）
资源消耗	低	中到高（取决于事件频率）
分析工具	PerfMon、PAL、Excel	Windows Performance Analyzer（WPA）、Tracerpt
典型场景	监控系统资源趋势（如CPU长期负载）	诊断延迟问题（如磁盘I/O卡顿、进程阻塞）

4. 如何选择？

使用 `logman create counter` 的场景

需要长期监控服务器资源使用情况（如生成每日CPU/内存报告）。
分析周期性性能瓶颈（如高峰时段的数据库连接数）。
低开销、简单指标收集。

使用 `logman create trace` 的场景

诊断偶发性问题（如进程崩溃前的最后操作）。
分析事件链（如某个请求为何耗时10秒）。
需要高精度的时间戳和事件上下文（如文件访问冲突）。

5. 联合使用示例

场景：数据库服务器CPU间歇性100%

第一步（计数器日志）：
用 logman create counter 监控CPU、内存、磁盘队列长度，确定峰值时段。
第二步（跟踪日志）：
在峰值时段用 logman create trace 跟踪进程切换和磁盘I/O事件，定位具体进程或操作。

总结

logman create counter：适合长期、低开销的资源监控，数据简单直观。
logman create trace：适合深度诊断事件驱动的复杂问题，需结合专业工具分析。
根据问题类型选择合适的日志类型，可大幅提升故障排查效率。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

oracle iis coldfusion memo2

一、Oracle在CPU 100%时无法查询的应对方案

问题核心

1. 利用Oracle日志和后台数据

2. 预先设置应急监控脚本

二、IIS响应时间长的优化方案

问题核心

1. 实时监控工具

2. 日志分析补充

三、错误日志与资源满载的关联表

日志分析建议

四、长期预防措施

1. 自动化监控基线

2. 压力测试与优化

3. 快速响应手册

总结

1. 初始快速捕获（1-5分钟）

2. 持续监控（30分钟-1小时）

3. 分段捕获（多次短时快照）

4. 日志保存与分析建议

5. 极端情况应对

总结建议

1. logman create counter（性能计数器日志）

用途

特点

示例命令

2. logman create trace（事件跟踪日志）

用途

特点

示例命令

3. 核心对比表

4. 如何选择？

使用 logman create counter 的场景

使用 logman create trace 的场景

5. 联合使用示例

场景：数据库服务器CPU间歇性100%

总结

1. `logman create counter`（性能计数器日志）

2. `logman create trace`（事件跟踪日志）

使用 `logman create counter` 的场景

使用 `logman create trace` 的场景