返回顶部
首页 > 资讯 > 数据库 >oracle数据库CPU过高问题定位分析
  • 380
分享到

oracle数据库CPU过高问题定位分析

2024-04-02 19:04:59 380人浏览 八月长安
摘要

本篇内容介绍了“oracle数据库CPU过高问题定位分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!一、

本篇内容介绍了“oracle数据库CPU过高问题定位分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

一、ASH

颗粒度最细最常用的诊断工具,通常当问题刚发生时,即可立即根据生成的ash报告诊断问题

下文示例为当问题出现后,查看最近5分钟的性能报告,运行ashrpt脚本后,其他选项直接默认跳过,在Enter value for begin_time选项中填写"-5"

sql> @ashrpt
Current Instance
~~~~~~~~~~~~~~~~
   DB Id    DB Name Inst Num Instance
----------- ------------ -------- ------------
 1506959389 ORCL1 orcl
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type:
Type Specified:  html
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   DB Id     Inst Num DB Name   InstanceHost
------------ -------- ------------ ------------ ------------
* 1506959389    1 ORCL   orcl localhost.lo
caldomain
Defaults to current database
Using database id: 1506959389
Enter instance numbers. Enter 'ALL' for all instances in a
RAC cluster or explicitly specify list of instances (e.g., 1,2,3).
Defaults to current instance.
Using instance number(s): 1
ASH Samples in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Oldest ASH sample available:  19-Jun-18 19:41:38   [  52092 mins in the past]
Latest ASH sample available:  25-Jul-18 23:52:52   [  1 mins in the past]
Specify the timeframe to generate the ASH report
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter begin time for report:
--    Valid input fORMats:
--To specify absolute begin time:
--  [MM/DD[/YY]] HH24:MI[:SS]
--  Examples: 02/23/03 14:30:15
--    02/23 14:30:15
--    14:30:15
--    14:30
--To specify relative begin time: (start with '-' sign)
--  -[HH24:]MI
--  Examples: -1:15  (SYSDATE - 1 Hr 15 Mins)
--    -25    (SYSDATE - 25 Mins)
Defaults to -15 mins
Enter value for begin_time: -5
Report begin time specified: -5
Enter duration in minutes starting from begin time:
Defaults to SYSDATE - begin_time
Press Enter to analyze till current time
Enter value for duration:
Report duration specified:
Using 25-Jul-18 23:48:39 as report begin time
Using 25-Jul-18 23:53:41 as report end time
Specify Slot Width (using ashrpti.sql) for 'Activity Over Time' section
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Explanation:
--   In the 'Activity Over Time' section of the ASH report,
--   the analysis period is divided into smaller slots
--   and top wait events are reported in each of those slots.
-- Default:
--   The analysis period will be automatically split upto 10 slots
--   complying to a minimum slot width of
--     1 minute,  if the source is V$ACTIVE_SESSION_HISTORY or
--     5 minutes, if the source is DBA_HIST_ACTIVE_SESS_HISTORY.
Specify Slot Width in seconds to use in the 'Activity Over Time' section:
Defaults to a value as explained above:
Slot Width specified:
Specify Report Targets (using ashrpti.sql) to generate the ASH report
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Explanation:
--   ASH Report can accept "Report Targets",
--   like a particular SQL statement, or a particular SESSION,
--   to generate the report on. If one or more report targets are
--   specified, then the data used to generate the report will only be
--   the ASH samples that pertain to ALL the specified report targets.
-- Default:
--   If none of the report targets are specified,
--   then the target defaults to all activity in the database instance.
Specify SESSION_ID (eg: from V$SESSION.SID) report target:
Defaults to NULL:
SESSION report target specified:
Specify SQL_ID (eg: from V$SQL.SQL_ID) report target:
Defaults to NULL: (% and _ wildcards allowed)
SQL report target specified:
Specify WAIT_CLASS name (eg: from V$EVENT_NAME.WAIT_CLASS) report target:
[Enter 'CPU' to investigate CPU usage]
Defaults to NULL: (% and _ wildcards allowed)
WAIT_CLASS report target specified:
Specify SERVICE_HASH (eg: from V$ACTIVE_SERVICES.NAME_HASH) report target:
Defaults to NULL:
SERVICE report target specified:
Specify MODULE name (eg: from V$SESSION.MODULE) report target:
Defaults to NULL: (% and _ wildcards allowed)
MODULE report target specified:
Specify ACTION name (eg: from V$SESSION.ACTION) report target:
Defaults to NULL: (% and _ wildcards allowed)
ACTION report target specified:
Specify CLIENT_ID (eg: from V$SESSION.CLIENT_IDENTIFIER) report target:
Defaults to NULL: (% and _ wildcards allowed)
CLIENT_ID report target specified:
Specify PLSQL_ENTRY name (eg: "SYS.DBMS_LOB.*") report target:
Defaults to NULL: (% and _ wildcards allowed)
PLSQL_ENTRY report target specified:
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is ashrpt_1_0725_2353.html.  To use this name,
press <return> to continue, otherwise enter an alternative.
Enter value for report_name: /home/oracle/ash_test.html
Using the report name /home/oracle/ash_test.html
Summary of All User Input
-------------------------
Format       : HTML
DB Id       : 1506959389
Inst num       : 1
Begin time     : 25-Jul-18 23:48:39
End time       : 25-Jul-18 23:53:41
Slot width     : Default
Report targets : 0
Report name    : /home/oracle/ash_test.html

