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.

What the Heck is the Oracle Optimizer Doing? Transformations

When Oracle optimizes your SQL, it works out what it thinks is the best way to execute your statement to retrieve your data as quickly as possible, minimising unnecessary resource usage. This presentation will look at what Oracle is doing. We will use the 10053 trace functionality to show how Oracle is transforming your queries, perhaps in ways you didn't think it was doing!

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.

Oracle Database high availability from the client's perspective

In this presentation we will look into high availability technologies Oracle provides for database clients, what happens during database instance failover or planned maintenance, and how to configure database services so that Java applications experience no or minimal disruption during scheduled maintenance or unplanned downtime.

We will cover both Oracle RAC and Oracle Single instance databases. Can some Oracle RAC high-availability features be added to single instance database setups? What is Oracle Connection Manager, and how does it fit into the high availability world. On the client side we will mainly focus on JDBC and UCP clients.

Oracle Database high availability from the client's perspective

In this presentation we will look into high availability technologies Oracle provides for database clients, what happens during database instance failover or planned maintenance, and how to configure database services so that Java applications experience no or minimal disruption during scheduled maintenance or unplanned downtime.

We will cover both Oracle RAC and Oracle Single instance databases. Can some Oracle RAC high-availability features be added to single instance database setups? What is Oracle Connection Manager, and how does it fit into the high availability world. On the client side we will mainly focus on JDBC and UCP clients.

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.

Koliko časa traja »restore«? Nič!

»Koliko časa traja restore?« je najpogostejše vprašanje strank, ko se pogovarjamo o backup strategijah. Zanimivo, da skoraj nikogar ne zanima, koliko traja in kolikšen vpliv na poslovanje ima izvajanje backupa, čeprav se ta izvaja redno ves čas, restavriranje pa … če imamo srečo, sploh nikoli.

V preteklosti smo zelo optimizirali backup postopke. Shranjujemo transakcije zbirk podatkov, uporabljamo bitmap indekse za označevanje spremenjenih blokov podatkov, da jih hitro najdemo in shranimo.

Ker pa to ne rešuje naslovnega vprašanja, smo v zadnjem času veliko truda vložili tudi v »restore«. Izkušenejši uporabniki se zatečejo k matematiki in znajo izračunati, da skozi gigabitni kanal dobimo približno 100 MB/s. Obnova 10 TB podatkov torej pri gigabitni hitrosti traja približno 24 ur, pri večji hitrosti sorazmerno manj. Matematika se tu zdi neizprosna.

Z inovativnimi postopki lahko matematiko pretentamo. Izhajamo s predpostavke, da kopijo podatkov že imamo. Zakaj bi te prepisovali na njihovo originalno mesto in ČAKALI, da se prepišejo? Zakaj preprosto teh podatkov ne bi kar uporabili TAKOJ – na mestu, kjer so. Čas nedostopnosti storitev se tako skrajša na samo aktivacijo podatkov – skoraj na NIČ. Ko storitve že delujejo, pa lahko v ozadju premeščamo podatke na originalno mesto.

Koliko časa traja »restore«? Nič!

»Koliko časa traja restore?« je najpogostejše vprašanje strank, ko se pogovarjamo o backup strategijah. Zanimivo, da skoraj nikogar ne zanima, koliko traja in kolikšen vpliv na poslovanje ima izvajanje backupa, čeprav se ta izvaja redno ves čas, restavriranje pa … če imamo srečo, sploh nikoli.

V preteklosti smo zelo optimizirali backup postopke. Shranjujemo transakcije zbirk podatkov, uporabljamo bitmap indekse za označevanje spremenjenih blokov podatkov, da jih hitro najdemo in shranimo.

Ker pa to ne rešuje naslovnega vprašanja, smo v zadnjem času veliko truda vložili tudi v »restore«. Izkušenejši uporabniki se zatečejo k matematiki in znajo izračunati, da skozi gigabitni kanal dobimo približno 100 MB/s. Obnova 10 TB podatkov torej pri gigabitni hitrosti traja približno 24 ur, pri večji hitrosti sorazmerno manj. Matematika se tu zdi neizprosna.

Z inovativnimi postopki lahko matematiko pretentamo. Izhajamo s predpostavke, da kopijo podatkov že imamo. Zakaj bi te prepisovali na njihovo originalno mesto in ČAKALI, da se prepišejo? Zakaj preprosto teh podatkov ne bi kar uporabili TAKOJ – na mestu, kjer so. Čas nedostopnosti storitev se tako skrajša na samo aktivacijo podatkov – skoraj na NIČ. Ko storitve že delujejo, pa lahko v ozadju premeščamo podatke na originalno mesto.