Oracle 26ai Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/oracle-26ai/ Database-centric development Tue, 31 Mar 2026 06:36:18 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.4 https://www.salvis.com/blog/wp-content/uploads/2014/04/favicon.png Oracle 26ai Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/oracle-26ai/ 32 32 Using SQL Assertions to Enforce Temporal Data Integrity https://www.salvis.com/blog/2026/03/09/using-sql-assertions-to-enforce-temporal-data-integrity/ https://www.salvis.com/blog/2026/03/09/using-sql-assertions-to-enforce-temporal-data-integrity/#respond Mon, 09 Mar 2026 14:45:31 +0000 https://www.salvis.com/blog/?p=16264 Introduction More than twelve years ago, I described the multi-temporal features of Oracle Database in this blog post. In the conclusion, I wrote that I missed a temporal DML API, temporal integrity constraints, temporal joins, and temporal aggregations. These features are still missing today. However, in the latest version of Oracle AI […]

The post Using SQL Assertions to Enforce Temporal Data Integrity appeared first on Philipp Salvisberg's Blog.

]]> Introduction

More than twelve years ago, I described the multi-temporal features of Oracle Database in this blog post. In the conclusion, I wrote that I missed a temporal DML API, temporal integrity constraints, temporal joins, and temporal aggregations. These features are still missing today.

However, in the latest version of Oracle AI Database (23.26.1), SQL assertions make it possible to define temporal integrity constraints manually. In this post, I demonstrate how.

Data Model

There are various ways to model temporal data. In this post, I use the well-known non-temporal DEPT-EMP model as a basis and add a history table for each non-temporal table with a valid-time period named vt using the column vt_start for the beginning of the period and vt_end for the end of the period. Please note that Oracle Database uses half-open intervals for temporal periods and NULL for -∞ and +∞.

Non-temporal tables store the most recent version of the data, which is kept in their history tables. This simplifies access to the latest version and provides the expected performance for non-temporal data. The disadvantage is that the API must maintain redundant data. Note that the latest version is not necessarily the current version. The current version is the one whose valid-time period contains the current date and time.

This model versions all columns of the base table, potentially resulting in more rows in the history tables than necessary. Furthermore, the model does not support soft deletes. In other words, there is no is_deleted flag. This makes managing data integrity easier. No need to keep reference and structure data just because some deleted rows still reference it. In any case, this is sufficient for this blog post.

Setup

For the examples in this blog post, I used Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0.

Connected as SYS, I ran the following script to create the user DEMO with the necessary privileges.

1) DEMO user
create user demo identified by demo
   default tablespace users
   temporary tablespace temp
   quota unlimited on users;
   
grant create session to demo;
grant create table to demo;
grant create sequence to demo;
grant create assertion to demo;
User DEMO created.


Grant succeeded.


Grant succeeded.


Grant succeeded.


Grant succeeded.

Connected as DEMO, I ran the following script to implement the data model as outlined in the previous chapter with initial data.

2) Install model with data
create table dept (
   deptno      number(2, 0)      not null,
   dname       varchar2(14 char) not null,
   loc         varchar2(13 char) not null,
   constraint dept_pk primary key (deptno) deferrable initially immediate
);

create table dept_ht (
   hist_id     integer generated always as identity not null,
   vt_start    date              null,
   vt_end      date              null,
   deptno      number(2, 0)      not null,
   dname       varchar2(14 char) not null,
   loc         varchar2(13 char) not null,
   period for vt (vt_start, vt_end),
   constraint dept_ht_pk primary key (hist_id),
   constraint dept_ht_uk unique (deptno, vt_start) deferrable initially immediate,
   constraint dept_ht_dept_fk foreign key (deptno) references dept deferrable initially immediate,
   constraint dept_ht_vt_ck check (vt_start is null or vt_end is null or vt_start < vt_end) deferrable initially immediate
);

create index dept_ht_dept_fk_i on dept_ht (deptno);

create table emp (
   empno       number(4, 0)      not null,
   ename       varchar2(10 char) not null,
   job         varchar2(9 char)  not null,
   mgr         number(4, 0),
   hiredate    date              not null,
   sal         number(7, 2)      not null,
   comm        number(7, 2),
   deptno      number(2, 0)      not null,
   constraint emp_pk primary key (empno) deferrable initially immediate,
   constraint emp_emp_fk foreign key (mgr) references emp deferrable initially immediate,
   constraint emp_dept_fk foreign key (deptno) references dept deferrable initially immediate
);

create index emp_dept_fk_i on emp(deptno);
create index emp_emp_fk_i on emp(mgr);

create table emp_ht (
   hist_id     integer generated always as identity not null,
   vt_start    date              null,
   vt_end      date              null,
   empno       number(4, 0)      not null,
   ename       varchar2(10 char) not null,
   job         varchar2(9 char)  not null,
   mgr         number(4, 0)      null,
   hiredate    date              not null,
   sal         number(7, 2)      not null,
   comm        number(7, 2)      null,
   deptno      number(2, 0)      not null,
   period for vt (vt_start, vt_end),
   constraint emp_ht_pk primary key (hist_id),
   constraint emp_ht_uk unique (empno, vt_start) deferrable initially immediate,
   constraint emp_ht_emp_empno_fk foreign key (empno) references emp deferrable initially immediate,
   constraint emp_ht_emp_mgr_fk foreign key (mgr) references emp deferrable initially immediate,
   constraint emp_ht_dept_fk foreign key (deptno) references dept deferrable initially immediate,
   constraint emp_ht_vt_ck check (vt_start is null or vt_end is null or vt_start < vt_end) deferrable initially immediate
);

create index emp_ht_emp_fk on emp_ht (deptno);
create index emp_ht_dept_fk on emp_ht (mgr);

insert into dept (deptno, dname, loc)
values (10, 'ACCOUNTING', 'NEW YORK'),
       (20, 'RESEARCH',   'DALLAS'),
       (30, 'SALES',      'CHICAGO'),
       (40, 'OPERATIONS', 'BOSTON');

insert into dept_ht (deptno, dname, loc)
select deptno, dname, loc
  from dept;

insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
values (7566, 'JONES',  'MANAGER',   7839, date '1981-04-02', 2975, null, 20),
       (7698, 'BLAKE',  'MANAGER',   7839, date '1981-05-01', 2850, null, 30),
       (7782, 'CLARK',  'MANAGER',   7839, date '1981-06-09', 2450, null, 10),
       (7788, 'SCOTT',  'ANALYST',   7566, date '1987-04-19', 3000, null, 20),
       (7902, 'FORD',   'ANALYST',   7566, date '1981-12-03', 3000, null, 20),
       (7499, 'ALLEN',  'SALESMAN',  7698, date '1981-02-20', 1600,  300, 30),
       (7521, 'WARD',   'SALESMAN',  7698, date '1981-02-22', 1250,  500, 30),
       (7654, 'MARTIN', 'SALESMAN',  7698, date '1981-09-28', 1250, 1400, 30),
       (7844, 'TURNER', 'SALESMAN',  7698, date '1981-09-08', 1500,    0, 30),
       (7900, 'JAMES',  'CLERK',     7698, date '1981-12-03',  950, null, 30),
       (7934, 'MILLER', 'CLERK',     7782, date '1982-01-23', 1300, null, 10),
       (7369, 'SMITH',  'CLERK',     7902, date '1980-12-17',  800, null, 20),
       (7839, 'KING',   'PRESIDENT', null, date '1981-11-17', 5000, null, 10),
       (7876, 'ADAMS',  'CLERK',     7788, date '1987-05-23', 1100, null, 20);

