Yesterday we saw the latest decision in the long-running legal spectacle of Oracle suing Google for allegedly infringing Oracle’s Java API.
Google defeats Oracle in Java code copyright case
I am not a lawyer, nor do I claim any depth of legal expertise. And as engineers, its easy to dismiss these events as one tech giant looking to squeeze some money from another tech giant using their lawyers instead of their products.
But as engineers, these courtroom events should directly concern us.
Increasingly the old paradigm of nightly backing up your large Oracle database to tape, or writing the backup to a NAS share which is then mysteriously swept to tape by some unseen force (the Sys Admins), is becoming an unsustainable approach when backup windows are shrinking, 24/7 availability is becoming the norm and databases are getting larger and larger.
Backup Appliances, such as Sun’s ZDLRA or EMC’s Data Domain, offer many performance and manageability advantages over traditional approaches, and much of the work of traditional backup software is now baked into the appliance itself.
A modern database backup and recovery appliance should include features such as data encryption, compression, de-duplication and remote replication as standard features, to offload those functions from the host CPUs which we want to dedicate to running the database software.
EMC’s Data Domain includes SISL technology – Stream-Informed Segment Layout – to yield some very impressive data reduction numbers using a combination of de-duplication and compression.
But what happens if we choose to use RMAN features in addition to those offered by the backup applicance? What happens if we try to encrypt, de-duplicate, or compress, an RMAN backupset that is itself encrypted or compressed?
During install of Oracle RAC 12c (184.108.40.206), the installer, or possibly the cluster verification utility reports an error:
PRVG-11850 : The system call "connect" failed with error "111" while executing exectask on node ...