通过结果图可以观察到短时间内引发问题的sql:

oracle数据库CPU过高问题定位分析

二、AWR报告

由oracle的两份快照而产生的差异报告,通常一小时一次,问题情况下可通过手动生成,缩小分析问题时段的范围

一般可在问题出现时以及几分钟后,各运行exec dbms_workload_repository.create_snapshot一次

SQL> exec dbms_workload_repository.create_snapshot;
PL/SQL procedure successfully completed.
SQL> exec dbms_workload_repository.create_snapshot;
PL/SQL procedure successfully completed.
SQL> @awrrpt
 
Current Instance
~~~~~~~~~~~~~~~~
 
   DB Id    DB Name     Inst Num Instance
----------- ------------ -------- ------------
 1506959389 ORCL      1 orcl
 
 
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: 
 
Type Specified:  html
 
 
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
   DB Id     Inst Num DB Name      Instance  Host
------------ -------- ------------ ------------ ------------
* 1506959389       1 ORCL    orcl     localhost.lo
                        caldomain
 
Using 1506959389 for database Id
Using          1 for instance number
 
 
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed.  Pressing <return> without
specifying a number lists all completed snapshots.
 
 
Enter value for num_days: 
 
Listing all Completed Snapshots
 
                            Snap
Instance     DB Name      Snap Id    Snap Started    Level
------------ ------------ --------- ------------------ -----
orcl         ORCL       21 25 Jul 2018 22:30     1
                 22 25 Jul 2018 23:42     1
                 23 25 Jul 2018 23:45     1
                 24 25 Jul 2018 23:47     1
                 25 25 Jul 2018 23:49     1
                 26 25 Jul 2018 23:51     1
                 27 26 Jul 2018 00:04     1
                 28 26 Jul 2018 00:07     1
                 29 26 Jul 2018 00:08     1
                 30 26 Jul 2018 00:09     1
 
 
 
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 29
Begin Snapshot Id specified: 29
 
Enter value for end_snap: 30
End   Snapshot Id specified: 30
 
 
 
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_29_30.html.  To use this name,
press <return> to continue, otherwise enter an alternative.
 
Enter value for report_name: /home/oracle/awr_test1.html
 
Using the report name /home/oracle/awr_test1.html

根据查看SQL ordered by CPU Time,可观察出相应时间段的高CPU消耗SQL

 oracle数据库CPU过高问题定位分析

三、ADDM

与awr类似,依托于快照生成,但有详细的分析建议(可在方法二中手动生成两次快照后使用)

运行exec DBMS_ADDM.ANALYZE_DB()命令时,第2、3参数分别为两次手动生成的快照号

SQL>  var task_name varchar2(30);
SQL> exec DBMS_ADDM.ANALYZE_DB(:task_name,21,36);
PL/SQL procedure successfully completed.
SQL> print :task_name
TASK_NAME
--------------------------------------------------------------------------------
TASK_236
SQL> set long 1000000 pagesize 0;
SQL> select dbms_addm.get_report('TASK_236') from dual;
 
 
通过报告可以精确的看到性能主要被消耗于哪里,消耗大小,以及事件描述
 
