Lessons from the time machine

Transcription

1 Worldwide Managed Services for OpenVMS and Rdb Lessons from the time machine Software Concepts International, LLC 402 Amherst Street, Suite 300 Nashua, NH 03063, USA Phone:

2 About Software Concepts International, LLC Questions to Consider How to Upgrade to Rdb V7.2 Moving Your Data Validating the Moved Data Cutting Over to New System Questions and Feedback World class managed services for OpenVMS 2

3 About Software Concepts International The leading provider of managed services for Rdb, DBMS and OpenVMS 24+ years in the business Performed many, many, many successful Rdb, DBMS and OpenVMS migrations from VAX Alpha, VAX Integrity and Alpha Integrity. Worldwide support World class managed services for OpenVMS 3

5 1. What version of Rdb are you on now? 2. Are you physically ymoving the database to new storage? (Are you moving the database to new storage or a new system?) World class managed services for OpenVMS 5

6 This means Rdb on Integrity and Rdb on Alpha share the exact same on disk structures (the data is the same) iff you are running Rdb v7.2 on Alpha and you are operating in a mixed architecture Alpha/Integrity cluster then Congratulations! Your (database) migration is complete! (you may still have to migrate your application). World class managed services for OpenVMS 6

7 In it s simplest form*, upgrading to Rdb v7.2 is as easy as using RMU/CONVERT to (now, the small print ) *This assumes that: update the RDB root file..fast! Done! Thank you for your time 1. The database is NOT being moved to new storage. 2. The source database is already at Rdb v7.0 or v The prior database convert has been committed. World class managed services for OpenVMS 7

8 What if you are running Rdb v6.1 or earlier? What if the database is being physically moved to new storage? What if the new storage is not available from the old hardware? What if downtime is not unlimited? World class managed services for OpenVMS 8

9 1. How to upgrade Rdb versions 2. Is the data moving World class managed services for OpenVMS 9

11 Depends on: Your prior version 5.0 and before 5.1 to to 7.1 Your prior hardware VAX Alpha The chosen upgrade method RMU/CONVERT or RMU/BACKUP & RESTORE EXPORT/IMPORT or UNLOAD/LOAD World class managed services for OpenVMS 11

12 There are multiple upgrade options 1. RMU/CONVERT 2. RMU/BACKUP RESTORE 3. SQL EXPORT IMPORT 4. RMU/UNLOAD CREATE LOAD World class managed services for OpenVMS 12

13 Rdb 7.2 (Alpha or Integrity) Rdb 7.0 (VAX or Alpha) Rdb v7.1 (Alpha) Rdb v5.1, v6.0 or v6.1 (VAX or Alpha) Rdb v (VAX) World class managed services for OpenVMS 13

14 1. Fast Benefits Limitations 1. Does not move data to new storage 2. Must follow Convert Upgrade Path (may need intermediate versions of Rdb) 3. Prior convert must have been committed World class managed services for OpenVMS 14

15 Benefits 1. Ability to move data to new storage 2. Preserves prior database version intact t (assuming you do not need to drop the old database for space) Limitations 1. Time to backup 2. Time to restore 3. Time to move backup file to new system/storage (if not available directly) 4. Storage space for backup World class managed services for OpenVMS 15

16 Benefits Limitations 3. An exact copy of the 5. An exact copy of the user user storage areas storage areas (no risk) (no improvement) 6. Must follow Restore Upgrade Path (may need intermediate versions of Rdb) 7. Prior convert must have been committed. World class managed services for OpenVMS 16

17 Upgrade and Move Rdb 7.2 (Alpha or Integrity) Rdb 7.0 (VAX or Alpha) Rdb v7.1 (Alpha) Rdb v5.1, v6.0 or v6.1 (VAX or Alpha) Rdb v (VAX) World class managed services for OpenVMS 17

18 Benefits 1. Ability to move data to new storage 2. Restructures t the database tb (Rebuilds indexes, places data based on current storage maps) 3. Ability to make some physical changes during the import 4. Preserves prior version of the database intact (assuming that you do not need to drop the old database for space) 5. Can migrate directly to v7.2 World class managed services for OpenVMS Limitations 1. Time to export 2. Time to import 3. Time to move export file to new storage (if not available directly) 4. Storage space for export 18

19 Benefits Limitationsit ti 1. Ability to move data to new storage 2. Restructures the database 3. Ability to make physical and logical changes to the database 4. Loads of target database may start as unloads complete (parallel unload/load) 5. Can migrate directly to v Time to unload 2. Time to load 3. Storage space for unload files 4. Complexity World class managed services for OpenVMS 19