insert into emp_ht (empno, ename, job, mgr, hiredate, sal, comm, deptno)
select empno, ename, job, mgr, hiredate, sal, comm, deptno
  from emp;

commit;
Table DEPT created.


Table DEPT_HT created.


Index DEPT_HT_DEPT_FK_I created.


Table EMP created.


Index EMP_DEPT_FK_I created.


Index EMP_EMP_FK_I created.


Table EMP_HT created.


Index EMP_HT_EMP_FK created.


Index EMP_HT_DEPT_FK created.


4 rows inserted.


4 rows inserted.


14 rows inserted.


14 rows inserted.


Commit complete.

Prohibit Overlapping Periods

Chris Saxon explains in this blog post how to prevent overlapping time ranges with SQL assertions. We use a similar approach here for dept_ht.

3) Create assertion: no overlapping in dept_ht for vt period
create assertion if not exists no_overlapping_dept_ht_vt_period_as
check (
   not exists (
      select 'a department version (d1)'
        from dept_ht d1
       where exists (
              select 'an overlapping department version (d2)'
                from dept_ht d2
               where d2.deptno = d1.deptno
                 and d2.hist_id != d1.hist_id
                 and (d1.vt_start is null or d2.vt_end is null or d1.vt_start < d2.vt_end)
                 and (d2.vt_start is null or d1.vt_end is null or d2.vt_start < d1.vt_end)
             )
   )
) deferrable initially immediate;
Assertion NO_OVERLAPPING_DEPT_HT_VT_PERIOD_AS created.

Let’s test the assertion. We defer all constraints to make the example easier to implement and read.

4) Overlapping test
set constraints all deferred;
delete from dept_ht where deptno = 10;
insert into dept_ht (deptno, dname, loc, vt_start, vt_end)
values (10, 'ACCOUNTING', 'NEW_YORK',   null,              date '2026-04-01'),
       (10, 'ACCOUNTING', 'WINTERTHUR', date '2026-03-01', null             );
commit;
Constraints ALL succeeded.


1 row deleted.


2 rows inserted.


Error starting at line : 6 in command -
commit
Error report -
ORA-02091: transaction rolled back
ORA-08601: SQL assertion (DEMO.NO_OVERLAPPING_DEPT_HT_VT_PERIOD_AS) violated.

https://docs.oracle.com/error-help/db/ora-02091/
02091. 00000 -  "transaction rolled back"
*Cause:    Also see error 2092. If the transaction is aborted at a remote
           site then you will only see 2091; if aborted at host then you will
           see 2092 and 2091.
*Action:   Add rollback segment and retry the transaction.

The test fails at line 6, at the commit statement, exactly as expected.

Let’s insert two adjacent (gapless) periods.

5) Non-overlapping test
set constraints all deferred;
delete from dept_ht where deptno = 10;
insert into dept_ht (deptno, dname, loc, vt_start, vt_end)
values (10, 'ACCOUNTING', 'NEW_YORK',   null,              date '2026-04-01'),
       (10, 'ACCOUNTING', 'WINTERTHUR', date '2026-04-01', null             );
commit;
Constraints ALL succeeded.


1 row deleted.


2 rows inserted.


Commit complete.

The test succeeds. So far so good.

However, this change leaves the redundant current-state copy in dept out of sync. After any change to dept_ht, the API should execute a statement like the following within the same transaction:

6) Updating redundancy in DEPT from DEPT_HT
update dept d
   set d.dname = ht.dname,
       d.loc   = ht.loc
  from (
          select deptno, dname, loc
            from dept_ht
           where deptno = 10
           order by vt_start desc nulls first
           fetch first 1 row only
       ) ht
 where d.deptno = ht.deptno;
1 row updated.

Of course, we would need a similar SQL assertion for the period in emp_ht. However, this is not essential for this blog post. Therefore, we will skip it.

Temporal Foreign Keys

Let’s now look at another typical problem in temporal data models: Temporal foreign keys. We have two temporal foreign keys in our model:

  • emp_ht_emp_mgr_fk
  • emp_ht_dept_fk

Although the foreign key technically references a non-temporal table, the business rule is temporal: the referenced entity must be valid throughout the relevant period of the referencing row.

In this example, that means a manager must exist for the entire validity period of the employee version.

Sounds complicated? Let’s look at an example based on emp_ht_emp_mgr_fk.

7) Inconsistent emp_ht_emp_mgr_fk
update emp_ht
   set vt_start = hiredate;

select e.vt_start, e.vt_end, e.empno, e.ename, e.mgr, m.ename as mgr_name, m.hiredate as mgr_hiredate,
       e.mgr is not null and hm.empno is null as is_inconsistent
 from emp_ht e
 left join emp m
   on m.empno = e.mgr
 left join emp_ht hm
   on hm.empno = e.mgr
      and (hm.vt_start is null or (e.vt_start is not null and hm.vt_start <= e.vt_start))
      and (hm.vt_end is null or e.vt_start is null or hm.vt_end > e.vt_start)
order by e.empno;

rollback;
14 rows updated.


VT_START   VT_END          EMPNO ENAME             MGR MGR_NAME   MGR_HIREDATE IS_INCONSISTENT
---------- ---------- ---------- ---------- ---------- ---------- ------------ ---------------
1980-12-17                  7369 SMITH            7902 FORD       1981-12-03   true           
1981-02-20                  7499 ALLEN            7698 BLAKE      1981-05-01   true           
1981-02-22                  7521 WARD             7698 BLAKE      1981-05-01   true           
1981-04-02                  7566 JONES            7839 KING       1981-11-17   true           
1981-09-28                  7654 MARTIN           7698 BLAKE      1981-05-01   false          
1981-05-01                  7698 BLAKE            7839 KING       1981-11-17   true           
1981-06-09                  7782 CLARK            7839 KING       1981-11-17   true           
1987-04-19                  7788 SCOTT            7566 JONES      1981-04-02   false          
1981-11-17                  7839 KING                                          false          
1981-09-08                  7844 TURNER           7698 BLAKE      1981-05-01   false          
1987-05-23                  7876 ADAMS            7788 SCOTT      1987-04-19   false          
1981-12-03                  7900 JAMES            7698 BLAKE      1981-05-01   false          
1981-12-03                  7902 FORD             7566 JONES      1981-04-02   false          
1982-01-23                  7934 MILLER           7782 CLARK      1981-06-09   false          

