Author: Maria Colgan

How to watch Oracle CloudWorld 2022 Technical Sessions

Just over a month ago, we said goodbye to Las Vegas and Oracle CloudWorld 2022.

If you couldn’t make it in person or couldn’t get to all the sessions you wanted, don’t worry, as Oracle has made over 50 critical database technical sessions available on YouTube.

Here are some of the sessions I think you might find worth a watch:

Andy Mendelsohn’s Solution Keynote on Oracle Database 23c. In his keynote, Andy shared details on Oracle Database 23c, the next long-term support release for the database. 23c was code-named App Simple because the primary goal of this release was to assist developers in building next-generation mission-critical, high-performance database apps.

Juan Loaiza’s Solution Keynote on JSON Relational Duality. Juan’s session focuses on one of the marque features of Oracle Database 23c, JSON Duality Views, which promises to provide use-case simplicity of JSON with multi-use case power of relational. With the help of Tirthankar Lahiri and Beda Hammerschmidt, Juan explains how this new approach solves the age-old problem of object-relational mismatch.

Jeff Smith’s technical session Tips and Tricks for the Oracle Database Developer[LRN1523], where Jeff explores Which features of Oracle SQL Developer, Oracle SQL Developer Web, Oracle SQLcl, and Oracle REST Data Services will save database developers the most time?

Vlad Haprian’s session explains Operational Property Graphs [LRN3789] and how they are part of the standard SQL in Oracle Database 23c. He includes some great, simple-to-follow examples too.

If you are looking for more information on our in-database microservices support, you will want to check out Deepak Goel’s session on Distributed Transactions for Kubernetes Microservices [LRN3484].

As always, there were several great sessions by Conor McDonald, including one where he shared his Five-Step Guide to SQL Tuning [LRN3790].

If performance-related sessions are what you are after, then you might want to check out my session on Harnessing the Power of Oracle Database Optimizer Hints[LRN1479] and Nigel Bayliss’s session on Automatic Indexing.

If you are interested in knowing, How to Write Great SQL That’s Easy to Maintain, check out Chris Saxon and Alex Nuijten’s session.

Finally, if you want more details on what to expect in 23c and the features that should make your life a lot easier, you should check out Gerald Venzl’s session on Oracle Database application development: what’s new, what’s next?

And don’t forget to save the date for CloudWorld 2023, which is happening September 18–21 in Las Vegas.

How to do a Fuzzy Text Search on JSON #JoelKallmanDay

More and more apps I deal with store data as JSON documents in the Oracle Database. It is exceptionally convenient for the developers but doesn’t always make it easy to know exactly what data we have stored.

The good news is that Oracle offers multiple ways to help you understand precisely what data you have stored in those JSON documents. For example, you can use the built-in JSON Data Guide, which will trawl through all your documents and return a list of all the attributes you have stored.

But suppose you are interested in searching through your documents and only returning those that contain a particular word, value, or a variation thereof. In that case, you will want to take advantage of Oracle’s fuzzy text search or approximate string matching.

Imagine we have a table that stores movie reviews as JSON documents. I’m doing this demo in 19c, so I’m using a VARCHAR2 column, but from 21c onwards, you can use a JSON column.

CREATE TABLE movie_reviews( 
                     title varchar2(200),
                     cust_id NUMBER(26), 
                     cust_reviews varchar2(32000)
                     CONSTRAINT cr_is_json CHECK (cust_reviews IS JSON));

If you really want a JSON column in 19c, you can take advantage of this trick I learned from @Connor_mc_d.

 CREATE TABLE movie_rewiews( title varchar2(200), 
                             cust_id NUMBER(26), 
                             cust_reviews BLOB,
                             CHECK (cust_reviews IS json format oson));

Each review document contains details on the movie id, the star rating, and the review.

{“movie_id”: 5641,
“star_rating”: 1,
"Feedback":" Loved the tv show, but hated the movie. I am so disappointed."
}

We have been asked to find all the reviews that contain the word disappoint or variations of it. To facilitate a fuzzy text search, we need to create a text-based index on the feedback column inside the review documents.

CREATE SEARCH INDEX review_search_ind ON movie_reviews(cust_reviews) FOR JSON;

Once the index is created, we can run a fuzzy text search using the following query:

