Exadata: October 2021

Wednesday, October 13, 2021

SQLcl latest download

The excellent database tool SQLcl latest download:

https://www.oracle.com/tools/downloads/sqlcl-downloads.html

Its "father": http://www.thatjeffsmith.com/

And the documentation: https://docs.oracle.com/en/database/oracle/sql-developer-command-line/

No oracle client is needed, it use JDBC connection and requires JRE.

Friday, October 8, 2021

DBMS_SPACE.create_index_cost ORA-01031: insufficient privileges

Running the script

----------------------------------------------------------
-- File name:   cs_estimate_index_size.sql
-- Purpose:     Estimate Index Size
-- Author:      Carlos Sierra
-- Version:     2020/12/06
-- Usage:       Execute connected to PDB.
--
-- Example:     $ sqlplus / as sysdba
--              SQL> @cs_estimate_index_size.sql
--
-- Notes:       Developed and tested on 12.1.0.2.
----------------------------------------------------------
--
SET HEA ON LIN 2490 PAGES 100 TAB OFF FEED OFF ECHO OFF VER OFF TRIMS ON TRIM ON TI OFF TIMI OFF LONG 240000 LONGC 2400 NUM 20 SERVEROUT OFF;
PRO
PRO 1. Enter Index Name:
DEF index_name = '&1.';
UNDEF 1;
--
COL schema_name NEW_V schema_name NOPRI;
SELECT owner AS schema_name FROM dba_indexes WHERE index_name = '&&index_name.';
--
VAR v_used_bytes NUMBER;
VAR v_alloc_bytes NUMBER;
BEGIN
DBMS_SPACE.create_index_cost (
    ddl             => DBMS_METADATA.get_ddl('INDEX', '&&index_name.', '&&schema_name.'),
    used_bytes      => :v_used_bytes,
    alloc_bytes     => :v_alloc_bytes
);
END;
/
COL used_gb FOR 999,990.000;
COL alloc_gb FOR 999,990.000;
SELECT :v_used_bytes/1e9 AS used_gb, :v_alloc_bytes/1e9 AS alloc_gb FROM DUAL;
--
ROLLBACK;
DELETE plan_table;
BEGIN
EXECUTE IMMEDIATE('EXPLAIN PLAN FOR '||DBMS_METADATA.get_ddl('INDEX', '&&index_name.', '&&schema_name.'));
END;
/
COMMIT;
SET HEA ON PAGES 0;
PRO
SELECT plan_table_output FROM
TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE', NULL, 'ADVANCED'))
/
SET HEA ON PAGES 100;
CLEAR COLUMNS;

the developer got an

ORA-01031: insufficient privileges
ORA-06512: at "SYS.DBMS_SPACE", line 2833
ORA-06512: at "SYS.DBMS_SPACE", line 2854
ORA-06512: at line 5

If the developer run this script as SYS - then it works well. But on the production system the developer works as specially created DEV_USER and this script produce error. And developer don't understand why, because it has all rights needed:

CREATE USER DEV_USER
IDENTIFIED BY ...
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP
PROFILE ...
ACCOUNT UNLOCK;

ALTER USER DEV_USER QUOTA 1g ON USERS;

GRANT CONNECT TO DEV_USER;
GRANT PERFORMANCE_TUNE TO DEV_USER;
ALTER USER DEV_USER DEFAULT ROLE ALL;

GRANT ANALYZE ANY TO DEV_USER;
GRANT ANALYZE ANY DICTIONARY TO DEV_USER;
GRANT CREATE PROCEDURE TO DEV_USER;
GRANT CREATE TABLE TO DEV_USER;
GRANT CREATE INDEX to DEV_USER;
GRANT SELECT ANY DICTIONARY TO DEV_USER;
GRANT SELECT ANY TABLE TO DEV_USER;

GRANT EXECUTE ON SYS.DBMS_METADATA TO DEV_USER;
GRANT EXECUTE ON SYS.DBMS_SPACE TO DEV_USER;

After we created a test case to run DBMS_SPACE manually:

declare
      x int;
      y int;
    begin
      dbms_space.CREATE_INDEX_COST(
         'create index ABCD.TAB1_COL1_ID on ABCD.TAB1 (COL1_ID)'
         ,used_bytes=>x
         ,alloc_bytes=>y);
      dbms_output.put_line(x);
     dbms_output.put_line(y);
   end;

Error at line 1
ORA-01031: insufficient privileges
ORA-06512: at "SYS.DBMS_SPACE", line 2833
ORA-06512: at "SYS.DBMS_SPACE", line 2854
ORA-06512: at line 5

Key point is: DEV_USER run DBMS_SPACE which try to create index in the foreign schema ! To be able to do this DEV_USER should have an "GRANT CREATE ANY INDEX TO DEV_USER " right.

Wednesday, October 6, 2021

CPU Load

Есть команда vmstat, у неё есть столбец r (runqueue), который можно считать мерой загрузки сервера (load). Ещё есть команда uptime, она выводит на экран среднюю загрузку за 1 минуту (Load-1), за 5 минут (Load-5) и за 15 минут (Load-15).
Для любителей шарад - снимок с реальной системы Linux@x64.

Сравниите значения vmstat-r и load-1.
Какой вывод напрашивается ?

Часто считается, что Load в Линуксе, это синоним vmstat-r.
Т.е. если запустить vmstat 60, то столбец r - это то же самое, что и load-1 в uptime (одноминутное среднее).
Оказалось - нет.

Посмотрим ещё раз:

Среднее арифметическое по столбцу vmstat-r - это 1.8, а load average = 13,6.
Load Average - ближе к значению столбца vmstat-b.

Т.е. при расчёте load average, Линукс складывает процессы, которые на ЦПУ и процессы которые ждут окончания В/В (столбец b).

А потом значение Load мы видим в AWR:

Теперь понятно, что показывает sar -q , когда он показывает разные runq-sz и ldavg-1:

Такой подход (складывать ЦПУ + В/В) - это специфика Линукса.
В больших Юниксах - Solaris, AIX, HPUX - ЦПУ считается отдельно, а В/В-отдельно.

Хотя тут сложно сказать кто больше прав, если процесс часть выделенного ему кванта прожил на ЦПУ, а затем не использовав весь квант времени выполнил В/В и освободил процессор, то в какую статистику записывать такой процесс? в статистику ЦПУ или В/В или в обе?

Man для uptime прямо об этом говорит:

       System load averages is the average number of processes that are
       either in a runnable or uninterruptable state.  A process in a
       runnable state is either using the CPU or waiting to use the CPU.
       A process in uninterruptable state is waiting for some I/O
       access, eg waiting for disk.  The averages are taken over the
       three time intervals.  Load averages are not normalized for the
       number of CPUs in a system, so a load average of 1 means a single
       CPU system is loaded all the time while on a 4 CPU system it
       means it was idle 75% of the time.

Man для vmstat:

Procs

       r: The number of runnable processes (running or waiting for run time).
       b: The number of processes blocked waiting for I/O to complete.

Что показывает vmstat-r в разных ОС:

Solaris: run queue - показывает только процессы, стоящие в очереди к процессорам.
Процессы, которые работают на ЦПУ не учитываются. Поэтому vmstat-r на Solaris показывает более низкие значения, чем в других ОС.

Linux: on CPU + run queue - процессы, которые работают на ЦПУ + стоят в очереди к ЦПУ,
т.е. все процессы, которые в состоянии runnable.
AIX: on CPU+run queue.