14 rows selected. 


Rollback complete.

First, we set the start of the valid period for all employees according to their hire date.

Then, we queried the employees and their managers at the start of their valid time period. Employees without a manager at that time are marked with true in the result column is_inconsistent.

CLARK, for example, was hired on 9 June 1981. His manager, KING, was hired on 17 November 1981. Consequently, CLARK had no assigned manager between 9 June 1981 and 17 November 1981. This is an invalid temporal foreign key. To resolve this issue, we must either assign CLARK a manager for this period or amend KING’s valid time period, which would likely require adjusting his hire date as well.

Valid Manager At the Start of a Period

Let’s implement the check in the previous query as an SQL assertion.

8) Create assertion: cover_vt_start_in_emp_ht_emp_mgr_fk_as
create assertion if not exists cover_vt_start_in_emp_ht_emp_mgr_fk_as
check (
   not exists (
      select 'an employee version (e)'
        from emp_ht e
       where e.mgr is not null
         and not exists (
                select 'a manager version (m) covering e.vt_start'
                  from emp_ht m
                 where m.empno = e.mgr
                   and (m.vt_start is null or (e.vt_start is not null and m.vt_start <= e.vt_start))
                   and (m.vt_end is null or e.vt_start is null or m.vt_end > e.vt_start)
             )
   )
) deferrable initially immediate;
Assertion COVER_VT_START_IN_EMP_HT_EMP_MGR_FK_AS created.

Let’s try to create a gap in manager coverage by setting the vt_start to a non-null value for a manager.

9) Test gap in manager coverage (vt_start)
update emp_ht
   set vt_start = hiredate
 where ename = 'KING';
Error starting at line : 1 in command -
update emp_ht
   set vt_start = hiredate
 where ename = 'KING'
Error report -
ORA-08601: SQL assertion (DEMO.COVER_VT_START_IN_EMP_HT_EMP_MGR_FK_AS) violated.

https://docs.oracle.com/error-help/db/ora-08601/

Good. The update fails because JONES, BLAKE and CLARK would have no manager assigned at the beginning of their valid time period.

Now let’s try to set vt_start for an employee who is not a manager.

10) Test no gap in manager coverage (vt_start)
update emp_ht
   set vt_start = hiredate
 where ename = 'ADAMS';
rollback;
1 row updated.


Rollback complete.

The update succeeded because ADAMS is not a manager and, therefore, no gap in manager coverage was created.

Valid Manager At the End of a Period

The previous SQL assertion ensures that manager coverage exists at the start of a period. However, to guarantee temporal data integrity for the entire period, we need an additional SQL assertion.

11) Create assertion: cover_vt_end_in_emp_ht_emp_mgr_fk_as
create assertion if not exists cover_vt_end_in_emp_ht_emp_mgr_fk_as
check (
   not exists (
      select 'an employee version (e)'
        from emp_ht e
       where e.mgr is not null
         and exists (
                select 'a manager version (m) ending before e.vt_end'
                  from emp_ht m
                 where m.empno = e.mgr
                   and m.vt_end is not null
                   and (e.vt_start is null or m.vt_end > e.vt_start)
                   and (e.vt_end is null or m.vt_end < e.vt_end)
                   and not exists (
                          select 'a manager version (m2) covering the m.vt_end'
                            from emp_ht m2
                           where m2.empno = e.mgr
                             and m2.hist_id != m.hist_id
                             and (m2.vt_start is null or m2.vt_start <= m.vt_end)
                             and (m2.vt_end is null or m2.vt_end > m.vt_end)
                       )
             )
   )
) deferrable initially immediate;
Assertion COVER_VT_END_IN_EMP_HT_EMP_MGR_FK_AS created.

Let’s try now to set the vt_end to a non-null value of a manager.

12) Test gap in manager coverage (vt_end)
update emp_ht
   set vt_end = date '2100-01-01'
 where ename = 'KING';
Error starting at line : 1 in command -
update emp_ht
   set vt_end = date '2100-01-01'
 where ename = 'KING'
Error at Command Line : 1 Column : 8
Error report -
SQL Error: ORA-08601: SQL assertion (DEMO.COVER_VT_END_IN_EMP_HT_EMP_MGR_FK_AS) violated.

https://docs.oracle.com/error-help/db/ora-08601/

Good. The update failed because JONES, BLAKE and CLARK would have had no manager from 1 January 2100 until the end of time.

13) Test no gap in manager coverage (vt_end)
update emp_ht
   set vt_end = date '2100-01-01'
  where ename = 'ADAMS';
rollback;
1 row updated.


Rollback complete.

The update succeeded because ADAMS is not a manager and, therefore, no gap in manager coverage was created.

Well, those were just simple test cases. What would happen if we left a one-day gap between versions of the history? Would this be detected?

14) Test gap in manager coverage of multiple versions
set constraints all deferred;
delete from emp_ht where ename = 'KING';
insert into emp_ht (vt_start, vt_end, empno, ename, job, hiredate, sal, deptno)
values (null,              date '1981-11-17', 7839, 'KING', 'PRESIDENT', date '1981-11-17', 2000, 10),
       (date '1981-11-17', date '2100-01-01', 7839, 'KING', 'PRESIDENT', date '1981-11-17', 4500, 10),
       (date '2100-01-02', date '2200-01-01', 7839, 'KING', 'PRESIDENT', date '1981-11-17', 4600, 10),
       (date '2200-01-01', null             , 7839, 'KING', 'PRESIDENT', date '1981-11-17', 5000, 10);
commit;
Constraints ALL succeeded.


1 row deleted.


4 rows inserted.


Error starting at line : 8 in command -
commit
Error report -
ORA-02091: transaction rolled back
ORA-08601: SQL assertion (DEMO.COVER_VT_END_IN_EMP_HT_EMP_MGR_FK_AS) violated.

https://docs.oracle.com/error-help/db/ora-02091/
02091. 00000 -  "transaction rolled back"
*Cause:    Also see error 2092. If the transaction is aborted at a remote
           site then you will only see 2091; if aborted at host then you will
           see 2092 and 2091.
*Action:   Add rollback segment and retry the transaction.

Yes! The commit statement failed because no version covered 1 January 2100.

When we fix the date on line 6, the transaction should succeed. Let’s try that.

15) Test no gap in manager coverage of multiple versions
set constraints all deferred;
delete from emp_ht where ename = 'KING';
insert into emp_ht (vt_start, vt_end, empno, ename, job, hiredate, sal, deptno)
values (null,              date '1981-11-17', 7839, 'KING', 'PRESIDENT', date '1981-11-17', 2000, 10),
       (date '1981-11-17', date '2100-01-01', 7839, 'KING', 'PRESIDENT', date '1981-11-17', 4500, 10),
       (date '2100-01-01', date '2200-01-01', 7839, 'KING', 'PRESIDENT', date '1981-11-17', 4600, 10),
       (date '2200-01-01', null             , 7839, 'KING', 'PRESIDENT', date '1981-11-17', 5000, 10);
