Draw graph for Linux sar output using ksar

I’ve recently heard about this tool , as it is said we are learning things until the death (:

Our company is saving sar output in a text file periodicly and after performance or other issues we need to analyze it’s output to find out which resource was busy and when.. analyzing text file is time-consuming and can also cause eye tension.

Output in sar:

00:00:01        CPU      %usr     %nice      %sys   %iowait    %steal      %irq     %soft    %guest    %gnice     %idle
00:10:01        all      3.14      0.00      2.43      1.64      0.00      0.00      0.60      0.00      0.00     92.20
00:10:01          0      3.64      0.00      2.33      4.10      0.00      0.00      1.10      0.00      0.00     88.83

00:00:01      scall/s badcall/s  packet/s     udp/s     tcp/s     hit/s    miss/s   sread/s  swrite/s saccess/s sgetatt/s
00:10:01         0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

00:00:01       totsck    tcpsck    udpsck    rawsck   ip-frag    tcp-tw
00:10:01         5682       656      1783         0         6       502
00:20:01         5651       668      1748         0         0       804

CPU, Network, Disk I/O, etc. activities are logged.

Same text file analyzed by ksar tool and graphycally displayed is the following:

Full list of items that can be seen graphycally are the following:

Now I will show all necessary information that is necessary to use this tool:

1. Download a pre-built jar from GitHub releases page.

2. Run jar on your computer:

   java -jar ksar-5.2.4-b396_gf0680721-SNAPSHOT-all.jar

3. Click Data -> Load from a file…and choose output of sar in a text file

Full information about this tool: https://github.com/vlsi/ksar

Exadata Performance Diagnostics with AWR

” The contents of this paper apply to all Exadata deployments – whether onpremises, Public Cloud, or Cloud at Customer “

Click to access exadata-awr-5100655.pdf

Table Locks and Foreign Keys

Brief Description:

After reading “Expert Indexing in Oracle Database 11g ” book, I decided to share the following information with you. Which, I think, is very very useful.

It is better to index foreign key columns to avoid locking issues. Note, that locking issues are avoided when index type is B-tree, not Bitmap.

The Scenario:

Note: This is the quote from the following book:

Expert Indexing in Oracle Database 11g
Maximum Performance for Your Database

Darl Kuhn
Sam R. Alapati
Bill Padfield

“Here’s a simple example that demonstrates the locking issue when foreign key columns are not indexed.

First, create two tables (DEPT and EMP) and associate them with a foreign key constraint.

create table emp(emp_id number primary key, dept_id number);

create table dept(dept_id number primary key);

alter table emp add constraint emp_fk1 foreign key (dept_id) references dept(dept_id);

Now insert some data.

insert into dept values(10);
insert into dept values(20);
insert into dept values(30);
insert into emp values(1,10);
insert into emp values(2,20);
insert into emp values(3,10);

Open two terminal sessions. From one, delete one record from the child table (don’t commit).

delete from emp where dept_id = 10;

Now attempt to delete from the parent table some data not impacted by the child table delete.

delete from dept where dept_id = 30;

The delete from the parent table hangs until the child table transaction is committed. Without a regular B-tree index on the foreign key column in the child table, any time you attempt to insert or delete in the child table, it places a table-wide lock on the parent table, which prevents deletes or updates in the parent table until the child table transaction completes.

Now run the prior experiment, except this time additionally create an index on the foreign key column of
the child table.

create index emp_fk1 on emp(dept_id);

You should be able to independently run the prior two delete statements. When you have a B-tree index on
the foreign key columns, if deleting from the child table, Oracle will not excessively lock all rows in the
parent table.”