ADDM Report for Task 'TASK_236'
-------------------------------
Analysis Period
---------------
AWR snapshot range from 21 to 36.
Time period starts at 25-JUL-18 10.30.54 PM
Time period ends at 26-JUL-18 10.00.29 PM
Analysis Target
---------------
Database 'ORCL' with DB ID 1506959389.
Database version 11.2.0.4.0.
Analysis was requested for all instances, but ADDM analyzed instance orcl,
numbered 1 and hosted at localhost.localdomain.
See the "Additional Information" section for more information on the requested instances.
Activity During the Analysis Period
-----------------------------------
Total database time was 1445 seconds.
The average number of active sessions was .02.
ADDM analyzed 1 of the requested 1 instances.
Summary of Findings
-------------------
   Description     Active Sessions  Recommendations     Percent of Activity
   ----------------------------------------  -------------------  --------------
-
1  Top SQL Statements     .02 | 88.73  4
2  PL/SQL Execution     .01 | 41.55  1
3  Unusual "User I/O" Wait Event     0 | 28.78  4
4  Top Segments by "User I/O" and "Cluster"  0 | 28.64  1
5  Undersized instance memory     0 | 23.6  1
6  Sequence Usage     0 | 2.14  1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
----------------------------
Finding 1: Top SQL Statements
Impact is .02 active sessions, 88.73% of total activity.
--------------------------------------------------------
SQL statements consuming significant database time were found. These
statements offer a Good opportUnity for performance improvement.
   Recommendation 1: SQL Tuning
   Estimated benefit is .01 active sessions, 36.62% of total activity.
   -------------------------------------------------------------------
   Action
      Run SQL Tuning Advisor on the INSERT statement with SQL_ID      "5hrxg25g8bdpd".
      Related Object SQL statement with SQL_ID 5hrxg25g8bdpd.
 INSERT INTO T1 VALUES (S_T1_ID.NEXTVAL,DBMS_RANDOM.STRING('u', 10),SYSDATE)
   Rationale
      The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
      This part of database time may be improved by the SQL Tuning Advisor.
   Rationale
      Database time for this SQL was divided as follows: 45% for SQL execution, 0% for parsing, 55% for PL/SQL execution and 0% for Java execution.
   Rationale
      SQL statement with SQL_ID "5hrxg25g8bdpd" was executed 8000000 times and
      had an average elapsed time of 0.00004 seconds.
   Rationale
      Top level calls to execute the PL/SQL statement with SQL_ID
      "7j89gjdpf4m4u" are responsible for 100% of the database time spent on
      the INSERT statement with SQL_ID "5hrxg25g8bdpd".
      Related Object
 SQL statement with SQL_ID 7j89gjdpf4m4u.
 begin
 for i in 1 .. 1000000 loop
 insert into t1 values (s_t1_id.Nextval,dbms_random.string('u',
 10),sysdate);
 end loop;
 end;
   Recommendation 2: SQL Tuning
   Estimated benefit is 0 active sessions, 28.87% of total activity.
   -----------------------------------------------------------------
   Action
      Investigate the ALTER TABLESPACE statement with SQL_ID "6sqc239sgbMQf"
      for possible performance improvements. You can supplement the
      information given here with an ASH report for this SQL_ID.
      Related Object
 SQL statement with SQL_ID 6sqc239sgbmqf.
   Rationale
      The SQL Tuning Advisor cannot operate on ALTER TABLESPACE statements.
   Rationale
      Database time for this SQL was divided as follows: 100% for SQL
      execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
      execution.
   Rationale
      I/O and Cluster wait for TABLE "SYS.KOTTD$" with object ID 543 consumed
      97% of the database time spent on this SQL statement.
   Recommendation 3: SQL Tuning
   Estimated benefit is 0 active sessions, 14.08% of total activity.
   -----------------------------------------------------------------
   Action
      Run SQL Tuning Advisor on the SELECT statement with SQL_ID
      "a0qbnz3z4x4ns".
      Related Object
 SQL statement with SQL_ID a0qbnz3z4x4ns.
 select * from scott.t1 where name=dbms_random.string('u', 10)
   Rationale
      The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
      This part of database time may be improved by the SQL Tuning Advisor.
   Rationale
      Database time for this SQL was divided as follows: 5% for SQL execution,
      0% for parsing, 95% for PL/SQL execution and 0% for Java execution.
   Rationale
      SQL statement with SQL_ID "a0qbnz3z4x4ns" was executed 2 times and had
      an average elapsed time of 89 seconds.
   Recommendation 4: SQL Tuning
   Estimated benefit is 0 active sessions, 9.15% of total activity.
   ----------------------------------------------------------------
   Action
      Run SQL Tuning Advisor on the SELECT statement with SQL_ID
      "gmkaj9nz7vyvw".
      Related Object
 SQL statement with SQL_ID gmkaj9nz7vyvw.
 select * from scott.t3 where name=dbms_random.string('u', 10)
   Rationale
      The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
      This part of database time may be improved by the SQL Tuning Advisor.
   Rationale
      Database time for this SQL was divided as follows: 16% for SQL
      execution, 0% for parsing, 84% for PL/SQL execution and 0% for Java
      execution.
   Rationale
      SQL statement with SQL_ID "gmkaj9nz7vyvw" was executed 2 times and had
      an average elapsed time of 62 seconds.