commit;
Constraints ALL succeeded.


1 row deleted.


4 rows inserted.


Commit complete.

Perfect. This works.

We have successfully enforced temporal referential integrity for the manager relationship using SQL assertions.

Summary

In this blog post, we created the SQL assertion no_overlapping_dept_ht_vt_period_as to ensure validity periods in the table dept_ht do not overlap.

We enforced temporal referential data integrity for the foreign key emp_ht_emp_mgr_fk using the SQL assertions cover_vt_start_in_emp_ht_emp_mgr_fk_as and cover_vt_end_in_emp_ht_emp_mgr_fk_as. This means that an employee always has a valid manager assigned throughout their validity period. Any gaps in manager coverage are detected correctly.

Adapting these SQL assertions for use in templates for temporal API generators should not be too difficult. All necessary information is in the Oracle data dictionary. With some additional metadata, we can generate additional SQL assertions for related, optional topics such as:

  • Enforce adjacent periods (no gaps)
  • Disallow adjacent periods with the same business values (enforce merge of periods)
  • Disallow different business keys across periods (enforce business key updates on all versions)
  • Disallow new versions for changes to non-versioned columns only (enforce update of all versions instead)

Although SQL assertions make it easier to enforce the integrity of temporal data, the use of temporal tables measurably increases complexity. Therefore, only use temporal tables if you really need to. Document which columns require temporal handling and explain why.

In any case, the integration of SQL assertions into Oracle AI Database makes the use of temporal tables much easier.

The post Using SQL Assertions to Enforce Temporal Data Integrity appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2026/03/09/using-sql-assertions-to-enforce-temporal-data-integrity/feed/ 0 Enforcing Acyclic Hierarchies With SQL Assertions https://www.salvis.com/blog/2026/02/23/enforcing-acyclic-hierarchies-with-sql-assertions/ https://www.salvis.com/blog/2026/02/23/enforcing-acyclic-hierarchies-with-sql-assertions/#respond Mon, 23 Feb 2026 16:24:15 +0000 https://www.salvis.com/blog/?p=15957 Introduction Referential integrity constraints have been available since version 7 of the Oracle Database. While these constraints ensure that referenced rows exist, they cannot express more complex integrity rules that span multiple rows or tables. Check constraints are similarly limited, as they can only validate conditions on the columns of a single […]

The post Enforcing Acyclic Hierarchies With SQL Assertions appeared first on Philipp Salvisberg's Blog.

]]>

Introduction

Referential integrity constraints have been available since version 7 of the Oracle Database. While these constraints ensure that referenced rows exist, they cannot express more complex integrity rules that span multiple rows or tables. Check constraints are similarly limited, as they can only validate conditions on the columns of a single row.

The latest version of the Oracle AI Database (23.26.1) introduced SQL Assertions, enabling us to define cross-row and cross-table checks declaratively.

SQL Assertions support a wide range of use cases where data must satisfy global consistency rules. One particularly interesting example is ensuring that hierarchical structures remain free of cycles.

In this blog post, I will demonstrate how SQL Assertions can detect and prevent cycles in hierarchical data structures.

Setup

For the examples in this blog post, I used an Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0.

Connected as SYS I ran the following script to create the user DEMO with the necessary privileges.

1) DEMO user
create user demo identified by demo
   default tablespace users
   temporary tablespace temp
   quota unlimited on users;

grant create session, create table, create assertion to demo;

Connected as DEMO I ran the following script to create the famous tables DEPT and EMP with initial data:

2) Install DEPT/EMP example
create table dept (
   deptno number(2, 0)      not null constraint dept_pk primary key,
   dname  varchar2(14 char) not null,
   loc    varchar2(13 char) not null
);

create table emp (
   empno    number(4, 0)      not null  constraint emp_pk primary key,
   ename    varchar2(10 char) not null,
   job      varchar2(9 char)  not null,
   mgr      number(4, 0)                constraint emp_mgr_fk references emp,
   hiredate date              not null,
   sal      number(7, 2)      not null,
   comm     number(7, 2),
   deptno   number(2, 0)      not null  constraint emp_deptno_fk references dept
);

create index emp_deptno_fk_i on emp(deptno);
create index emp_mgr_fk_i on emp(mgr);

insert into dept (deptno, dname, loc)
values (10, 'ACCOUNTING', 'NEW YORK'),
       (20, 'RESEARCH',   'DALLAS'),
       (30, 'SALES',      'CHICAGO'),
       (40, 'OPERATIONS', 'BOSTON');

insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
values (7566, 'JONES',  'MANAGER',   7839, date '1981-04-02', 2975, null, 20),
       (7698, 'BLAKE',  'MANAGER',   7839, date '1981-05-01', 2850, null, 30),
       (7782, 'CLARK',  'MANAGER',   7839, date '1981-06-09', 2450, null, 10),
       (7788, 'SCOTT',  'ANALYST',   7566, date '1987-04-19', 3000, null, 20),
       (7902, 'FORD',   'ANALYST',   7566, date '1981-12-03', 3000, null, 20),
       (7499, 'ALLEN',  'SALESMAN',  7698, date '1981-02-20', 1600,  300, 30),
       (7521, 'WARD',   'SALESMAN',  7698, date '1981-02-22', 1250,  500, 30),
       (7654, 'MARTIN', 'SALESMAN',  7698, date '1981-09-28', 1250, 1400, 30),
       (7844, 'TURNER', 'SALESMAN',  7698, date '1981-09-08', 1500,    0, 30),
       (7900, 'JAMES',  'CLERK',     7698, date '1981-12-03',  950, null, 30),
       (7934, 'MILLER', 'CLERK',     7782, date '1982-01-23', 1300, null, 10),
       (7369, 'SMITH',  'CLERK',     7902, date '1980-12-17',  800, null, 20),
       (7839, 'KING',   'PRESIDENT', null, date '1981-11-17', 5000, null, 10),
       (7876, 'ADAMS',  'CLERK',     7788, date '1987-05-23', 1100, null, 20);
commit;

Hierarchical SQL Query

Let’s look at the acyclic data first.

3) Hierarchical Query
column ename format a15
 select lpad(' ', 2 * (level - 1)) || ename as ename,
        empno,
        mgr
   from emp
connect by prior empno = mgr
  start with ename = 'KING';
ENAME                EMPNO        MGR
--------------- ---------- ----------
KING                  7839           
  JONES               7566       7839
    SCOTT             7788       7566
      ADAMS           7876       7788
    FORD              7902       7566
      SMITH           7369       7902
  BLAKE               7698       7839
    ALLEN             7499       7698
    WARD              7521       7698
    MARTIN            7654       7698
    TURNER            7844       7698
    JAMES             7900       7698
  CLARK               7782       7839
    MILLER            7934       7782

14 rows selected.

