|
The duties of a Unix systems administrator range from the simple and mundane, to the complex and mission-critical. We are often called upon to reset a password, remove an unwanted file, restore a backup, apply security patches, etc. Though not very challenging, these tasks are important and must be performed with vigor. Less frequently, we are enlisted to perform a challenging task, offering us a chance to learn something new and prove our worth.
Such tasks include operating system upgrades, building Web server farms, allocating new disk arrays, and database migrations, to name a few. Database migrations, which are the most complex and mission critical, offer the most reward and the opportunity to add new skills to one's oeuvre. Veritas Volume Manager (VxVM), available for most Unix platforms, has become the de facto LVM in many shops because of its advanced features and standardized command set across platforms. To provide a brief overview, VxVM allows the creation of volumes, which are logical devices that appear to the operating system as a type of hard disk or disk partition (i.e., a virtual disk). Volumes can be constructed from one disk to many disks supporting various RAID levels (RAID-0, RAID-1, RAID-5, etc.) as well as simple disk concatenation. The advantages of volumes include increased storage capacity beyond single disk, various degrees of data protection, increased read/write performance, and ease of storage management to name a few. Successful database migrations with VxVM require careful planning and preparation, but the reward is well worth the effort. Before the migration can begin, the DBA must determine the feasibility of the migration, since not all migrations can be performed with Veritas Volume Manager. There are several prerequisites for performing a migration with VxVM. First, the database should to be built from raw device volumes. If it isn't, forget about using VxVM for the migration. Instead, use any of the supplied database utilities or one of the aforementioned Unix archive/copy utilities. Second, does the target database support the original database's data files? If the migration is to a minor version upgrade of the database on the same platform, then this is most likely the case. However, if the migration is to a new major version of the database, then the DBA may need to consult with the database vendor first. In any event, if the new version of the database doesn't directly support the database files, VxVM may still be used for the migration and an in-place upgrade on the migrated database can be performed. Unfortunately, a VxVM database migration to a new platform, such as from Solaris to Windows, or to a new database platform, such as from Informix to Oracle, is probably not possible. If you've satisfied the VxVM database migration prerequisites, then a database migration the VxVM way might just be for you. Read more at SysAdmin |
