Exadata X7 -- Diagnostics iso, M.2 SSD Flash devices and the Secure Erase utility

After a while, I m here to write about Exadata.

As we are doing lots of migration projects, we are dealing with Exadata most of time and actually maybe this is the reason why I m writing less than before :)

Anyways, this post will be about 3 things actually.

1) The Secure erase utility, which is used to to securely erase all the information on the Exadata servers.

2) The diagnostics iso , which is a tool to be used to boot theExadata nodes to diagnose serious problems when no other way exists to analyze the system due to damage to the system.

3) The M.2 SSD devices in Exadata X7, which may be used for system boot and rescue functions.

As I mostly do, I will explain these 3 things by going through I real life story.

Recently, my team needed to erase a Exadata X7-2 1/4 machine after a POC.

We needed to use the Secure Erase utility and we needed to delete the data using the 3pass method. (note that there are also cyrpto and 7pass methods..)

According to the documentation, we needed to download the secure erase ISO and boot the nodes using PXE or USB. (note that, booting an Exadata X7 server using PXE boot is not that easy -- because of UEFI..)

While trying to boot the Exadata X7 cells, we first encountered an error .(Invalid signature detected , check secure boot policy in setup)..

This was actually an expected behaviour, as the documentation of Exadata was lacking the information for PXE booting an UEFI system.

At this point, we actually knew what we needed to do..

The solution was actually documented in another Oracle Documentation. 

Here -> https://docs.oracle.com/cd/E52668_01/E54695/html/ol7-install-pxe-dhcp-tftp.html

However, we didn't have the time to implement that. So we just disabled the secureboot in BIOS and rebooted the nodes.

Well.. After this move, cell nodes couldn't boot normally and we found ourselves in the diagnostics iso shell :)

This diagnostics shell was a result of the automatic boot that is done using the diagnostics iso residing in M.2 flash SSD devices.. 

Note that, in Exadata X7, we don't have internal USB devices anymore. USB devices were replaced by M.2 flash SSD devices.. So we have 2 M.2 flash devices for recovery purposes in Exadata X7 cells.

Well. we logged in to the diag shell using root/sos1exadata and we found that, there is a Secure Erase utilty inside /usr/sbin :)

So we got ourselves our erasing utility without actually doing anything :)

We booted the cells one by one and started deleting the data on them, using secureeareser 3 pass ->  

/usr/sbin/secureeraser -–erase --all --hdd_erasure_method 3pass --flash_erasure_method 3pass.

Note that, 3pass takes a long time.. (and it is directly depends on the sizes of  disks)

So far so good.

We were deleting the data on cells, but what about the Compute nodes?

Compute nodes don't have such a diag shell present, so we needed to boot them with an external usb, and execute the Secure Eraser through External USB, as explained in "Exadata Database Machine Security Guide".

At the end of the day, we have seen/learned 5 things ->

1) Secure eraser is present in the diag iso that comes with the M.2 devices in Cells.

2) Secure eraser's 3pass erasure method takes a really long time. (2-3 days maybe)

3) Oracle documentation in MOS is lacking the information on how to boot an UEFI system (Exadata X7) with PXE. That's why people keep saying that X7 can not boot with PXE.. Actually that's wrong.

4) Each Exadata X7 cell comes with 2 x M.2 SSD Flash devices (each 150 GB) for rescure operations. (No USBs anymore)

5) In order to boot X7 servers with PXE ->  https://docs.oracle.com/cd/E52668_01/E54695/html/ol7-install-pxe-dhcp-tftp.htm

RDBMS -- XTTS (+incremental rman backups) -- how to do it when the source tablespaces are read only?

In my previous post, I mentioned that the method explained in MOS document " 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1)" requires the source tablespaces to be in READ-WRITE mode.

The xxtdriver.pl script which is in the core of the XTTS method powered by incremental backups, just checks if there are any tablespaces in READ ONLY or OFFLINE mode..

What if our source tablespaces is in READ ONLY mode? --> According to that note, the rule is simple -> if tablespace is read only, use traditional TTS.

Why? Because it is a requirement of the process described in Note 1389592.1.. This requirement is checked inside the xxtdriver.pl and that's why we cannot execute this XTTS(+incremental backup) method for readonly tablespaces.

I still don't understand this requirement, because there seem to be no technical impossibilities for this.

Anyways; in my opinion, Oracle wants us to use this XTTS (+incremental backup) method when it is really required..

But, there are scenarios where a read only environment is required to be migrated using XTTS (+incremental backup) method.

One of these scenarios is an active dataguard environment, and the other one is described in the following sentence->

During a migration process ; a source environment can be readonly in t0 (time 0), then can be taken in to  read-write mode in t1 (time1), and then can be taken to readonly in t3(time 3).

So far so good.

What if we want to use XTTS (+incremental backup) method for read only tablespaces?
Then, my answer is use/try the manual method.

As I already wrote this down in my previous blog post; XTTS based conversion is done using the sys.dbms_backup_restore package. 

xxtdriver.pl uses it and we can manually execute it too! 

Moreover; technically, if we use that manual method, we do *not* need to make source tablespaces read write.

In the following url, you can see how this is done manually -> https://connor-mcdonald.com/2015/06/06/cross-platform-database-migration/

Ref: https://connor-mcdonald.com

Although I haven't test it yet, I believe, we can migrate our read-only source tablespaces  using a manual XTTS(+incremental backup) as described in the blog post above. (**this should be tested )

There is one more question.. What about using a Active Dataguard environment as the source for a XTTS (+incremental backup) based migration? .. 

Well.. My answer for this question, is the same as above. I believe, it can be done.. However; it should be tested well, because Oracle clearly states that -> "It is not supported to execute this procedure against a standby or snapshot standby databases".. (**this should be tested )