Migrazione dei dati Oracle TTS con backup incrementali

[Versione italiana di seguito]

Disclaimer: Many of our customers have confidentiality agreements safeguarding their brand names from commercial purposes. Hence, you may encounter references such as “Client Name Confidential”, or the customer’s industry instead of the customer’s brand name.

Customer is a well-known international banking group with annual revenue exceeding 20 billion.

For a couple of years we have been collaborating with VTS (a joint venture between [Client Name Confidential] and IBM which is now in charge of managing the technological infrastructure of [Client Name Confidential]) regarding the database part, in particular we are very active on the Oracle side. Among the activities we carry out, service migrations have a very important part of our work.

Starting from December 2021 we were asked to move the data of an application hosted by a single instance db on a server with Solaris 10 operating system to a rac hosted by a new Oracle Linux cluster (in particular on a PDB ad hoc [multitenant architecture]). Usually for this kind of activities we use the standard export/import of schemas via datapump, in this case, however, the amount of data was considerable (6/7 TB). Therefore discarded the approach through datapump, our technical contact on the VTS side proposed to the customer to export the objects through TTS (Transportable Tablespaces). After evaluating the proposal of our technical contact in relation to the downtime allowed by the customer, we concluded that the only data transfer from the source to the target would probably exceeded the window available. We therefore proposed to use a method (actually poorly documented) that uses TTS in conjunction with cross-platform incremental backups (in fact, here we were migrating from Solaris to Linux, endianness is therefore different https://docs.oracle.com/en/database/oracle/oracle-database/18/spucd/transporting-data-across-platforms.html#GUID-FE3003B9-605A-4269-B167-005AC778C870). Thanks to an ad hoc preparation on the customer's test environment and to a document wrote as a guide, all by our colleague Attilio Seghezzi, our technical representative positively evaluated the approach and gave us the green light for the use of the same for the request. In VTS this method had never been used nor tested and even if the referent was initially rather skeptical, thanks to the detailed work of the colleague he changed his mind.

The last week of April 2022 we carried out a test migration of the application, the downtime was about 6 hours. The testing phase is currently underway but the migration seems to have been successful.

Summarizing, the approach used was the following:

1. Identification of schemas and tablespaces to be migrated (no downtime)
2. Backup level 0 of the tablespaces to be migrated (no downtime)
3. Restore the backup level 0 on the target db (pay attention to endianness, use DBMS_FILE_TRANSFER or convert via RMAN) (no downtime)
4. Backup level 1 (incremental) of the tablespaces on source (no downtime)
5. Recover level 1 backup on target (pay attention to endianness) (no downtime)

FINAL STEPS:

6. Put tablespaces in readonly on source (downtime)
7. Last backup level 1 (incremental) of the tablespaces on source (downtime)
8. Export the metadata relating to the tablespaces to be migrated and the schemas to be migrated (downtime)
9. Last recover of backup level 1 on target (attention to endianness) (downtime)
10. Import of the metadata of the tablespace on target (downtime) and tablespace in read/write on target
11. Import of schemas metadata on target (downtime)

-> steps 4 and 5 are to be repeated one or more times based on the data produced on the target and the time distance between level 0 and the expected date for the final steps (obviously at the discretion of the dba)

Avviso: Molti dei nostri clienti hanno stipulato accordi di riservatezza che tutelano i loro marchi da scopi commerciali. Pertanto potresti incontrare diciture come “Nome Cliente Riservato” oppure vedrai riportato il settore del cliente invece del suo nome.

Il cliente è un noto gruppo bancario internazionale con un fatturato annuo superiore ai 20 miliardi.

Da ormai un paio d'anni collaboriamo con VTS (join venture tra [Nome Cliente Riservato] e IBM che si occupa di gestire l'infrastruttura tecnologica di [Nome Cliente Riservato]) per quanto riguarda la parte database, in particolare siamo molto attivi sulla parte Oracle. Tra le attività principali che svolgiamo le service migrations occupano una porzione molto importante del nostro lavoro.

A partire dal mese di dicembre 2021 ci è stato richiesto di spostare i dati di un'applicazione ospitata da un db single instance su un server con sistema operativo Solaris 10 verso un rac ospitato da un nuovo cluster Oracle Linux (in particolare su un PDB ad hoc [architettura multitenant]). Solitamente per questo genere di attività utilizziamo export e import degli schemas tramite datapump, in questo caso però la mole di dati era considerevole (6/7 TB). Scartato quindi l'approccio tramite datapump il nostro referente tecnico lato VTS ha proposto al cliente finale di esportare gli oggetti tramite le TTS (Transportable Tablespaces). Dopo aver valutato la proposta del nostro referente tecnico in relazione alla finestra di downtime ammessa dal cliente siamo giunti alla conclusione che il solo trasferimento di dati da source a target avrebbe probabilmente sforato la finestra a disposizione. Abbiamo quindi proposto di utilizzare un metodo (in realtà poco documentato) che utilizza le TTS in congiunzione ai backup incrementali cross-platform (infatti qui passiamo da Solaris a Linux, l'endianness è quindi diversa https://docs.oracle.com/en/database/oracle/oracle-database/18/spucd/transporting-data-across-platforms.html#GUID-FE3003B9-605A-4269-B167-005AC778C870). Grazie ad una preparazione ad hoc sull'ambiente di test del cliente e la scrittura di un documento guida, il tutto a cura del collega Attilio Seghezzi, il nostro referente tecnico ha valutato positivamente l'approccio e ci ha dato il via libera per l'utilizzo dello stesso per la migrazione richiesta. In VTS questo metodo non era mai stato utilizzato nè testato e anche se inizialmente il referente era piuttosto scettico, grazie al dettagliato lavoro del collega si è ricreduto.

L'ultima settimana di aprile 2022 abbiamo effettuato una migrazione di test dell'applicativo, il downtime è stato di circa 6 ore. La fase di test è attualmente in corso ma sembra proprio che la migrazione abbia avuto successo.

Riassumendo l'approccio utilizzato è stato il seguente:

1. Individuazione degli schemas e delle tablespaces da migrare (no downtime)
2. Backup level 0 delle tablespace da migrare (no downtime)
3. Restore del backup level 0 sul db target (attenzione all'endianness, utilizzare DBMS_FILE_TRANSFER oppure effettuare convert tramite RMAN) (no downtime)
4. Backup level 1 (incrementale) delle tablespace su source (no downtime)
5. Recover del backup level 1 sul target (attenzione all'endianness) (no downtime)

STEP FINALI:

6. Mettere tablespaces in readonly su source (downtime)
7. Ultimo backup level 1 (incrementale) delle tablespace su source (downtime)
8. Esportare i metadati relativi alle tablespaces da migrare e agli schemas da migrare (downtime)
9. Ultimo recover del backup level 1 sul target (attenzione all'endianness) (downtime)
10. Import dei metadati delle tablespace su target (downtime) e tablespace in read/write su target
11. Import dei metadati degli schemas su target (downtime)

-> gli step 4 e 5 sono da ripetere una o più volte in base ai dati prodotti sul target e alla distanza temporale tra level 0 e data prevista per gli step finali (ovviamente è a discrezione del dba)