Finding 2: PL/SQL Execution
Impact is .01 active sessions, 41.55% of total activity.
--------------------------------------------------------
PL/SQL execution consumed significant database time.
   Recommendation 1: SQL Tuning
   Estimated benefit is .01 active sessions, 41.55% of total activity.
   -------------------------------------------------------------------
   Action
      Tune the entry point PL/SQL "SYS.DBMS_RANDOM.STRING" of type "PACKAGE"
      and ID 9372. Refer to the PL/SQL documentation for addition information.
   Rationale
      193 seconds spent in executing PL/SQL
      "SYS.DBMS_RANDOM.RECORD_RANDOM_NUMBER" of type "PACKAGE" and ID 9372.
   Rationale
      193 seconds spent in executing PL/SQL
      "SYS.DBMS_RANDOM.REPLAY_RANDOM_NUMBER" of type "PACKAGE" and ID 9372.
   Rationale
      111 seconds spent in executing PL/SQL "SYS.DBMS_RANDOM.STRING" of type
      "PACKAGE" and ID 9372.
   Rationale
      101 seconds spent in executing PL/SQL "SYS.DBMS_RANDOM.VALUE#1" of type
      "PACKAGE" and ID 9372.
Finding 3: Unusual "User I/O" Wait Event
Impact is 0 active sessions, 28.78% of total activity.
------------------------------------------------------
Wait event "Data file init write" in wait class "User I/O" was consuming
significant database time.
   Recommendation 1: Application Analysis
   Estimated benefit is 0 active sessions, 28.78% of total activity.
   -----------------------------------------------------------------
   Action
      Investigate the cause for high "Data file init write" waits. Refer to
      Oracle's "Database Reference" for the description of this wait event.
   Recommendation 2: Application Analysis
   Estimated benefit is 0 active sessions, 28.78% of total activity.
   -----------------------------------------------------------------
   Action
      Investigate the cause for high "Data file init write" waits in Module
      "sqlplus@localhost.localdomain (TNS V1-V3)".
   Recommendation 3: Application Analysis
   Estimated benefit is 0 active sessions, 28.78% of total activity.
   -----------------------------------------------------------------
   Action
      Investigate the cause for high "Data file init write" waits in Service
      "SYS$USERS".
   Recommendation 4: Application Analysis
   Estimated benefit is 0 active sessions, 28.78% of total activity.
   -----------------------------------------------------------------
   Action
      Investigate the cause for high "Data file init write" waits with
      P1,P2,P3 ("count, intr, timeout") values "1", "256" and "4294967295"
      respectively.
   Symptoms That Led to the Finding:
   ---------------------------------
      Wait class "User I/O" was consuming significant database time.
      Impact is .01 active sessions, 32.41% of total activity.
