[Music] Hi everyone, welcome to the global launch of Oracle Database 23 AI. To kick off this monumental release, we've got Juan Lisa, Executive Vice President of Mission Critical Database Technologies, and a special guest, our founder and CTO, Larry Ellison. So, without further ado, over to you, Juan. Thanks, Kendall, and thanks, Larry, for joining me today for a discussion about Oracle Database 23 AI. This is a game-changing release for the industry. We have over 300 major new features in Oracle Database 23, and we have thousands of enhancements. And there are three main focus areas that we looked at. One was AI, the other one is developers, and the other one is Mission Critical. And today, we're going to discuss some of the major features, the major game-changing features in this release. So, let's start with AI. Probably the most important feature in this release for AI is AI Vector Search. So, just to give everyone a little bit of background, AI Vector Search is a new capability that allows the database to search data by its content. So, for example, you can search for documents by

its content, not the words in it, but the overall content and concepts in it. You can search for images, you can search for videos, you can search for audio. You can also search relational data by its conceptual content. So, your thoughts on AI Vector search, Larry? Well, being able to look at and converting everything to vectors, converting an image, converting a string of base pairs for DNA. Reducing everything to a vector allows a database to actually find similar pictures. So, if I want to find all the pictures of Juan LAA in my album, I can do that. Actually, I tried that yesterday. One, I don't have any pictures of you, but I confirm that with the new Oracle Vector search. The system allows us, as you said, to search the contents of the data and find similarities. We've had vectors, vector searches, and similarities researches for a very long time. This is not

one of the newer things but the vectorization but now it's all stored in the database. All these, uh, we can convert virtually anything, a language. That's how the large language models work. They convert language into vectors, uh, and they look at phrases that are similar. They can find phrases that are identical or almost identical. It's how they track down plagiarism, by the way, uh, right. Right now, you know, plagiarism is virtually impossible because I can can do a vector search and not and it doesn't have to be an exact match of what you wrote, but if it's very similar, very similar to what, uh, what you wrote, uh, the vector search will find it, and and it's this interesting ability to embed, uh, to convert, uh, data, uh, into vectors, and then find vectors that are similar to one another, or what we say, what they say, it's close in the vector space. Larry, what are your thoughts on vectors? Should these be delivered as a standalone product, or should they be delivered as a feature of a database? I think I think it's a

feature. And you know there were XML databases. If anyone's old, I'm old enough to remember XML databases. Every time there was a new data type, if you will, and every time there was a new feature, someone thought this is a great opportunity to develop a very quickly, develop and deliver a new kind of database. And again, XML is maybe my favorite example. Didn't last very long, but we had object databases, we have relational databases, we had, you know. But the answer is, I think the answer is always that all of your data should be in one place. It just makes life much easier to ask a question, ask a query that spans, spans. You don't know what the, you don't anticipate the query you'd like to have. The hardest problem usually is finding the data, but if you keep all the data in one database, it requires that that database handles every data type, whether it's a graph data type, whether it's a vector, whether it's XML, whether it's an.

adjacent document. Whether it's um a SQL table, uh, so we think, uh, that the right way to approach this problem is to have a have a database that can manage all of your data, and and then make, and and do it in a highly performant, very, and very economic way. It's interesting new technology, um, and you know other areas are finding anomalies, which can be things like fraud or broken parts in a in a factory, things like that. So it has it has a lot of different applications, and of course, one of the main ones is to combine it with llms with with AI chat. So now you can basically do natural language AI chat with the data in your database. So for example, you can ask a questions about your bank account or your phone account or your medical history, and we, the Oracle database, will take that question and use AI Vector search to find relevant data in the database. So your medical records, your account data, your phone records, and then we can answer the question using the LM, again using natural language. So that's a big new

