note to mezelf: chunk CLOB?

Ever had a trouble while you were trying to print a variable, got an ORA-06502 error?

ORA-06502: PL/SQL: numeric or value error string

Cause: An arithmetic, numeric, string, conversion, or constraint error occurred. For example, this error occurs if an attempt is made to assign the value NULL to a variable declared NOT NULL, or if an attempt is made to assign an integer larger than 99 to a variable declared NUMBER(2).

Action: Change the data, how it is manipulated, or how it is declared so that values do not violate constraints.

If your variable is a CLOB it might be confusing as it was for me..

However, you ‘ll figure out the reason soon enough: Those string parts that you were collecting are bigger than 32K

And you ‘ll realize that you should tell it what to do.

Here is what I came across to. A big and special thanks to oracle forums, of course :)

PROCEDURE chunk_clob(p_clob CLOB) IS
v_buf_size VARCHAR2(32000);
v_chunk PLS_INTEGER;
v_clob CLOB := p_clob;
v_chunk := dbms_lob.getchunksize(v_clob);
v_len := dbms_lob.getlength(v_clob);
WHILE v_offset v_chunk
THEN v_size := v_chunk;
ELSE v_size := v_len - (v_offset - 1);
v_buf_size := NULL;
dbms_lob.READ(v_clob, v_size, v_offset, v_buf_size);
v_offset := v_offset + v_size;

– OKAY what is this and what am I going to do with this?

It ‘ll take care of your oversized strings so you get to see what your VAR has in it.



Oracle Database In-Memory and Hash Keys

Data Warehousing with Oracle

Hash keys are often used as primary keys in Data Vault environments. When loading dimensional data marts from a Data Vault schema, it seems to be obvious to use them as dimension keys, too. At least in combination with Oracle Database In-Memory, this is not a good idea.

View original post 14,906 more words

Limiting the percentage of ordered rows retrieved in Oracle 12c

Lczinkoc's Blog

In a previous post I compared two solutions for the same ranking
problem. Now I would like to compare two solutions for the same
percentages report.
The goal of the query: Let's see the first 5% rows of the total
rows according to the salary in descending way.
Let's consider the solution in Oracle 12c, where we can use the
new FETCH {FIRST|NEXT}  <pct> PERCENT ROWS clause:
One of the possible traditional solution uses
the cumulative distribution (CUME_DIST) analytic function.
Let's consider the execution plan for that query which 
uses the new FETCH {FIRST|NEXT} <pct> PERCENT ROWS clause:

Now we examine the execution plan of the query that uses the CUME_DIST analytic function:

We can observe that BOTH queries use the SAME EXECUTION plan,
but with different number of consistent gets (1551 versus 7!). 
Other metrics are same. 
I created a greater table:I executed the following queries:

Of course, I…

View original post 48 more words