There are possible problems with the db conversion to Unicode suggested here;
***
3. Convert the db character set/transport the data
1. Empty the temp new database with AL32UTF8 character set
2. Exported (exp utility) the data from original database (source)
with the source character set
3. Copy the dump to the new server
4. Import (imp utility) the data into the new
database(destination) with character set AL32UTF8
***
Whether this would be successful depends on whether you have accented
characters stored as user data and/or as part of the ARS metadata
(form/workflow object names and workflow actions).
If you have characters in your user data that would require multiple bytes to
store (European accented characters for example) in a Unicode database you MAY
find that the data gets truncated when converted as the arserver treats all
field lengths in terms of bytes. For example a field with a length of 10 that
contains this data in the non-unicode system - testätestä - would require 12
bytes to store in a Unicode db. (ARS 7.5 does have some enhancements in this
area but they need to be applied manually at the field level.)
The metadata issue is a problem because the serialised strings used by ARS to
store form/workflow information includes string lengths and this will not be
modified by a conversion at the database level. Example - a form called TESTä
would have entries in the server data dictionary where the string length of 5
is encoded. After conversion to Unicode this string would require 6 bytes to
store and the server would encounter errors when loading and parsing the data
during the cache load on startup. This is likely to leave you with forms that
are not accessible via ARS.
If you are absolutely certain you have no characters that would need multiple
bytes to store in a Unicode db then the db conversion may be an option but I
would strongly recommend that you export/import forms/workflow and data using
ARS tools instead.
Mark Walters
The opinions, statements, and/or suggested courses of action expressed in this
E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary
participation in this forum is not intended to convey a role as a spokesperson,
liaison or support representative for BMC Software, Inc.
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Axton
Sent: 18 September 2009 03:55
To: arslist@ARSLIST.ORG
Subject: Re: Major 6.3 Migration Project
Assumptions I am making:
- You are running custom applications (not sla, itsm, cs, crm, etc.)
- You do not have any external api's (plugins, external binaries
compiled for Solaris) on the ar servers
-
I would go with something along these lines:
1. Build the new 7.5 servers:
1. Install the prerequisite software (db client, java, etc.)
2. Install ARS 7.5, point it at an empty database that uses the
AL32UTF8 character set
1. Install subsystems in use (email, approval, etc.)
3. [1] Manually apply your form/field/permission changes to the core
forms and grab a def
4. [2] You will need a load balancer, get it set up properly, get
the server group set up properly
2. Migration preparation
1. Install the 64-bit 10g oracle client on the old arserver(s)
2. Empty the contents of the new db instance
3. Migration:
1. Upgrade the existing 6.3 server to 7.5
1. Perform a minimal installation (ARServer only)
2. Stop AR on the new and old servers
3. Convert the db character set/transport the data
1. Empty the temp new database with AL32UTF8 character set
2. Exported (exp utility) the data from original database (source)
with the source character set
3. Copy the dump to the new server
4. Import (imp utility) the data into the new
database(destination) with character set AL32UTF8
4. Perform the upgrade installer for other core ar components
(email, fb, approval, etc.)
4. Post-migration
1. Set up oracle data guard
Footnotes:
1. A better option would be to update your applications so they do not
rely on (any) changes to the core forms prior to the migration.
2. Load Balancer: You will require a hardware load balancer (BigIP,
etc.) in front of the ARServers:
- Enable session persistence based on the source ip address
Special Notes:
1. Do perform this operation in a non-production environment prior to
upgrading production and verify it works. Also, during this time, if
you run into workflow problems, generate the defs necessary to apply
to an upgraded system so that you can use them during your upgrade.
Server Groups: Server groups will make the following operations
easier, but is not required to run an HA arrangement with AR:
- Object cache synchronization across all nodes
- Subsystem failover between nodes (e.g., escalations)
DR Failover: There are many approaches to this; the choice usually
depends on the size of your wallet and the practices currently
implemented for dr:
- Using Oracle DG, the db should be available at the time you need to fail over
- You should be able to image the AR VM's in the DR with a near mirror
image of the production hosts (hostname can/may vary)
- This can be done on the fly during a dr or maintained separately
- You will need to create a runbook of the operations required to
perform a failover in the event you do not have any type of automated
failover in place. Tasks would include things like:
- dns changes
- fail over db to standby server
- bring up ar servers
Axton Grams
The opinions, statements, and/or suggested courses of action expressed
in this E-mail do not necessarily reflect those of BMC Software, Inc.
My voluntary participation in this forum is not intended to convey a
role as a spokesperson, liaison or public relations representative for
BMC Software, Inc.
On Thu, Sep 17, 2009 at 7:05 PM, Paul Blasquez <pblasq...@equinix.com> wrote:
> **
> Hello,
>
> I have been tasked from moving our current production installation to a more
> robust/modern installation. Any and all help would be appreciated!
>
> Currently:
>
> -AR System 6.3 custom server (with modifications to forms User and AR System
> Email Messages)
> -Oracle 9iR2 non-unicode
> -Solaris 9
> -Application and Database reside on the same machine
>
> Goal:
>
> -AR System 7.1 or 7.5 (With form modifications intact)
> -Oracle 11g unicode
> -Linux Redhat 5
> -Application and Database on different machines
> -Disaster Recovery (DR) backup site (Using Oracle log-shipping)
> -Local High Availibility (HA) backup server (server groups?)
>
> I have at my disposal 4 Virtual Machines (VMs) to do development and
> testing, with an additional 2 VMs and 2 dedicated servers (for the DBs)
> reserved for the final production installation. (Please note that there
> will be Midtier servers involved in all of this, but their deployment is
> trivial so I'm not including them here.)
>
> From my point of view I see that multiple operations must occur for this
> migration to be successful (in no particular order):
>
> 1) The Oracle 9iR2 DB
> -Must be upgraded to 11g
> -Must be translated into Unicode
> -Must be moved from the Solaris 9 machine to the Linux RH5 machine
>
> 2) The current 6.3 installation
> -Must be upgraded to 7.1 or 7.5
> -Must be configured for server groups
> -Must be moved from the Solaris 9 machine to the Linux RH5 machine
> -Must begin connecting to the DB remotely instead of locally
>
> 3) The finished AR System 7.x installation and Oracle 11g DB
> -Must begin log shipping (Data Guard) to the second DB
> -Must have a method for failing over to the second site
> -Must have a method for local server group failover (load balancer/quick
> TTL DNS)
>
> If you have completed any one of these tasks before, *please* share with me
> your experience and what you would recommend for my situation! I would
> save me hours of researching dead-ends!
>
>
> Finally, I would like input on what would be the correct order to complete
> all of these tasks, so that the cutover would be as smooth as possible with
> the least downtime possible. So far, I have tested the following scenario
> in Dev/Test:
>
> Fresh installation of 7.1/7.5
> -DEF import of workflow
> -ARX import of data
>
> This method seems stable but tedious, as there are many import errors I
> would need to repair. This would be the method I would fall back on if
> there were no more clever/sophisticated way to upgrade.
>
>
> Again, ANY input at all would be GREAT, as of course this project is on a
> tight timeline. THANK YOU to anyone who responds!
>
> ____________
> Paul Blasquez
> Senior Network Engineer/Remedy Developer
>
>
> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers
> Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
