Merjenje performanc pred in po Oracle migraciji

Kako ugotoviti ali se baza na novem strežniku, drugi platformi ali celo na drugi ediciji (enterprise/standard), odziva hitreje ali počasneje? Kako identificirati SQL stavke, ki so bili po migraciji počasnejši? Zakaj in za koliko so bili hitrejši v novem okolju?

Marsikatera organizacija se za odgovore na tovrstna vprašanja zanaša na dolgoletne izkušnje DBA-ja. Mi pa bomo tokrat prikazali, kako lahko pridemo do teh odgovorov tudi brez pisanja SQL stavkov, tako na Standard kot tudi na Enterprise Edition.

JSON Relational Duality

Oracle JSON Relational Duality technology allows developers to store and query JSON data in an Oracle database using SQL, while also preserving the hierarchical structure of the JSON data. This technology allows for seamless integration of JSON data with traditional relational data in the same database, providing a way to work with both structured and semi-structured data in one system.

Percentiles, lies, and database performance monitoring

It is becoming increasingly popular these days to put response time percentiles into the SLAs and OLAs. But, unfortunately, most people do it wrong. In this presentation, we will explain the most common failure modes regarding performance metrics and how to handle situations when someone comes complaining with a 99th percentile graph.

Response times are often not normally distributed, and averages and dispersions are just garbage. The simplest way to make sense of such data is to use percentiles. Popular choices are 50th (median) and 99th percentiles. By definition, there can be values larger than 99th percentile, so adding 99th percentile to the SLA will hide outliers.

Oracle provides histograms for the wait events, for query response times it is still only averages. The only way to get a hold of the outliers is ASH or event 10046 traces. As always, these options come with their own challenges.

Welcome to the World of OPatch

Every DBA knows the small but important tool OPatch, which is mandatory for applying patches to an Oracle Home. Over the last years and versions, new tools, such as opatchauto, oplan or datapatch have been added, or features have been improved.

When using OPatch, the following questions often come up:

1. How exactly do I use these tools or when can I not use these tools?
2. How do I use Opatch to remove backups of old patches?
3. How do I use OPlan to patch my complete cluster?
4. How do I use datapatch to apply the changes to my databases?
5. ...

The presentation will answer all these questions and provide some deep dive information into OPatch. Newer features like for example out-of-place patching will also be part of the presentation. Additionally, pitfalls and how to overcome them will be shown.

Migrating a TB Database from 11g Windows to 19c Linux in less than an hour

Upgrading a database with plattform migration is always challenging especially if you should hav a very short downtime. There are many ways to do this. In a recent project I used Transportable Tablespace for that. I'll show how I did this and what could go wrong.

Supercharge your upgrade with AutoUpgrade

Upgrading your Oracle Database with AutoUpgrade is easy. But have you tried to use the advanced features in AutoUpgrade? You can easily supercharge your Oracle Database upgrade by using some of the advanced features. We will show you how to upgrade as many as PDBs as fast as possible and how you can leverage all nodes in your RAC cluster for optimal performance. You will also learn how to work with encrypted databases and how to deal with the encryption key. In addition, we will show you can migrate to the multitenant architecture using refreshable clone PDBs. Avoid a lengthy outage by allowing AutoUpgrade to copy the data files in advance and keep them in sync with redo. All that plus a few bonus features are covered in this session.

Is your database backup recoverable?

While concerns about new applications, end-user satisfaction, and the costs of IT all rightly get lots of press and IT attention, those concerns vary across businesses and fluctuate over time. Yet there are two constant headaches for all IT organizations: data loss and data recovery. Let’s face it, everything else in IT is replaceable. Data, if lost, cannot be replaced. Furthermore, when looked at in light of today’s demands and expectations of IT, the definition of “lost data” can reasonably be expanded to include data that is inaccessible to the business for long enough to significantly and negatively impact it. So, preventing data loss and providing rapid data/application recovery are equally important. Any data loss in Oracle Database environments—whether of the permanent or temporary variety—is likely to have a disproportionately harmful business impact. Oracle developed its Recovery Appliance to address the most common forms of potential data loss issues in Oracle Database environments. Its eponymous name is something of a rarity in IT marketing, but it emphasizes the system’s abilities to avoid permanent data loss and to greatly reduce temporary data lost to the business.

Our presentation is delivering real life reactive and proactive case studies and references from the Adriatic region which prove the need and value of Oracle’s Recovery Appliance engineered system.

Stop editing code in Production database - a journey from 90's to CICD

Source control in databases is a difficult problem. There are tools like Liquibase or Flyway but none of those is fully addressing all challenges of applying changes to databases. This presentation is based on real life implementation and shows a story of a company moving from direct PL/SQL code edit on production server to CICD pipeline.

List of the typical challenges covered in the presentation: - how to design a source control repository, - how to keep a DDL changes, - code merges, - continuous deployment without production outages - rollback - pipeline implementations

Presentation will finish with lesson learned and potential process and tools improvements including Oracle Cloud DevOps tools.