accenture enkitecgroup migrating to exadata … · •changes to source immediately replicated to...

MARTIN BACHDOAG EXADAY 2017

MIGRATING TO EXADATAMADE EASY(ER)

Accenture Enkitec Group

Copyright © 2016 Accenture All rights reserved. |

MIGRATIONS MADE EASYAN OVERVIEW

2

Migrations do not need to be scaryKnowing what to do and testing should provide enough confidence to rise to the challenge.At the end of this session I hope you are more familiar with the migration methods available.

Copyright © 2016 Accenture All rights reserved. | 3

$(WHOAMI)MARTIN BACH

• I work for Accenture Enkitec Group– Opinions are strictly my own

• Authoring– Co-author of Pro Oracle RAC 11g on Linux– Expert Consolidation in Oracle Database 12c– Lead author of Expert Oracle Exadata 2nd edition

martincarstenbach.wordpress.com

@MartinDBA


AGENDAWHAT TO EXPECT

The Exadata Migration• An overviewLogical migration• Data Pump based• Golden Gate basedPhysical migration• Recovery Manager• Data Guard and friendsCombinations• Fully Transportable Tablespaces


MIGRATING TO EXADATA


We do not migrate to Exadata without full regression testing. Period.

And our test environment matches production.Ideally we strive to use Exadata features as much as we can.


MIGRATING TO EXADATAREASONS

Plenty of reasons to migrate• End of life on hardware• Entire platform decommissioned• Consolidation on single hardware platform• Need the performance• Save on licenses• ...


MIGRATING TO EXADATADECISION TIME

A lot of decisions …• Exadata as reporting platform• Exadata as consolidation platform• Migrate and upgrade?• Migrate or stay on same release?– 12c Container Database – 12c Non Container Database


MIGRATING TO EXADATAPLANNING THE MOVE

Sizing is hard – try a scientific approach nevertheless• Don’t just put the finger in the air• Refrain from sizing by budget• Which databases are in scope?• Analyse their workload characteristics– Your methodology– eDB360 and eSP– https://carlos-sierra.net/edb360-an-oracle-database-360-degree-view/

• Size accordingly– CPU, memory, IO latency and bandwidth etc.– Develop/document/test migration strategy


MIGRATING TO EXADATAPLANNING THE MOVE: IOPS


MIGRATING TO EXADATAPLANNING THE MOVE: THROUGHPUT


MIGRATING TO EXADATA


MIGRATING TO EXADATATHE OPPORTUNE MOMENT

The migration to Exadata opens the doors to reflect about• The way you run your IT department– Standards– Automation– Consolidation

• Maybe you could even give it a fancy name

Con

solid

atio

n

Auto

mat

ion

Stan

dard

isat

ion

Future Architecture

Legacy IT landscape


MIGRATING TO EXADATAEXADATA USE CASE #1

Reporting• Usually one application• High visibility• Very critical• Long historyOften migrated from Big Iron


MIGRATING TO EXADATAEXADATA USE CASE #2

Consolidation• Often multiple database instances• Use Resource Management– Database Resource Manager goes without saying– Use I/O Resource Manager as well, because you can

• Do not oversubscribe if you can avoid it• Focus on Flash usage• Must get sizing rightOften green-field


MIGRATING TO EXADATASOFTWARE OPTIONS

Maybe you don’t want to think about this…

Anyone considering 12.2 yet?


MIGRATING TO EXADATAORACLE 12C RELEASE 2

Oracle 12.2.0.1 is out for everyone by now• Exadata was one of the first to receive 12.2 RDBMS and 12.2 cell software• But be careful:– The list of new features is the longest I have ever seen in the “what’s new section”– With new features you find new bugs– The first proactive bundle patch is out …– And has been withdrawn

• Personally I wouldn’t put 12.2 on anything but lab systems as of May 2017


MIGRATION STRATEGIES

19


MIGRATION STRATEGIESFACTORS INFLUENCING THE MIGRATION

Migration Strategy

Database size

Skills within the team

Database source

platformDowntime

window

42 other factors...


MIGRATION STRATEGIESWHERE YOU MIGHT BE COMING FROM

Big Endian

Little Endian


MIGRATION STRATEGIESLITTLE VS BIG ENDIAN

