As a database developer, I’m sure you’re aware of the importance of staying up-to-date with the latest technology. Oracle 23c is the latest version of Oracle’s database software, and it’s a necessary upgrade for the future. With its improved scalability, enhanced security, and advanced analytics capabilities, Oracle 23c is a must-have for any business that wants to stay competitive in the digital age. It’s a powerful tool that can help you take your business to the next level.
Things that we as Oracle Database Developers have been missing for a long time have now been implemented for the most part:
DROP TABLE IF EXISTS
CREATE TABLE IF NOT EXISTS
Data type BOOLEAN
The End from DUAL
Column alias in GROUP BY und HAVING
Better Error Messages
Annotiations for Table, Columns usw.. useful for LOVs ?
Oracle 23c is a great upgrade for the future. It’s packed with new features that make it easier to use and more secure. I’m excited to see what this upgrade has to offer and how it can help us stay ahead of the competition. It’s a necessary upgrade for the future!
TIPP to get more Free Stuff from Oracle .. more coming soon ..
After a new installation of an Oracle 19 CDB+PDB database we always look at the alert.log.
And there were 2 anomalies:
1: ORA-00800:
So the customer had to open a ticket with RHEL:
The latter already knew the problem:
Removing any software which enabled CPUQuota and/or CPUaccounting on systemd level (usually Insights), or remove the CPUQuota and accounting directives from systemd files. This solves ORA-00800 error without need of changing cpu.rt_runtime_us.
Why does Insights prevent Oracle grid services from starting https://access.redhat.com/solutions/6020561
Oracle Database Enterprise 19c fails to start with error: ORA-00800: soft external error, arguments: [Set Priority Failed], [VKTM] https://access.redhat.com/solutions/6991342
2: Prallel FPTR failed:
support.oracle.com:
Workaround:
The default value for _min_undosegs_for_parallel_fptr is 100, which you can change to 0. This problem appears to be documented in the note below and fix included in oracle 20.0 version.
Database links in Autonomous Database Shared are the past – Cloud links are the future
Hermann BAER – Oracle PRODUCT MANAGEMENT
Database links have been a popular way to let remote databases access specific tables or views in a database, but they require a lot of back and forth communication to establish the connection. However, with Oracle Autonomous Database Shared’s new feature, Cloud Links, data owners can easily register a table or view for remote access by a certain audience, without needing to set up a connection every time someone needs to access the data. This means that anyone with remote access can discover and use the data that has been made available to them without any extra hassle.
Tom, I want to use your app, but only with my data!
MICHAEL
There are a few ways to achieve this (here only 2):
Clone the app in a workspace and mount it on its own Oracle schema, create all the necessary objects (which you can now define right inside Oracle Apex with the install scripts).
not all sideeffects:
Update of the app means more complex app lifecycle management.
Maybe other processes have to be adapted which also write to the new database or schema.
There might be common data that should be used by all
2. Don’t clone the app and change the data model and customize the APP
not all side effects:
This means you have to filter in the Apex App depending on APP_USER or client of a user.
Depending on how the data is connected to Regions, IG, IR etc., you might have to make an adjustment in each page.
to point 2:
Here we can proceed very effectively because we can use the option of Oracle VPD-Virtual Private Database. We do not need to customize a single view or Apex SQL + PL/SQL query and that is really a huge advantage.
What was to be done?
In my case I had to extend the APP_USER in the relevant tables (of course not in attached views), I call the column MANDANT:
ALTER TABLE CARLOG_DATA add MANDANT VARCHAR2(100);
Next I had to tell the asynchronous load process to assign the data to the user. That means the DML (Insert , Update, Delete) in this table had to be extended by the column MANDANT. It would also have been possible to use a DML trigger that could assign the data correctly. But this was not an „easier“ option for me so I decided to customize the loading process.
As soon as the data of the other client was in the database, I saw my data aggregated with his in the Apex APP. For example, in this specific case, my car drove 133km instead of 100km that day.
Now the Oracle VPD comes into play:
First, create a function that allows to manage more complex criteria in one place: Here I restrict that the check only takes place if the session is in the context of the Apex application 100.
The APP_USER is my client. Oracle Apex automatically sets the APP_USER to the session context after login. Nice…
create or replace function get_mandant_criteria
(
object_schema IN VARCHAR2,
object_name VARCHAR2
)
return varchar2 DETERMINISTIC as
l_criteria varchar2(4000);
begin
-- Only apply VPD to specific APEX applications
if sys_context('APEX$SESSION', 'APP_ID') in (100)
then
l_criteria:=q'#(MANDANT=sys_context('APEX$SESSION', 'APP_USER'))#';
end if;
return l_criteria;
end get_mandant_criteria;
/