Finding 4: Top Segments by "User I/O" and "Cluster"
Impact is 0 active sessions, 28.64% of total activity.
------------------------------------------------------
Individual database segments responsible for significant "User I/O" and
"Cluster" waits were found.
   Recommendation 1: Segment Tuning
   Estimated benefit is 0 active sessions, 28.64% of total activity.
   -----------------------------------------------------------------
   Action
      Investigate application logic involving I/O on TABLE "SYS.KOTTD$" with
      object ID 543.
      Related Object
 Database object with ID 543.
   Action
      Look at the "Top SQL Statements" finding for SQL statements consuming
      significant I/O on this segment. For example, the ALTER TABLESPACE
      statement with SQL_ID "6sqc239sgbmqf" is responsible for 98% of "User
      I/O" and "Cluster" waits for this segment.
   Rationale
      The I/O usage statistics for the object are: 0 full object scans, 2
      physical reads, 0 physical writes and 0 direct reads.
   Symptoms That Led to the Finding:
   ---------------------------------
      Wait class "User I/O" was consuming significant database time.
      Impact is .01 active sessions, 32.41% of total activity.
Finding 5: Undersized instance memory
Impact is 0 active sessions, 23.6% of total activity.
-----------------------------------------------------
The Oracle instance memory (SGA and PGA) was inadequately sized, causing
additional I/O and CPU usage.
The value of parameter "memory_target" was "300 M" during the analysis period.
   Recommendation 1: Database Configuration
   Estimated benefit is 0 active sessions, 14.46% of total activity.
   -----------------------------------------------------------------
   Action
      Increase memory allocated to the instance by setting the parameter
      "memory_target" to 450 M.
   Symptoms That Led to the Finding:
   ---------------------------------
      Wait class "User I/O" was consuming significant database time.
      Impact is .01 active sessions, 32.41% of total activity.
      Hard parsing of SQL statements was consuming significant database time.
      Impact is 0 active sessions, 2.07% of total activity.
Finding 6: Sequence Usage
Impact is 0 active sessions, 2.14% of total activity.
-----------------------------------------------------
Sequence cache misses were consuming significant database time.
   Recommendation 1: Application Analysis
   Estimated benefit is 0 active sessions, 2.14% of total activity.
   ----------------------------------------------------------------
   Action
      Investigate application or look at top SQL to find hot sequences. Use a
      larger cache size for those sequences. Try avoiding the use of the ORDER
      setting if running RAC.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Additional Information
  ----------------------
Miscellaneous Information
-------------------------
Wait class "Application" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Concurrency" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
CPU was not a bottleneck for the instance.
Wait class "Network" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.

“oracle数据库CPU过高问题定位分析”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程网网站,小编将为大家输出更多高质量的实用文章!

您可能感兴趣的文档:

--结束END--

本文标题: oracle数据库CPU过高问题定位分析