SELECT m.title, m.cust_reviews.feedback AS customer_review
FROM   movie_reviews m
WHERE  JSON_TEXTCONTAINS(m.cust_reviews, '$.feedback', 'fuzzy((disappoint))');

This results in the following entries being returned.

TITLE                    COMMENTS
-------------------- ----------------------------------------------------------------
Can You Ever Forgive Me? This movie was so disappointing
Top Gun                  Tom Cruise never disappoints. Definitely worth a watch.
Vice                     Perry’s performance in this movie is just so disappointing
Baywatch                 Loved the tv show but hated the movie. I’m so disappointed.
La La Land               Rent this movie you won’t be disappointed!
Batman                   Complete Disappointment

Alternatively, you can use the abbreviated syntax, which will return the same results as above:

SELECT m.cust_reviews.feedback AS comments
FROM movie_reviews m
WHERE JSON_TEXTCONTAINS(cust_reviews, '$.feedback', '?disapoint');

You can also use the stem search operator $. That will match verb forms sharing the same stem, so $disappoint will match “disappointing,” “disappointed,” and “disappoints,” but not “disappointment.”

SELECT m.cust_reviews.feedback AS comments
FROM movie_reviews m
WHERE JSON_TEXTCONTAINS(cust_reviews, '$.feedback', '$disapoint');

This blog was made possible by the lovely Roger Ford, the product manager for Oracle Text and JSON, who has taught me everything I know about text searches in the Oracle Database.

Looking forward to Oracle CloudWorld

There are only 2 days to go until Oracle CloudWorld in Las Vegas, the largest gathering of Oracle customers, partners, developers, and technology enthusiasts of the year! That’s right, folks; we are finally back in person.

Of course, the database team will be there. You will have multiple opportunities to meet with us in one of the informative executive keynotes, technical sessions, customer sessions, or hands-on labs.

But what can you expect from this year’s event?

To help whet your appetite, here are some of the things I’m looking forward to at this year’s CloudWorld.

Reconnecting with the community

If you have ever been to an Oracle OpenWorld conference, you will know there are always plenty of chances to network throughout the day and into the evening. But this year, after two years of pandemic living, I reckon it’s more important than ever to spend time face to face with friends and colleagues to catch up and to learn from one another. That’s why I’m looking forward to networking on the expo floor, meeting customers in the Executive Briefing Center (formerly CVC), hanging out in our Expert Lounges, and kicking back with friends and customers at the legendary Oracle Party featuring the Steve Millar Band.

Getting Inspired

There is nothing quite like attending an Oracle Keynote by Larry Ellison to reignite my love of Oracle technologies. Larry never fails to deliver insights on our end-to-end data strategy and the latest on databases, apps, analytics, and our cloud services.
There will be three other Keynotes along with Larry’s this year featuring Oracle customers and leaders offering additional insights and inspiration on tech and apps.

I’m particularly keen to see Andy Mendelsohn and Juan Loaiza’s Solution Keynotes. Andy will share details on Oracle Database Directions on Tuesday, October 18th, at 12:15 pm. While Juan will be introducing new capabilities that are Revolutionizing Objects, Documents, and Relational Development on Wednesday, October 19th at 11:15 am.

Boosting my knowledge

This year there are even more ways to boost your knowledge and build your skills at CloudWorld via technical deep dives, panel discussions, hands-on labs, and more.

With hundreds of in-depth learning sessions across nine different tracks, no matter your role or where you plan to run your Oracle systems (in the public cloud, on-premises, hybrid cloud, etc.), we will have all the product updates, technology deep-dives, and best practices sessions you need. Choose a track based on your focus areas to get information, advice, and best practices tailored to your specific needs and goals.

I plan to spend most of my time in the database and developer tracks. You’ll hear about new product enhancements and what’s next for the Oracle Database and be able to attend deep-dive sessions on Machine Learning, Graph, Spatial, JSON, REST, APEX, MAA, Exadata, and App Dev. These sessions will be jam-packed with technical details, tips, and tricks you can take home and apply immediately, not marketing hype. You can check out the entire searchable catalog online.