And why does it matter at all?• Exadata is based on Intel Xeon processors• These use a little-endian architecture• Migrating to Exadata from a Big Endian Platform– SPARC, pSeries, Itanium, …– Requires an endianness conversion– A tad more work

• Migrating from Little Endian– Little endian to little Endian can be very simple– Even more so if you are on the same O/S platform

• Exadata SL6


MIGRATION STRATEGIESAN OVERVIEW

Logical migration• Traditional export and import• Data Pump export and import• Database links• SQLPlus ”copy” command

Replication• Streams• Oracle Golden Gate• Third party

Physical migration• Data Guard• Backup and Restore

Combinations• Fully transportable TTS


MIGRATION STRATEGIESMIGRATION TARGETS

Potential source systems include Targets can be• Database• Schemas• Pluggable Database

t

LOGICAL MIGRATION


LOGICAL MIGRATIONCONCEPTS

Logical migrations do not migrate data bit for bit• Characteristics– Extract objects from the source– Reload them into the target database

• Think about these factors– Staged migration– Selective migration– Platform difference– Hybrid Columnar Compression


LOGICAL MIGRATIONEXTRACT AND LOAD

Example: Data Pump• Select what to export• Export to file or via network• Import into destination

Example: database links• Create a database link between databases• CTAS or IAS to move data• Can be parallelised easily


LOGICAL MIGRATIONDATA PUMP AT A GLANCE

Advantages• Can transform DDL on the fly within limits• Can compress data (*)• Possible to take subset of source• Heavily parallelised• Platform-neutral format• Easy to combine migration with upgrade to 12c

Disadvantages• DML most likely suspended• Potentially long outage window• Requires 10g+ on the source• Cumbersome for large volumes


REPLICATION BASED MIGRATIONCONCEPTS

How does a replication-based migration work?• Characteristics– Capture changes from the source– Instantiate copy of source in Exadata– Ship and apply captured changes– Based heavily on keyed tables

• Examples– Streams– Golden Gate– Logical Standby


REPLICATION BASED MIGRATIONPOTENTIAL BENEFITS

Remember that Big Endian Little Endian migrations were difficult?• Works between platforms• Allows you to change things in Exadata• Works even outside of Oracle’s RDBMS• Also the only option for near-zero downtime migration– That’s why it’s expensive– And complex


REPLICATION BASED MIGRATIONSTREAMS AT A GLANCE

Advantages• Part of the package• Can capture at source or downstream• Based on log mining• Can capture DDL (*)

Disadvantages• Bulk statements difficult• Not very stable in my experience• Recreating Streams configuration difficult at best• Deprecated in 12c• No support for CDBs• Needs babysitting


REPLICATION BASED MIGRATIONGOLDEN GATE AT A GLANCE

Advantages• Easier to set up than Streams• More robust• New integrated capture supports more data types

(and compression)• Supports bulk updates• Can capture (some) DDL• The future anyway

Disadvantages• Costs you money• SQL interface can be inferior to Streams• A bit of a learning curve• Might need addition of indexes


REPLICATION BASED MIGRATIONLOGICAL STANDBY

No one seems to be using Logical Standby for migrations

Or are you?


REPLICATION BASED MIGRATIONSUMMARY

A “logical” migration strategy can be very flexible• Most flexibility due to the option to– Change data model “on the fly”– Introduce Hybrid Columnar Compression, partitioning, …– Insert favourite feature here

• Requires careful planning– “Staged” migration– Otherwise potentially large outage window

• Verification of data post-migration can be a headache

PHYSICAL MIGRATION


PHYSICAL MIGRATIONCONCEPTS

Unlike logical migration patterns you get a 1:1 copy with a physical migration• A block-for-block copy of the source in Exadata• Examples– RMAN backup and restore– Data Guard Physical Standby– Transportable Tablespaces

• Usually the preferred method• Know the restrictions


PHYSICAL MIGRATIONRMAN-BACKUP AND RESTORE (1)

Bread and butter DBA job• Take a backup of the source database– Including spfile, other components– Restore into Exadata

• Restrictions– For the most part restricted to same platform– Cannot change the database structure during migration– Migration and Upgrade a bit more difficult


PHYSICAL MIGRATIONRMAN-BACKUP AND RESTORE (2)