thing. Yeah, well, that, I mean, they call that retrieval augmented, uh, generation, uh, where, uh, we can do that a couple of ways. We can do that with prompt engineering, uh, where you can actually include some of the data in before you ask ask your question. You kind of tell the, uh, the, uh, large language model, uh, give it some context before you ask your question. But actually, that doesn't scale very well. And by putting, uh, specializing and personalizing large language models with your data, uh, is something you can do in, uh, with the Oracle, uh, Vector database. So you have a, a trained, a foundational model that is trained, but it doesn't know it obvious doesn't have your banking records, and it doesn't have your personal email, that you know that that's not public data that these large language models are trained on. But you can specialize these large language models, uh, with your personal data. That's one of the things we can do. You can specialize these large language models with the latest clinical research papers that have been written and come out in

the last month or so uh and to make sure that uh the uh the foundational model is up to date in its training. It has it is up to date up to the minute because the very latest news is in uh the vector database. The other stuff uh is available was available when the foundational model was initially trained, yeah. So that combination of database and and the llms is going to be amazing for for users, a lot of amazing new capabilities that were never possible before. Um, we've also added AI all over the place, we've added AI exed accelerate AI, we've added adaa, um AI to Golden Gate so you can you can distribute your your V vectors across your entire Enterprise. You can pull in data into Oracle database 23 that you want to vectorize and do AI search on without having to upgrade your production database right away. So there's a lot of new capabilities, um. Do you want to describe what our pricing philosophy is on on this AI technology inside the Oracle database as as you and I discussed, uh, before we made the

decision. We think this is a transformational technology, artificial intelligence, and we think that the Oracle database, the Oracle Vector database, is a highly scalable, very powerful, highly secure system that can store your personal data, highly secure data, medical record data, those kinds of things, keep that data very, very secure, yet use that data to make the neural network smarter, and we think that is so important. We want to encourage you, we want many people to see this capability and use this capability as quickly as possible. Therefore, it just, as my mother would say, comes with a meal, there is no extra charge for these AI capabilities, they're built in to 10 23 AI, the latest version of our database, and everyone, everyone, can use them. Yeah, so it's just there, so AI is The New Normal, it's just going to be everywhere, and we're making sure that it's available for all your data. So let's move on to another topic, developers, so another big Focus for us making developers more productive, making

developers making data easier to use by developers. So a big focus of ours was the unification of Json, graph, and relational. So we've had Jason and graph available in the Oracle database for a lot of years. We have really industry-leading Technologies, but up to now you've had to choose one format. You're data as either relational Json or graph, and once you've chosen that one format, you get all the benefits of that format, but you also get all the limitations and drawbacks of that format. So the big new thing in 23 AI is we've unified these. So now you can store your data once, and then one part of the app can treat it as relational and access it using SQL. Another part of the app can treat it as Json, both read and write it as Json using Json API. So you get all the benefits of Jason. And then another part of the app can treat it as a graph and run graph queries. So we I think this is a huge development, not just for us, but for the entire industry, and it will

greatly simplify development make developers much more productive so you've been around this whole object representing objects it has been an issue for databases for decades and you've seen the evolution of this thing what are your thoughts on this new technology well I can just tell you from our own experience in building applications the first the first thing people decide well I'm am I going to build fundamentally an object schema or I'm going to build fundamentally a relational schema you know two-dimensional arrays and there seemed to be no right answer because at Oracle we built some of our applications with object schemas primarily object schemas which we had to manage in the at the application layer and we built some of them with with underlying relational schemas and that what yeah and and and then we do a mapping between but we would always do a mapping between the objects and the relations because a lot of the transactions a lot of the data entry is more more convenient in in JSON and

Jason objects uh and people plus people don't like to before they start programming completely define their relational schema. A lot of programmers uh resisted SQL, and I mean no SQL used to mean mean no SQL. Now it means not only SQL uh. They decided they really didn't want to give up SQL entirely, but that a lot of programmers want to get start building their application and start collecting information as quickly as possible, and they don't want to work out in advance what their schema is going to be. So what we did is let you okay. Define your Json objects, and we will generate the relational schema from that. And the beauty of that is you can then query all your data, which is much very hard to do if you if you actually use an object database. Having a powerful query language is not something object databases come with uh, and it is fundamental to relational, so we have all the power of the SQL query language to sit on top of the objects, but we view you can view the them as objects Json objects or as as relations. They coexist.

