60% of query execution time is spent in "cluster wait" in ORACLE ADW database.
What causes this cluster wait?
That is a wait class related to RAC nodes, https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/classes-of-wait-events.html#GUID-B30B0811-0FDC-40FC-92FC-F6726CE94736. In the SQL Monitor report you posted the screenshot of, you can look at the Activity bar and see what individual wait events you are seeing. You can also look at the execution plan in the report to see where those waits are happening.
Related
Starting in Oracle 11g, GATHER_STATS_JOB is no longer valid, and has been replace by "auto optimizer stats collection".
This job supposedly runs during the "maintenance windows" and gathers statistics for objects which have changed 10% or more, or have stale stats. If this is true, then why when I run a query checking "stale_stats='YES'", I still get objects?
Maybe I'm not understanding how the job executes......
Two broad possibilities
Oracle updates stale_statistics to "YES" in dba_tab_statistics periodically throughout the day as tables undergo changes. It is entirely possible that a table had just under the threshold amount of changes when stats were gathered this morning and that stale_stats flipped to "YES" during the day today when a few more changes were made.
Depending on how many objects had stale stats when the job ran and how much data those tables contained, how large your maintenance window is, and how powerful your server is, it is possible that the statistics job had to be aborted before it could re-gather all the stale statistics. If the job was aborted, that abort would be logged in the job history. If this happened because there happened to be a large number of changes one day (say you ran an annual purge process that deleted a large amount of data from almost every table in the database), the stale statistics would be updated over the course of several days worth of statistics job runs until the job caught up.
I am new to performance analysis of DB.
How to pull AWR report from dynatrace?
What parameters we are monitoring in AWR report?
You don't. You pull it from ORACLE.
Dynatrace enables monitoring of your entire infrastructure including your hosts, processes, and network. You can schedule AWR report on email trigger.
2. What parameters we are monitoring in AWR report?
You have check combination of AWR report. using single AWR report willl not give clear idea.
dependen on issue you have to see different section.
The main sections in an AWR report include:
Report Summary: overall summary of the instance during the snapshot period, and it contains important aggregate summary information.
Cache Sizes (end): size of each SGA region after AMM has changed them. This information can be compared to the original init.ora parameters at the end of the AWR report.
Load Profile: shows important rates expressed in units of per second and transactions per second.
Instance Efficiency Percentages: With a target of 100%, these are high-level ratios for activity in the SGA.
Shared Pool Statistics: T good summary of changes to the shared pool during the snapshot period.
Top 5 Timed Events: It shows the top wait events and can quickly show the overall database bottleneck.
Wait Events Statistics Section: shows a breakdown of the main wait events in the database including foreground and background database wait events as well as time model, operating system, service, and wait classes statistics.
Wait Events: This AWR report section provides more detailed wait event information for foreground user processes which includes Top 5 wait events and many other wait events that occurred during the snapshot interval.
Background Wait Events: This section is relevant to the background process wait events.
Time Model Statistics: Time mode statistics report how database-processing time is spent. This section contains detailed timing information on particular components participating in database processing.
Operating System Statistics: The stress on the Oracle server is important, and this section shows the main external resources including I/O, CPU, memory, and network usage.
Service Statistics: The service statistics section gives information about how particular services configured in the database are operating.
I have a SQL query that fetches roughly 200 columns from multiple tables and normally runs in a matter of minutes.
A Java program kicked off by cron calls the SQL every 4 hours, but occasionally hangs forever(=not fetching any data. Neither updates nor inserts are involved).
Here are some outputs from V$SESSION.
STATUS: ACTIVE
ROW_WAIT_OBJ#: 22392 ←not changing
ROW_WAIT_FILE#: 6 ←not changing
ROW_WAIT_BLOCK#: 8896642 ←not changing
ROW_WAIT_ROW#: 0 ←not changing
LAST_CALL_ET: 5632 ←keeps incresing
★No other heavy SQL queries are running at the same time
What could be the cause of this and what should I look into to solve it?
You can use TKPROF or SQL Profiler. This reports can help you. We can not replay your question now.
If you attach your tuning reports, we can help you. Because many things can cause performance problems. A comprehensive study is needed to understand this.
Follow this link;
https://docs.oracle.com/cd/E11882_01/server.112/e41573/perf_overview.htm
The app is connected to an oracle 11G database using the JDBC driver provided from the official website. When many users (Around 50) from different instances connected to the same schema start using the application, i experience some freezes all around the app and when i run a query to get the locking sessions and the locked objects i find only "Row Exclusive" lock type, which normally should not lock all the table and permits multiple sessions to perfom DML queries. Thus my question is when can a row exclusive table lock the whole table or else provoque these freezes.
Note: i have looked around in forums and saw some MAXTRANS and ITL configurations, could these parameters be generating these freezes ?
Thank you
i think you have your terms confused.. "Row Exclusive" locks mean 'i have locked this row.. no other session is allowed to update it'.
so if you have 50 sessions all trying to update or delete a specific row then yes.. you are going to have contention. and that will seriously limit your performance.
so I would guess that its possible your application is missing a commit statment that would free the lock after the row has been modified.
you say you are using sequences.. are you using an actually oracle sequence (ie create sequence my_seq; ) or are you doing to custom thing that like select max(id)+1 from sequence_table which would be another bad idea.
Maybe it's too early to blame Oracle. It can be a servlet container configuration such as not enough exec threads. Or it can be an internal contention. Many things can go wrong. A quick way to identify the bottleneck is to get a thread dump when the application is experiencing "some freezes all around the app" and see where your threads as stuck. You can get a thread dump by sending kill -3 to your Java process. Post it here and will be happy to look at it.
I have a query CREATE TABLE foobar AS SELECT ... that runs successfully in Hue (the returned status is Inserted 986571 row(s)) and takes a couple seconds to complete. However, in Cloudera Manager its status - after more than 10 minutes - still says Executing.
Is it a bug in Cloudera Manager or is this query actually still running?
When Hue executes a query, it leaves the query open so that users can page through results at their own pace. (Of course, this behavior isn't very useful for DDL statements.) That means that Impala still considers the query to be executing, even if it is not actively using CPU cycles (keep in mind it is still holding memory!). Hue will close the query if explicitly told to, or when the page/session is closed, e.g. using the hue command:
> build/env/bin/hue close_queries --help
Note that Impala has a query option to automatically 'timeout' queries after a period of time, see query_timeout_s. Hue sets this to 10 minutes by default, but you can override it in the hue.ini settings.
One thing to note is that when queries 'time out', they are cancelled but not closed, i.e. the query will remain "in flight" with a CANCELLED status. The reason for this is so that users (or tools) can continue to observe the query metadata (e.g. query profile, status, etc.), which would not be available if the query is fully closed and thus deregistered from the impalad. Unfortunately these cancelled queries may still hold some non-negligible resources, but this will be fixed with IMPALA-1575.
More information: Hive and Impala queries life cycle