Changing Databases

Migrating from Oracle to Microsoft SQL Server

B Y

L E S L I E

C A I R N S

M any companies are looking to

save money by migrating from an
Oracle/UNIX platform to a
Microsoft SQL Server/Windows
platform. That was the main reason
for our migration. We were also
looking to upgrade to the latest
version of PeopleSoft HRMS.
Initially when I began looking at the
migration and upgrade, I was a bit
overwhelmed with project. I decided
that SQL Server would be easier to
work with than Oracle, and I wanted
to do the toughest part of the project
on that platform. I would migrate
my data over to the new platform,
then perform the upgrade on SQL
Server.

...to complete a project that

encompasses both a
migration and an upgrade, I
would suggest,completing
your upgrade on your
current platform and then
completing the migration to
the new platform.

I began looking at the Data

Transformation Services, or DTS,
feature built into SQL Server to get
my data tranferred. It seemed
pretty straight forward. However,
the most important tool I had
overlooked was already given to me
by PeopleSoft Data Mover. If you
look up Data Mover in PeopleBooks,
one of the tasks it was designed for
is to transfer PeopleSoft databases
across operating systems and
database platforms. But, before I
started with the data itself, I had to
get the Microsoft platform ready.
The first thing you will want to do
is contact PeopleSoft and request the
necessary version of the software for
your new platform, in my case
HRMS 7.51, or the version that you
may be upgrading to, such as HRMS
8.3. Once you have received the
software, you will need to install it
to the SQL Server/Windows
platform. You will need to create the
AUSYS, DMO, and PROD databases
per your PeopleSoft installation
documentation and then do your
initial backup of the databases.
If your company is going to
complete a project that encompasses
both a migration and an upgrade, I
V P 1 O N L I N E . C O M

18

would suggest completing your

upgrade on your current platform
and then completing the migration
to the new platform. You will save
yourself a lot of time in the long
run.
When I received the HRMS v7.51
for my new platform, it included the
tax updates through 99-B. If the
version that you receive is the same,
you will need to apply all of the tax
updates that have been applied on
your current version. In my case, I
had to apply 16 tax updates. You
will also need to include any of the
updates that have been done to your
system that were not included in the
tax updates. These would include
those that add/delete/change
anything that you can open in the
Application Designer such as fields
and records. To save some time, I
only concentrated on those that
changed the PeopleTools data, not
cobol or sqr changes, because I only
used this pseudo-system as a
staging area. The main goal is to get
your table structures on the new
platform to match the table
structures on your old platform.
Otherwise, you may receive an error
when you attempt to import your
data to the new platform. Now, if
you tackle your upgrade prior to
your migration to a new platform,

19

you will need to apply every part of

every update that you performed on
your current system. If you are
unsure of the current tax updates
applied to your system, you can find
out by navigating to: Define
Business Rules/Define Payroll
Taxes/Report/Tax Update. This will
display all of the tax updates that
have been done to your system since
this table was created in tax update
00-A. Keep in mind that if you have
made any customizations to your
database objects, such as fields,
records, panels, etc, you will need to
apply those same customizations on
your new database platform. At this
point, you will need to run the
SYSAUDIT.SQR and the
DDDAUDIT.SQR to flush out any
errors that may be lurking in the
shadows prior to the first data load.
The SYSAUDIT.SQR is used to
compare inconsistencies with your
PeopleTools tables, such as orphaned
records. The DDDAUDIT.SQR will
compare the PeopleTools table
structures against the database
structures. If either report shows
any type of error, they will need to
be resolved.

Once you have cleaned up both of

these reports, its a good idea to do
the sp_updatestats stored procedure
in Query Analyzer. This will update
all of your table indexes.
Make sure to do a backup of
Listing 1
the database after all of the
set log c:\Temp\Export_HRPROD.log;
updates are applied. It may be
set output c:\Temp\HRPROD.db;
necessary to restore the
set no trace;
export *;
database (the one done after

V P 1

J A N

F E B

2 0 0 3