you do not have to predefine the schema. You're a programmer, you can get started writing your application. But what all the trouble they get into is when they write their application without predefining the schema. If they want to make a change, they want to evolve that schema, they want to add things to it, they want to modify things. It's very difficult to do with an object-like schema with underlying relational schema. Schema evolution is quite easy. So there are advantages of objects, there are advantages of relations. Two-dimensional tables with Oracle 23 AI, you get both. You get all the advantages of objects, you can use objects. From your point of view, you can think of as entirely as an object database. Afterwards you say, wait a second, I need a powerful query language and I need to do some schema evolution, no problem. It really is both. You get the best of both worlds with this unification, and it's completely seamless. Some users can think of it one way, some users think of it the other.

way it all works. Yeah, so this is a problem that we've been trying to crack for decades, and we feel like we're there now. This is it, you know. It actually, once you figure it out, it's much simpler than than some of the things that we tried in the past. It's interesting. Oh, it's all automated. We used to have to do this at the application level, right? We had to do AOT. It was never completely transparent to move from objects to relations. The application had to be aware of it. Now that's not true. The application developer, the users can see objects if they want to, you know, pop a switch and they see that same data in relations. They can operate through both a sets of APIs, right? And graph is yet another benefit, which is you can run these graph queries to navigate, right? Yeah, no, no. Graph is yet another another example of a model that we've incorporated. So we really have unified three separate models into 23AI, right? And it's not even

application by application, it's use case. So you can use it, you know, one format, then use it in a different format. Well, exactly, exactly. I said you can build all your data entry applications using the JSON schema, and you can build all your analytic applications using SQL tables, right? And in the SQL language, and those two different use cases, same application, same data, same everything, just different use cases, analytics versus data entry. Yeah, yeah, that's great. So you mentioned NoSQL. So in the last decade, there was a big push for NoSQL and also for getting rid of transactions. Transactions were considered kind of at best an annoyance and at worst kind of a problem. And so there was a move to move transaction management into the application. Now, one of the things we've done with Oracle Database 23 AI is we've addressed some of the long-standing problems with transactions because transactions had some issues. So among those are stateless transactions, like REST transactions. You know how do we read data and write it back and make sure

that nobody wrote it while while while I was looking at it. Another one is long-running transactions. We don't want to lock a row for a long time that blocks out other users, and another one is microservice. How do you keep the microservices consistent? So these are areas that we put a lot of work into. So, I think you know already that trend toward moving transactions into the application is really kind of dying because people have been trying it. It's not working so well. So now, I think we'll really kind of get back to, you know, data integrity. I mean, the whole idea of data integrity is kind of a lot of people have lost track of that data consistency. So your thoughts on this? Well, again, it's a matter of rediscovery. Transactions can have complexity, certainly long-running transactions holding locks for too long. You know, Oracle's always had a unique locking model. We really don't have update locks. We really don't have read locks, which is very unusual. I'm not going to

spend a lot of time talking about it, but it solves a lot of long-running transaction problems, uh, already, but it wasn't, uh, but there are certain cases, there were certain cases where long-running transactions were a problem for the Oracle database as well, and we've addressed, and by the way, moving this into the application, uh, you. You're simply saying, okay, I've got this great idea, rather than solving the problem once in the database and the application, uh, developers don't have to worry about it at all. How about every time you have you write an application, you have to handle TR, you know, data consistency in the application? Well, it makes your data, your application almost impossible to write, uh, and it makes your application 10 times harder to write. It's not really a very good idea, uh, as much stuff you can shove down, uh, in the stack, uh, the better, uh, to ensure you got data, uh, data. Same thing with security, uh, you want to shove that down, you don't want the application developer to resp be responsible for security, you don't want

the application developer to be responsible for application for data consistency. That should be the responsibility of the database. So, the application developer focuses on getting the job done, building that application, and inheriting from below from the database data. Uh, both security, consistency, reliability, all that should be done at the database level, not the, yeah, the idea of uh, you, the Integrity of your data is as good as your worst developer on his worst day. Know what do you think of that idea Larry? Is that a good plan? I think because we are, we're a very unusual hyperscaler. We, we, uh, both provide infrastructure things like, like autonomous Linux and the Oracle autonomous database. Uh, and we also build a lot of applications, uh, whether it be in healthcare or an Erp or, uh, Human Resources. We, you know, we build large bunch of different Industries. We build a lot of applications and, uh, again, I think you want those application developers to be highly productive. And so you don't want to, you want, you don't want to burden them with the problem of getting

data consistency, right? And that, and, and plus, you really don't want to have to audit every single application to make sure that the data consistency is programmed properly in the application. That should be something you simply inherit from the underlying infrastructure, from the underlying database. Let's keep the application developer focused on what the application does, not underlying problems like data consistency. Yeah, so here's another related issue that new technologies come around, which is caching in the middle tier. So caching the database in the middle tier. So there's a number of products now in the market that cache data, and the way this works is the actual application developer reads the data from the back end and puts them manually into the cache and then manages their consistency in the cache. So this is kind of what's in the market. One of the features that we've added to Oracle 23 is called True Cache. And what this is, is very simply a real cache, a true cache, not a faux cache. So we have a cache in the middle

tier the developer just you know runs the regular database operations against that query SQL Jason as data is is not is is it finds data not in there it'll automatically pull the data from the database. You don't have to do that manually. And then once it pulls the data in there, the database will automatically keep it consistent so you don't have to worry about hey somebody changed the data and I have a steale copy of the data now I got to deal with this thing so so again very similar thing what are what are your thoughts on this whole area of caching in the middle tier well I I think what people were doing at the application Lev level building their own middle tier caches was just um you know a way of monitoring the market and see that they wanted better performance so you know someone once joked and said there are three ways to improve performance there's caching caching and cashing I think that's a bit of a simplication but it it there's an element of Truth in that uh and uh so

having this mid-tier cache of for the database is very important. But once again, it shouldn't be done at the application layer. The application should just expect the database to provide that kind of performance by storing a data consistent cache for them in the middle tier. So they should get the improved performance without going into making any extra effort in their application. And that's what we've done by providing true cache. Basically, it's impossible to keep it consistent. You can't even if you try. So this is a case where no matter what you do because you don't know when someone's changing the data in the back end. So your data goes forward and backward in time because part of the data you loaded earlier and later and it's changed. And you know going forward and backward in time in the application. That's a hard problem. It is a hard problem. But a lot of things they take on at the application layer is well let's call it a digital Cry for Help. Okay look I just need this

performance. That's why I'm going to try to do it this way in the application because you're not providing this for me. So, we watch what was going on in the marketplace, we realized we could dramatically improve Oracle's performance. From where we were with this, the idea of a mid-tier cache was a good one. But let's make sure we do it properly in the database and not burden the application developer with that. Yeah, that's exactly right. So, one other thing, let's talk about one more thing, which is globally distributed data. So now there's more and more countries that are passing data sovereignty, data residency laws. So that means that country's data has to be stored inside that country. However, if you're an Enterprise, you want to see the data as one Global unit, as you know, regardless of what country is in, so you can run your operations on that. And for that, we've introduced something we used to call A Shard sharded database. Now it's called a globally distributed

database, and it has two main functions. One is you can place your data wherever you want in the world. So European data goes in Europe, Indian data goes in India, American data goes in America. Everybody's happy, and it's all transparent. The other thing, of course, you get much higher scalability. So this is a technology we've been working on for a long time. We've been enhancing it in 23. We've enhanced it a lot. We've added something called raft replication, which allows much faster failovers in single-digit second failovers when you have some kind of an issue. So what are your thoughts on the whole data regulation, data sovereignty, you know, this thing presumably is only going to increase over time. So we keep the illusion of a single database even though it is not a single database. It's partitioned geographically. There are also partitions that exist for reliability purposes and performance purposes. You know, there are caches, and there's lots of copies of that data.

but but again once again automatically we adhere to the different data sovereignty laws in every country. The Swedish laws might be somewhat different than the Ukrainian laws and we implement this and implement the requirements of what data has to be in Sweden, what data has to be in Ukraine. We implement that all automatically and from the point of view of the organization that owns the data that's running, that's running the application, it looks like a unified Global database. But from the point of view of compliance, Regulatory Compliance, we partition it and obey all of the rules. So we just once again trying to make life easier for people who are developing these applications and have to build Global applications yet comply to local sovereignty laws. Yeah, yeah. So overall, I mean there's we talked about a number of these technologies that they're not just better, they do things that were never possible before. So the AI, the vector search, the llms, the ability to do transactions across micros.

Services long-running distributed things like the true cache. You know, we talked about the distributed database, the JSON unification with relational graph unification with relational. These aren't just additional features. These are things that have been pain points for the whole data management in this for decades forever that we're addressing in this release. So it's really, I believe, a monumental release. So what do you think of the overall package? Well, the overall package, again, we solved a lot of problems. The object-relational unification is, I think, one of the biggest deals from the logical level of the database. That one of the biggest things we've ever done, one of the most important things we've ever done in terms of ending the debate should it be a relational schema or should it be an object schema. And the answer is simply yes. We need it. It needs to be both at the same time because that debate never ended. But now you can have the best of both.

worlds. We can actually deliver that AI as you say, is this extraordinary new technology. And one of the, as we know, these, these models are trained on all the data in the internet, on the internet, all the language on the internet, and lots and lots of images as well. It's not just language that they, they train on, but they're not trained on your, your personal data. They're not trained on your corporate data, your, your proprietary, not trained on a lot of medical records because that data is private. But the great thing about our Vector database, it allows you to supplement the training of the foundational model, whether it's chat GPT from OpenAI, or, or, or Gro, or what Llama. Or what, what have you, you can supplement the training of that model with your personal data, with your corporate, your proprietary corporate data, with private data, without having to disclose that data to the PE, the people who are building those models. So you can't specialize the AI for your

company for you personally for a particular topic uh like u a certain type of cancer to make sure you've got all of that data in a single place so so the model is smarter than it otherwise would have been because you can safely add your private data to that uh so because you want that that that data should be anonymized the patient identifiers won't be there if you're collecting a lot of cancer data but the anonymized data will make much better recommendations to doctors about how to treat a cancer patient uh having that data there is going to make it means we're going get better recommendations on how doctors treat cancer and I think that's a very big deal or how uh in Wall Street they'll want much better recommendations on uh what stock to buy next you know uh we're uh we're we're focused on healthc care uh at Oracle building Healthcare applications but there are lots of applications for this technology yeah and all the new transaction capabilities transparent caching you know distributed data so I think it's it's not just

another release. It's really kind of a monumental milestone in the industry. No, no, absolutely me AI. I mean, I remember I gave a presentation a little while ago. It says, Is AI most important uh technology in the history of it uh? And I think I said, Maybe we we'll find out very soon. And the answer is probably yes, yeah, maybe maybe transistors in in AI. Those are the two big things, okay. This has been a great conversation, Larry. Thank you, thank you so much, Juan and Larry. What an exciting conversation. And hey, for all of you tuning in, if you want to learn more about Oracle database 23 aai, go to oracle.com database. Bye. [Music]

AI and Converged Data: Oracle's Strategy for Data Management

We’re a cloud technology company that provides organizations around the world with computing infrastructure and software to help them innovate, unlock efficiencies and become more effective. We also created the world’s first–and only–autonomous database to help organize and secure our customers’ data. From nonprofits to companies of all sizes, millions of people use our tools to streamline supply chains, make HR more human, quickly pivot to a new financial plan, and connect data and people around the world.  
 
Contact Oracle Sales - https://social.ora.cl/6004zuD5G
Oracle - https://social.ora.cl/600258yuQ
Join us at Oracle CloudWorld - https://social.ora.cl/6009ejskz
Try Oracle Cloud for free: https://social.ora.cl/6002ejsxs
Oracle Events: https://social.ora.cl/60075XCsd
Oracle Support: https://social.ora.cl/600458GnE
Oracle's Communities: https://social.ora.cl/60035BCrX



AI and Converged Data: Oracle's Strategy for Data Management

AI and Converged Data: Oracle's Strategy for Data Management

스크립트