Detecting Cycles Via SQL Query

We see that KING is the only employee without a manager. With the next update, we create a cycle by making SCOTT the manager of KING:

4) Create Cycle
update emp 
   set mgr = 7788 
 where empno = 7839;
commit;

When we now re-run the previous query, we get an ORA-01436: CONNECT BY loop in user data error.

Of course, we can work around it by adding a NOCYCLE parameter to produce a result:

5) NOCYCLE Hierarchical Query
 select lpad(' ', 2 * (level - 1)) || ename as ename,
        empno,
        mgr
   from emp
connect by nocycle prior empno = mgr
  start with ename = 'KING'; 
ENAME                EMPNO        MGR
--------------- ---------- ----------
KING                  7839       7788
  JONES               7566       7839
    SCOTT             7788       7566
      ADAMS           7876       7788
    FORD              7902       7566
      SMITH           7369       7902
  BLAKE               7698       7839
    ALLEN             7499       7698
    WARD              7521       7698
    MARTIN            7654       7698
    TURNER            7844       7698
    JAMES             7900       7698
  CLARK               7782       7839
    MILLER            7934       7782

14 rows selected.

However, I want a query that shows the reason for the cycle, rather than ignoring it. Something like this:

6) Detecting Cycles
column ename_path format a20
select *
  from (
          select e.ename,
                 e.empno,
                 e.mgr,
                 connect_by_iscycle as is_cycle,
                 sys_connect_by_path(e.ename, '/') as ename_path
            from emp e
         connect by nocycle prior e.empno = e.mgr
           start with e.mgr is not null
       )
 where is_cycle = 1;
ENAME                EMPNO        MGR   IS_CYCLE ENAME_PATH          
--------------- ---------- ---------- ---------- --------------------
JONES                 7566       7839          1 /SCOTT/KING/JONES   
SCOTT                 7788       7566          1 /KING/JONES/SCOTT   
KING                  7839       7788          1 /JONES/SCOTT/KING

SQL Assertion Using Connect By

According to the CREATE ASSERTION syntax diagram, we should be able to use the previous query within the SQL Assertion as follows:

7) Create assertion with CONNECT_BY
create assertion if not exists emp_mgr_fk_no_cycle_as
   check (
      not exists (
         select 'cycle detected'
           from (
                   select connect_by_iscycle as is_cycle
                     from emp e
                  connect by nocycle prior e.empno = e.mgr
                    start with e.mgr is not null
                )
          where is_cycle = 1
      )
   );
ORA-08689: CREATE ASSERTION failed
ORA-08677: Certain SQL functions are not supported.

Unfortunately, this does not work. We get a generic error. The documentation for ORA-08677: Certain SQL functions are not supported. does not reveal the culprit either. However, there is a rather long list of limitations listed at the end of this section for the CREATE ASSERTION statement in the SQL Language Reference.

After some experimentation, I have concluded that as of version 23.26.1, hierarchical queries are not supported in SQL assertions and that this limitation is not explicitly documented. (Updated on 2026-03-30: The SQL Language Reference now lists “Hierarchical queries” as a feature that cannot be used with assertions.)

SQL Assertion Using Joins

It would be useful to be able to use hierarchical queries to identify cycles within hierarchies.

However, we can tighten up the business requirements. From

“Cycles are not allowed for the emp_mgr_fk relationship.”

to

“The number of levels in the emp_mgr_fk relationship is limited to 5.”

Now we can rewrite the CREATE ASSERTION statement like this:

8) Create assertion with joins
create assertion if not exists emp_mgr_fk_no_cycle_as
   check (
      not exists (
         select '6 Levels detected, cycle assumed'
           from emp e1, emp e2, emp e3, emp e4, emp e5, emp e6
          where e1.mgr is not null and e1.mgr = e2.empno
            and e2.mgr is not null and e2.mgr = e3.empno
            and e3.mgr is not null and e3.mgr = e4.empno
            and e4.mgr is not null and e4.mgr = e5.empno
            and e5.mgr is not null and e5.mgr = e6.empno
      )
   );
ORA-08689: CREATE ASSERTION failed
ORA-08601: SQL assertion (DEMO.EMP_MGR_FK_NO_CYCLE_AS) violated.

This error is expected since we have a cycle in our data. Let’s fix that.

9) Remove Cycle
update emp 
   set mgr = null 
 where ename = 'KING';
commit;

Let’s try to create the SQL Assertion again.

10) Create assertion with joins (try again)
create assertion if not exists emp_mgr_fk_no_cycle_as
   check (
      not exists (
         select '6 Levels detected, cycle assumed'
           from emp e1, emp e2, emp e3, emp e4, emp e5, emp e6
          where e1.mgr is not null and e1.mgr = e2.empno
            and e2.mgr is not null and e2.mgr = e3.empno
            and e3.mgr is not null and e3.mgr = e4.empno
            and e4.mgr is not null and e4.mgr = e5.empno
            and e5.mgr is not null and e5.mgr = e6.empno
      )
   );
Assertion EMP_MGR_FK_NO_CYCLE_AS created.

Success!

This approach enforces acyclic hierarchies and additionally limits the number of hierarchical levels to 5.

For real-life applications, you may wish to increase the number of levels to more than 5. In any case, you should be able to decide on a suitable maximum number of levels. The number of joins will match the number of levels. The code for that is boring but not too complicated.

Test Cases

Let’s run some tests to verify if the SQL Assertion behaves as expected.

11) Test cases
set echo on
-- fails (cycle)
update emp
   set mgr = (select empno from emp where ename = 'SCOTT')
 where ename = 'KING';

-- fails (cycle)
update emp
   set mgr = (select empno from emp where ename = 'SMITH')
 where ename = 'JONES';

-- succeeds
insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
values (1000, 'LEVEL5', 'TESTER', (select empno from emp where ename = 'ADAMS'), date '2026-02-01', 1000, null, 10);

-- fails (6 levels, no cycle)
insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
values (1001, 'LEVEL6', 'TESTER', (select empno from emp where ename = 'LEVEL5'), date '2026-02-01', 1100, null, 20);
SQL> -- fails (cycle)
SQL> update emp
  2  	set mgr = (select empno from emp where ename = 'SCOTT')
  3   where ename = 'KING';
update emp
*
ERROR at line 1:
ORA-08601: SQL assertion (DEMO.EMP_MGR_FK_NO_CYCLE_AS) violated.
Help: https://docs.oracle.com/error-help/db/ora-08601/


SQL> 
SQL> -- fails (cycle)
SQL> update emp
  2  	set mgr = (select empno from emp where ename = 'SMITH')
  3   where ename = 'JONES';
update emp
       *
ERROR at line 1:
ORA-08601: SQL assertion (DEMO.EMP_MGR_FK_NO_CYCLE_AS) violated.
Help: https://docs.oracle.com/error-help/db/ora-08601/