I’m particularly looking forward to sessions on my favorite topic, the Oracle Optimizer.  There will be sessions by Nigel Bayliss, the Optimizer product manager, covering the Oracle Database 19c Optimizer (Thursday at 9 am) and the new Automatic Indexing capabilities (Tuesday at 4:40 pm). There will even be a session on Optimizer Hints given by little ole me (Wednesday at 3:45 pm)!

As well as in-depth technical sessions delivered by Oracle experts and Aces, you will also get an opportunity to try out all the technological innovations you hear about in our Hands-on-Labs.

Putting my knowledge to the test

One of the other things I’m looking forward to participating in at Cloud world is the OCI certifications.  You can earn a recognized OCI certification credential with on-site preparation classes and exams. I’ll definitely try my hand at the updated Oracle Autonomous Database 2022 Certified Professional exam.

Visiting Las Vegas again

Las Vegas is the ultimate home to world-class entertainment, cuisine, and nightlife. If you are a foodie like me, a trip to Las Vegas would not be complete without checking out some of the incredible restaurants they have on offer. Whether you want a great steak, sushi, or a vegetarian feast, Las Vegas has you covered. After all, you will need some fortification after spending all day learning and trying your hand at the latest Oracle technology.

Regardless of what you look forward to at Oracle CloudWorld, I hope to see you there!

If you can’t make it in person, be sure to sign up for a digital pass, so you don’t miss any of the action. I have a code you can use to get a free Cloud World Digital Pass! Simple use Comp Code: OCWDIGITAL.

Register for Oracle Cloud World today!

SQL Tuning: How to fix a SQL statement that isn’t getting partition pruning

Partitioning is one of the most powerful tools at your disposal when managing large volumes of data and improving the performance of queries that would otherwise scan and filter lots and lots of data.

However, it can be tricky to determine why it isn’t helping when you thought it should.

Typically partitioning improves query performance by ensuring only the partition(s) needed to answer the business user’s query will be scanned rather than the entire table.

But how can you tell if you got partition pruning in an execution plan? Or worse yet, how do you determine why you didn’t get partitioning pruning when you were expecting it.

In the video below, I share the steps I use to determine if partition pruning has occurred and what to look at and correct if you don’t automatically get the partition pruning you were expecting.

This blog post is part of a series on SQL Tuning. I shared some simple steps to help you tune a SQL Statement using the wrong Join Type in part one. While part two deals with how to tackle a problem where the optimizer picks the wrong index, and part three shares tips on how to fix statements where the Optimizer chooses a nested loop join instead of a hash join.

Happy Tuning!

 

SQL Tuning: How to fix a SQL statement that picks a Nested Loop instead of a Hash Join

At one point or another during your career, you will face a situation where the optimizer picks the wrong join method. As tempting as it is to brute-force the plan you want via a hint, it’s always better to understand why the Optimizer made a decision and provide the necessary information to allow the Optimizer to select the plan you want by default.

In this short video below, I explain how the Optimizer determines the join method based on the cardinality of the table on the left-hand side of the join. I also provide a simple set of steps to help you identify the common problems that can cause an incorrect join method to be used and guidance on how to supply the necessary information, so the Optimizer will automatically select the appropriate join method.

Adaptive joins, introduced in 12c, can help address some cases where the Optimizer selects the wrong join method but not in all cases. It’s always better to know how to save yourself rather than relying on the built-in safety net.

Happy Tuning!

Five simple ingredients for deploying and running mission-critical databases

At the recent Oracle Database World event, I had the pleasure of presenting the general session for the mission-critical track, along with my colleague Ashish Ray. In our session, I outline the five essential ingredients you need to deploy and operate a mission-critical database, regardless of what workload you plan to run.

Each of the subsequent technical sessions provides a deeper dive into each ingredient.  These sessions include:

  1. Transparent Performance with Exadata presented by Kodi Umamgeswaran
  2. Oracle Maximum Availablity Architecture delivered by Markus Michalewicz
  3. Simplifying App Dev with RAC given by Anil Nair
  4. Complete Database security in 4 simple steps presented by Russ Lowenthal
  5. How to evolve Database Apps entirely online presented by Ludovico Caldara

If you didn’t have an opportunity to join the live event, you can now access all the sessions on YouTube. Below is a link to the entire mission-critical playlist.

Hopefully, watching this playlist will give you valuable tips and technologies to deploy a mission-critical database successfully.

SQL Tuning: How to determine why the Optimizer is picking the wrong index