本文链接: https://lsjlt.com/news/65090.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • oracle数据库CPU过高问题定位分析
    本篇内容介绍了“oracle数据库CPU过高问题定位分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!一、...
    99+
    2024-04-02
  • oracle数据库CPU过高问题定位、分析(总结)
    一、为ASH、AWR、ADDM、SPA分别开启会话,并使用会话跟踪: --ASH alter session set events '...
    99+
    2024-04-02
  • oracle数据库CPU过高问题分析
    这篇文章主要讲解了“oracle数据库CPU过高问题分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“oracle数据库CPU过高问题分析”吧!一、执行一条...
    99+
    2024-04-02
  • oracle数据库CPU过高问题举例分析
    本篇内容介绍了“oracle数据库CPU过高问题举例分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!一、...
    99+
    2024-04-02
  • Mysql通过explain分析定位数据库性能问题
    目录引言explain基础exlpain分析实战总结引言 数据库性能优化是每个后端程序猿必备的基础技能之一,而mysql中的explain堪称Mysql的性能优化分析神器,我们可以通过它来分析SQL语句的对应的执行计划在...
    99+
    2023-01-13
    Mysql的explain使用 Mysql的explain
  • MYSQL数据库服务CPU高问题分析与优化
    MYSQL数据库服务CPU高问题分析与优化   MySQL服务性能监控分析与优化是永恒的主题,做为性能测试人员有时也要站在DBA角度出发进行适当分析与优化,这也是性能测试人员能长期生存发...
    99+
    2024-04-02
  • oracle数据库cpu负载过高怎么办
    处理 oracle 数据库高 cpu 负载需要采取以下步骤:确定原因:使用日志文件和性能监控工具识别高负载源。优化查询和索引:分析查询执行计划、优化查询并创建适当的索引。调整数据库参数:...
    99+
    2024-05-11
    oracle
  • 利用 Arthas 精准定位 Java 应用 CPU 负载过高问题
    Arthas 官方社区正在举行征文活动,参加即有奖品拿哦~点击投稿作者 | 张云翔最近我们线上有个应用服务器有点上头,CPU总能跑到99%,我寻思着它流量也不大啊,为啥能把自己整这么累?于是我登上这台服务器,看看它到底在干啥!以前碰到类似问...
    99+
    2023-06-04
  • 分析Oracle表数据库高水位及shrink操作
    这篇文章主要介绍“分析Oracle表数据库高水位及shrink操作”,在日常操作中,相信很多人在分析Oracle表数据库高水位及shrink操作问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,...
    99+
    2024-04-02
  • java应用cpu占用过高问题分析及解决方法
    使用jstack分析java程序cpu占用率过高的问题1,使用jps查找出java进程的pid,如37072,使用top -p 14292 -H观察该进程中所有线程的CPU占用。[root@cp01-game-dudai-0100.cp01...
    99+
    2023-05-31
    java cpu ava
  • 数据库中出现chmod 6751 oracle问题的示例分析
    这篇文章给大家分享的是有关数据库中出现chmod 6751 oracle问题的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。具体忘了怎么产生这个问题了,好像是迁移x3的库...
    99+
    2024-04-02
  • Linux问题故障定位的示例分析
    小编给大家分享一下Linux问题故障定位的示例分析,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!1. 背景有时候会遇到一些疑难杂症,并且监控插件并不能一眼立马发现...
    99+
    2023-06-16
  • Oracle数据库常见运算问题解析
    Oracle数据库是一款功能强大且广泛应用的关系型数据库管理系统,在开发过程中经常会遇到各种运算问题。在本文中,将针对Oracle数据库中常见的运算问题进行深入分析,并给出具体的代码示...
    99+
    2024-03-03
    数据库 oracle 运算
  • Win7 32位中audiodg进程CPU占用率过高问题解决方法
      最近有用户win7 32位操作系统下使用酷狗音乐、PPS或千千静音等等播放器时,在任务管理器中查看到audiodg.exe进程CPU占用率过高,导致系统运行缓慢甚至出现假死现象,出现这种问题该如何解决呢   Win7...
    99+
    2023-06-13
    Win7 32位 audiodg进程CPU占用率过高 问题 CPU 占用率 进程 解决
  • 如何用用工具快速定位数据库问题
    本篇文章为大家展示了如何用用工具快速定位数据库问题,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。我们经常会收到业务反馈“在么 xx端口感觉访问有点慢啊!” &nbs...
    99+
    2024-04-02
  • 数据库中谓词越界问题分析
    这篇文章主要介绍“数据库中谓词越界问题分析”,在日常操作中,相信很多人在数据库中谓词越界问题分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”数据库中谓词越界问题分析”的疑惑...
    99+
    2024-04-02
  • ORACLE数据库的DBLINK问题
    当用户要跨本地数据库,访问另外一个数据库表中的数据时,本地数据库中必须创建了远程数据库的dblink,通过dblink本地数据库可以像访问本地数据库一样访问远程数据库表中的数据。下面讲介绍我之前项目中如何在本地数据库中创建dblink。 ...
    99+
    2017-07-02
    ORACLE数据库的DBLINK问题
  • Android性能优化之ANR问题定位分析
    目录前言1 ANR原因总结1.1 KeyDispatchTimeout1.2 BroadCastTimeout1.3 ServiceTimeout1.4 ContentProvide...
    99+
    2024-04-02
  • PostgreSQL通过oracle_fdw访问Oracle数据的示例分析
    这篇文章给大家分享的是有关PostgreSQL通过oracle_fdw访问Oracle数据的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。背景:同一个项目两个系统分别使用了PG库和Oracle库,Orac...
    99+
    2023-06-15
  • 数据库突然宕机的问题及分析
    昨天晚上,某个环境的数据库在做一个压力测试的时候突然宕机了。这个问题比较急。马上查看日志文件。 看到了如下的一段,报了os级的linux错误。提示没有空间了。 Fri Mar 14 19:16:47 20...
    99+
    2024-04-02
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作