SQL> 
SQL> -- succeeds
SQL> insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
  2  values (1000, 'LEVEL5', 'TESTER', (select empno from emp where ename = 'ADAMS'), date '2026-02-01', 1000, null, 10);

1 row created.

SQL> 
SQL> -- fails (6 levels, no cycle)
SQL> insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
  2  values (1001, 'LEVEL6', 'TESTER', (select empno from emp where ename = 'LEVEL5'), date '2026-02-01', 1100, null, 20);
insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
            *
ERROR at line 1:
ORA-08601: SQL assertion (DEMO.EMP_MGR_FK_NO_CYCLE_AS) violated.
Help: https://docs.oracle.com/error-help/db/ora-08601/

Conclusion

SQL Assertions allow us to implement integrity rules that were previously difficult to enforce when taking factors such as concurrency and performance into account. They allow us to perform consistency checks in the database layer instead of relying on application logic.

Although the inability to use hierarchical queries within SQL Assertions is a significant limitation, the join-based approach presented in this post can effectively prevent hierarchical cycles and ensure consistency through a purely declarative solution. For most real-life data models, limiting the depth of the hierarchy should be a feasible workaround.

SQL Assertions close one of the last major gaps toward Codd’s principle of integrity independence (Rule 10 of Codd’s 12 rules), making declarative data integrity in the Oracle AI Database nearly complete.

Updated on 2026-03-30: The SQL Language Reference now lists “Hierarchical queries” as a feature that cannot be used with assertions.

The post Enforcing Acyclic Hierarchies With SQL Assertions appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2026/02/23/enforcing-acyclic-hierarchies-with-sql-assertions/feed/ 0 Avoid Implicit Type Conversion in JSON Access https://www.salvis.com/blog/2025/01/28/avoid-implicit-type-conversion-in-json-access/ Tue, 28 Jan 2025 16:38:55 +0000 https://www.salvis.com/blog/?p=13804 Introduction Before comparing two values, the Oracle Database automatically ensures that both values have the same data type. It converts one of the values to match the data type of the other value. The SQL Language Reference manual describes when and how implicit data conversions happen. However, Oracle recommends that you convert […]

The post Avoid Implicit Type Conversion in JSON Access appeared first on Philipp Salvisberg's Blog.

]]> Introduction

Before comparing two values, the Oracle Database automatically ensures that both values have the same data type. It converts one of the values to match the data type of the other value. The SQL Language Reference manual describes when and how implicit data conversions happen. However, Oracle recommends that you convert data types explicitly. This ensures consistent results and better performance.

I am using JSON relational duality views in my current project. During development, I have stumbled across some implicit data conversions that I was unaware of and that are causing poor performance. I will use a simplified example to show you what I mean.

  1. Setup
  2. JSON-relational Duality View
  3. JSON Data Types
  4. Explicit Conversion
  5. JSON Collection View
  6. Conclusion

1. Setup

I’ve tested this example with an Oracle Database 23.6 and 23.7.

In a schema of your choice you can run the following setup script:

1) Setup table dept and emp
drop table if exists emp;
drop table if exists dept;

create table dept (
   deptno number(2, 0)      not null constraint dept_pk primary key,
   dname  varchar2(14 char) not null,
   loc    varchar2(13 char) not null
);

create table emp (
   empno    number(4, 0)      not null  constraint emp_pk primary key,
   ename    varchar2(10 char) not null,
   job      varchar2(9 char)  not null,
   mgr      number(4, 0)                constraint emp_mgr_fk references emp,
   hiredate date              not null,
   sal      number(7, 2)      not null,
   comm     number(7, 2),
   deptno   number(2, 0)      not null  constraint emp_deptno_fk references dept
);

insert into dept (deptno, dname, loc)
values (10, 'ACCOUNTING', 'NEW YORK'),
       (20, 'RESEARCH',   'DALLAS'),
       (30, 'SALES',      'CHICAGO'),
       (40, 'OPERATIONS', 'BOSTON');

insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
values (7566, 'JONES',  'MANAGER',   7839, date '1981-04-02', 2975, null, 20),
       (7698, 'BLAKE',  'MANAGER',   7839, date '1981-05-01', 2850, null, 30),
       (7782, 'CLARK',  'MANAGER',   7839, date '1981-06-09', 2450, null, 10),
       (7788, 'SCOTT',  'ANALYST',   7566, date '1987-04-19', 3000, null, 20),
       (7902, 'FORD',   'ANALYST',   7566, date '1981-12-03', 3000, null, 20),
       (7499, 'ALLEN',  'SALESMAN',  7698, date '1981-02-20', 1600,  300, 30),
       (7521, 'WARD',   'SALESMAN',  7698, date '1981-02-22', 1250,  500, 30),
       (7654, 'MARTIN', 'SALESMAN',  7698, date '1981-09-28', 1250, 1400, 30),
       (7844, 'TURNER', 'SALESMAN',  7698, date '1981-09-08', 1500,    0, 30),
       (7900, 'JAMES',  'CLERK',     7698, date '1981-12-03',  950, null, 30),
       (7934, 'MILLER', 'CLERK',     7782, date '1982-01-23', 1300, null, 10),
       (7369, 'SMITH',  'CLERK',     7902, date '1980-12-17',  800, null, 20),
       (7839, 'KING',   'PRESIDENT', null, date '1981-11-17', 5000, null, 10),
       (7876, 'ADAMS',  'CLERK',     7788, date '1987-05-23', 1100, null, 20);

begin
   dbms_stats.gather_table_stats(user, 'dept');
   dbms_stats.gather_table_stats(user, 'emp');
end;
/

alter session set nls_date_format = 'YYYY-MM-DD';
column deptno format a6
column dname format a10
column loc format a9
column empid format a8
column empno format a5
column ename format a6
column mgr format a4
column sal format a4
column comm format a4

select * from dept;
select * from emp;
Table EMP dropped.


Table DEPT dropped.


Table DEPT created.


Table EMP created.


4 rows inserted.


14 rows inserted.


PL/SQL procedure successfully completed.


Session altered.


DEPTNO DNAME      LOC      
------ ---------- ---------
    10 ACCOUNTING NEW YORK 
    20 RESEARCH   DALLAS   
    30 SALES      CHICAGO  
    40 OPERATIONS BOSTON   


EMPNO ENAME  JOB        MGR HIREDATE    SAL COMM DEPTNO
----- ------ --------- ---- ---------- ---- ---- ------
 7566 JONES  MANAGER   7839 1981-04-02 2975          20
 7698 BLAKE  MANAGER   7839 1981-05-01 2850          30
 7782 CLARK  MANAGER   7839 1981-06-09 2450          10
 7788 SCOTT  ANALYST   7566 1987-04-19 3000          20
 7902 FORD   ANALYST   7566 1981-12-03 3000          20
 7499 ALLEN  SALESMAN  7698 1981-02-20 1600  300     30
 7521 WARD   SALESMAN  7698 1981-02-22 1250  500     30
 7654 MARTIN SALESMAN  7698 1981-09-28 1250 1400     30
 7844 TURNER SALESMAN  7698 1981-09-08 1500    0     30
 7900 JAMES  CLERK     7698 1981-12-03  950          30
 7934 MILLER CLERK     7782 1982-01-23 1300          10
 7369 SMITH  CLERK     7902 1980-12-17  800          20
 7839 KING   PRESIDENT      1981-11-17 5000          10
 7876 ADAMS  CLERK     7788 1987-05-23 1100          20