One of the most common SQL Tuning challenges you will encounter with enterprise applications is a SQL statement where the Optimizer picks the wrong index. As tempting as it is to brute-force the plan you want via an index hint, it’s always better to understand why the Optimizer made the decision and provide the necessary information and access structures to allow the Optimizer to select the plan you want by default.

In the short video below, I explain how the Optimizer costs each of the index accesses available to it and provide you with a simple set of steps to help you identify these types of problems and guidance on how to create indexes so the Optimizer will automatically select them.

This post is part two of a series of blog posts on SQL Tuning. In part one, I shared some simple steps to help you tune a SQL Statement using the wrong Join Type.

SQL Tuning: How to tune a SQL Statement with the wrong Join Type

When it comes to SQL Tuning, I don’t typically recommend folks add one-off hints or look for magical underscore parameters to help improve their query performance.

Instead, I like to share some simple steps to

  1. Accurately characterise the problem
  2. Determine and apply a solution
  3. Measure the effectiveness of that solution

But instead of talking about my approach, I thought it would be more beneficial to show you how I do it. So in the video below, you will see the exact steps I used to determine what was causing a Sales Report to run slowly and the two alternative approaches you can take to resolve similar problems.

Explain the Explain Plan: Join Order

 

Continuing my blog series on reading and interpreting Oracle execution plans, this week’s post covers Join Order.

So what is the Join Order?

The join order is the order in which the tables are joined together in a multi-table SQL statement. Ideally, a plan should start with the join that eliminates the most data to minimize the amount of data carried into the subsequent joins.

How is the Join Order Determined?

The join order is determined based on cost, which is strongly influenced by the cardinality estimates and available access paths. However, the Optimizer will also always adhere to some basic rules:

    • The Optimizer will always select a join that will produce at most 1 row as the initial join in the plan. For example, a join between two row sources that only have 1 row each. Like a primary key lookup or an index unique scan.
    • If a SQL statement uses an outer join, then the optimizer must obey the join order specified by the outer join. That is to say; the row preserving table must come after the other table in the predicate to ensure all of the additional rows that don’t satisfy the join condition can be added to the result set correctly. For example, with the Oracle syntax for outer joins, the table with the outer join operator must come after the other table in the predicate. Thus, in this example, the cites table must come before the countries table. 
       WHERE cities.country_id = countries.id(+);
    •  For SQL statements that reference a database view,  the Optimizer will attempt to do view merging, where the definition of the view is inserted into the rest of the SQL statement, and the entire expanded statement is optimized as a whole. However, there are a few cases where view merging isn’t possible. In these cases, the optimizer will join all of the tables in the view together before the resulting data set is joined to the tables outside the view.
    • When a subquery has been converted into an anti-join (NOT IN subquery) or semi-join (EXISTS subquery), the tables from the subquery must come after those tables in the outer query block to which they were connected or correlated. However, hash anti-joins and semi-joins can override this ordering condition under certain circumstances.

How to determine the Join Order in an execution plan

You can take several approaches to determine the Join Order in a plan, from looking at the indentation of the tables in the operation column to a depth-first search. To clearly explain how to identify the Join Order in an execution plan, I’ve created a short video demonstrating several approaches using real-world examples.

What if I don’t get the Join Order I want?

The leading cause of the wrong Join Order is typically a cardinality misestimate on the table or joins in the query or missing access methods.

Don’t forget this post is part of a series of posts on interpreting execution plans, covering how to generate plans, cardinality estimates, access methods, and join methods.

Why Oracle Implement Blockchain in the Database

The primary focus of conventional data security technologies like passwords, firewalls, and data encryption is to keep criminals out of your company and your data stores.

But what protects your data, especially your essential asset (contracts, property titles, account statements, etc.), from being modified or even deleted by folks who gain access to your systems legitimately or illegitimately (hackers)?

Crypto-secure Data Management

This is where Blockchain can help. Layering Blockchain technologies on top of conventional data security features provide an extra level of protection that prevents illicit modifications or deletes of data.

What is Blockchain?

When we think of Blockchain, many of us instantly think of decentralized peer to peer apps that only permit consensus-based data changes. However, adopting these apps requires new development methodologies, speciality data stores and potentially new business practices, which is complicated and expensive!