RMAN backup and retore can be seriously quick• Clever use of dNFS and RMAN channels in Full Rack!• Restoring from a ZFSSA over IB rocks• Time requirement based on database size and bandwidth• Requires downtime until restore is complete– Remedy: incremental backup and roll forward– Nothing prevents you from being ready


PHYSICAL MIGRATIONDATA GUARD (1)

Whenever you can, use this method• Data Guard based migrations are arguably the easiest way to do it– RMAN duplicate/restore/etc.– 1:1 copy of the source database in Exadata– Added into Data Guard Broker configuration

• Changes to source immediately replicated to Exadata• Switchover is a one liner– No need to worry about data– Can even test database in read only mode on Exadata


PHYSICAL MIGRATIONDATA GUARD (2)

There is fine print to be known with this method as well• Almost always limited to same platform– Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard

Configuration (Doc ID 413484.1)– Using Oracle Data Guard between IBM AIX on Power systems and Oracle Solaris on SPARC

systems (Doc ID 1982638.1)

• Nevertheless my Preferred Migration Method


PHYSICAL MIGRATIONTRANSPORTABLE TABLESPACES

A common way to move a lot of data fast• Simple in theory:

1. Set tablespace to read-only on source2. Export tablespace metadata from source3. Transport files to destination4. Create necessary metadata (users, grants)5. Import tablespace metadata to destination6. Make tablespace available for reading and writing

• If you have a large enough downtime window

Might require Endiannessconversion


PHYSICAL MIGRATIONTRANSPORTABLE TABLESPACES AT A GLANCE

Advantages• Quicker than logical migration• A lot.• Can cross platforms• Digests different block sizes (*)

Disadvantages• Data must be self-contained• Not all objects supported• Downtime during transport/conversion• Metadata export can be lengthy• Must ensure SYSTEM data is loaded• Characterset!• Encryption not supported• Manual process (*)


PHYSICAL MIGRATIONX-PLATFORM TTS + INCREMENTAL BACKUPS

New migration method• Cross Platform incremental backups + TTS addresses– The need for extended downtime– Read-Only phase can be shortened– Less/no need for replication tools

• Implemented as a perl script available from MOS• Not terribly suitable for large ERP systems (EBS, SAP, …)• Reference– Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup– Note for 11.2 and 12.1


PHYSICAL MIGRATIONSUMMARY

The physical migration is potentially the quickest way to move data• Tradeoff– Speed of migration vs.– Flexibility

• Physical migration usually very quick– Big Bang or– Changes from production applied incrementally

• Usually requires a “phase two” to optimise for Exadata

FULL TRANSPORTABLE EXPORT/IMPORT


FULL TRANSPORTABLE EXPORTCONCEPTS

Exporting data is slow. Using Transportable Tablespaces is hard work• Oracle strives at making hard work easier with fully transportable tablespaces• Combination of TTS and full export/import– User data transported using TTS– Administrative data transported using Data Pump– Takes care of a lot of steps

• Does not perform platform migration automatically• From 11.2.0.3 onwards• Well suited to migrate to Pluggable Databases


FULL TRANSPORTABLE EXPORTCOMPARISON WITH TRADITIONAL TTS

Traditional Transportable Tablespaces are• Faster than Data Pump when moving lots of data• Can be combined with option to change platform• Really quick in summary!• But: objects in the SYSTEM tablespace are not included

Is there no way to combine the convenience of Data Pump Exportwith the speed of plugging a tablespace in?


FULL TRANSPORTABLE EXPORTCONCEPTS

Full Transportable Tablespaces• Requires 11.2.0.3 or later as source• Must be 12.1 or later as destination• Distinction: – User Tablespace– Administrative Tablespace

• Prerequisites– All user tablespaces must be read only– User tablespaces must be self-contained


FULL TRANSPORTABLE EXPORTEXAMPLE

Example setup: Source• Oracle Linux 6.8 64bit• Oracle 11.2.0.4.170418 (including OVJM patch)• User tablespaces:– USERS– SOE_TBS

• Linux timezone: America/New_York• dbtimezone: +00:00• sessiontimezone: -04:00