14 rows selected.

The model has primary and foreign keys which are required for the duality views. However, the constraints do not need to be enabled.

2. JSON-relational Duality View

Now let’s create an updateable duality view for the model we created earlier.

2) Create duality view dept_dv
create or replace json duality view dept_dv as
dept @insert @update @delete
{
   _id: deptno
   dname
   loc
   emps: emp @insert @update @delete
      {
         empno
         ename
         job
         emp @unnest @link(from: [mgr])
            {
               mgr    : empno @nocheck
               mgrname: ename @nocheck
            }
         hiredate
         sal
         comm
      }
};
Json duality view DEPT_DV created.

We can query the department 10 as follows:

3) Query deptno 10 in dept_dv
column json_data format a50
alter session disable parallel query;
set pagesize 1000

select json_serialize(dv.data returning varchar2 pretty) as json_data
  from dept_dv dv
 where dv.data."_id" = 10;
Session altered.


JSON_DATA
--------------------------------------------------
{
  "_id" : 10,
  "_metadata" :
  {
    "etag" : "E0146035FE26EE16D4968A21E6350D81",
    "asof" : "00002604AFC8A4BC"
  },
  "dname" : "ACCOUNTING",
  "loc" : "NEW YORK",
  "emps" :
  [
    {
      "empno" : 7782,
      "ename" : "CLARK",
      "job" : "MANAGER",
      "mgr" : 7839,
      "mgrname" : "KING",
      "hiredate" : "1981-06-09T00:00:00",
      "sal" : 2450,
      "comm" : null
    },
    {
      "empno" : 7839,
      "ename" : "KING",
      "job" : "PRESIDENT",
      "hiredate" : "1981-11-17T00:00:00",
      "sal" : 5000,
      "comm" : null
    },
    {
      "empno" : 7934,
      "ename" : "MILLER",
      "job" : "CLERK",
      "mgr" : 7782,
      "mgrname" : "CLARK",
      "hiredate" : "1982-01-23T00:00:00",
      "sal" : 1300,
      "comm" : null
    }
  ]
}

The where clause in line 7 contains an implicit conversion. It’s not that obvious and the execution plan does not help to spot it either.

4) Execution plan
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------
SQL_ID  8nns7xgu0v6vu, child number 4
-------------------------------------
select json_serialize(dv.data returning varchar2 pretty) as json_data   
from dept_dv dv  where dv.data."_id" = 10
 
Plan hash value: 2166484641
 
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |       |       |     7 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    10 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | EMP_PK  |     1 |       |     0   (0)|          |
|   3 |  SORT GROUP BY              |         |     1 |    38 |            |          |
|*  4 |   TABLE ACCESS FULL         | EMP     |     5 |   190 |     3   (0)| 00:00:01 |
|   5 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  6 |   INDEX UNIQUE SCAN         | DEPT_PK |     1 |       |     0   (0)|          |
---------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("OUTER_ALIAS2"."EMPNO"=:B1)
   4 - filter("OUTER_ALIAS1"."DEPTNO"=:B1)
   6 - access("DEPTNO"=10)

The highlighted lines show that a unique index scan has been performed for deptno 10. This looks good. So where does the implicit conversion take place?

3. JSON Data Types

The condition dv.data."_id" = 10 in the where clause compares a JSON data type with a numeric data type. As a result, the Oracle Database needs to convert one of the values. It decided to convert the JSON to a numeric value. That’s what we see in the execution plan.

Really? Can we prove this claim? Yes, with the following statement.

5) Determine JSON data type
select is_json_condition, value
  from (
          select deptno is json as is_json,
                 deptno is json(value) as is_json_value,
                 deptno is json(array) as is_json_array,
                 deptno is json(object) as is_json_object,
                 deptno is json(scalar) as is_json_scalar,
                 deptno is json(scalar number) as is_json_scalar_number,
                 deptno is json(scalar string) as is_json_scalar_string,
                 deptno is json(scalar binary_double) as is_json_scalar_binary_double,
                 deptno is json(scalar binary_float) as is_json_scalar_binary_float,
                 deptno is json(scalar date) as is_json_scalar_date,
                 deptno is json(scalar timestamp) as is_json_scalar_timestamp,
                 deptno is json(scalar timestamp with time zone) as is_json_scalar_timestamp_with_time_zone,
                 deptno is json(scalar null) as is_json_scalar_null,
                 deptno is json(scalar boolean) as is_json_scalar_boolean,
                 deptno is json(scalar binary) as is_json_scalar_binary,
                 deptno is json(scalar interval year to month) as is_json_scalar_interval_year_to_month,
                 deptno is json(scalar interval day to second) as is_json_scalar_interval_day_to_second
            from (select dv.data."_id" as deptno from dept_dv dv where rownum = 1)
       ) src unpivot (
          value for is_json_condition in (
             is_json,
             is_json_value,
             is_json_array,
             is_json_object,
             is_json_scalar,
             is_json_scalar_number,
             is_json_scalar_string,
             is_json_scalar_binary_double,
             is_json_scalar_binary_float,
             is_json_scalar_date,
             is_json_scalar_timestamp,
             is_json_scalar_timestamp_with_time_zone,
             is_json_scalar_null,
             is_json_scalar_boolean,
             is_json_scalar_binary,
             is_json_scalar_interval_year_to_month,
             is_json_scalar_interval_day_to_second
          )
       );
IS_JSON_CONDITION                       VALUE
--------------------------------------- -----
IS_JSON                                 true 
IS_JSON_VALUE                           true 
IS_JSON_ARRAY                           false
IS_JSON_OBJECT                          false
IS_JSON_SCALAR                          true 
IS_JSON_SCALAR_NUMBER                   true 
IS_JSON_SCALAR_STRING                   false
IS_JSON_SCALAR_BINARY_DOUBLE            false
IS_JSON_SCALAR_BINARY_FLOAT             false
IS_JSON_SCALAR_DATE                     false
IS_JSON_SCALAR_TIMESTAMP                false
IS_JSON_SCALAR_TIMESTAMP_WITH_TIME_ZONE false
IS_JSON_SCALAR_NULL                     false
IS_JSON_SCALAR_BOOLEAN                  false
IS_JSON_SCALAR_BINARY                   false
IS_JSON_SCALAR_INTERVAL_YEAR_TO_MONTH   false
IS_JSON_SCALAR_INTERVAL_DAY_TO_SECOND   false

17 rows selected.