21 Is the database being moved to different storage? Are the old and new systems part of the same OpenVMS cluster? If moving to new storage, is the new storage accessible to the old system, if yes, how? Cluster available storage DECnet TCPIP World class managed services for OpenVMS 21

22 1. RMU/BACKUP RESTORE 2. SQL EXPORT IMPORT 3. RMU/UNLOAD CREATE LOAD 4. HOT STANDBY or warm spare (Physical AIJ synchronization) i 5. LOGMINER (Logical AIJ synchronization) 6. OpenVMS volume shadowing (using Dissimilar Device Shadowing) World class managed services for OpenVMS 22

23 Key points: CONVERTS are FAST MOVES are slow Need to MOVE the data to the new system first, THEN convert at cutover. World class managed services for OpenVMS 23

24 Move database before cutover, and apply transactions to database on target storage: *Applying AIJs *Hot standby Logminer + JCC loader At cutover, apply final transactions, and perform Rdb v7.2 conversion *Source and target systems must be running the same version of Rdb. World class managed services for OpenVMS 24

25 Source (old) system Target (new) system database AIJ AIJ database AIJ AIJ RMU- /BACKUP db backup db backup RMU- /RESTORE World class managed services for OpenVMS 25

26 repeat RMU /BACKUP /AFTER RMU /RECOVER database AIJ AIJ Aij back Aij back database AIJ AIJ Rdb Hot-standby or Logminer + JCC loader may also be used! World class managed services for OpenVMS 26

27 but, I m running Rdb v6.1* on my old system, and Rdb v6.1 is not available on the new system? Can I still use the fast move technique? Yes! * Any version of Rdb prior to v7.2 (v3.x, v4.x, v5.x, v6.x, v7.0, v7.1) World class managed services for OpenVMS 27

28 Only Rdb v7.2 runs on Integrity (can t apply AIJs) Must have access to prior versions Cluster member? VAX or Alpha emulator World class managed services for OpenVMS 28

29 One creative solution to this problem is through the use of VAX or Alpha virtualization software to create a VAX or Alpha environment that runs on the new Hardware. Integrity Server OpenVMS v8.3x Rdb v7.2x VAX or Alpha Virtualization (Software) OpenVMS v6.2 Rdb v6.1 World class managed services for OpenVMS 29

30 repeat Virtual RMU /BACKUP /AFTER RMU /RECOVER Virtual VAX / Alpha database AIJ AIJ Aij back Aij back database AIJ AIJ World class managed services for OpenVMS 30

32 How do I know that the data was not changed during the migration? Depending on the method used for migration, and the type of data, this may be a real issue or it may only be an exercise for the truly paranoid. World class managed services for OpenVMS 32

33 1. RMU/verify <target db> if failure, verify source db (perhaps the source was also bad) 2. Use RMU/Analyze on both source and target databases to obtain row counts compare row counts by table. Note: If export/import or unload/load was used to move the database and tables are horizontally partitioned, you need to aggregate row-counts by table before comparing results. World class managed services for OpenVMS 33

34 3. Perform application audit totals (compare column totals for key tables/columns) 4. For the truly paranoid unload all tables to individual files, sort, and checksum each unload file compare source/target checksums. 5. Database Protections (RMU and SQL) Be careful of different identifier values on new server Three areas to verify RMU Privileges database root SQL Privileges database root Database Table and Object Privileges World class managed services for OpenVMS 34

35 Data is placed in the target database according current storage map definitions (which may have been modified since the data was originally stored in the source database). For tables that are horizontally partitioned, the placement of the data in the target database may be in different storage areas than that of the source database. This is due to partition definitions that were changed in the source database after the data was originally inserted. Note: This is not an issue if upgrade was a performed with RMU/convert or RMU/restore World class managed services for OpenVMS 35

36 Example Partitioning Results: World class managed services for OpenVMS

37 Results with Subtotals: World class managed services for OpenVMS

38 In some older versions of Rdb, EXPORT was not able to process views that referenced system relations. Result: Export would fail Solution: Drop the views prior to Export World class managed services for OpenVMS 38

40 1. Shutdown application 2. Close database 3. Execute migration/upgrade 4. Validate results 5. Test application 6. Open to users World class managed services for OpenVMS 40

41 Worldwide Managed Services for OpenVMS and Rdb World class managed services for OpenVMS 41