Example setup: Destination• Oracle Linux 7.3 64bit• Oracle 12.2.0.1.0• Linux timezone: America/New_York• dbtimezone: +00:00• sessiontimezone: -04:00• Shell database created by dbca


FULL TRANSPORTABLE EXPORTEXAMPLE: EXPORT

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing optionsStarting "SYSTEM"."SYS_EXPORT_FULL_01": system/******** full=y dumpfile=expfulltts.dmp directory=data_pump_dir transportable=always logfile=expfulltts.log version=12Estimate in progress using BLOCKS method...Processing object type DATABASE_EXPORT/PLUGTS_FULL/FULL/PLUGTS_TABLESPACEProcessing object type DATABASE_EXPORT/PLUGTS_FULL/PLUGTS_BLKProcessing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA…Processing object type DATABASE_EXPORT/AUDITProcessing object type DATABASE_EXPORT/POST_SYSTEM_IMPCALLOUT/MARKER. . exported "SYS"."KU$_USER_MAPPING_VIEW" 5.914 KB 31 rows. . exported "SYS"."AUD$" 34.56 KB 73 rows. . exported "SYS"."DAM_CONFIG_PARAM$" 6.367 KB 10 rows. . exported "WMSYS"."WM$ENV_VARS" 5.921 KB 3 rows…. . exported "SYSTEM"."REPCAT$_USER_PARM_VALUES" 0 KB 0 rows. . exported "SYSTEM"."SQLPLUS_PRODUCT_PROFILE" 0 KB 0 rowsMaster table "SYSTEM"."SYS_EXPORT_FULL_01" successfully loaded/unloaded******************************************************************************Dump file set for SYSTEM.SYS_EXPORT_FULL_01 is:/u01/app/oracle/admin/SRC/dpdump/expfulltts.dmp

******************************************************************************Datafiles required for transportable tablespace SOE_TBS:/u01/oradata/SRC/datafile/o1_mf_soe_tbs_dhycnlc5_.dbf

Datafiles required for transportable tablespace USERS:/u01/oradata/SRC/datafile/o1_mf_users_dhy7gbhr_.dbf

Job "SYSTEM"."SYS_EXPORT_FULL_01" successfully completed at Tue Apr 25 11:36:54 2017 elapsed 0 00:03:33


FULL TRANSPORTABLE EXPORTEXAMPLE: EXPORT

Notable objects exported during the procedure• APEX• OUTLN • SYS – AUD$, NET$_ACL– Auditing, FGA

• SYSMAN: database control• SYSTEM– Scheduler– Replication

• WMSYS


FULL TRANSPORTABLE EXPORTEXAMPLE: IMPORT

Very similar to traditional Transportable Tablespaces• User activities have been quiesced during the export• Do you need an endianness conversion?– If no, you can simply copy the files to the destination host– If you need one, you can use DBMS_FILE_TRANSFER or RMAN convert

• Probably best not to use the original files on the source



Import: Release 12.2.0.1.0 - Production on Wed Apr 26 05:29:05 2017

Copyright (c) 1982, 2017, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit ProductionMaster table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloadedStarting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** full=Y dumpfile=expfulltts.dmp directory=DATA_PUMP_DIR transport_datafiles=/u01/oradata/DST/datafile/o1_mf_soe_tbs_dhycnlc5_.dbf, /u01/oradata/DST/datafile/o1_mf_users_dhy7gbhr_.dbf logfile=imp_full_transportable.logProcessing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER…ORA-31685: Object type USER:"SYS" failed due to insufficient privileges. Failing sql is:ALTER USER "SYS" IDENTIFIED BY VALUES 'S:4368896C8AE3E10E8497BEC72D5D8D2FC863FAF4A6;4DE42795E66117AE' TEMPORARY TABLESPACE "TEMP"Processing object type DATABASE_EXPORT/SCHEMA/USERORA-31684: Object type USER:"OUTLN" already existsORA-31684: Object type USER:"ORDDATA" already existsORA-31684: Object type USER:"OLAPSYS" already existsORA-31684: Object type USER:"MDDATA" already existsORA-31684: Object type USER:"SPATIAL_CSW_ADMIN_USR" already existsProcessing object type DATABASE_EXPORT/ROLE

…ORA-39082: Object type PACKAGE BODY:"APEX_030200"."WWV_RENDER_CHART2" created with compilation warningsORA-39082: Object type PACKAGE BODY:"APEX_030200"."WWV_RENDER_REPORT3" created with compilation warningsORA-39082: Object type PACKAGE BODY:"SOE"."ORDERENTRY" created with compilation warningsORA-39082: Object type TRIGGER:"APEX_030200"."WWV_BIU_FLOW_SESSIONS" created with compilation warningsORA-39082: Object type TRIGGER:"SYSMAN"."MGMT_CREDS_INS_UPD" created with compilation warningsJob "SYSTEM"."SYS_IMPORT_FULL_01" completed with 563 error(s) at Wed Apr 26 05:42:38 2017 elapsed 0 00:13:27



Things that went wrong during the import• Duplicate users, roles, tables, sequences, …• APEX• Missing SYS grants• Lots of compilation errors at the end



Be conscious of timezone differences and Timestamp with Local Timezone

[oracle@server1 ~]$ impdp ...

Import: Release 12.1.0.2.0 - Production on Mon May 18 12:22:12 2016

Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, Advanced Analyticsand Real Application Testing optionsMaster table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloadedSource time zone is +00:00 and target time zone is -07:00.

...

ORA-39360: Table "SOE"."ORDERS" was skipped due to transportable import and TSLTZ issues resulting from time zone mismatch.ORA-39082: Object type PACKAGE:"SOE"."ORDERENTRY" created with compilation warningsORA-39112: Dependent object type INDEX:"SOE"."ORDER_PK" skipped, base object type TABLE:"SOE"."ORDERS" creation failedORA-39112: Dependent object type INDEX:"SOE"."ORD_SALES_REP_IX" skipped, base object type TABLE:"SOE"."ORDERS" creation failedORA-39112: Dependent object type INDEX:"SOE"."ORD_CUSTOMER_IX" skipped, base object type TABLE:"SOE"."ORDERS" creation failed…

POST MIGRATION


POST MIGRATIONADDITIONAL STEPS

Ideally this work has already been tested prior to the cut-over weekend• Use your documented post-migration steps– You wrote them down– You tested them– So let’s make use of this

• Exadatafy– Simplify if you used physical migration– Review and optimise if needed


POST MIGRATIONADDITIONAL STEPS

At the very least ensure the following are in place• Monitoring• Infrastructure services • Maintenance/patch plans• Maybe also provide extra support for the app-team?


POST MIGRATIONEXADATAFICATION

You pay all that money, so why don’t you strive for more?• Lift and Shift is not bad– You need to get started!– Don’t over-engineer the solution– First results quickly

• But– Don’t stop there– Analyse workload– Optimise for Exadata


POST MIGRATIONEXADATAFICATION

It is well worth learning about Exadata features• If you don’t investigate in understanding Exadata– … you don’t learn about Smart I/O and – More specifically Smart Scans– You miss out on the use of Hybrid Columnar Compression– … and how to use it most efficiently– … you don’t get to use I/O Resource Manager

• And we forgot to mention all the other useful features!

UNLEARNING

63


UNLEARNINGEXADATA IS EVER SO SLIGHTLY DIFFERENT

You should probably not• Tune the system on the source platform– Tuning for Exadata <> tuning for non-Exadata– Your source platform is not Smart I/O capable

• Have the largest SGA you could ever dream about– Unless you consolidate on a schema level– Or maybe perform OLTP only work

• Drop all your indexes



You should probably not• Micro-partition your data model– Because your previous storage array didn’t perform– Exadata is very good at scooping a lot of data from disk/flash

• Set lots of obscure underscore parameters• Hint everything to death• Fine-tune stats gathering– Use table prefs if needed– AUTO_SAMPLE_SIZE is ok in 11.2 and newer



Nevertheless the machine has its limits!• In summary Exadata is “just” Oracle on Linux– However the hardware is very fancy!– Nevertheless it adheres to the laws of physics, too

• It cannot do magic– X6-2 has 2s44c88t and up to 1.5TB DRAM per node– X6-8 has 8s144c288t and up to 6 TB DRAM– Yet it is possible to overload even a full rack

• Plan your consolidation carefully

accenture enkitecgroup migrating to exadata … · •changes to source immediately replicated to...

Documents