In line 20 we query dv.data."_id" and use the IS JSON condition to determine the data type. The most granular type is JSON scalar number.

4. Explicit Conversion

So, we know now, that we need to convert a JSON scalar number to a number. And how do we do that? – By using a SQL/JSON path expression method, as in the next example.

7) Query deptno 10 in dept_dv with explicit type conversion
select json_serialize(dv.data returning varchar2 pretty) as json_data
  from dept_dv dv
 where dv.data."_id".number() = 10;

We used the .number() method in this example. The execution plan for this query looks now like this:

8) Execution plan querying dept_dv with explicit type conversion
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------
SQL_ID  4rjg8g02bph16, child number 2
-------------------------------------
select json_serialize(dv.data returning varchar2 pretty) as json_data   
from dept_dv dv  where dv.data."_id".number() = 10
 
Plan hash value: 2166484641
 
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |       |       |     7 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    10 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | EMP_PK  |     1 |       |     0   (0)|          |
|   3 |  SORT GROUP BY              |         |     1 |    38 |            |          |
|*  4 |   TABLE ACCESS FULL         | EMP     |     5 |   190 |     3   (0)| 00:00:01 |
|   5 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  6 |   INDEX UNIQUE SCAN         | DEPT_PK |     1 |       |     0   (0)|          |
---------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("OUTER_ALIAS2"."EMPNO"=:B1)
   4 - filter("OUTER_ALIAS1"."DEPTNO"=:B1)
   6 - access("DEPTNO"=10)

The plan looks the same as without calling the .number() method, but in this case, we did not rely on implicit type conversion.

We’ve proven, that a .number() call does not make things worse. But are there cases where such an explicit type conversion results in a better execution plan?

5. JSON Collection View

Let’s say we need a view that filters the data in the duality view. For example, for security purposes. One way to achieve this is to create a JSON collection view. From a consumer point of view, such a view behaves 100% the same as a duality view. The only difference is that it is read-only and allows the full SQL grammar to define such a view.

Here’s an example.

9) Create JSON collection view dept_cv
create or replace json collection view dept_cv as
select dv.data
  from dept_dv dv
 where dv.data."_id".number() = 10 or dv.data.loc.string() = 'DALLAS';
Json collection view DEPT_CV created.

Now, let’s run a query with implicit type conversion.

10) Query deptno 10 in dept_cv
column json_data format a50
alter session disable parallel query;
set pagesize 1000

select json_serialize(cv.data returning varchar2 pretty) as json_data
  from dept_cv cv
 where cv.data."_id" = 10;
Session altered.


JSON_DATA
--------------------------------------------------
{
  "_id" : 10,
  "_metadata" :
  {
    "etag" : "E0146035FE26EE16D4968A21E6350D81",
    "asof" : "00002604B0C08AAE"
  },
  "dname" : "ACCOUNTING",
  "loc" : "NEW YORK",
  "emps" :
  [
    {
      "empno" : 7782,
      "ename" : "CLARK",
      "job" : "MANAGER",
      "mgr" : 7839,
      "mgrname" : "KING",
      "hiredate" : "1981-06-09T00:00:00",
      "sal" : 2450,
      "comm" : null
    },
    {
      "empno" : 7839,
      "ename" : "KING",
      "job" : "PRESIDENT",
      "hiredate" : "1981-11-17T00:00:00",
      "sal" : 5000,
      "comm" : null
    },
    {
      "empno" : 7934,
      "ename" : "MILLER",
      "job" : "CLERK",
      "mgr" : 7782,
      "mgrname" : "CLARK",
      "hiredate" : "1982-01-23T00:00:00",
      "sal" : 1300,
      "comm" : null
    }
  ]
}

The execution plan of the query above looks like this:

11) Execution plan querying dept_cv with implicit type conversion
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------
SQL_ID  gkhradvxjrwfq, child number 4
-------------------------------------
select json_serialize(cv.data returning varchar2 pretty) as json_data   
from dept_cv cv  where cv.data."_id" = 10
 
Plan hash value: 1318549807
 
--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |       |       |     9 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    10 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | EMP_PK |     1 |       |     0   (0)|          |
|   3 |  SORT GROUP BY              |        |     1 |    38 |            |          |
|*  4 |   TABLE ACCESS FULL         | EMP    |     5 |   190 |     3   (0)| 00:00:01 |
|*  5 |  TABLE ACCESS FULL          | DEPT   |     1 |    20 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("OUTER_ALIAS2"."EMPNO"=:B1)
   4 - filter("OUTER_ALIAS1"."DEPTNO"=:B1)
   5 - filter((("DEPTNO"=10 OR "LOC"='DALLAS') AND 
              JSON_VALUE(JSON_SCALAR("DEPTNO" JSON NULL ON NULL ) FORMAT OSON , '$' 
              RETURNING NUMBER NULL ON ERROR TYPE(STRICT) )=10))
 
SQL Analysis Report (identified by operation id/Query Block Name/Object Alias):
-------------------------------------------------------------------------------
 
   5 -  SEL$95C0DFA4 / "OUTER_ALIAS0"@"SEL$3"
           -  The following columns have predicates which preclude their 
              use as keys in index range scan. Consider rewriting the 
              predicates.
                "DEPTNO"

The SQL analysis report at the bottom is interesting. It clearly states that no index range scan was used and that we should rewrite the query to avoid implicit type conversion.

Let’s do that.

12) Query deptno 10 in dept_cv with explicit type conversion
select json_serialize(cv.data returning varchar2 pretty) as json_data
  from dept_cv cv
 where cv.data."_id".number() = 10;

And now the execution plan has changed for the better.

13) Execution plan querying dept_cv with explicit type conversion
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------
SQL_ID  cca5xrgndnmkd, child number 2
-------------------------------------
select json_serialize(cv.data returning varchar2 pretty) as json_data   
from dept_cv cv  where cv.data."_id".number() = 10
 
Plan hash value: 2166484641
 
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |       |       |     7 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    10 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | EMP_PK  |     1 |       |     0   (0)|          |
|   3 |  SORT GROUP BY              |         |     1 |    38 |            |          |
|*  4 |   TABLE ACCESS FULL         | EMP     |     5 |   190 |     3   (0)| 00:00:01 |
|   5 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  6 |   INDEX UNIQUE SCAN         | DEPT_PK |     1 |       |     0   (0)|          |
---------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("OUTER_ALIAS2"."EMPNO"=:B1)
   4 - filter("OUTER_ALIAS1"."DEPTNO"=:B1)
   6 - access("DEPTNO"=10)

Making an index unique scan possible.

6. Conclusion

Always use a SQL/JSON path expression method (binary(), boolean(), date(), dateWithTime(), number(), string(), …) when comparing a JSON value to a non-JSON value in SQL. This way you avoid implicit type conversions, improve the readability of your code, and give the Oracle Database everything it needs to create an optimal execution plan.

The post Avoid Implicit Type Conversion in JSON Access appeared first on Philipp Salvisberg's Blog.

]]>