But if we take a closer look at Blockchain technologies, we see four critical components; immutability, cryptographic digests, cryptographic signatures, and distributed systems. Each part works to protect against a different aspect of illicit data changes performed using legitimate user credentials or by hackers.

Integrating these Blockchain technologies into the Oracle Database brings the critical security benefits of Blockchain to mainstream applications with minimal or no changes required. Providing the full functionality of the world’s leading database on crypto-protected data.

In the video below, Juan Loaiza explains how Oracle implemented Blockchain technologies in the Oracle Database and how they can be used to protect your essential business data. I’ve also included a brief description of these features under the video.

How do Blockchain technologies work in the Oracle Database?

To protect against illicit data changes made by rogue insiders or malicious actors using insiders’ credentials, Oracle has introduced Immutable tables (insert-only tables) in Oracle Database 21c (21.3).

Immutable Tables

With an Immutable table, it is possible to insert new data, but existing data cannot be changed or deleted by anyone using the database, even the database administrators (SYSDBA). It is also impossible to change an immutable table’s definition or convert it to an updatable table. However, an Immutable table appears like any other table in the database from an application’s point of view. It can store both relational data and JSON documents, and it can be indexed and partitioned or used as the basis of a view.

Blockchain Tables

To protect against illicit changes made by hackers, Oracle has introduced Blockchain tables. Blockchain tables are immutable tables that organize rows into several chains. Each row, except the first row in the chain, is chained to the previous row via a cryptographic digest or hash. The hash is automatically calculated on insert based on that row’s data and the hash value of the previous row in the chain. Timestamps are also recorded for each row on insertion.

Any modification to data in a Blockchain table breaks the cryptographic chain because the hash value of the row will change. You can verify the contents of a blockchain table have not been modified since they were inserted using the DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS procedure.

DECLARE
actual_rows NUMBER;
verified_rows NUMBER;
 
BEGIN
 
SELECT COUNT(*)
INTO actual_rows
FROM admin.my_bc_tab;
 
dbms_blockchain_table.verify_rows(
schema_name => 'admin',
table_name => 'MY_BC_TAB',
number_of_rows_verified => verified_rows);
 
DBMS_OUTPUT.put_line('Actual_rows='||actual_rows|| ' Verified Rows=' || verified_rows);
END;
/

End-User Data Signing

Even with Immutable or Blockchain tables, data can be falsely inserted in an end user’s name by someone using stolen credentials. To address this vulnerability, Oracle allows end-users to cryptographically sign the data they insert using their private key that is never passed to the database.

Each end-user registers a digital certificate containing their public key with this database. This digital certificate allows the database to validate the end-users signature when new data is inserted. Even if a hacker manages to steal a valid set of credentials without the private key, the data insert signature won’t match and will therefore not be accepted.

It’s also possible for end-users to ensure the database has received their changes by requesting Oracle countersign the newly inserted data. Oracle returns a crypto-receipt to the user, ensuring nothing on the mid-tier can filter specific data to prevent it from being recorded.

Distributing Cryptographic Digest

Even with cryptographically chained rows, sophisticated cyber-criminals or authorities could illicitly change data via a large-scale cover-up, where the entire database is replaced. To detect such a cover-up, Oracle enables schema owners to sign and distribute the cryptographic digest for a blockchain table periodically. Remember, the digest can’t be used to infer the data in the table, but authorized users can use it to validate the chain and confirm their newly inserted data is present. The crypto-digest can be posted to an independent public store or blockchain, like Ethereum or sent out by email or made available via a REST API.

A cover-up can easily be detected by comparing the previously published digests to the current table content. Also, distributing the publicly across multiple independent services prevents an authority or cyber-attacker from deleting all the separate copies.

Getting Started With Blockchain

Both Immutable and Blockchain tables are free features of the Oracle  Database. No additional licenses or software is needed to take advantage of these new table types, which are completely transparent to all new and existing applications.

Also, note Oracle has backported Immutable tables and Blockchain tables to Oracle Database 19c (19.11 and 19.10, respectively). Please check My Oracle Support for more details before attempting to use Blockchain tables in 19.10.

For more information on Blockchain check out the Oracle Blockchain blog, Oracle Blockchain LiveLabs or the Oracle Blockchain documentation.

%d bloggers like this: