Your host during the day is:
Ready to migrate & upgrade Oracle Database? Have you configured tempfiles.d daemon? Have you updated the db credentials? Is your list of clients accessing the db complete? Lets take a look at trivial, not so trivial & the very best practices & tools, that can help make your migration a success.
This paper would like to focus on many small, but not so trivial things that often go under the radar during Migration & Upgrade Projects, but later can potentially come back to haunt us. These can be changes in behavior of features (eg. RESOURCE ROLE or database jobs) between database versions, or changes in OS (e.g. the new tempfiles.d daemon with OEL7) that could impact the database operations. Some of the things on our checklist includes Database Credentials, scheduler or cron jobs, how to capture information about clients connecting to your database, performance considerations, database auditing , database links and various such Migration Best Practices. Accompanying our checklist would be, examples from real world migrations, and the various tools and automation that can help us with this task. These are some of the aspects of migrations and upgrade projects that are seldom given due importance & yet often are the yardstick that a truly successful migration is measured against.
“We absolutely, definitively must have RAC” is a common cry. Despite its cost and complexity, RAC is widely used in response to various performance, high availability & scalability requirements. But does anyone really need it? Are there other, simpler solutions that could be used instead?
During my time as an Oracle DBA, I loved RAC. When I started working with PostgreSQL, I was quite vocal about the fact that an alternative to RAC was “missing”. Over time, and over a number of (sometimes beer-fueled) debates, I came to the realisation that perhaps it wasn’t as much of an issue as I at first thought.
As a DBA you probably know the situation: one of the first SQL commands when installing third-party software is “GRANT DBA TO ..”. Or: the developers in your own development department don’t know which privileges they need in the database – and first demand DBA rights in the development environment. And then the security officer appears on stage and says “everyone may only get the rights he really needs” – the well-known least privilege principle is required. But how can this be found out? Since database version 12c Oracle offers the feature “Privilege Analysis” for this purpose. Unfortunately, the use of this feature was originally linked to the Database-Vault-License – and therefore not (legally) applicable for most DBAs. This restriction was lifted in November 2018: all customers with Enterprise Edition are allowed to use the feature. Reason enough to take a closer look at this functionality in the presentation: how can the DBA determine which rights the applications and users really need and set up a suitable rights concept for them?
Most developers often avoid direct interaction with SQL, because an ORM can handle that task for them. But SQL has grown enormously from its origins of just simple data access. Modern SQL now has extensions for XML, JSON and advanced data processing. But by delving deeper into these modern SQL facilities, developers can get performance benefits and write a lot less middle-tier code. This session highlights some SQL techniques to solve problems that would otherwise require a lot of complex coding. Learn how to become a more productive developer by modernizing your knowledge of the SQL language.
Most people use AutoUpgrade already to upgrade to Oracle Database 19c.
If you don’t, no worries – we will give you a 10 min overview on how to start with AutoUpgrade. But for those of you who are familiar with it, we will dig deep into some pretty awesome features of AutoUpgrade.
We will take this case by case with realistic cases taken from your daily tasks. Not only will we explain but of course we will demo the approaches as well. You’ll be an upgrade specialist after this talk.
And as usual, this talk will be free of marketing and advertising but instead show as many demos as possible.
In my talk “How to Beautify SQL and PL/SQL Code” I explained how you can configure the formatter to enforce your formatting rules. Thanks to the custom formatting rules based on Arbori, there are almost no limits in this area.
You can format the editor content or part of it by pressing Ctrl-F7 in SQL Developer. To format one or more files, you can use SQLcl’s built-in command or a custom command like tvdformat (which is freely available on GitHub). That’s cool. However, you still have to run it manually and that’s cumbersome. Especially if you have agreed on a set of formatting rules. Maybe you also work in multiple projects with different formatter settings. Wouldn’t it be nice to automatically format files with the matching rules when committing changes to a Git repository? – No problem.
In this talk, I explain step-by-step how to configure a Git repository to automatically format modified SQL files with SQLcl and your settings before committing them to a Git repository.
Join the virtual tour of the newly completed Oracle Industries Innovation Lab. Our Lab, a simulated site for testing and exploring cutting-edge technologies has transformed into an actual construction worksite in 2020, full of equipment, materials, and teams working to deliver a planned expansion of the facility. We used Oracle and it’s partner technologies to successfully complete this project as we innovate with customers and partners.
Please join us to hear how we actively used various technologies, including our own, at the construction site, leveraging them as Owner of this new facility:
Remote site monitoring
Material Readiness and Contactless Deliveries
Automated progress reporting with robots