Solution Guide for Migrating Oracle on UNIX to SQL Server - Willy .Net

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong>
on UNIX to SQL Server on Windows
Published April 2005

The in<strong>for</strong>mation in this document and any document referenced herein is provided <strong>for</strong> in<strong>for</strong>mational purposes only, is provided AS IS AND WITH ALL
FAULTS and cannot be understood as substituting <strong>for</strong> customized service and in<strong>for</strong>mation that might be developed by Microsoft Corporation <strong>for</strong> a
particular user based upon that user’s particular environment. RELIANCE UPON THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN
IS AT THE USER’S OWN RISK.
MICROSOFT CORPORATION PROVIDES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION CONTAINED IN
THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN. Microsoft Corporation provides no warranty and makes no representation that
the in<strong>for</strong>mation provided in this document or any document referenced herein is suitable or appropriate <strong>for</strong> any situation, and Microsoft Corporation
cannot be held liable <strong>for</strong> any claim or damage of any kind that users of this document or any document referenced herein may suffer. Your retention of
and/or use of this document and/or any document referenced herein constitutes your acceptance of these terms and conditions. If you do not accept
these terms and conditions, Microsoft Corporation does not provide you with any right to use any part of this document or any document referenced
herein.
Complying with the applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may
be reproduced, stored in or introduced into a retrieval system, or transmitted in any <strong>for</strong>m or by any means (electronic, mechanical, photocopying,
recording or otherwise), or <strong>for</strong> any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights or other intellectual property rights covering subject matter within this
document. Except as provided in any separate written license agreement from Microsoft, the furnishing of this document does not give you, the user,
any license to these patents, trademarks, copyrights or other intellectual property.
In<strong>for</strong>mation in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the
example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and
no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be
inferred.
Microsoft, Visual Basic, Visual Studio, Windows, Windows Server, and Win32 are either registered trademarks or trademarks of Microsoft Corporation
in the United States and/or other countries.
©2005 Microsoft Corporation. All rights reserved.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents
iii
Contents
Preface........................................................................................................................................... ix
Overview..................................................................................................................................................ix
Technical Subjects Covered in This <strong>Guide</strong> ........................................................................................x
Technical Subjects That Are Not Covered in This <strong>Guide</strong>...................................................................x
Intended Audiences .................................................................................................................................xi
Knowledge Prerequisites ................................................................................................................ xiii
How to Use This <strong>Solution</strong> <strong>Guide</strong> ............................................................................................................ xiii
Organization by Chapter..................................................................................................................xv
Document Conventions ................................................................................................................. xvii
Job Aids ................................................................................................................................................ xvii
Contributors ........................................................................................................................................... xix
Program Manager........................................................................................................................... xix
Author ............................................................................................................................................. xix
Editors ............................................................................................................................................ xix
Architects........................................................................................................................................ xix
Test................................................................................................................................................. xix
Feedback ............................................................................................................................................... xix
Introduction to the Microsoft <strong>Solution</strong>s Framework.................................................................. 1
Introduction and Goals............................................................................................................................. 1
Overview of MSF ..................................................................................................................................... 1
MSF Foundational Principles............................................................................................................ 2
The MSF Team Model — Overview.................................................................................................. 2
The MSF Process Model — Overview.............................................................................................. 3
The MSF Disciplines — Overview .................................................................................................... 5
Overview of MSF Phases ................................................................................................................11
Envisioning Phase....................................................................................................................... 13
Introduction and Goals............................................................................................................................13
Understand the Goals of the Migration Project .......................................................................................14
Define the Business Goals ..............................................................................................................15
Identify the Design Goals.................................................................................................................16
Create the Problem Statement ...............................................................................................................18
Create the Vision Statement ...................................................................................................................18
Define the User Profiles..........................................................................................................................19
Assess the Current Situation (High Level) ..............................................................................................19
Capture High Level Requirements..........................................................................................................22
Define the Project Scope ........................................................................................................................22
Define the <strong>Solution</strong> Concept ...................................................................................................................23
Application and Database Migration <strong>Solution</strong> Design Strategy........................................................23
Optimal Strategy..............................................................................................................................30
Set Up a Team........................................................................................................................................30
Special Considerations <strong>for</strong> Setting Up Your Migration Team...........................................................33
Define the Project Structure....................................................................................................................34
Define Project Communications ......................................................................................................34
Define Change Control ....................................................................................................................35
Assess Risk ............................................................................................................................................36
Manage Risks .........................................................................................................................................37
Planning Phase............................................................................................................................ 39
Introduction and Goals............................................................................................................................39
Complete a Detailed Assessment of the Existing Environment ..............................................................40
Application .......................................................................................................................................41
Database .........................................................................................................................................42
Application Infrastructure .................................................................................................................42
Develop the <strong>Solution</strong> Design and Architecture........................................................................................43
Build the Conceptual Design ...........................................................................................................44
Build the Logical Design ..................................................................................................................45

iv
Contents
Build the Physical Design ................................................................................................................48
Incorporate Design Considerations.........................................................................................................50
Hardware Design Considerations ....................................................................................................50
Validate the Technology .........................................................................................................................50
SQL Server Editions and Features ..................................................................................................51
Windows Server 2003......................................................................................................................52
Technical Proof of Concept .............................................................................................................52
Develop the Project Plans.......................................................................................................................53
Development Plan ...........................................................................................................................53
Stabilizing Phase Plans ...................................................................................................................55
Test Plan .........................................................................................................................................55
Pilot Plan .........................................................................................................................................59
Deployment Plan .............................................................................................................................60
Create the Project Schedules .................................................................................................................63
Estimating the Ef<strong>for</strong>t ........................................................................................................................63
Set Up the Development and Test Environments ...................................................................................65
Developing: Databases — Introduction .................................................................................... 67
Introduction and Goals............................................................................................................................67
<strong>Migrating</strong> the Database...........................................................................................................................68
Developing: Databases — <strong>Migrating</strong> the Database Architecture ........................................... 71
Introduction and Goals............................................................................................................................71
Build the SQL Server Instance................................................................................................................71
Pre-Installation Planning..................................................................................................................72
Installation .......................................................................................................................................72
Configure the Server...............................................................................................................................73
Configure Memory ...........................................................................................................................74
Set the CPU Affinity.........................................................................................................................76
Configure the Listener .....................................................................................................................77
Migrate the Storage Architecture ............................................................................................................77
Blocks ..............................................................................................................................................77
Extents and Segments.....................................................................................................................78
Tablespaces and Datafiles ..............................................................................................................79
Storage Definition <strong>for</strong> Tables and Indexes.......................................................................................81
Migrate System Storage Structures.................................................................................................82
Developing: Databases — <strong>Migrating</strong> Schemas ........................................................................ 83
Introduction and Goals............................................................................................................................83
Scripting Migrated Schema Objects........................................................................................................84
Script Everything..............................................................................................................................84
Provide Support Documentation......................................................................................................84
Protect the Scripts ...........................................................................................................................84
Migrate the Schema................................................................................................................................85
Map the Storage Architecture ..........................................................................................................85
Create Databases <strong>for</strong> the Schema...................................................................................................87
Create Filegroups <strong>for</strong> the Tablespaces............................................................................................90
Add Datafiles to Filegroups..............................................................................................................90
Add Transaction Logs......................................................................................................................91
Sample Schema Migration...............................................................................................................91
Migrate the Schema Objects...................................................................................................................98
Create the Schema Owner ..............................................................................................................98
Create the Schema Objects...........................................................................................................102
Comments .....................................................................................................................................111
Constraints ....................................................................................................................................111
Triggers .........................................................................................................................................119
Indexes ..........................................................................................................................................121
Views .............................................................................................................................................123
Stored Programs............................................................................................................................126
<strong>Solution</strong>s <strong>for</strong> Objects not Found in SQL Server .............................................................................129
Sample Schema Object Migration .................................................................................................132

Contents
v
Developing: Databases — <strong>Migrating</strong> the Database Users .................................................... 143
Introduction and Goals..........................................................................................................................143
Create User Accounts...........................................................................................................................143
Create Roles and Grant Privileges .......................................................................................................145
Sample User Migration .........................................................................................................................147
Developing: Databases — <strong>Migrating</strong> the Data........................................................................ 153
Introduction and Goals..........................................................................................................................153
Planning the Data Migration..................................................................................................................153
Options <strong>for</strong> Migration .....................................................................................................................153
Factors in Migration .......................................................................................................................155
Migration Strategy..........................................................................................................................156
Executing the Data Migration................................................................................................................157
Pre-Implementation Tasks.............................................................................................................158
Implementation Tasks....................................................................................................................160
Post-Implementation Tasks ...........................................................................................................165
Validating the Data Migration.........................................................................................................165
Developing: Databases — Unit Testing the Migration........................................................... 167
Introduction and Goals..........................................................................................................................167
Objectives of Testing ............................................................................................................................167
The Testing Process.............................................................................................................................168
Test Database Integrity..................................................................................................................169
Test Security..................................................................................................................................169
Validate Data .................................................................................................................................170
Validate the Migration ....................................................................................................................170
Developing: Applications — Introduction............................................................................... 173
Introduction and Goals..........................................................................................................................173
Application Migration Strategies ...........................................................................................................174
Interoperation ................................................................................................................................174
Port or Rewrite to .NET Framework...............................................................................................175
Port or Rewrite to Win32................................................................................................................175
Quick Port Using Windows Services <strong>for</strong> UNIX...............................................................................176
Scenarios and Cases............................................................................................................................176
Developing: Applications —<strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL............................................ 177
Introduction ...........................................................................................................................................177
<strong>Migrating</strong> Data Access..........................................................................................................................177
Sample Tables...............................................................................................................................179
Migration Process Overview ..........................................................................................................181
Step 1: Extraction of Data Access .................................................................................................182
Step 2: Transaction Management..................................................................................................202
Step 3: Fetch Strategy ...................................................................................................................203
Step 4: Subprograms Conversion..................................................................................................206
Step 5: Job Scheduling..................................................................................................................213
Step 6: Interface File Conversion...................................................................................................217
Step 7: Workflow Automation ........................................................................................................217
Step 8: Per<strong>for</strong>mance Tuning..........................................................................................................218
Developing: Applications — <strong>Migrating</strong> Perl............................................................................ 223
Introduction and Goals..........................................................................................................................223
Introduction to the Perl DBI Architecture...............................................................................................224
Scenario 1: Interoperation of Perl on UNIX with SQL Server................................................................225
Case 1: Interoperating an ODBC DBD Application........................................................................226
Case 2: Interoperating an <strong>Oracle</strong> DBD Application........................................................................228
Scenario 2: Porting the Perl Application to Windows ............................................................................232
Case 1: Porting a Perl Application using ODBC DBD....................................................................232
Case 2: Porting a Perl Application Using <strong>Oracle</strong> DBD...................................................................234
Developing: Applications — <strong>Migrating</strong> PHP ........................................................................... 237
Introduction and Goals..........................................................................................................................237
PHP Modules........................................................................................................................................238
Scenario 1: Interoperating PHP on UNIX with SQL Server...................................................................240
Case 1: Interoperating a PHP Application Using ORA Functions ..................................................240

vi
Contents
Case 2: Interoperating a PHP Application Using OCI8 Functions.........................................................244
Case 3: Interoperating a PHP Application Using ODBC Functions.......................................................246
Common Function Translation Issues ..................................................................................................249
Handling Transactions ...................................................................................................................249
<strong>Migrating</strong> Cursors ..........................................................................................................................250
Connection Pooling........................................................................................................................251
Stored Procedures.........................................................................................................................251
Scenario 2: Porting the Application to Win32........................................................................................252
Case 1: Porting a PHP Application using ORA Functions .............................................................252
Case 2: Porting a PHP Application Using OCI8 Functions ............................................................252
Case 3: Porting a PHP Application Using ODBC Functions ..........................................................253
Developing: Applications — <strong>Migrating</strong> Java .......................................................................... 255
Introduction and Goals..........................................................................................................................255
Scenario 1: Interoperating Java on UNIX with SQL Server...................................................................256
Case 1: Interoperating a Java Application Using the JDBC Driver ................................................256
Scenario 2 — Porting the Application to Win32 ....................................................................................259
Developing: Applications — <strong>Migrating</strong> Python ...................................................................... 261
Introduction and Goals..........................................................................................................................261
Scenario 1: Interoperating Python on UNIX with SQL Server ...............................................................263
Case 1: Interoperating Using the mxODBC Module ......................................................................263
Scenario 2: Port the Python Application to Win32 ................................................................................266
Case 1: Porting a Python Application using mxODBC...................................................................266
Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Pro*C ............................................................ 269
Introduction and Goals..........................................................................................................................269
Understanding the Technology .............................................................................................................270
Understanding Pro*C.....................................................................................................................270
Understanding .NET and ADO.NET ..............................................................................................270
Scenario 1: Rewriting Pro*C to the .NET Plat<strong>for</strong>m................................................................................271
Case 1: Rewrite the Application using Visual Basic.NET...............................................................271
Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms ........................................................... 279
Introduction and Goals..........................................................................................................................279
Migration Approach...............................................................................................................................279
Examining <strong>Oracle</strong> Forms ......................................................................................................................281
Object Library ................................................................................................................................284
PL/SQL Library ..............................................................................................................................284
Form Module .................................................................................................................................285
Menu Module.................................................................................................................................288
Windows and Canvases ................................................................................................................288
Understanding Visual Basic .NET.........................................................................................................290
Scenario 1: Rewriting to Visual Basic .NET ..........................................................................................291
Case 1: Using <strong>Oracle</strong> Designer .....................................................................................................291
Case 2: Manually Redesigning the Application..............................................................................291
Testing the Visual Basic .NET Application ............................................................................................295
Stabilizing Phase ....................................................................................................................... 297
Introduction and Goals..........................................................................................................................297
Testing the <strong>Solution</strong> ..............................................................................................................................298
Best Practices................................................................................................................................299
Preparing <strong>for</strong> Testing .....................................................................................................................299
Types of Testing ............................................................................................................................301
Bug Tracking and Reporting ..........................................................................................................305
User Acceptance Testing and Signoff............................................................................................308
Piloting the <strong>Solution</strong> ..............................................................................................................................308
Preparing <strong>for</strong> the Pilot ....................................................................................................................309
Conducting the Pilot.......................................................................................................................309
Evaluating the Pilot ........................................................................................................................310
Finalizing the Release...........................................................................................................................310
Deploying Phase........................................................................................................................ 313

Contents
vii
Introduction and Goals..........................................................................................................................313
Deploying the <strong>Solution</strong>..........................................................................................................................313
Deploying the Database Server.....................................................................................................314
Deploying the Server Side Applications.........................................................................................317
Deploying the Client Application ....................................................................................................318
Change Management ....................................................................................................................320
Stabilizing the Deployment ...................................................................................................................320
Deployment Checklist ....................................................................................................................320
Quiet Period...................................................................................................................................323
Transferring Ownership to Operations..................................................................................................324
Project Team Tasks.......................................................................................................................324
Operations Team Tasks ................................................................................................................325
Conducting Project Review and Closure...............................................................................................325
Operations.................................................................................................................................. 327
Introduction and Goals..........................................................................................................................327
Operational Framework ........................................................................................................................327
Windows Environment Operations........................................................................................................328
System Administration ...................................................................................................................328
Security Administration ..................................................................................................................328
Monitoring......................................................................................................................................329
Additional Links .............................................................................................................................329
SQL Server Environment Operations ...................................................................................................329
Administration................................................................................................................................329
Security..........................................................................................................................................330
Monitoring......................................................................................................................................330
Additional Links .............................................................................................................................330
APPENDICES ............................................................................................................................. 331
Appendix A: SQL Server <strong>for</strong> <strong>Oracle</strong> Professionals................................................................................331
Architecture ...................................................................................................................................331
Administration................................................................................................................................343
Appendix B: Getting the Best Out of SQL Server 2000 and Windows ..................................................348
Per<strong>for</strong>mance ..................................................................................................................................348
Scalability ......................................................................................................................................349
High Availability .............................................................................................................................349
Features and Tools........................................................................................................................351
Appendix C: Baselining.........................................................................................................................353
Creating Baselines.........................................................................................................................353
Capturing Statistics........................................................................................................................357
Comparing and Reporting Results.................................................................................................357
Appendix D: Installing Common Drivers and Applications ....................................................................358
Installing FreeTDS ................................................................................................................................358
Configuring FreeTDS.....................................................................................................................358
Testing the FreeTDS Configuration ...............................................................................................358
Installing unixODBC..............................................................................................................................359
Installing ActiveState Perl .....................................................................................................................360
Appendix E: Reference Resources.......................................................................................................362

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows
ix
Preface
Overview
The <strong>Oracle</strong> on UNIX to SQL Server on Windows Migration <strong>Guide</strong> provides practical
guidance on the processes and procedures to be followed while migrating from <strong>Oracle</strong>
databases (versions 8i and later) on UNIX plat<strong>for</strong>ms to
Microsoft® Windows® Server 2003 and Microsoft SQL Server 2000. This guide also
presents strategies and procedural guidance to convert existing applications <strong>for</strong> use
within the SQL Server 2000 and Microsoft Windows Server environment. This guide
provides additional in<strong>for</strong>mation and references to online resources about migrating other
components of your application ecosystem, including the server and network
infrastructure, development and test environment, and user accounts.
The guide is based on the experience of consultants working in the field and
organizations that have successfully migrated from an <strong>Oracle</strong> on UNIX to a SQL Server
on Windows environment, and it comprises the best lab-tested, customer-proven, crossproduct
technical guidance from Microsoft on planning, building, deploying, and operating
the migration solution. All processes and procedures contained in this guide have been
validated through the Microsoft Technology Adoption Program (TAP), which is a beta
program that consists of customers and partners who have evaluated and validated the
various technologies and practices described in this guide.
An important assumption made in this guide is that your organization has decided to
migrate all or parts of the <strong>Oracle</strong> database and application environment from UNIX to
SQL Server 2000 in a Windows environment. Because of this assumption, this guide
does not present a competitive analysis of <strong>Oracle</strong> versus SQL Server 2000, or UNIX
versus Windows. This guide does help you decide which migration strategy is best <strong>for</strong>
your organization given your specific business and technical requirements, and it
explains how to plan <strong>for</strong> and execute that strategy.
This process-driven approach to migration is applied to the <strong>Oracle</strong> database, the UNIX
applications that rely on the database, and the application programming interfaces (APIs)
that connect the applications to the database. The strategies and methods <strong>for</strong> migrating
these components vary according to the size and complexity of the database, application,
and infrastructure of the <strong>Oracle</strong> source system. The strategies and methods also vary
according to any new business or technical requirements your organization develops as a
result of migrating to the Microsoft Windows plat<strong>for</strong>m.
Because there is so much variance in the possible approaches to migration, this guide
provides numerous examples and best practices to help you better understand both the
concepts and detailed processes involved in migration. A series of job aids (templates,
spreadsheets, and questionnaires) are included as part of this solution guide to help you
better analyze, plan, structure, and per<strong>for</strong>m the migration.
The in<strong>for</strong>mation under the following two headings outlines the technical scope of the
migration strategies and methods provided in this guide.

x
Preface
Technical Subjects Covered in This <strong>Guide</strong>
The following technical topics and subject areas are included in this guide:
●
●
●
●
Migration of a typical <strong>Oracle</strong> database, including objects (such as tables, indexes,
views, triggers, and stored procedures) and the contents of the objects to SQL
Server.
Methods and procedures that focus on taking advantage of existing applications on
UNIX plat<strong>for</strong>ms by communicating with SQL Server on Windows.
Migration of applications and APIs to work under Microsoft Win32®, Microsoft
Windows Services <strong>for</strong> UNIX, and Microsoft .NET.
Application and API interoperability with SQL Server, including:
●
●
●
●
●
●
●
Java 2 Enterprise Edition (J2EE) and Java Database Connectivity (JDBC)
Open Database Connectivity (ODBC)
Perl, including the DBI and DBD modules
PHP
Python
Pro*C
<strong>Oracle</strong> Forms
●
Microsoft offers the SQL Server Migration Assistant toolset <strong>for</strong> the migration of
<strong>Oracle</strong> databases to SQL Server, including:
●
●
●
●
Migration Analyzer—analyzes the source <strong>Oracle</strong> databases and produces vital
statistics on the size and complexity of the migration.
Schema and Data Migrator—migrates the <strong>Oracle</strong> schemas and moves the
data into the new SQL Server objects.
SQL Converter—converts code found in <strong>Oracle</strong> objects to their T-SQL
equivalents.
Migration Tester—automatically tests the converted code.
These tools can be downloaded from http://www.microsoft.com/sql/migration/. The tools
are in beta as of the date of publication <strong>for</strong> this solution. Version 1 of the tools is slated <strong>for</strong>
release in June 2005 and will be available <strong>for</strong> download at the same location.
Technical Subjects That Are Not Covered in This <strong>Guide</strong>
The following technical topics and subject areas are not included in this guide:
●
<strong>Oracle</strong> versions earlier than 8i and <strong>Oracle</strong> 10g
● SQL Server versions earlier than SQL Server 2000
●
●
●
●
●
●
Design of hardware architecture
Modeling and design of databases
Procedures <strong>for</strong> database administration functions, such as capacity planning,
backup and recovery, per<strong>for</strong>mance tuning, and monitoring
Aspects of the database that could be rendered inapplicable in the new
environment, such as archived data and backups
Features available in <strong>Oracle</strong> that do not have corresponding features in SQL
Server, such as spatial data, XML DB, flashback query, SQLJ, and XSQL
Installation of application clients, or client connectivity to the application server or
database

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows
xi
● Migration of the operating system to Microsoft Windows Server 2003
●
●
Support <strong>for</strong> Open Management Group (OMG), an open-source, java-based
standard <strong>for</strong> metadata
Data extraction from enterprise resource planning (ERP) systems
While these technical subjects are not explicitly discussed in this guide, in<strong>for</strong>mation about
many of them is available from Microsoft. Where appropriate throughout this guide, links
to more in<strong>for</strong>mation are provided.
Intended Audiences
Generally, the intended audience <strong>for</strong> this solution guide includes medium and large-sized
IT organizations that want to migrate their database and applications from <strong>Oracle</strong> on
UNIX to SQL Server 2000 on Windows. More specifically, this guide is written <strong>for</strong> all of
the members of the migration team, from business decision makers to development to
operations. As a result, not all chapters in this guide are relevant to all team members,
and the knowledge prerequisites <strong>for</strong> using this guide are expressed as an aggregate of
the knowledge required of the team. The rest of this section provides brief descriptions of
the typical audiences <strong>for</strong> this guide, followed by a brief statement of the aggregate
knowledge prerequisites <strong>for</strong> developing the solution described in this guide. The intended
audience <strong>for</strong> individual chapters is identified in the "How to Use This <strong>Solution</strong> <strong>Guide</strong>"
section later in this Preface.
The following list organizes common job titles and organizational responsibilities under
the Microsoft <strong>Solution</strong>s Framework (MSF) role most commonly associated with that title
or responsibility. The relationship between this solution guide and MSF is discussed in
more detail in the "How to Use This <strong>Solution</strong> <strong>Guide</strong>" section. In some organizations, a
role may be filled by a single team member or many.
● Stakeholders and High Level Decision Makers. These team members can be
subdivided into two groups:
● Business Decision Makers (BDMs). This group often includes the CIO and IT
director of an organization. These personnel decide the business priorities <strong>for</strong>
purchasing and implementing solutions within the organizations. IT BDMs
require a high-level understanding of the technical solutions being explored so
that they can assess the value that the solution can provide to the
organization.
● Technical Decision Makers (TDMs). The focus of TDMs is to determine the
technology used to solve business problems. IT TDMs must understand the
business drivers the organizations face along with the functionality delivered by
multiple technology scenarios.
●
●
Product Management Role. This role usually includes team members with the
following job title and responsibilities:
● Product Manager. This team member acts as a link between the team
members of the project and the customers of the solution by handling highlevel
communication and managing the customer's expectations. The Product
Manager ensures that the team addresses the customer's needs, concerns,
questions, and feedback throughout the project. Product managers must
understand the business needs of the solution, including operations, business
processes, and policies.
User Experience Role. This role usually includes team members with the
following job titles and responsibilities:

xii
Preface
●
Usability Expert or Technical Writer/Editor. Ensures that the new solution is
easy <strong>for</strong> customers to use. The Usability Experts ensure that documentation
and training is provided to end users to use the new solution effectively.
●
●
●
●
Program Management Role. This role usually includes team members with the
following job title and responsibilities:
●
Project Managers. These personnel are responsible <strong>for</strong> managing the
resources and schedule <strong>for</strong> the migration project from start to end.
Development Role. This role usually includes team members with the following
job titles and responsibilities:
●
●
●
●
●
●
●
●
IT Architect. The primary role of the IT architect is to carry out decisions made
by the TDMs. Team members with this responsibility are most involved during
the Planning, Developing, and Stabilizing Phases of the migration project.
<strong>Oracle</strong> Database Administrators. These personnel are knowledgeable about
the physical characteristics, logical characteristics, per<strong>for</strong>mance, and service
requirements of the source database. These personnel also have knowledge
of any scripts and tools that are used in database administration.
SQL Server Database Administrators. These personnel are expert in
architecting and implementing SQL Server databases. These team members
will design the target SQL Server database environment and per<strong>for</strong>m key tasks
during the actual migration.
UNIX System Administrators. These personnel have complete knowledge of
the UNIX servers and the operating system installations, such as versions,
packages, configuration, and security.
Windows System Administrators. These personnel have complete
knowledge of the Windows operating system and the Microsoft application
product line. These team members should have some experience in defining
and implementing server technologies in Windows.
UNIX Application Developers. These personnel have knowledge of the
applications that are running in the current UNIX environment and their
implementation details.
Windows Application Developers. These personnel have per<strong>for</strong>med
development in the Windows environment <strong>for</strong> the technologies involved in the
solution.
Security Specialists. These personnel have a wide base of knowledge about
security issues, including how security relates to networks, servers, databases,
and applications.
Test Role. This role usually includes team members with the following job titles
and responsibilities:
● Test Engineering Managers. These personnel have knowledge about testing
application and database solutions and also have managerial experience.
● UNIX Database and Applications Testers. These personnel have knowledge
about all databases and applications that are running in the current UNIX
environment and provide input when test plans are created <strong>for</strong> the migrated
environment.
● Windows Database and Applications Testers. These team members have
knowledge of databases and applications in both UNIX and Windows. These
personnel are experienced at creating and executing test plans.
Release Management Role. This role usually includes team members with the
following job titles and responsibilities:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows
xiii
●
●
Deployment Manager. These personnel have knowledge of managing the
deployment of the new database and applications in the production
environment.
Technology Specialist. These personnel have knowledge of the technology
and processes in a data center operation. They have intimate knowledge of the
solution being developed and will aid in transitioning them into the production
environment.
Knowledge Prerequisites
It is assumed that the technically-oriented audience <strong>for</strong> this guide has, in aggregate, the
following specific technology competencies and proficiencies:
● Expert level of UNIX development and administration
● Expert level of Windows development and administration
● Expert level of SQL Server and <strong>Oracle</strong> administration
● Knowledgeable staff to maintain the new environment and the technologies
involved
● Knowledgeable staff that understand any interaction between the UNIX and
Windows environment when interoperability is created and maintained
How to Use This <strong>Solution</strong> <strong>Guide</strong>
The organization of this guide is based on the industry-proven need to manage IT
projects according to a disciplined process that improves the likelihood of the project's
success. It is designed to be used with a companion guide, the UNIX Migration Project
<strong>Guide</strong> (UMPG). While this guide contains the technical and solution-specific in<strong>for</strong>mation
needed <strong>for</strong> the project, the UMPG provides the disciplined process steps <strong>for</strong> using this
in<strong>for</strong>mation in the context of a migration project and a team organization model ("people
and process" guidance).
To facilitate their side-by-side use, both guides use project phases as an organizational
device. Specifically, they follow the structure of the Microsoft <strong>Solution</strong>s Framework
(MSF), which defines five distinct phases <strong>for</strong> IT projects: Envisioning, Planning,
Developing (or <strong>Migrating</strong>), Stabilizing, and Deploying. Each guide presents the
in<strong>for</strong>mation (process or technical) needed <strong>for</strong> a phase within chapters named <strong>for</strong> that
phase. For example, in the solution guide, business and technical in<strong>for</strong>mation needed <strong>for</strong>
the initial decision-making is in the Envisioning chapter and detailed procedures and
scripts are in the <strong>Migrating</strong> chapters.
The UMPG is essentially "MSF applied to UNIX migration projects." It begins with an
overview of MSF and then describes the processes that belong to each phase and the
team roles responsible <strong>for</strong> them — it is not, however, meant to serve as a comprehensive
introduction to MSF. In-depth in<strong>for</strong>mation about MSF is available to interested readers on
the Microsoft <strong>Solution</strong>s Frameworks Web site at http://www.microsoft.com/msf.
The reason <strong>for</strong> separating the process guidance from technical and project-specific
guidance is to keep this guide as lean as possible. It is recognized that some readers
need to focus narrowly on project tasks, while persons with project management and
team lead responsibilities need to digest the UMPG guidance and apply it to the project.
Because organizational personnel and project team members tend to have different
levels of involvement during different phases, the division of content according to project
phase also supports the ability to focus on the material that is most relevant to a
particular responsibility.

xiv
Preface
It is important <strong>for</strong> you to note the content scope of this guidance. The application
migration and interoperation-related in<strong>for</strong>mation in this solution only discusses issues
pertaining to the database connectivity logic. It does not discuss general application
porting issues between UNIX and Windows such as mapping UNIX system calls to
Windows APIs and migrating the graphical user interface (GUI). For detailed in<strong>for</strong>mation
about UNIX to Windows application migration, refer to the UNIX Application Migration
<strong>Guide</strong> (UAMG) available at http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnucmg/html/ucmglp.asp.
Note Although the two guides are designed to be used together, it is not necessary to
follow the MSF processes and team guidance described in the UMPG if the
organization has an alternative project methodology in place. In that case, the UMPG
would be used merely to map the MSF phases and team structure to the elements of
the organization's methodology. Readers who will use this guide to implement a project
should read at least the overview of MSF in the UMPG to familiarize themselves with
the MSF Process Model, the MSF Team Model, and MSF terminology.
Figure 0.1 represents the chapters of interest to readers with different areas of
responsibility.
Figure 0.1
Chapters of interest by team role

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows
xv
Organization by Chapter
The following chapter list provides an overview of the content and structure of this guide.
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Preface.
Chapter 1: Introduction to the Microsoft <strong>Solution</strong>s Framework. This chapter
provides a brief introduction to the Microsoft <strong>Solution</strong>s Framework (MSF) and how
it is applied to migration projects.
Chapter 2: Envisioning Phase. This chapter provides guidance to carry out the
various activities of the Envisioning Phase in an <strong>Oracle</strong> on UNIX to SQL Server on
Windows migration project. These activities include understanding your business
and technical goals, assessing your current situation at a high level, building a
high-level solution concept, setting up the project team, and assessing project
risks.
Chapter 3: Planning Phase. This chapter provides guidance to carry out the
various activities of the Planning Phase in an <strong>Oracle</strong> on UNIX to SQL Server on
Windows migration project. These activities include creating a detailed assessment
of the current environment, developing the solution design and architecture, and
producing detailed project plans and project schedule.
Chapter 4: Developing: Databases — Introduction. This chapter introduces the
different tasks in migrating the <strong>Oracle</strong> database to SQL Server 2000.
Chapter 5: Developing: Databases — <strong>Migrating</strong> the Database Architecture.
This chapter describes the steps <strong>for</strong> creating an instance of SQL Server which is
equivalent in architecture to the original <strong>Oracle</strong> database.
Chapter 6: Developing: Databases — <strong>Migrating</strong> Schemas. This chapter shows
how to migrate a schema owner and its objects to a SQL Server database.
Chapter 7: Developing: Databases — <strong>Migrating</strong> the Database Users. This
chapter contains detailed steps <strong>for</strong> creating users in the SQL Server databases
and granting them the same kind of privileges they had in the original <strong>Oracle</strong>
database.
Chapter 8: Developing: Databases — <strong>Migrating</strong> the Data. This chapter explores
the different options <strong>for</strong> migrating the application data from <strong>Oracle</strong> to SQL Server.
It provides details in the usage of each of the options.
Chapter 9: Developing: Databases — Unit Testing the Migration. This chapter
contains the processes <strong>for</strong> testing the migrated database, its objects, and data.
Chapter 10: Developing: Applications — Introduction. This chapter introduces
the procedures to migrate the application and the API (the connectivity tier
between the database and the application) from the existing solution to the
proposed solution.
Chapter 11: Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL.
This chapter provides specific steps and procedures <strong>for</strong> converting SQL
statements and PL/SQL code <strong>for</strong> use with SQL Server.
Chapter 12: Developing: Applications — <strong>Migrating</strong> Perl. This chapter provides
specific steps and procedures <strong>for</strong> migrating Perl applications to the SQL Server on
Windows environment.
Chapter 13: Developing: Applications — <strong>Migrating</strong> PHP. This chapter provides
specific steps and procedures <strong>for</strong> migrating PHP applications to the SQL Server on
Windows environment.
Chapter 14: Developing: Applications — <strong>Migrating</strong> Java. This chapter provides
specific steps and procedures <strong>for</strong> migrating Java applications to the SQL Server on
Windows environment.

xvi
Preface
●
●
●
●
●
●
●
●
●
●
Chapter 15: Developing: Applications — <strong>Migrating</strong> Python. This chapter
provides specific steps and procedures <strong>for</strong> migrating Python applications to the
SQL Server on Windows environment.
Chapter 16: Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Pro*C. This chapter
provides specific steps and procedures <strong>for</strong> migrating Pro*C applications to the SQL
Server on Windows environment.
Chapter 17: Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms. This chapter
discusses the options available <strong>for</strong> migrating an <strong>Oracle</strong> Forms-based application.
Chapter 18: Stabilizing Phase. In this chapter, the solution is tested in an
environment similar to the production environment. This chapter describes the
various testing options and processes that can be implemented to ensure the
quality of the solution.
Chapter 19: Deploying Phase. This chapter describes the procedure <strong>for</strong> moving
the solution into the production environment and transferring ownership of the
solution to operations. The chapter also identifies the tests that need to be
per<strong>for</strong>med on the solution during deployment.
Chapter 20: Operations. This chapter provides references to existing operational
guides to administer a Windows-based server infrastructure and SQL Server 200
based databases.
Appendix A: SQL Server <strong>for</strong> <strong>Oracle</strong> Professionals. This appendix provides
in<strong>for</strong>mation to help <strong>Oracle</strong> DBAs who do not have SQL Server experience learn
about its administration.
Appendix B: Getting the Best Out of SQL Server 2000 and Windows. This
appendix provides reference to material to optimize and take advantage of SQL
Server and Windows.
Appendix C: Baselining. This appendix provides detailed in<strong>for</strong>mation about
collecting statistics in SQL Server.
Appendix D: Installing Common Applications and Drivers. This appendix
provides installation instructions <strong>for</strong> applications and drivers that may be used
while migrating the application.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows
xvii
Document Conventions
This guide uses the style conventions shown in Table 0.1.
Table 0.1: Document Conventions
Text Element
Meaning
Bold text
Bold text is used in the context of
paragraphs <strong>for</strong> commands; literal
arguments to commands (including paths
when they <strong>for</strong>m part of the command);
switches; and programming elements,
such as methods, functions, data types,
and data structures. User interface
elements are also identified with bold font.
Italic text
Italic text is used in the context of
paragraphs <strong>for</strong> variables to be replaced by
the user. It is also used to emphasize
important in<strong>for</strong>mation.
Monospace font
Used <strong>for</strong> excerpts from configuration files,
code examples, and terminal sessions.
Monospace bold font
Used to represent commands or other text
that the user types.
Monospace italic font
Used to represent variables the reader
supplies in command line examples and
terminal sessions.
UPPERCASE
Transact-SQL keywords and SQL
elements.
%SystemRoot% The folder in which Windows Server 2003
is installed.
Job Aids
The job aids included with this guide can be used to support the various tasks per<strong>for</strong>med
during the different phases of the migration. The aids are in the <strong>for</strong>m of questionnaires,
tools, and templates used <strong>for</strong> designing, planning, and managing the migration project.
The job aids are either in Microsoft Excel spreadsheet or Microsoft Word document
<strong>for</strong>mat. They are available in the Tools and Templates folder in the zip file download of
this guidance at http://go.microsoft.com/fwlink/?LinkId=45289.
The purpose of providing job aids is to help you speed up the development of your
project documents. New or additional guidance is not provided in the job aids. Instead,
the job aids are generic templates that you should customize to fit your requirements.

xviii
Preface
Table 1.2: Job Aids Descriptions
Job Aid
Vision/Scope
Project Structure
Migration Risk Exposure Rating Form
Assessing the Current Environment
Template
Development Plan
Test Plan
Pilot Plan
Deployment Plan
Description
Use this template to describe the goals of
the project and the approaches that the
team will use to achieve those goals.
Use this template to define how the project
is structured and managed and how the
solution will be created. This template will
help you control and coordinate the entire
project.
This spreadsheet will help you identify the
possible migration risks and their
consequences. In addition, this document
also helps you to prioritize the risks and
prepare a mitigation plan <strong>for</strong> each risk.
This template provides separate
spreadsheets to assist in assessing the
application, database, and server
environments.
This template helps you to describe the
solution development process used <strong>for</strong> the
project. This plan provides the technical
details of what will be built, and it provides
consistent guidelines and processes to the
teams creating the solution.
This template helps you to describe the
strategy and approach used to plan,
organize, and manage the project’s testing
activities. It identifies testing objectives,
methodologies and tools, expected results,
responsibilities, and resource
requirements.
This template contains in<strong>for</strong>mation to help
prepare and execute a successful pilot. It
includes pilot scope, user interactions and
pilot evaluation
This template helps you to describe the
actions necessary <strong>for</strong> a smooth
deployment and transition to ongoing
operations. It covers the processes of
preparing, installing, testing, training, and
transferring the solution to operations.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows
xix
Contributors
The following organizations and individuals contributed to this project.
Program Manager
Dhilip Gopalakrishnan (Microsoft)
Author
Scalability Experts
Editors
Thomas Olsen (Volt Technical Services)
Gaile Simmons (Microsoft)
Architects
Peter Skjøtt Larsen (Microsoft)
Jason Zions (Microsoft)
Test
Sandor Kiss (Microsoft)
Infosys Technologies
Feedback
Please direct questions and comments about this guide to cisfdbk@microsoft.com.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 1
1
Introduction to the Microsoft
<strong>Solution</strong>s Framework
Introduction and Goals
For large-scale projects, such as database migrations, it is vital to have a cohesive and
structured project framework in place. This foundation ensures that projects are carefully
planned, roles and tasks are clearly identified and defined, and that the thousands of
crucial details are addressed <strong>for</strong> a successful migration.
In this chapter, you will learn about Microsoft <strong>Solution</strong>s Framework (MSF), which has
been used successfully on numerous IT projects. This adaptable and robust project
framework provides a comprehensive structure that assists in guiding the project from the
initial planning stages until after the project has been completed. If you are familiar with
MSF, skip this chapter and continue with Chapter 2, "Envisioning Phase."
Overview of MSF
Every successful project follows a methodology to achieve its objectives. The
methodology employed in this migration guide is the Microsoft <strong>Solution</strong>s Framework. A
vast amount of in<strong>for</strong>mation about MSF is available from Microsoft, and the UNIX
Migration Project <strong>Guide</strong> provides a thorough explanation of MSF <strong>for</strong> specific audiences of
this migration guide, such as the team members that fulfill the Program Management
role. Yet not every team member on your migration project needs in-depth knowledge of
MSF to successfully per<strong>for</strong>m their team function. Because this is the case, the following
brief overview is intended to provide all team members with a high-level overview of MSF
that will familiarize them with basic concepts and terminology and help them to better
understand the specific sections of this migration guide that they will need to read,
understand, and execute.
MSF was created to maximize the success of IT projects throughout the entire IT life
cycle. This in<strong>for</strong>mation is derived from the experience gained within Microsoft on largescale
software development and service operation projects, the experience of Microsoft’s
consultants, and common best practices from the worldwide IT industry.
As opposed to a prescriptive methodology, MSF provides a flexible and scalable
framework to meet the needs of any sized organization or project team. MSF guidance
consists of principles, models, and disciplines <strong>for</strong> managing the people, process, and

2
Introduction to the Microsoft <strong>Solution</strong>s Framework
technology elements that most projects encounter. A detailed introduction to the MSF
models and disciplines is available at http://www.microsoft.com/msf.
MSF Foundational Principles
At the core of MSF are eight foundational principles. For detailed in<strong>for</strong>mation on the eight
foundational principles, download the MSF Version 3 Overview from
http://msdn.microsoft.com/vstudio/enterprise/msf/.
The eight foundational principles of MSF are:
● Foster open communications. The MSF Process Model enables an open and
free flow of in<strong>for</strong>mation among the team members and key stakeholders to prevent
misunderstandings and reduce the probability that work will have to be redone.
Documenting the progress of the project and making it available to the team
members, stakeholders, and customers can best achieve this.
● Work toward a shared vision. The MSF Process Model provides a phase (the
Envisioning Phase) and a separate milestone (Vision/Scope Approved) <strong>for</strong> creating
a shared vision. A vision includes detailed understanding of the goals and
objectives that the solution needs to achieve. A shared vision highlights the
assumptions that the team members and customers have <strong>for</strong> the solution.
● Empower team members. Empowering the team members implies that the
members accept responsibility and ownership of work assigned to them. Team
empowerment can be achieved by preparing schedules where the team members
commit to complete their work on a fixed date. This makes the team members feel
accountable and also provides a method <strong>for</strong> identifying any potential delays early
in the project.
● Establish clear accountability and shared responsibility. The MSF Team
Model is based on the principle that each role is accountable <strong>for</strong> the quality of the
solution. All the team members share the overall responsibility of the project
because the project can fail due to a mistake made by a single member.
● Focus on delivering business value. The solution must deliver value to the
organization in the <strong>for</strong>m of business value. This business value is achieved only
after the solution is completely deployed into the production environment.
● Stay agile, expect change. MSF assumes that the solution will encounter
continuous changes be<strong>for</strong>e being deployed to the production environment. The
team should be aware and prepared to manage such changes.
● Invest in quality. In MSF, each team member is responsible <strong>for</strong> the quality of the
solution. To confirm the quality throughout the project's duration, a test team is
<strong>for</strong>med. This ensures that the solution meets the quality level of the stakeholders.
● Learn from all experiences. MSF states that the experiences derived from one
project should be used and shared with teams in other projects. These
experiences can also help to identify the best practices that should be followed in
your organization.
The MSF Team Model — Overview
The MSF Team Model was developed over a period of several years to compensate <strong>for</strong>
some of the disadvantages imposed by the top-down, hierarchical structure of traditional
project teams. Teams organized under the MSF Team Model are small and
multidisciplinary teams of peers, although the model is scalable <strong>for</strong> both small and large
projects. Team members share responsibilities and balance each other’s competencies
to keenly focus on the project at hand. They are expected to share a common project

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 3
vision, a focus on deploying the project, high standards <strong>for</strong> quality and communication,
and a willingness to learn. Figure 1.1 shows the role clusters of the MSF Team Model.
Figure 1.1
The MSF Team Model
The MSF Team Model emphasizes the importance of aligning role clusters (commonly
referred to simply as "roles") to business needs. It does this by organizing each role
around a quality goal that the project must meet to be successful. Each role aggregates a
"cluster" of related functional areas and responsibilities. The functional areas each
require a different discipline and focus, but are related in that they contribute toward
meeting the quality goal.
The result is a well-balanced team whose skills and perspective represent all of the
fundamental project goals. For team members, possessing a clearly defined role and
owning a clearly defined goal is motivational. It increases the understanding of
responsibilities, and ultimately leads to a better solution. Because each goal is critical to
the success of a project, the roles that represent these goals are considered to be equally
important. Persons filling the roles are given equal say in critical decisions and are
thought of as peers. MSF teams are known as "teams of peers." Table 1.1 associates
each role cluster with a quality goal.
Table 1.1: Role Clusters and Quality Goals
Role Cluster
Program Management
Development
Test
User Experience
Release Management
Product Management
Goal
Deliver the solution within project constraints
Build to specification
Approve <strong>for</strong> release only after all product quality
issues are identified and addressed
Enhance user effectiveness
Achieve smooth deployment and ongoing operations
Satisfy customers
The MSF Process Model — Overview
The MSF Process Model describes a high-level sequence of activities <strong>for</strong> building and
deploying IT solutions. Rather than prescribing a specific series of procedures, it is
flexible enough to accommodate a broad range of IT projects. MSF combines two
industry standard models: the waterfall model, which emphasizes the achievement of
milestones, and the spiral model, which focuses on the continual need to refine the

4
Introduction to the Microsoft <strong>Solution</strong>s Framework
requirements and estimates <strong>for</strong> a project. An innovative aspect of the MSF process
model is that it covers the life cycle of a solution from project inception to live deployment.
This helps project teams focus on customer business value, because no value is realized
until the solution is deployed and in operation.
Figure 1.2
The MSF Process Model showing phases and major milestones
MSF is a milestone-driven process. Milestones fall at the end of each phase and contain
criteria <strong>for</strong> completing the phase. Important deliverables must have been completed and
critical questions, such as: Does the team agree on the project scope? Have we planned
enough to proceed? Have we built what we said we would build? Is the solution working
properly <strong>for</strong> the customer? must be satisfactorily answered. The project team and key
stakeholders review the deliverables and reach agreement that the project can proceed
to the next phase in a milestone meeting.
MSF is also an iterative process. The process model is designed to accommodate
changing project requirements by iterating through short development cycles and
incremental versions of the solution.
The iterative aspect of the MSF process applies well to migration projects, which are
frequently driven by an iterative process. In some cases, the migration task itself is
approached iteratively. The first cycle migrates limited, basic functionality to the new
plat<strong>for</strong>m; and subsequent cycles add additional capabilities to the new environment until
it is equivalent to the original, unmigrated technology. In some other migration projects,
the first cycle completely migrates some technology to a new environment, while
subsequent cycles extend the technology beyond its original capabilities. Iterative
approaches to migration projects provide a means to control project risk and create
greater flexibility to accommodate changing requirements.
The MSF Process Model originated with the process used by Microsoft to develop
applications. This model may be applied to traditional application development
environments, but is equally appropriate <strong>for</strong> the development and deployment of
enterprise infrastructure solutions, Web development, e-commerce, and distributed
applications.
Although the Program Management Role orchestrates the overall process within each
phase, the successful achievement of each milestone requires special leadership and
accountability from each of the other team roles. As a project moves sequentially through
each phase, the level of ef<strong>for</strong>t <strong>for</strong> each of the roles varies. The use of milestones helps to
manage this ebb and flow of involvement in the project.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 5
Table 1.2: Major Milestones and Primary Drivers
Milestone
Vision/Scope Approved
Project Plans Approved
Scope Complete
Release Readiness Approved
Deployment Complete
Primary Driver(s)
Product Management
Program Management
Development and User Experience
Test and Release Management
Release Management
Each phase also has interim milestones that lead to the achievement of the final phase
milestone. Recommended interim milestones are shown in Figure 1.3, but they may need
to be modified <strong>for</strong> a particular project.
Figure 1.3
MSF Process Model with interim milestones
The MSF Disciplines — Overview
MSF makes use of three classic disciplines, Risk Management, Readiness Management,
and Project Management, which it has adapted to fit the framework. They are reflected in
both the Process Model and the role responsibilities defined in the Team Model. This
section describes each discipline briefly. For a thorough discussion of each discipline and
its application within MSF, see the respective white papers available at
http://msdn.microsoft.com/vstudio/enterprise/msf/.
Risk Management
The MSF Risk Management Discipline advocates proactive risk management, continuous
risk assessment, and integration into decision-making throughout the project and
operational life cycle. Risks are continuously assessed, monitored, and actively managed
until they are either resolved or the possible negative event happens and the risks have

6
Introduction to the Microsoft <strong>Solution</strong>s Framework
become real problems to be handled as such. The MSF risk management process
defines six logical steps the team uses to manage current risks, plan and execute risk
management strategies, and capture knowledge <strong>for</strong> the enterprise. Figure 1.4 illustrates
the relationship between the six steps.
Figure 1.4
The MSF risk management process
The following list provides detailed in<strong>for</strong>mation about each of the six risk management
steps.
● Identify. The process of risk identification calls <strong>for</strong> all team members to participate
in surfacing risks to make the team aware of potential problems. As the input to the
risk management process, risk identification should be undertaken as early as
possible and repeated frequently throughout the project life cycle.
● Analyze and Prioritize. Risk analysis trans<strong>for</strong>ms the estimates or data about
specific project risks that surface during risk identification into a <strong>for</strong>m that the team
can use to make decisions regarding prioritization. Risk prioritization enables the
team to commit project resources to manage the most important risks.
● Plan and Schedule. Risk planning takes the in<strong>for</strong>mation obtained from risk
analysis and prioritization and uses it to <strong>for</strong>mulate strategies, plans, and actions.
Risk scheduling ensures that these plans are approved and then incorporated into
the project management process and infrastructure to ensure that risk
management is carried out as part of the day-to-day activities of the team. Risk
scheduling explicitly connects risk planning with project planning.
● Track and Report. Risk tracking monitors the status of specific risks and the
progress in their respective action plans. Risk tracking also includes monitoring the
probability, impact, exposure, and other measures of risk <strong>for</strong> changes that could
alter priority, risk plans, and project features, resources, or schedule. Risk tracking
enables visibility of the risk management process within the project from the
perspective of risk levels as opposed to the task completion perspective of the
standard operational project management process. Risk reporting ensures that the
team, sponsor, and other stakeholders are aware of the status of project risks and
the plans to manage them.
● Control. Risk control is the process of executing risk action plans and their
associated status reporting. Risk control also includes initiation of project change
control requests when changes in risk status or risk plans could result in changes
in project features, resources, or schedule.
● Learn. Risk learning <strong>for</strong>malizes the lessons learned from the project, collects the
relevant project artifacts and tools, and captures that knowledge in reusable <strong>for</strong>m.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 7
Readiness Management
The MSF Readiness Management Discipline defines readiness as a measurement of the
current state versus the desired state of knowledge, skills, and abilities (KSAs) of
individuals in an organization. This measurement is the real or perceived capabilities of
the individuals at any point during the ongoing process of planning, building, and
managing solutions.
Each role on a project team includes key functional areas that the individuals undertaking
those roles must be capable of fulfilling. Individual readiness is the measurement of the
state of an individual with regard to the KSAs needed to meet the responsibilities required
of their particular role. The MSF Readiness Management Discipline includes a process to
help teams prepare <strong>for</strong> the KSAs needed to build and manage projects and solutions.
The most basic approach to the readiness process is simply to assess skills and make
appropriate changes through training. On projects that are small or have short
timeframes, this streamlined approach is quite effective. For longer term or serial
projects, organizations can benefit from per<strong>for</strong>ming the steps of defining the skills
needed, evaluating the results of change produced by training, and keeping track of
KSAs. This allows <strong>for</strong> the full realization of readiness management, and is typically where
organizations reap the rewards of investments in readiness activities.
The readiness management process is composed of four steps: Define, Assess, Change,
and Evaluate. Each process step includes a series of tasks to help reach the next step.
Figure 1.5
The readiness management process
Define
This step focuses on defining requirements. It identifies and describes the scenarios,
competencies, and proficiency levels needed to successfully plan, build, and manage the
solutions. It also determines which roles in the team should be proficient in the defined
competencies. Depending on the role, the individual filling it may need to be proficient in
one or many of the defined competencies.
Scenarios describe the different types of activities that occur in a typical enterprise.
Scenarios generally fall into one of four categories defined in terms of the business value
they offer the organization — High Potential, Strategic, Key Operational, and Support.
Different scenarios call <strong>for</strong> different types of skills and knowledge and distinct approaches
to obtaining the appropriate resources and skills <strong>for</strong> that project type.

8
Introduction to the Microsoft <strong>Solution</strong>s Framework
●
●
●
●
High Potential. These focus on the situations an IT department encounters when
planning and designing to deploy, upgrade, or implement a new product,
technology, or service in its organization. These are typically research type
situations in which the technology is brand new or in beta <strong>for</strong>m. The organization
needs to have a high degree of agility and the capability to investigate and
evaluate new technologies. For these scenarios, it needs to be prepared to obtain
(<strong>for</strong> a short period) the best expertise available.
Strategic. Scenarios in this category focus on the situations an IT department is
likely to encounter when exploiting new technologies, products, or services. These
are typically market-leading solutions that could lead to business trans<strong>for</strong>mation
defining the to-be long-term architecture. Here the organization needs in-house, indepth
expertise at the solution architect level and the capability of bridging skills
across technology to the business.
Key Operational. Scenarios in this category focus on the situations an IT
department is likely to encounter once it has deployed, upgraded, or implemented
a new product, technology, or service that has to coexist, or continue to seamlessly
interact with legacy software and systems. These are typically today's businesscritical
systems, aligned with the as-is technology architecture. Quality of technical
knowledge and process are critical, as is ready availability of the skills applicable to
the relevant technologies. The challenges are easier to plan <strong>for</strong> when the
technologies are proven. Typically, organizations obtain the readiness and skills
needed in this scenario by out-sourcing or by developing strong in-house
capability.
Support. Scenarios in this category focus on situations in which it is necessary to
extend the product to fit the needs of a customer’s environment. These are
typically valuable but not business-critical solutions and often involve legacy
technology. Here, cost of delivery becomes paramount and the organization may
decide to rely on external skills (particularly <strong>for</strong> legacy) on a reactive basis.
When determining the most appropriate scenario <strong>for</strong> a migration project, keep in mind
that the technology being migrated was initially deployed under one scenario. For
example, it might have been implemented when the technology was new, or it might have
been a key operational technology. As the new migrated environment is envisioned,
though, a different scenario may apply. If the technology has matured, <strong>for</strong> example, what
was a “high potential” project may be treated, in migration, as a “key operational”
scenario. Alternatively, what might have originally been a classical support-scenario
project might involve, as a result of migration to newer technology, something more akin
to the high potential scenario. Identifying the most appropriate scenario helps to map the
appropriate competencies and proficiencies required <strong>for</strong> the migration.
● Competencies describe the measurable objectives, or tasks, in a given scenario
that an individual needs to be able to complete with proficiency. A single
competency is used to define a major part of an individual’s job or job responsibility
relating to per<strong>for</strong>mance. A competency can be considered a combination of skills,
knowledge, and per<strong>for</strong>mance requirements
● Proficiencies are the measure of the capability to execute tasks associated with a
particular competency within a given scenario. An individual's proficiency level
provides a baseline <strong>for</strong> analyzing the gap between that individual's current skill set
and the necessary skills <strong>for</strong> completion of the tasks associated with the given
scenario.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 9
Assess
The assess step focuses on the individual team members. It determines the
competencies that these individuals currently possess. It is during this step that analysis
of the competencies as they relate to the various job roles is undertaken to determine the
skills of individuals within each of these roles. The desired competencies are then
analyzed against the current competencies — the “to-be" versus the “as-is.” This work
enables the development of learning plans, so that desired competency levels can be
reached. The following tasks need to be per<strong>for</strong>med to complete the assess step:
● Measure individuals' knowledge, skills, and abilities through self-assessments or
skills assessments (tests).
● Analyze gaps by comparing the individual's KSA measurements to the expected
proficiency level <strong>for</strong> the role. Individuals can then concentrate on bridging these
gaps through the use of learning plans.
● Create learning plans that identify the appropriate resources and methods (such as
training materials, courseware, white papers, computer based training, mentoring,
on-the-job, and self-directed training) to fill the gaps. Learning plans should consist
of both <strong>for</strong>mal and in<strong>for</strong>mal learning activities, and guide individuals through the
process of moving from one proficiency level to the next.
Change
In this step, individuals advance their skills through learning in order to bridge the gap
between their current proficiency and desired proficiency levels. In this step, the following
tasks are accomplished:
● Train individuals using the actual training, hands-on learning, and mentoring
techniques described in the learning plans.
● Track the learning of each individual. Monitor and report the progress of individuals
and their skills by scenario and competency. Tracking progress enables individual
and overall readiness to be determined at any time in the life cycle.
Evaluate
This step determines whether the learning plans were effective and whether the lessons
learned were successfully implemented on the job. At this point it is time to:
● Review results to see if more training is necessary or if what was learned is being
implemented on the job.
● Manage knowledge to foster the sharing of the new intellectual resources. This
sharing of knowledge enhances the collective knowledge of the solution team and
the enterprise and fosters a learning community. Additionally, a <strong>for</strong>mal knowledge
management system can provide a way to share common and repeatable best
practices that help reduce costs and risks <strong>for</strong> other project teams.
The MSF Readiness Management Discipline is considered an ongoing, iterative
approach to readiness. Following the steps in the process helps manage the various
tasks required to align individual, project team, or organizational KSAs. It can lead to
better individual, project team, and strategic planning success.

10
Introduction to the Microsoft <strong>Solution</strong>s Framework
Project Management
The third important discipline adopted by MSF is the Project Management Discipline. To
deliver a solution within project constraints, strong project management skills are
essential. The MSF Team Model does not contain a role known as Project Manager;
however, most project management functions are conducted by the MSF Program
Management Role.
Project management is a set of skills and techniques that include:
● Integrating planning done <strong>for</strong> each aspect of the project.
● Conducting change control.
● Defining and managing the scope of the project.
● Preparing a budget and managing costs.
● Preparing and tracking schedules.
● Getting the right resources allocated to the project.
● Managing contracts and vendors, and procuring project resources.
● Facilitating team and external communications.
● Facilitating the risk management process.
● Documenting and tracking the team’s quality management process.
Three distinctive characteristics of the MSF approach to project management stand out:
● Most of the responsibilities of the role commonly known as "Project Manager" are
encompassed in the MSF Program Management Role Cluster. As the size and
complexity of a project grows, this role cluster is broken out into two branches of
specialization: one dealing with architecture and specifications and the other
dealing with project management.
● In larger projects requiring scaled-up MSF teams, project management activities
occur at multiple levels. As the teams grow in number, the project management
activities become distributed among the team leads <strong>for</strong> each of the MSF team
roles. The Program Management Role is then responsible <strong>for</strong> management of the
“rolled up” work from the leads in order to manage the entire solution.
● Some large or complex projects require a specialist Project Manager or project
management team. As the size, complexity, or risk becomes very large, often
specialist roles or teams are created to focus on one particular area. For the
Program Management Role, this can be done to break the many project
management tasks into smaller, more manageable responsibility areas. These
could include a specialist project manager, risk manager, solution architect,
schedule administrator, and so on.
The differentiating factor of the MSF approach to project management is that the project
management job function and activities do not impose a hierarchical structure on the
decision-making process. MSF advocates against a rigid, “dictator” project management
style because it works against an effective team of peers.
The team of peers approach is a key success factor of MSF. All roles in MSF are
considered equally important and major decisions are arrived at by consensus of the core
team. If that consensus cannot be achieved, the Program Management Role plays a
tiebreaker function, making the final decision on the issue by transitioning into a decision
leader to drive the project <strong>for</strong>ward. This decision is made from the perspective of meeting
the customer’s requirements and delivering the solution within the constraints. Afterward,
the team immediately resumes their normal peer relationships.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 11
Overview of MSF Phases
The in<strong>for</strong>mation in this section describes the MSF phases that structure the organization
of this migration guide. These phases create the structure used <strong>for</strong> the project throughout
the rest of this guide.
Envisioning Phase
In the Envisioning Phase, the team identifies the vision and scope of the project by
preparing a vision and scope document.
During this phase, goals <strong>for</strong> the project are <strong>for</strong>med and a vision statement is created that
defines the entire project. This shared vision helps the team to work towards a common
objective. The project team is assembled and the team members are empowered by
having roles and responsibilities assigned to them.
Another important activity in this phase is the identification of risks and preparation of
mitigation and contingency plans. The risks identified and the mitigation plans are used
throughout the life cycle of the project. Refer to Chapter 2, "Envisioning Phase," <strong>for</strong> more
details on the tasks and deliverables of the Envisioning Phase.
Planning Phase
During this phase, the existing environment is assessed to <strong>for</strong>m a solution design. The
main activity of this phase is to do a detailed planning to ensure success of the project. In
this phase, a master project plan deliverable is created that consists of all sub-plans,
such as the test plan, and development plan.
The plan focuses on budgets, quality, schedule, and the technical implementation of the
solution. The project team follows these plans in the subsequent phases. Refer to
Chapter 3, "Planning Phase," <strong>for</strong> more details on the tasks and deliverables of the
Planning Phase.
Developing Phase
During this phase, the application components undergo trans<strong>for</strong>mation based on the
development plans.
Components that need a rewrite are developed. In components that are ported, changes
based on syntax compliancy, per<strong>for</strong>mance, and security are carried out. The source code
and executables help to create the deliverables of this stage. Refer to Chapter 4,
"Developing: Databases — Introduction," <strong>for</strong> more in<strong>for</strong>mation on how to migrate a
database. Chapter 10, "Developing: Applications — Introduction," provides different
scenarios <strong>for</strong> migrating an application.
Stabilizing Phase
During this phase, all the components are tested collectively to ensure that the entire
solution operates properly.
The testing criteria include achieving the desired functionality, security, and per<strong>for</strong>mance
requirements. To ensure this, both white box and black box testing are per<strong>for</strong>med. The
tested database and components <strong>for</strong>m the deliverables of this stage.
Once testing is complete, the solution must be stabilized to ensure that it meets defined
quality levels. If the migration is complex, a pilot test of the application can also be
per<strong>for</strong>med during the Stabilizing Phase. Refer to Chapter 18, "Stabilizing Phase," <strong>for</strong>
more details on the tasks and deliverables of the Stabilizing Phase.

12
Introduction to the Microsoft <strong>Solution</strong>s Framework
Deploying Phase
In this phase, the team deploys the solution and ensures that it is stable and can be
used. The tested solution is moved into production and transferred to operations.
During this phase, the solution components are tuned in the production environment. A
solution signoff is obtained from all stakeholders that confirms that the application meets
the requirements developed during the Envisioning and Planning Phases. Refer to
Chapter 19, "Deploying Phase," <strong>for</strong> more details on the tasks and deliverables of the
Deploying Phase. The migration project and the guidance are deeply rooted in the MSF
methodology, and the chapters are in chronological order of the MSF phases starting
from Chapter 2, "Envisioning Phase, through Chapter 19, "Deploying Phase."

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 13
2
Envisioning Phase
Introduction and Goals
This chapter provides the process and technical in<strong>for</strong>mation required to complete the
Envisioning Phase of an <strong>Oracle</strong> on UNIX to SQL Server on Windows® migration project.
The Envisioning Phase is an early stage of planning. This is the period during which the
team, the customer, and the sponsors define the high-level requirements and overall
goals of the project. The main purpose of the work per<strong>for</strong>med during the phase is to
ensure a common vision and reach consensus among the team members that the project
is both valuable to the organization and likely to succeed. During the Envisioning Phase,
the focus is on creating clear definitions of the problem and understanding the high level
approach to solving the problem. This sets a solid foundation from which specific plans
can be developed during the Planning Phase and executed during all subsequent phases
to achieve the migration objectives. The Envisioning Phase culminates in the
Vision/Scope Approved Milestone.
The key deliverables <strong>for</strong> the project team during the Envisioning Phase are:
● Vision/scope document. The vision/scope document describes the project goals
and constraints. It outlines the solution being developed, the requirements the
solution will meet, and the approach that the team will take to complete the project.
The vision/scope document is an early <strong>for</strong>m of the functional specification that is
developed during the Planning Phase. For more in<strong>for</strong>mation on creating your
vision/scope document, refer to the vision/scope template.
● Project structure document. The project structure document defines the approach
the team will take to manage the project. It defines the team’s administrative
structure, standards, processes (such as version control and change control),
project resources, and constraints. The document identifies the team lead
responsible <strong>for</strong> each MSF role.
● Risk assessment document. The risk assessment document provides an initial
identification and analysis of risks associated with a project. This analysis includes
mitigation and contingency plans to help the team manage specific risks. Refer to
the Risk Assessment template <strong>for</strong> more in<strong>for</strong>mation.
Templates <strong>for</strong> each of these key deliverables are available in the Tools and Templates
folder in the zip file download of this guidance at
http://go.microsoft.com/fwlink/?LinkId=45289.
Table 2.1 lists the key activities that the team undertakes in the Envisioning Phase. The
results of these activities are documented in this phase's deliverables.

14
Envisioning Phase
Table 2.1: Major Tasks, Deliverables, and Primary Owners
Tasks Project Deliverable Primary Owner
Understand the goals of the Vision/scope document Product Management
migration project (business
and design)
Create the problem
Vision/scope document Product Management
statement
Create the vision statement Vision/scope document Product Management
Define end user profiles Vision/scope document Product Management
Assess the current situation Vision/scope document Program Management
(high level)
Identify high level
Vision/scope document Product Management
requirements
Define the project scope Vision/scope document Program Management
Define the solution concept Vision/scope document Program Management
Set up a team Project structure document Program Management
Product Management
Define the project structure Project structure document Program Management
Assess risk Risk assessment document Program Management
Note This chapter provides in<strong>for</strong>mation about the essential tasks of the Envisioning
Phase <strong>for</strong> an <strong>Oracle</strong> on UNIX to SQL Server on Windows migration project. The chapter
is not exhaustive. For a detailed description of all the activities and deliverables <strong>for</strong> the
MSF Envisioning Phase, refer to the UNIX Migration Project <strong>Guide</strong> (UMPG) available at
http://go.microsoft.com/fwlink/?LinkId=19832.
Understand the Goals of the Migration Project
An early, clear understanding of the goals of the migration project by the project team is
imperative <strong>for</strong> its success. These high level goals are not defined by the project team;
they are defined by the business managers and major stakeholders. The reasoning <strong>for</strong>
reaching an early consensus on the goals includes:
● The migration goals, once identified, are used to create a vision statement <strong>for</strong> the
migration project. This vision statement is the key driver <strong>for</strong> all actions and
decisions made by the team during the course of the migration project.
● The goals determine the aggregate skill set required by the project team to
successfully execute the migration project.
● The project team uses these goals to scope specific requirements that, in turn,
serve as the basis <strong>for</strong> detailed solution designs and plans.
● The goals serve as the basis <strong>for</strong> reconciling conflicts and establishing priorities that
guide any trade-off decisions (schedule, features, resources, budgetary
restrictions) that need to be made later in the project.
The project goals can be classified as business goals and design goals. Both types of
goals are described in detail in the following sections.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 15
Define the Business Goals
Business goals are established either to take advantage of an opportunity or to solve a
problem in the current business. Each organization has business goals specific to them.
For example, a business goal <strong>for</strong> one organization could be to “consolidate the ERP
applications across all worldwide units on one software plat<strong>for</strong>m after a merger with
another company,” while a different organization may have compliance with new federal
regulations as its primary business goal. Because business goals can vary widely, this
guide does not provide a specific, comprehensive list of business goals. Your
organization will have to determine the business goals specific to it. However, the two
most common business goals <strong>for</strong> IT projects are:
● Reduce total cost of ownership (TCO) of the IT plat<strong>for</strong>m
● Maximize return on investment (ROI)
Because these two business goals are so common, they are discussed in more detail
under the following headings.
Reduce TCO of IT Plat<strong>for</strong>m
TCO of a system includes not only the price of purchasing software and hardware, but
also the cost of training users and supporting and maintaining the system. There<strong>for</strong>e,
while evaluating the TCO of any system, there are several factors to consider.
● Cost of hardware. Evaluate the cost of server hardware, networking equipment
such as hubs and routers, and other equipment. Also include facilities cost <strong>for</strong>
hosting the hardware.
● Cost of software. Evaluate the cost of all software including the operating system
and applications, such as database systems, developer tools, and management
software.
● Reliability of the system. If the system fails or crashes often, the support cost <strong>for</strong>
such a system would increase.
● Cost of system maintenance. System administration is single highest cost factor
<strong>for</strong> any IT organization. Evaluate the staff strength needed and associated costs
<strong>for</strong> maintaining the system.
● Cost of supporting the users. Users may need extensive training and frequent
support, significantly adding to the TCO.
● Projected cost of the migration project itself. Factors such as availability of
skills in-house versus hiring external consultants will influence the project cost. You
will be able to estimate these costs better after completing the Planning Phase.
Microsoft offers several solutions to help reduce TCO.
For example, Microsoft Visual Studio .NET provides an Integrated Development
Environment (IDE) <strong>for</strong> rapid development of applications that reduces the cost of
developing and upgrading applications. The Windows graphical user interface (GUI)
environment provides an easy-to-use interface <strong>for</strong> Windows users. The Windows
standard GUI and GUI-based management applications simplify server administration
and thus contribute to reducing support costs.
For more in<strong>for</strong>mation about TCO on the Windows plat<strong>for</strong>m, refer to
http://www.microsoft.com/business/reducecosts/efficiency/consolidate/tco.mspx.
For customer case studies about reduced TCO on a Windows plat<strong>for</strong>m, refer to
http://www.microsoft.com/business/reducecosts/efficiency/consolidate/casestudies.mspx
#EBAA.

16
Envisioning Phase
Maximize ROI
TCO is concerned with an organization’s bottom-line (cutting costs), and ROI is related to
the top line (increasing revenue). A lowered TCO and increased ROI scenario is the
ultimate goal of any migration project. To estimate the ROI due to the migration ef<strong>for</strong>t,
you should take into account the following considerations:
● Creation of new business opportunities. The migration may provide new
technological capabilities and drive new business innovations that lead to
increased revenue.
● Opportunities created by improved per<strong>for</strong>mance. For example, a faster
response time to online users on a Web site can drive more satisfied customers to
the site and increase profitability.
● Total downtime required to complete the migration. System downtime can
affect revenue and should be minimized.
● Reliability of the system. Unplanned system downtime can negatively affect
productivity and revenue.
● Time to recover investment costs. The business needs to understand how long
it expects to realize a return on the investment in the project.
● Impact on user productivity due to the migration. If users are going to take a
long time to ramp up on the new technology, it can impact the near term
productivity and profitability of the organization. Productivity can also be affected
positively by easing the integration between the database application and other
office software.
● Managing risk. The organization needs to evaluate the risk of doing the project as
well as not doing the project. Not taking the risk may be the path of least
resistance, but it may deprive you of significant revenue opportunities. Proven best
practices and processes can minimize risk and make the migration more
predictable. Several system integrators (SIs) offer service offerings that can greatly
mitigate the risk. The SIs who are known to offer <strong>Oracle</strong> to SQL migration
offerings, as of publishing this solution, are listed in the "Set Up a Team" section
later in this chapter.
Some of the questions that result from these considerations can be answered by
analysis. However, a proof-of-concept or a limited pilot exercise can help provide
quantifiable answers to these questions, including estimating application migration costs
and determining the reliability of software. More in<strong>for</strong>mation is available in the "Technical
Proof of Concept" section of Chapter 3, "Planning Phase."
Identify the Design Goals
Design goals are similar to business goals in many ways. The difference is that design
goals focus more on the attributes of the solution and less on what the solution will
accomplish <strong>for</strong> the business. As with business goals, an organization's design goals are
unique and specific to that organization. For example, one organization may determine
that “corporate data should be accessible from the mobile devices issued to company
employees.” A different organization's primary design goal may be to “reduce the time
and level of ef<strong>for</strong>t required <strong>for</strong> a user to connect to the server and complete a task.” This
guide does not provide a specific list of design goals. Your organization will have to
determine the design goals specific to it. However, the following list provides the six most
common and generic design goals <strong>for</strong> UNIX to Windows migration projects.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 17
●
●
●
●
High availability and reliability. The solution should process requests without
interruption, even in the event of a failure. For more in<strong>for</strong>mation on Windows
reliability, refer to http://www.microsoft.com/mscorp/twc/reliability/default.mspx
SQL Server allows <strong>for</strong> servers to be clustered into groups of connected nodes. The
solution described in this guide provides high availability <strong>for</strong> business applications.
If there is a failure of the operating system, hardware, or any planned upgrade
event on a single machine, SQL Server can be configured to fail over to another
node, minimizing down time. For more in<strong>for</strong>mation about SQL Server clustering,
refer to http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/enus/part4/c1261.mspx.
Robust security. In business, data security is vital. Launched under the
Trustworthy Computing Initiative, Windows Server 2003 was designed with an
emphasis on security.
Many new features have been added, including support <strong>for</strong> strong authentication
protocols such as Kerberos, 802.11x (WiFi) and Internet Protocol Security (IPSec).
For more in<strong>for</strong>mation about Windows Server 2003 security, refer to
http://www.microsoft.com/windowsserver2003/technologies/security.
For more in<strong>for</strong>mation about SQL Server 2000 security, refer to the following three
resources:
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sp3sec01.mspx
http://www.microsoft.com/sql/techinfo/administration/2000/security/default.asp
http://www.microsoft.com/sql/evaluation/features/security.asp
High per<strong>for</strong>mance and scalability. The system should show an acceptable level
of per<strong>for</strong>mance even when the number of users increases.
SQL Server 2000 can support multi-terabyte databases served to millions of users.
This scalability is achieved by supporting scale up on symmetric multiprocessor
(SMP) systems, allowing the installation of additional processors, memory, disks
and networking to build a large single node. In addition, SQL Server supports scale
out, or allowing large databases to be split between a cluster of servers. Each
server stores a portion of the database and assists in processing functions. For
more in<strong>for</strong>mation about Windows per<strong>for</strong>mance and scalability, refer to the following
two resources:
http://www.microsoft.com/windowsserver2003/evaluation/per<strong>for</strong>mance/default.msp
x
http://www.microsoft.com/windowsserver2003/techinfo/serverroles/appserver/scale
.mspx
For more in<strong>for</strong>mation about SQL Server per<strong>for</strong>mance and scalability, refer to the
following two resources:
http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/ssmsam.mspx
http://www.microsoft.com/sql/evaluation/compare/benchmarks.asp
Easy manageability. The system should provide easy ways <strong>for</strong> the administrators
to install, manage, and maintain the operating system, application software, and
updates. For more in<strong>for</strong>mation on management products from Microsoft, refer to
http://www.microsoft.com/management/default.mspx.
SQL Server provides a number of robust administration tools <strong>for</strong> managing data.
Tools include graphic administration tools, task wizards, and command line utilities.
For detailed in<strong>for</strong>mation about the SQL Server tool set, refer to the following two
resources:
http://www.microsoft.com/technet/prodtechnol/sql/2000/books/c01ppcsq.mspx

18
Envisioning Phase
●
●
http://msdn.microsoft.com/library/default.asp?url=/library/enus/usetools/usetools_4ovn.asp
Consolidation of servers. The new system should allow <strong>for</strong> the consolidation of
existing databases into a small number of servers. If the existing solution is based
on older hardware, a migration presents an opportunity to consolidate to fewer and
more powerful servers.
For more in<strong>for</strong>mation about Windows Server 2003 Datacenter Edition — the
Microsoft server operating system optimized <strong>for</strong> server consolidation — refer to
http://www.microsoft.com/windowsserver2003/datacenter/default.mspx.
Interoperability with the existing UNIX plat<strong>for</strong>m. The new system should
integrate with the existing applications and infrastructure on the UNIX plat<strong>for</strong>m. For
more in<strong>for</strong>mation about Windows interoperability with UNIX, refer to
http://www.microsoft.com/sfu.
For a detailed comparison of the system abilities of existing UNIX systems and
Windows Server 2003 and SQL Server 2000, refer to
http://go.microsoft.com/fwlink/?linkid=37907
Create the Problem Statement
A problem statement is usually a short narrative describing the specific issues that the
business hopes to address with the project. It relates primarily to the current state of
business activities and is a direct result of the business goals or design goals not being
met adequately. The more precisely the problem statement is recorded, the easier it will
be to measure the success of the project.
Because the aim of the project is to solve a problem, the understanding of the problem
determines the design of the solution. A good problem statement provides sufficient
in<strong>for</strong>mation about the business problem <strong>for</strong> a new team member to use the problem
statement and the rest of the documentation to put the project into context.
The following are some examples of problem statements that may be relevant in an
<strong>Oracle</strong> on UNIX to SQL Server on Windows migration project:
● Customer support cannot effectively process the high number of customer calls
because of the time it takes <strong>for</strong> them to retrieve customer data from the existing
customer database.
● Product managers cannot make in<strong>for</strong>med decisions about sales promotions
because they do not have recent sales trends.
Create the Vision Statement
The vision statement addresses the problem statement and establishes a common vision
of the end state that can be shared among team members. While brief, this statement
provides a common starting point <strong>for</strong> future decisions throughout the rest of the project.
A good vision statement has the following characteristics:
● Specific. A vision statement should be specific and include the ideal state of the
business problem solution so that the end result is meaningful.
● Measurable. By creating a vision statement that is measurable, the project team
can determine the degree of success at the completion of the project.
● Achievable. Given the resources, the time frame, and the skills of the team
members, the vision statement should be achievable. An achievable and
challenging vision statement can motivate team members.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 19
●
●
Relevant. The vision statement should relate to the business problem being
addressed. If not, the project team might realize that they are solving the wrong
problem, or one that does not exist, and — in the process — lose sponsorship.
Time-based. The vision statement should clearly indicate the estimated time frame
<strong>for</strong> the delivery of the solution.
The following two examples are vision statements <strong>for</strong> an <strong>Oracle</strong> on UNIX to SQL Server
on Windows migration project:
● Be<strong>for</strong>e the end of the year, our customer support staff will be able to retrieve all
customer data and account history within three seconds of the customer identifying
himself or herself.
● Be<strong>for</strong>e the start of the next fiscal year, our product managers will have access to
daily sales reports from all the showrooms in the country.
Define the User Profiles
Understanding the users <strong>for</strong> whom the solution is being developed is critical to the
project's success. To capture a clear description of each user, the team creates profiles
of each user class. The process of profiling develops a set of user requirements. The
combination of these user requirements with the business and design requirements will
help to define the project scope later in the Envisioning Phase.
In an <strong>Oracle</strong> on UNIX to SQL Server on Windows migration project, the most important
profiles are that of the system managers and users of the migrated application. Consider
the following while profiling the user types:
● Proficiency of the users in using Microsoft applications and the Windows
environment. Administrators largely use command line tools in the <strong>Oracle</strong>/UNIX
world. While Windows also provides some command line interfaces, Windows
tools tend to be graphical user interfaces (GUIs). Users new to the Windows
environment may need training.
● The type of tasks that the users will per<strong>for</strong>m on the new system.
● Essential expectations of the end user from the current application interface that
will have to be met in the new environment.
● The language localization needs <strong>for</strong> the end users, if necessary. Consider the GUI
as well as user documentation.
● The physical location of the end users. Factors such as locations, number of users
at each location, and the bandwidth and usage of network links between the sites
should be understood and documented.
Assess the Current Situation (High Level)
Organizations planning an <strong>Oracle</strong> on UNIX to SQL Server on Windows migration need to
consider the following five entities <strong>for</strong> a successful migration. While these entities are
assessed in detail in the Planning Phase of the project, a high level preliminary
assessment is essential in the Envisioning Phase to evaluate the feasibility of the project.
● Application
This entity includes the target applications that are migration candidates. While
assessing applications, the following questions should be asked:
● Which are the specific applications that are to be migrated?
● What languages are these applications written in?

20
Envisioning Phase
●
●
●
If there are custom applications to be migrated, is the source code available?
Are the developers of the application still a part of the team?
Do the applications to be migrated interoperate with other applications or
systems?
●
●
●
●
Database
This entity includes the <strong>Oracle</strong> databases that need to be migrated to SQL Server.
The following are some of the high level questions you need to ask:
●
●
●
●
Do your existing databases implement specialized features of <strong>Oracle</strong> or any
other third-party customizations to provide additional database features?
Are the databases that need to be migrated shared by multiple applications?
What are the sizes of the databases being migrated?
What is the user population of the databases?
Application infrastructure
This entity includes server and network-related resources, such as compute nodes,
storage, file systems, routers, firewalls, hubs, and so on. The following are some of
the questions you need to ask to assess the current state:
● Do you already have an existing infrastructure based on Windows that can be
readily used or expanded, or do you have to set up the infrastructure from
scratch?
● What are the other external systems, such as those of your partners or clients,
that would be impacted by the migration?
Microsoft provides a standardized infrastructure architecture named Windows
Server System Reference Architecture (WSSRA). WSSRA provides lab and real
world tested, architectural blueprints and proven best practices to design and
implement enterprise infrastructure solutions with minimal risk and cost. The
guidance addresses infrastructure issues including availability, security, scalability,
and manageability of the plat<strong>for</strong>m in a fully integrated fashion. For detailed
in<strong>for</strong>mation on WSSRA, refer to
http://www.microsoft.com/windowsserversystem/overview/referencearchitecture.ms
px.
Development environment
This entity includes software construction environments such as the UNIX make
environment, developer tools, and so on. Migration of the database and data can
be achieved by using tools bundled with <strong>Oracle</strong> and SQL Server, such as
SQL*Plus, Enterprise Manager, and Query Analyzer. Microsoft offers a set of tools
called SQL Server Migration Assistant <strong>for</strong> migrating <strong>Oracle</strong> databases to
SQL Server.
Questions to ask while assessing the development environment include:
● What is the software construction environment that you have to build the UNIX
applications? A commonly used software construction mechanism is the use of
makefiles. For detailed process and technical guidance on using a makebased
build environment to build Windows executables, refer to
http://go.microsoft.com/fwlink/?LinkId=22225
● Are the required licenses <strong>for</strong> the appropriate SQL Server edition available?
● What are the server, storage, and network resources to support the
development and testing activities?
Existing documentation

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 21
This entity includes end user documentation, requirements analysis, functional
specifications, design documents, and so on. The existing documentation should
be scrutinized as part of the task of assessing your current environment. This is
something that is often overlooked. Existing design documentation is a valuable
resource <strong>for</strong> building project documents and plans, especially when a large portion
of the existing functionality is carried over to the new solution. Developing test
plans and test cases <strong>for</strong> the new application based upon existing documentation is
especially useful. Modifications to existing documentation are almost certainly
needed to support the migrated solution. One problem often encountered is that
the existing documentation is incorrect or insufficient, which may <strong>for</strong>ce the
migration project to absorb the ef<strong>for</strong>t of bringing it up to date.
These are some of the questions that you need to ask:
● Are the original requirements <strong>for</strong> each of the applications to be migrated
available?
● Are database and application design (high level as well as detailed) documents
available?
● Are the logical and physical data models available <strong>for</strong> all databases to be
migrated?
● Is documentation <strong>for</strong> the application code maintained?
● Are user manuals available <strong>for</strong> client applications?
● Are training documents available <strong>for</strong> support, end users, and operations
personnel?
●
Application users
User accounts that exist in the UNIX domain need to be migrated or recreated in
the Windows-based domain along with the necessary permissions <strong>for</strong> users to start
using the application on the Windows domain. Ask the following questions:
● What security services are in use (examples include local, Kerberos, NIS,
NIS+, and LDAP)?
● What is the authentication method in use (examples include password, digital
certificate, and so on)?
● What authority does the user have on the system?
● How is authorization implemented?
● What activities of the users are audited?
● Are users required to use secure communication methods such as SSH?
● Are application users authenticated by the operating system as well as by the
database?
For prescriptive guidance on how to enable Windows Server 2003 to be used <strong>for</strong>
authentication and as an identity store within Windows and UNIX environments,
refer to http://go.microsoft.com/fwlink/?LinkId=23120.
Note The primary purpose of this solution is to provide guidance on migrating the
applications and databases from an <strong>Oracle</strong> on UNIX environment to a SQL Server on
Windows environment. The discussions about migrating the infrastructure, development
environment, user accounts, and documentation are, there<strong>for</strong>e, limited in this solution.
The discussions have been included to provide readers a holistic perspective of the
migration. Pointers to other resources that provide more in<strong>for</strong>mation, including
prescriptive guidance, are provided when relevant.

22
Envisioning Phase
Figure 2.1 represents the primary entities involved in an <strong>Oracle</strong> on UNIX to SQL Server
on Windows migration. To reiterate: this guide provides prescriptive guidance <strong>for</strong>
migrating the application, database, and application infrastructure entities only.
In<strong>for</strong>mation about the other entities is available from the sources cited earlier.
Figure 2.1
Primary Migration Entities
Capture High Level Requirements
An important task in the Envisioning Phase is to document the high-level business, user,
and design requirements. These requirements are refined further in the conceptual
design stage of the Planning Phase (discussed in Chapter 3, "Planning Phase").
A common way of gathering and analyzing in<strong>for</strong>mation is through developing use-cases
and building usage scenarios to document the business processes and user
requirements. While use cases describe the high level interactions between an individual
and the system, usage scenarios provide additional in<strong>for</strong>mation about the activities and
task sequences that constitute a process.
A detailed discussion of use-case analysis is out of scope of this solution. Please refer to
the following resource <strong>for</strong> additional guidance: Advanced Use Case Modeling (Armour
and Miller, 2000).
Define the Project Scope
One of the critical factors in the success of a project is clearly defining the scope of the
project. Scope defines what will be and what will not be included in the project. The
scope uses the high level requirements gathered earlier in the Envisioning Phase and
incorporates the constraints imposed on the project by resources, schedule, budget, and
other limiting factors. A good way of scoping is to address use cases and usage
scenarios that impact the business the most.
As with the business and design goals, the scope <strong>for</strong> projects is organization-specific,
and you will need to determine the scope <strong>for</strong> your project and document it in the

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 23
vision/scope document. However, when producing the scope <strong>for</strong> your <strong>Oracle</strong> on UNIX to
SQL Server on Windows migration project, some general guidelines should be followed:
●
●
●
●
●
●
●
Consider a multiphase approach to the migration. In the first phase, consider
migrating only the database and reconnect the UNIX applications to connect to
SQL Server. Limiting the scope <strong>for</strong> each phase of the migration increases your
ability to monitor and measure the migration project's success.
Consider migrating the portable applications first. These include applications
written using Java, Perl, PHP, and Python. Portable applications can usually be
ported or configured to interoperate with relative ease, and this helps build user
and management confidence.
<strong>Oracle</strong> Forms and Pro*C applications are the hardest to migrate because they
have to be rewritten; per<strong>for</strong>m them in a later phase, if possible.
The migration of code present in the database in the <strong>for</strong>m of triggers, functions,
stored procedures, and packages impacts the migration of applications that are
dependent on them. As a result, these have to be migrated first.
Databases using advanced <strong>Oracle</strong> functionality, such as advanced queuing, Java
packages, objects, and so on are more difficult to migrate, and a proof-of-concept
should be created to verify the solution.
Smaller databases with less stringent requirements on per<strong>for</strong>mance and availability
should be migrated be<strong>for</strong>e attempting larger ones.
To reduce the complexity, migration at the schema level should be considered
where feasible instead of entire databases.
Define the <strong>Solution</strong> Concept
The solution concept outlines the high level approach the team will take to meet the goals
of the project and provides the basis <strong>for</strong> proceeding to the Planning Phase. This
approach includes the assessment of technologies, development, test, quality assurance,
training, deployment, release, operations and so on. These approaches can be
developed into full-fledged plans in the Planning Phase. Because the solution concept
focuses on the concepts and not the details, it is not very technical.
The solution concept also includes a high-level solution design strategy <strong>for</strong> all the
software and hardware components of the system. Because the primary focus of this
solution is migrating the <strong>Oracle</strong> databases and associated applications to SQL Server on
Windows, the rest of this section discusses only solution design strategies <strong>for</strong> the
database and applications.
Application and Database Migration <strong>Solution</strong> Design
Strategy
For the purposes of explanation, the application and database ecosystem can be viewed
in terms of three components:
● Application. This component includes applications written in a variety of
programming languages, including <strong>Oracle</strong> Forms, Perl, Python, and so on.
● Connectivity interface. This is the intermediate tier between the application and the
database. The connectivity tier is also referred to as the application programming
interface (API). This layer facilitates the communication between the application
and the database. <strong>Oracle</strong> and SQL Server support different connectivity interfaces,
some proprietary and some standard. <strong>Oracle</strong> Call Interface (OCI) is an example of
a proprietary interface <strong>for</strong> an application to communicate with <strong>Oracle</strong>. Object

24
Envisioning Phase
●
Database Connectivity (ODBC) is an example of a standards-based interface. The
available API also differs from UNIX to Windows.
Database. The database tier consists of the database management system and
the objects that store and facilitate access to the data in the database.
The relationship between these three components is shown in Figure 2.2. The
connectivity interface binds the application to the database and allows in<strong>for</strong>mation to
pass between them.
Figure 2.2
Application, database, and connectivity tiers
Once the database is migrated from <strong>Oracle</strong> to SQL Server, there are four different
approaches to connect the application to the SQL Server database using an appropriate
connectivity layer.
1. Interoperation
The application components remain on the UNIX plat<strong>for</strong>m.
2. Port or rewrite application to the .NET plat<strong>for</strong>m
The.NET framework is the next generation plat<strong>for</strong>m from Microsoft <strong>for</strong> building,
deploying, and running Windows applications. It provides a standards-based, multilanguage
environment <strong>for</strong> integrating existing investments with next-generation
applications and services.
3. Port or rewrite application to Win32 plat<strong>for</strong>m
The Win32 API is one of the primary programming interfaces to the Windows
operating system family, including Windows 2003. The Win32 API provides
functions <strong>for</strong> processes, memory management, security, windowing, and graphics.
4. Quick port: port application to the Windows Services <strong>for</strong> UNIX 3.5 plat<strong>for</strong>m
Port applications to an environment on Windows named Interix, which is similar to
UNIX. Interix is a complete, POSIX-compliant development environment that is
tightly integrated with the Windows kernel. It is a part of the Microsoft
Windows Services <strong>for</strong> UNIX 3.5 product suite from Microsoft.
Each of these four options constitutes a separate design strategy <strong>for</strong> your migration
project, and each of the four is discussed in more detail under the following headings.
One, some, or all of these solution design strategies will <strong>for</strong>m the basis of the solution
concept you will produce as a part of completing the Envisioning Phase. Even when the
goal is to standardize on the Windows plat<strong>for</strong>m, some of these strategies may be
employed as intermediary steps in a multi-phased migration. This solution concept —
documented in the vision/scope document — will be used to develop detailed plans
during the Planning Phase and code during the Developing Phase.
Note Due to the complexities inherent in a migration project, it may not be possible to
immediately select a migration strategy. Proof-of-concept testing may need to occur
be<strong>for</strong>e the design strategy is decided upon.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 25
<strong>Solution</strong> Design Strategy A: Interoperability
In this strategy, the applications remain on the UNIX plat<strong>for</strong>m while the database alone is
migrated from <strong>Oracle</strong> to SQL Server.
Interoperation is preferred in the following situations:
●
●
●
●
The migration ef<strong>for</strong>t and risks need to be minimized at the expense of not being
able to fully realize the benefits of migrating the application to Windows.
A multiphased approach <strong>for</strong> migration is more appropriate. The first phase of
migration could involve migrating the database only, and later phases could focus
on migrating the applications.
The needs served by the application are static; the evolution of the application is
not a business or design goal of the project.
Maintaining a tight or complex integration of UNIX applications with other services
is required.
Interoperation is not recommended in the following situations:
●
●
●
●
●
The cost of maintaining two environments is prohibitive.
The goals of the project include changing the application to take advantage of the
greater business value of Windows technologies.
Components being on two different plat<strong>for</strong>ms do not produce acceptable
per<strong>for</strong>mance or service levels.
The required measure of security cannot be achieved because of disparate
technologies.
When the interoperation is complex and requires huge ef<strong>for</strong>t in development and
implementation as compared to employing one of the other methods.
<strong>Solution</strong> Design Strategy B: Port or Rewrite to .NET Framework
When migrating an application to the .NET framework, there are two different options.
One is to per<strong>for</strong>m a full port of the application, and the other is to rewrite the application
using the .NET application programming interfaces (APIs).
A full port is defined as the capability to execute the application in the Windows
environment in its native <strong>for</strong>m. Applications written using languages such as Java, Perl,
PHP, and Python, which are available on both the UNIX and Windows plat<strong>for</strong>ms, can
take advantage of a full port. In most cases, SQL Server database drivers are available
<strong>for</strong> the specific application languages. A full port requires minimum changes to be done to
the source code, and a full port uses standard libraries and utilities that exist on the
Windows plat<strong>for</strong>m. New documentation and user training is not required in the case of a
full port because the business logic and the user interface remain the same.
A full port to the .NET framework is preferred in the following situations:
● The programming environment in which the application was written is fully
supported in the .NET framework.
● Appropriate .NET database drivers are available and support all the function calls
made in the application code.
● Rewriting an application consumes too much time and increases cost prohibitively.
● When ported into the .NET framework, the application successfully interacts with
other applications.
A rewrite of the application would be required when there are no equivalents on the .NET
plat<strong>for</strong>m <strong>for</strong> the language in use. An example of this would be applications based on

26
Envisioning Phase
<strong>Oracle</strong> Forms. The best option in this case would be to rewrite the application on
Windows using Visual Basic .NET.
A rewrite of the application is preferred in the following situations:
● The cost and complexity of porting is prohibitively high. It may be easier to recreate
the application rapidly using Visual Basic.NET, rather than porting the application.
● The business logic is likely to change significantly in the new environment, which
would limit the amount of code reused from the source plat<strong>for</strong>m.
● The application requires new features and code that is specific to the Windows
environment.
● Tight integration with Windows features is required in the new application.
● The best possible integration with other Windows-based applications is required.
● A port is not possible either because the language is not supported or API libraries
<strong>for</strong> SQL Server do not exist.
Potentially, rewriting an application can be challenging. It can be a time-consuming, risky,
and costly option. The risk inherent in a rewrite is that the business logic or an important
functionality is changed while rewriting the code. Careful testing and stabilizing of the
rewritten application needs to be conducted to ensure proper business logic and
functionality.
When porting or rewriting to Windows, migration to the .NET plat<strong>for</strong>m is preferred. .NET
technology provides the ability to build, deploy, manage, and use connected, securityenhanced
solutions with Web services. For more in<strong>for</strong>mation about the .NET plat<strong>for</strong>m
and its key capabilities, refer to the following two resources:
http://www.microsoft.com/net/basics/
http://msdn.microsoft.com/netframework/programming/fundamentals/default.aspx
There are situations when moving to .NET may not be feasible. For instance, at the time
that this guide was published no production-ready implementations of Python on the
.NET framework existed. However, this technology is currently available in a beta <strong>for</strong>mat,
and investigation of current technologies is recommended.
<strong>Solution</strong> Design Strategy C: Port or Rewrite to Win32
The.NET Framework offers the next generation of applications and services. Migration to
the Win32 plat<strong>for</strong>m should be considered when migration to .NET is not technically
feasible <strong>for</strong> your organization. As with strategy B, two migration options are available
when moving to a Win32-based plat<strong>for</strong>m. The first is to per<strong>for</strong>m a full port of the
application, and the other is to rewrite the application using the Win32 APIs. The rationale
<strong>for</strong> deciding whether to port or rewrite the application to function with Win32 is the same
as the rationale <strong>for</strong> using .NET. Please refer to the description in the "<strong>Solution</strong> Design
Strategy B: Port or Rewrite to .NET Framework" section <strong>for</strong> more details.
<strong>Solution</strong> Design Strategy D: Quick Port by <strong>Migrating</strong> to
Windows Services <strong>for</strong> UNIX
One of the quickest migration paths possible is to port the code directly to
Windows Services <strong>for</strong> UNIX. Windows Services <strong>for</strong> UNIX includes Microsoft Interix, which
provides a UNIX environment that runs on top of the Windows kernel. Interix allows
native UNIX applications and scripts to work alongside Windows applications. The best
way to view Interix is to understand it as a POSIX-compliant version of UNIX built on top
of the Windows kernel. It is not an emulation of a UNIX environment on the Windows
APIs. Migration using Windows Services <strong>for</strong> UNIX involves obtaining the source code,

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 27
installing it in the Interix development environment, modifying the configuration scripts
and makefiles, and recompiling the application. This strategy is referred to as a quick
port.
The ported application may be successful immediately, or it may require modifications to
the configuration scripts or makefiles to account <strong>for</strong> the new hardware plat<strong>for</strong>m, the target
operating systems, and local configuration in<strong>for</strong>mation. A detailed assessment of the
application has to be conducted to inventory the various APIs and utilities in use. The
support <strong>for</strong> these in the Windows Services <strong>for</strong> UNIX environment has to be verified.
Extensive testing of the application is essential after the port to ensure that all features
have been migrated successfully.
A quick port is preferred in the following situations:
● A port <strong>for</strong> the language the application was written in does not exist in .NET or
Win32. An example application is X Windows.
● Application investments on the UNIX plat<strong>for</strong>m need to be reused. Interix can
optimize your investments in UNIX applications by reusing code. New functionality
and value can be added to your existing UNIX applications by integrating the UNIX
code with .NET or Win32 functionality.
● It is too expensive and time-consuming to do a full port or complete rewrite of the
application.
● A large set of UNIX scripts need to be ported. Interix allows you to get the most out
of existing UNIX network administrator tools and skill sets. It provides more than
300 UNIX utilities, and it provides shells and scripting languages (including Perl)
that enable you to run existing shell scripts with little or no change on Windows.
A quick port is not recommended in the following situations:
● A port of the application is available in Win32 or .NET.
● You can af<strong>for</strong>d the rewrite or port to Win32 or .NET and wants to tightly integrate
the application with other Windows technologies.
● You want to significantly evolve the application by using the capabilities of the
Windows environment.
● A quick port requires huge ef<strong>for</strong>t in development and implementation as compared
to employing one of the other methods. For example, when the required libraries
available on the original UNIX plat<strong>for</strong>m are not available on Interix.
Most UNIX database environments use scripts to support databases and client
applications. You should evaluate the importance of the services that these scripts
per<strong>for</strong>m. <strong>Migrating</strong> the scripts to Windows Services <strong>for</strong> UNIX is an option; however,
scripts that make use of <strong>Oracle</strong> utility programs must be modified to use suitable
replacements <strong>for</strong> SQL Server.
Using Windows Services <strong>for</strong> UNIX, organizations can rapidly consolidate diverse
plat<strong>for</strong>ms, maximizing their previous investments in UNIX infrastructure, applications, and
knowledge while capitalizing on Windows innovation. Moreover,
Windows Services <strong>for</strong> UNIX provides a full range of supported and fully integrated, crossplat<strong>for</strong>m
network services <strong>for</strong> blending Windows and UNIX networks.
For a detailed discussion of Windows Services <strong>for</strong> UNIX in migration projects, refer to the
UNIX Application Migration <strong>Guide</strong> available at
http://go.microsoft.com/fwlink/?LinkId=30832
Windows Services <strong>for</strong> UNIX 3.5 is available as a complimentary download from Microsoft
<strong>for</strong> Windows Server 2003, Windows® XP Professional, and Windows® 2000.
Some Windows Services <strong>for</strong> UNIX 3.5 features include:

28
Envisioning Phase
●
●
●
It is designed to work well with other major UNIX plat<strong>for</strong>ms and versions. It has
been tested specifically with Sun Solaris 7 and 8, HP-UX 11i, AIX 5L 5.2, and Red
Hat Linux 8.0.
It includes version 5.6 of the ActiveState Perl distribution <strong>for</strong> native Windows
scripting and Perl 5.6.1 <strong>for</strong> scripting in the Interix environment.
It includes more than 300 UNIX utilities and tools that per<strong>for</strong>m on UNIX and
Windows systems in a similar manner. In addition, Windows Services <strong>for</strong> UNIX 3.5
also contains a Software Development Kit (SDK) that supports more than 1,900
UNIX APIs and migration tools, such as make, rcs, yacc, lex, cc, c89, nm, strip,
and gbd, as well as the gcc, g++, and g77 compilers.
More in<strong>for</strong>mation about Windows Services <strong>for</strong> UNIX is available from the following two
resources:
http://www.microsoft.com/windows/sfu/productinfo/overview/default.asp
http://www.microsoft.com/windows/sfu/
Migration Strategy Scenarios
Tables 2.2 through 2.5 show the migration opportunities <strong>for</strong> several scenarios of the
source UNIX environment. Each scenario is a combination of the three components of
database, application, and connectivity (API). The first column of the tables represents
the current state in the UNIX environment, and the third column shows the migration
possibilities <strong>for</strong> each of the migration strategies: interoperate, port or rewrite to the .NET
Framework, port or rewrite to Win32, and port to Windows Services <strong>for</strong> UNIX.
Table 2.2: Application Interoperation Strategy
<strong>Oracle</strong>/UNIX
language
PHP
API
<strong>Oracle</strong> or OCI8 or
ODBC
Interoperate SQL
Server/UNIX
language
PHP
API
MS SQL Server or
ODBC
Pro*C OCI <strong>Solution</strong> not available
or feasible
<strong>Oracle</strong> Forms Forms C or JDAPI <strong>Solution</strong> not available
or feasible
Perl <strong>Oracle</strong> or ODBC Perl ODBC or Sybase
Python <strong>Oracle</strong> or ODBC Python ODBC
Java JDBC Java JDBC

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 29
Table 2.3: Application Port to Windows Services <strong>for</strong> UNIX Strategy
<strong>Oracle</strong>/UNIX
language
PHP
API
<strong>Oracle</strong> or OCI8 or
ODBC
Port SQL
Server/Windows
Services <strong>for</strong> UNIX
language
PHP
Pro*C OCI <strong>Solution</strong> not available
or feasible
<strong>Oracle</strong> Forms Forms C or JDAPI <strong>Solution</strong> not available
or feasible
API
MS SQL Server or
ODBC
Perl <strong>Oracle</strong> or ODBC Perl ODBC or Sybase
Python <strong>Oracle</strong> or ODBC Python ODBC
Java JDBC Java JDBC
Table 2.4: Application Port or Rewrite to Win32 Strategy
<strong>Oracle</strong>/UNIX
language
PHP
API
<strong>Oracle</strong> or OCI8 or
ODBC
Port/rewrite SQL
Server/WIN32
language
PHP
API
MS SQL Server or
ODBC
Pro*C OCI VB ODBC or ADO
<strong>Oracle</strong> Forms Forms C or JDAPI VB ODBC or ADO
Perl <strong>Oracle</strong> or ODBC Perl ODBC or ADO
Python <strong>Oracle</strong> or ODBC Python ODBC
Java JDBC Java JDBC
Table 2.5: Application Port or Rewrite to .NET Strategy
<strong>Oracle</strong>/UNIX
language
PHP
API
<strong>Oracle</strong> or OCI8 or
ODBC
Port/rewrite SQL
Server/.NET
language
<strong>Solution</strong> not available
or feasible
Pro*C OCI VB.NET ODBC or ADO.NET
<strong>Oracle</strong> Forms Forms C or JDAPI VB.NET ODBC or ADO.NET
Perl <strong>Oracle</strong> or ODBC Perl PerlNET
Python <strong>Oracle</strong> or ODBC <strong>Solution</strong> not available
or feasible
Java JDBC <strong>Solution</strong> not available
or feasible
API

30
Envisioning Phase
Optimal Strategy
The factors that need to be considered while deciding a migration strategy are:
●
●
●
●
Business needs. The migration strategy should meet the present and future
needs of the organization.
For example, an organization may need to open its existing application to external
users. Security needs to be implemented <strong>for</strong> the external users. The organization
may select the rewrite strategy.
Technical feasibility. <strong>Migrating</strong> <strong>Oracle</strong> Forms to the Windows plat<strong>for</strong>m may not be
technically feasible. If the new features warrant a lot of change to the current
application, the organization may opt to select rewriting as a strategy.
Time. The time frame within which the migration has to be planned, developed,
tested, and deployed needs to be decided. In addition, the actual time taken in the
migration needs to be minimized to reduce the business risk.
For example, an organization may plan to provide access to its application to the
external users within three months. A quick port to the Windows Services <strong>for</strong> UNIX
plat<strong>for</strong>m may be the best option.
Budget. The budget available needs to be planned. According to the money
available, the infrastructure, human resources, and cost need to be planned.
For example, the direct cost of porting may be lower than the cost of a rewrite.
Also, porting an application minimizes the cost of training, as the same application
is used in the new environment. The indirect cost; such as cost of maintenance,
testing, and retraining, will also be lower.
Set Up a Team
To trans<strong>for</strong>m overall business and design goals into a clear vision <strong>for</strong> the project, an
organization needs to assemble a multidisciplinary team, based on MSF roles, and with
defined skill sets appropriate to the project. These roles are Product Management,
Program Management, Development, Test, User Experience, and Release Management.
Once assembled, this team defines the vision and scope that together provide a clear
direction <strong>for</strong> the project and set expectations within the organization. During the
Envisioning Phase, it is likely that only the lead person or persons <strong>for</strong> each team role will
be determined. During the Planning Phase, the entire team should be assembled if it is
necessary <strong>for</strong> your organization to staff each role with more than one person. More
in<strong>for</strong>mation about the MSF Team Model is available in the UMPG.
Table 2.6 lists each role with its goal and identifies its key functional areas and project
responsibilities <strong>for</strong> an <strong>Oracle</strong> on UNIX to SQL Server on Windows migration project.
Table 2.6: Project Requirements and Responsibilities by Task
Role Project responsibilities and tasks Knowledge and skill
requirements
Product
Management
Role
* Ensure that the team addresses
business goals and customer
requirements
* Manage communications, launch
planning, and feedback with customers
(both internal and external)
Understanding of the
organization's business
priorities and goals
Program * Drive solution design * Project management skills

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 31
Role Project responsibilities and tasks Knowledge and skill
requirements
Management
Role
Development
Role
Development
Functional
Team #1
(Database)
* Manage projects to meet budget and
schedule
* Manage scope and track progress
* Provide process leadership
It is recommended that two teams be
created <strong>for</strong> the Development Role. One
development team should focus on
migrating the database, providing
database administration and support.
The second development team should
focus on migrating the application.
* Ensure that requirements of the
Windows environment are met <strong>for</strong> the
migrated database (<strong>for</strong> example, OS
support <strong>for</strong> amount of memory
required).
* Identify and provide access to shell
and other scripts that are used to
support the database being migrated.
* Migrate user accounts and verifiy that
they have been migrated correctly.
* Install DBMS software and database
applications on servers.
* Create database in SQL Server and
migrate data from <strong>Oracle</strong>.
* Identify the time and order in which
the shell scripts are invoked.
* Design and implement the appropriate
security model <strong>for</strong> migrated databases,
based on analysis of application and
database.
* Identify and resolve issues associated
with Windows security and connectivity.
* Validate that the chosen security
configuration provides at least the same
security levels as the existing
configuration.
* Apply appropriate permissions at the
database object level.
* Work with test groups to build test
environment.
* Work with client development
functional team on issues related to
connectivity between database and
application
* Communication skills
* Adequate knowledge of UNIX
and Windows environments
and of <strong>Oracle</strong> and SQL Server
databases to drive solution
design
* Knowledge of security
configuration <strong>for</strong> current <strong>Oracle</strong>
database and applications
running on UNIX.
* Knowledge of shell and other
scripts used to support the
<strong>Oracle</strong> database.
* Knowledge of cron jobs,
including times and the order
in which scripts are run.
* Understanding of security,
connectivity, software, and
database installation issues in
the Windows environment.
* Understanding of both the
Windows and UNIX
environment.
* Understanding of Network
Library <strong>Oracle</strong> SQL*Net, Net8,
and TCP/IP.
* Understanding of the <strong>Oracle</strong>
schema, tables, views, stored
procedures and triggers.
*Knowledge of SQL Server
and ability to per<strong>for</strong>m all these
tasks in a Windows
environment

32
Envisioning Phase
Role Project responsibilities and tasks Knowledge and skill
requirements
Development
Functional
Team #2
(Application)
User
Experience
Role
Test Role
* Participate in assessment activities <strong>for</strong>
client applications.
* Identify and articulate security
requirements <strong>for</strong> client applications.
* Retarget or migrate existing client
applications.
* Work with test team to ensure
requirements are met and defects are
reduced.
* Work with database team on issues
related to connectivity or other
database-related problems.
* Manage process of gathering,
analyzing, and prioritizing user
requirements.
* Help develop usage scenarios and
use cases.
* Provide feedback on the solution
design.
* Drive the creation of user training
materials.
* Participate in data gathering relevant
to Test during all phases of the project.
* Design and develop the test
environment in conjunction with the
Development functional teams <strong>for</strong>
database and client migrations.
* Maintain ownership of the test
environment.
* Design, create the specification <strong>for</strong>,
and refine the test plan and the user
acceptance test plan.
* Implement and validate the migration
test plan.
Implement test cases.
* Knowledge of <strong>Oracle</strong> client
applications and their security
requirements.
* Proficiency in either Perl,
Python, PHP, Java, Visual
Basic.NET, Windows Services
<strong>for</strong> UNIX, or Windows.
* Experience with technologies
<strong>for</strong> application interoperation
with SQL Server such as
FreeTDS.
* Understanding of stored
procedures, database logic,
and application logic.
* Understanding of connectivity
issues with database.
* Understanding of the
applications being migrated.
* Experience in developing
usage scenarios and use
cases.
* Understanding of training
principles.
* Understanding of the UNIX
and Windows operating
systems (including Windows
Services <strong>for</strong> UNIX, if
appropriate).
* Expertise with <strong>Oracle</strong>
databases, application and
client development.
* Experience with
interoperation between UNIX
and Windows.
* Understanding of tiered
database systems in
homogeneous and
heterogeneous environments.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 33
Role Project responsibilities and tasks Knowledge and skill
requirements
Release
Management
* Act as primary advocate between
project development and operations
groups.
* Manage tool selection <strong>for</strong> release
activities and drive optimizing
automation.
* Set operations criteria <strong>for</strong> release to
production.
* Participate in design, focusing on
manageability, supportability, and in
deployment.
* Drive training <strong>for</strong> operations.
* Drive and set up <strong>for</strong> pilot deployments.
* Plan and manage solution deployment
into production.
* Ensure that stabilization
measurements meet acceptance
criteria.
* Understanding of standard
operational procedures in the
Windows environment.
* Understanding of
applications being migrated.
* Management and
communication skills.
Special Considerations <strong>for</strong> Setting Up Your Migration Team
An <strong>Oracle</strong> on UNIX to SQL Server on Windows migration project can present some
unique issues <strong>for</strong> staffing your project team. Keep the following considerations in mind
when staffing your project team:
● It is relatively easy to find technical staff with a deep knowledge of <strong>Oracle</strong> and
UNIX or SQL and Windows, but it is not easy to find technical staff that has a deep
understanding of all of these areas. Migration involves creating a metaphorical
bridge between the two environments. Make sure you have a senior architect on
the team who understands both worlds deeply enough to engineer the bridge's
creation. If the skill is not available in-house, consider finding a consultant or a
consulting organization with experience in this <strong>for</strong>m of migration. The consulting
organizations often offer services to complete these migration projects end-to-end.
It may be possible <strong>for</strong> you to successfully implement the migration with lowered
risk and reduced cost by engaging a consulting organization. For more in<strong>for</strong>mation
about Microsoft partners that offer <strong>Oracle</strong> to SQL Server migration services, refer
to http://www.microsoft.com/sql/partners/migration.asp
● Ensure that the hardware and infrastructure experts from the Development Role
and Test Role are actively engaged during the Envisioning Phase. The hardware
on which databases and applications are run is commonly overlooked until later in
the project life cycle than it should be. Involving the experts early in the project will
help in<strong>for</strong>m more accurate estimates regarding budget, time, and resources.
● The Test Role should include, if possible, team members who have worked with
the application being migrated. Their experience will help them write better test
cases.
● The User Experience Role should include, if possible, team members who have
worked with the application in the UNIX environment. They should have a good
understanding of the application's user interface so that they will be able to define
and provide the training required <strong>for</strong> end users after the application migration.

34
Envisioning Phase
●
●
●
●
●
Consider including in the Test Role team members who have the expertise to test
the security of the migrated environment. The security of the migrated application
is often overlooked in migration projects.
Migration projects are often undertaken using existing technical staff who have
day-to-day responsibilities which impact their availability. Resources should be
properly planned and allocated to the project to avoid such impact.
Technical staff that has experience with the current application and database
should be involved in the project from design to deployment. Any required training
should be provided to improve their utility in the migration.
Security, hardware, and infrastructure experts from Operations should also be
involved in the Envisioning Phase because they can provide valuable advice about
the technical availability, costs, and the capabilities of the organization.
Because moving from <strong>Oracle</strong> on UNIX to SQL Server on Windows is a major
paradigm shift, it could impact the employment and careers of existing personnel.
This issue should be considered when <strong>for</strong>ming the team and carrying out the
migration. Change is often inevitable and should be perceived as a way to expand
and develop skills.
Define the Project Structure
The project structure defines how the team manages and supports the project and
describes the administrative structure <strong>for</strong> the project team going into the subsequent
project phases.
The main function of the project structure is to define standards the team will use during
the project. These include communication standards, documentation standards, and
change control procedure standards. Program Management takes the lead in defining the
project structure.
Refer to the UNIX Migration Project <strong>Guide</strong> <strong>for</strong> detailed in<strong>for</strong>mation about project structure.
Use the Project Structure document template to assist you in defining and recording the
project structure and protocols <strong>for</strong> the project team. This template is available in theTools
and Templates folder in the zip file download of this guidance at
http://go.microsoft.com/fwlink/?LinkId=45289.
Define Project Communications
Program Management should use the project structure to define standards <strong>for</strong> team
members to communicate with one another. Among these standards can be a definition
of the reporting structure under which team members operate, procedures to elevate
project issues, regular mandated status meetings, and any other project-specific
communication standards that need to be defined during the Envisioning Phase.
The document may also include e-mail names, aliases, telephone lists, mail addresses,
server share names, directory structures, and other in<strong>for</strong>mation critical to team
organization. Consider establishing a team collaboration environment where
communication can occur and progress be monitored and updated as necessary. The
following list of factors needs to be considered <strong>for</strong> most <strong>Oracle</strong> on UNIX to SQL Server
on Windows migration projects.
● The project team will likely include members from the UNIX domain of the IT
department as well as the Windows domain. There are often work-based cultural
differences between members of these two domains. The Program Management
role should ensure that this potential difference is identified and extra attention is
paid to ensure clear communication between the members of the two domains.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 35
●
●
Similarly, the communication tools used by the UNIX and Windows users are often
very different. For example, Windows users use the calendaring features of
Outlook extensively <strong>for</strong> team communication. The UNIX users may be accustomed
to a different set of tools or clients.
Different geographical locations and different cultural backgrounds of team
members involved in the migration ef<strong>for</strong>t can cause communication issues. Extra
attention is required to make sure that there is clear communication between all
team members.
Determine secure methods to share in<strong>for</strong>mation about the project among the team
members. If your team comprises consultants and in-house employees, there may
be corporate policies about what in<strong>for</strong>mation can be shared with outside
consultants.
Define Change Control
Change control standards and tools help to manage both project documents and
components of the solution that are subject to revision or iteration. The requirements
should be clearly defined in the project structure. General in<strong>for</strong>mation about change
control is available in the UMPG.
Migration projects have an additional source of change that is not obvious but must be
managed: the initial state of the technology being migrated. This could be source code <strong>for</strong>
applications, hardware and software configuration, and versions of application software.
Although the initial state can be baselined when the migration project is started,
operational needs may require changes to that configuration while the migration is under
way. These operational changes are typically subject to Configuration Management
standards imposed by an operations team.
The Program Manager Role and Release Manager Role should work with operations
personnel responsible <strong>for</strong> the existing technology to minimize and accommodate these
changes. Long-lived migration projects may require a <strong>for</strong>mal process to connect
operational Configuration Management to project change control. Here are some
additional points to remember:
● The major difference between a migration project and a new development project
is that the initial work has already been per<strong>for</strong>med to create the existing solution.
The existing solution provides a working example of the goals which the solution
must meet.
● Depending on the long term objectives of the project, an existing change control
tool and repository on the UNIX plat<strong>for</strong>m may be migrated to tools in the Windows
plat<strong>for</strong>m.
● As migration involves making modifications to objects currently in production, care
has to be taken in how these objects are shared with the new development ef<strong>for</strong>t.
As changes are discovered, there is the danger of modifying an object in the
production thread. Creation of a separate project is recommended. In this situation,
any changes made to the production thread should also be applied to the
development (migration) thread. Appropriate controls have to put in place to handle
this.

36
Envisioning Phase
Configuration Management
A major task in any database migration is the trans<strong>for</strong>mation of database objects, such as
sequences and code within the database, including stored procedures. These
trans<strong>for</strong>mations inherently change the source code. To maintain a known state as work
progresses towards migration, two aspects of Configuration Management have to be
addressed:
● As discussed earlier, any change to the original environment after the baseline is
created needs to be communicated to the project team and accounted <strong>for</strong>. Change
management in the area of configuration becomes critical if problems are
encountered during the migration and you are <strong>for</strong>ced to return production to the
pre-migration environment.
● Any changes to the solution that occur during the Developing Phase and
Stabilizing Phase need to be documented and communicated to the entire project
team.
During the Stabilizing Phase, knowledge of and control over the test environment
configuration is critical to understanding the results that are received. If documentation
exists identifying the aspects that have changed, the results of a given test can be
validated against both current and future results.
Some points to remember include:
● Every configuration change should have a fallback or rollback path.
● Configuration management tools, such as bug tracking software, should be able to
operate within the Windows environment.
Assess Risk
MSF stresses assessing project risk continuously throughout a project and makes this
the responsibility of every team member. Risk is defined as the possibility of suffering a
loss or, more specifically, the possibility of a negative outcome that can put the project in
peril. The team comes up with an initial set of risks in the Envisioning Phase. This list is
constantly updated in later phases of the project as new risks begin to appear and old
ones start to lose relevance. It is important to understand that in a migration project
issues are sometimes hidden, <strong>for</strong> example, in the design or implementation of a piece of
code, which will appear only as the solution is being trans<strong>for</strong>med. Here are some
questions that you need to ask to understand the potential high level risks at the start of
the project. These questions can help you generate the risk assessment list that can
serve as the basis <strong>for</strong> your ongoing risk assessment and management <strong>for</strong> the project.
● Are the project sponsors and stakeholders committed to support the project?
● Does the migration team have the aggregate skill set to per<strong>for</strong>m the migration?
● Are the project team members adequately motivated to per<strong>for</strong>m their role in the
project?
● What will the impact on the business be if there is a delay in the project
completion?
● Do you understand the real problems of the business and users that the project is
meant to address?
● Have you accounted any possible temporary decrease in productivity due to
distractions <strong>for</strong> the project staff from their daily duties to support the migration
project or while the customers learn to use the new application?

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 37
●
●
●
●
●
●
●
●
For the application suite to be migrated, do the vendors of any third-party
applications provide technical support in the new environment?
Is the application dependent on third-party software that is not compatible with
Windows?
Does the existing <strong>Oracle</strong> database contain technologies that SQL Server cannot
directly implement?
Have you fully considered the impact of the migration on other systems or
applications that currently rely on or interact with the existing solution?
Does documentation exist <strong>for</strong> all the applications and databases, such as
requirements, models (logical, physical), and source code?
How will you handle possibly unproductive situations from staff members (technical
and operational) who could be displaced by the migration?
How will you handle possible scope creep in the migration project?
Have you considered the impact of the migrated application failing to meet one or
more functional requirements?
Manage Risks
A good way to manage risks is to identify or anticipate potential risks be<strong>for</strong>ehand and
come up with a good mitigation and prevention strategy to deal with them in case they
occur. The list of potential risks <strong>for</strong> a project is likely to be long, and not all potential risks
can be given the same amount of attention over the course of the project. It is there<strong>for</strong>e
imperative to prioritize all the risks. This allows the team to focus more on the high priority
risks, come up with suitable mitigation plans to prevent them from happening, and create
contingency plans to deal with them effectively if they materialize.
This solution guide provides a risk assessment spreadsheet <strong>for</strong> you to monitor your
project risks based on this methodology.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 39
3
Planning Phase
Introduction and Goals
In the Planning Phase, the team defines the solution in detail — what to build, how to
build it, who will build it, and when it will be built. During this phase, the initial vision and
solution concept defined in the Envisioning Phase is translated into practical
implementation designs and plans <strong>for</strong> how to achieve it. Team members draw upon their
expertise to create individual plans and designs in all areas of the project, ranging from
security to budget to deployment. Likewise, individual team schedules and associated
dependencies are identified. These plans and schedules are rolled into a master project
plan by the Program Management Role.
The phase concludes when the project team agrees that the plans are sufficiently welldefined
to proceed with development, and the team, business sponsor, and key
stakeholders approve the functional specification and the master project plan and
schedule, usually at a milestone meeting. The <strong>for</strong>mal conclusion is marked by the second
major project milestone, Project Plans Approved.
The key deliverables <strong>for</strong> the project team <strong>for</strong> the Planning Phase are:
● Functional specification. The functional specification is the virtual repository of
project and design related artifacts that are created in the Planning Phase. The
artifacts are primarily a result of design activities during the conceptual design,
logical design, and physical design processes of the Planning Phase. The artifacts
can include models such as case diagrams, usage scenarios, feature list, user
interface screen shots, database design, and so on.
The key goals of the functional specification are to consolidate a common
understanding of the business, design, and user requirements; break down the
problem and modularize the solution logically; provide a framework to plan,
schedule, and build the solution; and to serve as a contract between the team and
the customer and stakeholders.
● Master project plan. The master project plan is a collection of individual plans that
address tasks per<strong>for</strong>med by each of the six team roles to achieve the functionality
defined in the functional specification. The master project plan documents the
strategies the team roles will use to complete their work. The solution concept that
the team developed in the Envisioning Phase provides high-level approaches that
are developed into detailed plans in the Planning Phase. See Chapter 2,
"Envisioning Phase," <strong>for</strong> the discussion of team roles.
● Master project schedule. The individual team schedules apply a time frame to the
master plan. The master project schedule synchronizes project schedules across

40
Planning Phase
●
the teams. Aggregating the individual schedules gives the team an overall view of
the project schedule and is the first step toward determining a fixed ship date.
Updated master risk assessment document. The master risk assessment
document that was developed during the Envisioning Phase is reviewed and
updated regularly during the Planning Phase.
All of these deliverables are living documents, evolving as the project progresses.
Though these documents can be modified, modifications must follow the change
management policies set up <strong>for</strong> the project during the Envisioning Phase.
Table 3.1 lists the key activities that the team undertakes in the Planning Phase. The
results of these activities are documented in this phase's deliverables.
Table 3.1: Major Tasks, Deliverables, Owners, and Job Aids
Tasks
Deliverable
where results
are documented
Primary owner
Job Aids
provided in this
solution
Complete detailed
assessment of the
current environment
Functional
specification
Program
Management
Assessing the
Environment
Questionnaire
Develop the
solution design and
architecture
Functional
specification
Program
Management
Validate the
technology
Develop the project
plans
Functional
specification
Master project plan
Development
Team leads <strong>for</strong> all
roles; plans
consolidated by
Program Manager
* Development Plan
* Test Plan
* Deployment Plan
* Pilot Plan
Create the project
schedules
Set up the
development and
test environments
Reassess current
project risks
Master project
schedule
Risk assessment
document
Team leads <strong>for</strong> all
roles
Development and
Test
Program
Management
Migration Risk
Exposure Rating
Form
Complete a Detailed Assessment of the Existing
Environment
To begin the migration process, an accurate and detailed assessment of the existing
environment of your organization is essential. A high level assessment is carried out in
the Envisioning Phase. The detailed assessment in the Planning Phase is a follow up
activity.
The in<strong>for</strong>mation collected by this assessment should be comprehensive enough to plan
the specific details of the solution migration. For instance, a detailed assessment of the
application will provide definitive in<strong>for</strong>mation on whether existing test plans can be reused

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 41
to test the solution. Without this detailed in<strong>for</strong>mation about the existing environment,
there is no way to accurately estimate the development, test, or deployment plans.
The key elements of the environment that need to be assessed in detail include:
●
●
●
Application
Database
Application infrastructure
Refer to the Assessing the Environment Questionnaire job aid to help you assess the
main areas of the environment.
Application
A detailed assessment should be per<strong>for</strong>med <strong>for</strong> any application that is affected by the
migration. A database application migration project assessment should not be limited to
assessing the application alone; it should also include database connectivity.
Assessment activities related to the database should include the following:
● Note all database interfaces used by the applications and their types (OCI, ODBC,
and so on).
● Note the relationship between applications and databases. For example, note if a
database supports multiple applications, or an application connects to multiple
databases.
● Identify all the database, schemas, and schema objects that the application
interacts with.
● Note the protocol that is used by the application to communicate with the
database. <strong>Oracle</strong> supports TCP/IP, TCP/IP with SSL, and named pipes.
● Identify all encryption methods employed by the applications with the databases.
● Identify the security features of the database used by the applications, such as
authentication, password features, single sign on, and so on.
● Determine if there are any other network-related security authentication methods
used with the current application. Common <strong>Oracle</strong> authentication methods include
Kerberos, Radius, DES Algorithm, RSA, and Cybersafe.
● Note the data sources in use, such as ODBC, OLE DB, and ADO.
In addition to questions related to database connectivity, here are some general
application assessment questions that you may need to ask.
● Identify the programming language used <strong>for</strong> the main application as well as any
supplementary programs.
● Identify the plat<strong>for</strong>m support (hardware and operating system), architecture, and
component interfaces of the existing application.
● Locate any existing in<strong>for</strong>mation about the application. Is the source code
available? Other items that may help plan <strong>for</strong> migration include test scripts,
documentation, process flow charts, and use cases.
● Record any dependencies and characteristics, such as third-party libraries, UNIX
utilities, or path names. Also, determine if the UNIX application uses X Windows,
Motif, or xrt libraries.
● Determine the security architecture of the application. This in<strong>for</strong>mation is important
because features and implementations are different between Microsoft Windows®
and UNIX plat<strong>for</strong>ms.
● Record any encryption protocols currently being used. SSL and PGP are two
common encryption methods.

42
Planning Phase
●
●
Verify if the application uses daemon processes. This in<strong>for</strong>mation is required
because UNIX applications can be started in the background and will continue to
run even after a user logs off the system. Using application services in Windows
2003 provides similar functionality.
Check <strong>for</strong> any file system dependencies. This in<strong>for</strong>mation is required because
UNIX and Windows use different file access methods.
For more in<strong>for</strong>mation on assessing the application be<strong>for</strong>e migrating from UNIX to
Windows, refer to the UNIX Application Migration <strong>Guide</strong>, available at
http://go.microsoft.com/fwlink/?LinkId=30832.
Database
To migrate an <strong>Oracle</strong> database to Microsoft SQL Server successfully, the project team
must assess the technical details of the current system.
The following assessment activities should be per<strong>for</strong>med on the existing <strong>Oracle</strong>
database:
● Identify and record the database name and all configuration in<strong>for</strong>mation.
● Determine the type of database being used. Common database types include
Decision Support System (DSS), Online Transaction Processing (OLTP), or a
combination of the two.
● Locate any existing design documents, such as data models, database creation
scripts, or data definition language (DDL) specifications.
● Record detailed in<strong>for</strong>mation on existing database structures, including tables,
views, stored procedures, indexes, users, and roles.
● Identify and record the current location of database files, such as Storage Area
Network (SAN), Network Attached Storage (NAS), or local attached storage.
● Identify and record the disk space consumed by the existing database files. Also,
obtain estimates of growth rate of the database files.
● Evaluate the existing backup solution, including the frequency and type of backup
(full, archive log, and so on).
● Assess the database configuration in<strong>for</strong>mation, including the sort order and
character set.
● Examine the frequency of data dumps and log dumps.
● Determine the dependencies of the database on other databases or plat<strong>for</strong>ms.
Common examples include distributed databases, replication, data marts, and data
warehouses.
● Identify and analyze the server side scripts in use <strong>for</strong> activities such as data loads,
batch processing, reporting, and administration.
The Migration Analyzer tool, which is a part of the SQL Server Migration Assistant
(SSMA), analyzes the source <strong>Oracle</strong> databases and produces vital statistics on the size
and complexity of the migration. This tool can be downloaded from
http://www.microsoft.com/sql/migration. The beta version of this tool is available as of the
date of publishing this solution. Version 1.0 of the tool is slated to be available in June
2005
Application Infrastructure
The application infrastructure can be broadly classified as server-related and networkrelated.
Server-related infrastructure relates directly to the hardware and software on the
server. Server-related items include operating systems, processors, memory, storage,

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 43
tape drives, and file systems. Examples of network-related infrastructure include routers,
firewalls, switches, domain name servers (DNS), and virtual private networks (VPN).
Security infrastructure is classified under both server-related and network-related
infrastructure. Common items within the server security infrastructure are Network
In<strong>for</strong>mation Services (NIS and NIS+) and Lightweight Directory Access Protocol (LDAP).
The following assessment activities should be per<strong>for</strong>med <strong>for</strong> server-related infrastructure:
●
●
●
●
Check the capacity and per<strong>for</strong>mance of the servers and server clusters of the
existing environment. Also verify if the clusters are situated in single or multiple
locations.
The hardware configuration details need to be gathered <strong>for</strong> any dependencies that
might affect the migration, including architecture (32-bit versus 64-bit, hyperthreading,
hybrid), processor speed, number of CPUs, and the number of available
sockets <strong>for</strong> upgrades.
Record any pertinent in<strong>for</strong>mation about the RAM installed in the server, including
size, configuration, and number of open slots available <strong>for</strong> upgrades.
Verify disk storage needs <strong>for</strong> database files and the disk space consumed <strong>for</strong> the
existing database files. Identify the storage requirements, such as:
● Amount of space needed <strong>for</strong> current and growth factors
● Spindle RPM (disks: 15000 RPM versus 10000 RPM; SAN: 1 gbps versus 2
gbps)
● Throughput (theoretical I/O, current I/O, anticipated I/O) <strong>for</strong> each element of
the storage system
● Disk size(s)
● RAID levels
● Storage Architecture (SAN, NAS, external storage, internal storage)
The following assessment activities should be per<strong>for</strong>med <strong>for</strong> network-related
infrastructure:
● Identify the existing network protocols and network bandwidth.
● Examine the routers, switches, and firewalls <strong>for</strong> the existing solution. Verify the
configuration and location of firewalls and proxies.
● Assess the network topology that exists in the organization.
● In<strong>for</strong>mation about the network infrastructure needs to be identified, including the
logical organization of the network, name and address resolution methods, and
network naming conventions.
● Analyze the network sites and the bandwidth between the sites. This in<strong>for</strong>mation
can be used to plan optimum strategies and schedules <strong>for</strong> installation and
deployment.
● Assess the trust relationships and policy restrictions of the existing solution.
Develop the <strong>Solution</strong> Design and Architecture
The Planning Phase of the MSF Process Model includes three design processes:
conceptual, logical, and physical. These three processes are not per<strong>for</strong>med in parallel.
Instead, their starting and ending points are staggered. These processes are dependent
on each other. The logical design is dependent on the conceptual design, and the
physical design is dependent on the logical design. Table 3.2 compares the three design
processes.

44
Planning Phase
Table 3.2: Comparing Conceptual, Logical, and Physical Design
Type of Design Perspective Purpose
Conceptual Design
Logical Design
Physical Design
Views the problem from the
perspective of the user and
business
Views the solution from the
perspective of the
design/architecture team
Views the solution from the
perspective of the
developers
Defines the problem and
solution in terms of usage
scenarios and refined
requirements
Defines the solution as a
logical set of co-operating
objects and services
Defines the solution
components and
technologies
In a migration project it is quite likely that you already have detailed design documents <strong>for</strong>
the existing system. These documents can provide an excellent starting point <strong>for</strong> your
design process. Enhancements can be made to account <strong>for</strong> the additional requirements
and functionality <strong>for</strong> the new system.
Build the Conceptual Design
The first design process in the Planning Phase is conceptual design. Once completed,
the conceptual design is used in the creation of the logical and physical design
processes.
Conceptual design is the process of gathering, analyzing, and prioritizing business and
user perspectives of the problem and the solution, and then creating a high level
representation of the solution in the <strong>for</strong>m of detailed requirements. The team gathers high
level requirements during the Envisioning Phase and documents them in the <strong>for</strong>m of use
cases and usage scenarios. While producing the conceptual design, the team refines
these requirements.
Develop Detailed Requirements
A conceptual design records the system requirements in terms of the following
requirements:
● Business requirements
● User requirements
● System requirements
● Operational requirements
Each of these is described under the following headings
Business Requirements
Business requirements describe the organization's needs and expectations <strong>for</strong> the
solution. These requirements exist at the managerial decision-making level and provide
the context in which the solution will operate.
Some example business requirements include:
● The database migration from UNIX to Windows should be completed in the given
time frame.
● The existing business rules and policies should be maintained on the new system.
● Ef<strong>for</strong>t required <strong>for</strong> migration should justify the cost incurred.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 45
●
The existing level of per<strong>for</strong>mance and functionality should be maintained after the
migration, including disaster recovery, availability, and scalability.
User Requirements
User requirements define the nonfunctional aspect of the user's interaction with the
solution. They help you to determine the user interface and per<strong>for</strong>mance expectations of
the solution in terms of its reliability, availability, and accessibility. In addition, the user
requirements help you identify the training that the users will need to effectively use the
solution.
Some example user requirements include:
●
●
●
The user should be able to use the same or similar interface as the application
running on the UNIX system to minimize user retraining.
The time taken to retrieve in<strong>for</strong>mation from the system should not increase.
There should be comprehensive user manuals <strong>for</strong> the new system. Training
manuals should also be considered <strong>for</strong> new users.
System Requirements
System requirements specify the detailed transactions and their sequence in the system.
The requirements help the project team define how the new solution will interact with the
existing systems. Some example system requirements include:
●
●
●
After the migration, the new system should continue to interoperate with
applications as it did on the UNIX plat<strong>for</strong>m.
The system should not require a user credential other than the credentials passed
from logging onto the corporate network (single sign on).
The system should support internal and remote users.
Operational Requirements
Operational requirements describe what the solution must deliver to maximize operability
and improve service delivery with reduced downtime and risks. Some example
operational requirements include:
●
●
●
●
●
The system should allow administrators to per<strong>for</strong>m their tasks both on-site and
remotely.
The system should be able to recover from critical failure without major impact and
within service levels.
The system should include a process <strong>for</strong> managing the total throughput and
response time within the stated service levels.
The system should be able to handle varying levels of user load and transactions.
In addition, the site should be designed so that it can be modified and upgraded
without affecting availability and per<strong>for</strong>mance.
Large clients should be separated with respect to database infrastructure to
minimize the impact on maintenance and availability.
Build the Logical Design
The logical design is the second step in creating the solution design. After identifying the
business and user needs in the conceptual design, the logical design defines how the
different parts of the solution will coordinate and work together. The logical design
defines the parts of the system, provides a framework to hold all the parts of the system
together, and illustrates how the system interacts with the users and other systems.

46
Planning Phase
While creating the logical design, the team takes into account all the business, user,
operational and system requirements that state the need <strong>for</strong> security, auditing, logging,
scalability, state management, error handling, licensing, globalization, application
architecture, integration with other systems, and so on.
There are several ways to represent the logical design of a system. A commonly used
visual modeling language is Unified Modeling Language (UML). A detailed discussion of
UML is out of the scope of this solution. For more in<strong>for</strong>mation on UML, refer to The
Unified Modeling Language User <strong>Guide</strong> (Booch, Jacobson, and Rumbaugh 1999) and
Use Case Driven Object Modeling with UML: A Practical Approach (Rosenberg and Scott
1999).
Figure 3.1 shows a sample logical design <strong>for</strong> a system using the Logical Object Model, as
defined by UML. The sample design represents the system in terms of:
● Objects. These are people or things in the system. "Order" is an example of an
object in Figure 3.1.
● Services. These are the behavior or functionality associated with any object. For
example, "Track Status()" is a service provided by the "Order" object in Figure 3.1.
● Attributes. These are characteristics or properties of the objects. For example,
"Order ID" and "Ship Date" are attributes of the "Order" object in Figure 3.1
● Relationships. These represent ways in which objects are linked with each other.
For example, the object Order and the object Order line item are shown to have an
associative relationship in Figure 3.1 by a thick line. This shows that they are
related and a change to one affects the other.
The objects, services, attributes and relationships can be obtained from the detailed
usage scenarios that were developed in the conceptual design phase.
The logical design represents a logical view of the complete system. Individual teams,
such as those <strong>for</strong> User Interface (UI) development, the database development, and the
application development can take this representation and start to build the detailed
designs <strong>for</strong> their domain when making the physical design.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 47
Figure 3.1
Creating a logical design <strong>for</strong> the application
Logical Design Considerations
The logical design <strong>for</strong> an <strong>Oracle</strong> database migration project must take into account the
changes that will occur as a result of migration from <strong>Oracle</strong> to SQL Server. The following
items should be considered:
● Are there any dependencies between client applications and database
connectivity?
● Do UNIX scripts support the client applications?
● How are communications between the application and database secured internally
and over the internet?
● How is data distributed across multiple databases and multiple servers?

48
Planning Phase
Examining the conceptual design of the client application will provide an understanding of
how it operates and is structured. This in<strong>for</strong>mation is used to create the physical design
of the solution. Two additional design studies that may assist in creating the physical
design are discussed in the following section.
High Level User Interface and Database Design
Using the objects, services, attributes, and relationships identified in the logical design of
the system, the team might decide to create a high-level user interface and database
design.
The list of objects and services gives the team an idea about the kind of functionality
expected by the users. The team can use this in<strong>for</strong>mation to design user interface
elements such as buttons, text fields, and menu items.
Similarly, the object and attribute in<strong>for</strong>mation of the logical design can be used to develop
an initial database design equivalent to the <strong>Oracle</strong> database being migrated.
Build the Physical Design
Physical design is the process of describing the components, services, and technologies
of the solution from the perspective of the development team. The goal of the design is to
provide clarity and detail <strong>for</strong> each of the development teams to develop their components,
be it the user interface, business logic, database, or infrastructure.
The physical design should include:
● Class definition of applications.
● Database schema <strong>for</strong> the solution.
● Baseline deployment model that provides:
● The network topology, showing hardware locations and interconnections.
● The data and component technology, which indicates the locations of the
solution components, services, and data storage in relation to the network
topology.
●
●
Component specifications that include internal structure of components and
component interfaces.
Programming models that identify implementation guidelines <strong>for</strong> threading, error
handling, security, and code documentation.
A detailed discussion of physical design is out of scope of this solution. For detailed
guidance on designing the data layer, designing the presentation layer, and designing the
security specifications, refer to chapters 7 through 9 of Analyzing Requirements and
Defining Microsoft .NET <strong>Solution</strong> Architectures (Microsoft Press 2003).
The physical design diagram allows you to see how all the components connect together.
For completeness, it may include infrastructure elements outside of the scope of the
project such as firewalls or network connections that are not directly related to the
solution. It will help prove the security of the system, and may show potential throughput
bottlenecks, or highlight single points of failure.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 49
Figure 3.2 shows a sample physical design diagram. Your design considerations will
require you to modify this example.
Figure 3.2
Creating a physical design <strong>for</strong> the application and database.
The following sections will help you plan <strong>for</strong> a migration by identifying the various
components of the physical design and outlining the typical design considerations that
are part of a typical migration.

50
Planning Phase
Incorporate Design Considerations
While migrating, you may want to utilize some of the advanced functions that are
incorporated into SQL Server and Windows Server 2003. Some references may exist
<strong>for</strong> Windows® 2000 but the in<strong>for</strong>mation also applies to Windows Server 2003. For more
in<strong>for</strong>mation, refer to the following resources:
● Designing <strong>for</strong> scalability
http://msdn.microsoft.com/library/default.asp?url=/library/enus/architec/8_ar_sa2_8rnd.asp
● Designing <strong>for</strong> availability
http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/ssmsam.mspx
● Designing <strong>for</strong> reliability
http://www.microsoft.com/mscorp/twc/reliability/default.mspx
● Designing <strong>for</strong> per<strong>for</strong>mance
http://www.microsoft.com/sql/evaluation/compare/benchmarks.asp
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ansvcspg.mspx
● Designing <strong>for</strong> interoperability
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/sqlorcle.mspx
Hardware Design Considerations
In addition to the advanced features available in SQL Server, there are many software
tools available to assist in ensuring that the correct hardware is acquired. Some of these
tools are listed here:
● Microsoft Datasizer Tool. This spreadsheet helps estimate table sizes. For more
in<strong>for</strong>mation, refer to
http://www.microsoft.com/downloads/details.aspx?FamilyId=564C5704-D4F5-
4EE8-9F3C-CB429499D075&displaylang=en.
● Dell Powermatch sizing tools. These tools are available to assist in selecting Dell
hardware <strong>for</strong> use with SQL Server. For more in<strong>for</strong>mation, refer to
http://www1.us.dell.com/content/topics/global.aspx/alliances/en/sizing?c=us&cs=5
55&l=en&s=biz.
● HP sizing tools. These tools are available to assist in selecting HP servers <strong>for</strong> use
with SQL Server. For more in<strong>for</strong>mation, refer to
http://h71019.www7.hp.com/ActiveAnswers/cache/70729-0-0-0-121.aspx.
● Unisys System Sizing Tools <strong>for</strong> SQL Server. These tools are available to assist
in configuring Unisys servers <strong>for</strong> use with SQL Server. For more in<strong>for</strong>mation, refer
to
http://unisys.com/products/es7000__servers/business__solutions/oltp__database_
_server/sql__server__resources.htm.
Validate the Technology
Parallel to the design process, the team will often validate the technologies being used in
the solution. During technology validation, the team evaluates the products or
technologies to ensure that they work according to specifications provided by their vendor
and that they will meet the business needs <strong>for</strong> the specific solution scenario.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 51
SQL Server Editions and Features
While <strong>Oracle</strong> is available in Personal, Standard, and Enterprise Editions,
SQL Server 2000 is available in the following editions:
● SQL Server 2000 Enterprise Edition (64-bit)
● SQL Server 2000 Enterprise Edition
● SQL Server 2000 Standard Edition
● SQL Server 2000 Developer Edition
All editions of Windows® XP and Windows Server 2003 include support <strong>for</strong> SQL Server.
Support exists <strong>for</strong> many earlier versions of Windows, as well.
As with <strong>Oracle</strong>, each edition is distinguished primarily by the availability of certain
features, progressing from Personal Edition to Enterprise Edition. SQL Server also offers
several different editions. Each edition provides functionality based on scale as shown in
Table 3.3.
Table 3.3: SQL Server 2000 Editions Compared
OS
Requirements
and Scalability
Operating System
Enterprise (64-
bit) Edition
* Windows Server
2003 Enterprise
Edition
* Windows Server
2003 Datacenter
Edition
Scalability * Up to 64
processors
* Up to 512 GB of
memory
* Maximum
database size of
1,048,516 TB
Enterprise
Edition
* Windows Server
2003 Standard
Edition
* Windows Server
2003 Enterprise
Edition
* Windows Server
2003 Datacenter
Edition
* Up to 32
processors
* Up to 64 GB of
memory
* Maximum
database size of
1,048,516 TB
Standard Edition
* Windows Server
2003 Standard
Edition
* Windows Server
2003 Enterprise
Edition
* Windows Server
2003 Datacenter
Edition
* Up to 4
processors
* Up to 2 GB of
memory
* Maximum
database size of
1,048,516 TB
For a detailed preview of all the SQL Server features and supporting tools, refer to
http://www.microsoft.com/sql/evaluation/features/byfunction/default.asp.
For in<strong>for</strong>mation on features by edition, refer to
http://www.microsoft.com/sql/evaluation/features/choosing.asp.
While migrating to SQL Server, the choice of edition of SQL Server that is required to
support the demands on the database has to be validated. Refer to the following
resource <strong>for</strong> a whitepaper that can aid in choosing the appropriate edition of SQL Server:
http://www.microsoft.com/sql/techinfo/planning/SQLReskChooseEd.asp.

52
Planning Phase
Windows Server 2003
Windows Server 2003 is available in the following editions:
●
●
●
●
Windows Server 2003, Standard Edition. For departmental and standard corporate
workloads.
Windows Server 2003, Enterprise Edition. For critical or heavy server workloads.
Windows Server 2003, Datacenter Edition. For high levels of scalability and
reliability.
Windows Server 2003, Web Edition. For Web serving and hosting.
The goals of the Windows Server System are to promote operational efficiencies through
simplified deployment, management, and security; to ensure high levels of dependability,
per<strong>for</strong>mance, and productivity <strong>for</strong> application development; and to seamlessly connect
in<strong>for</strong>mation, people, and systems.
For more in<strong>for</strong>mation on the different editions of Windows Server 2003, refer to
http://www.microsoft.com/windowsserver2003/evaluation/features/compareeditions.mspx.
Technical Proof of Concept
After validating the technologies, the team creates a prototype project using a small
database that contains a representative sample of the data, tables, and other objects
found in the production databases. This process will validate the approach <strong>for</strong> the
migration and provide useful experience when using the various tools that have been
selected.
This prototype can also be used as a basis <strong>for</strong> a proof of concept, and ultimately the
development of the solution itself. This initial proof-of-concept model often produces both
answers and additional questions <strong>for</strong> the team. This in<strong>for</strong>mation helps in the risk
management process and identifies changes needed to the overall design that must be
incorporated into the specifications.
Here are some candidates <strong>for</strong> the proof of concept that are typically part of this type of
migration:
● Per<strong>for</strong>mance of binary large objects (BLOB) in storing, accessing, and updating
based on differences in their storage architecture between SQL Server and <strong>Oracle</strong>.
● Migration of sequences. Sequences are not supported by SQL Server, but the
functionality can be duplicated.
● Replacing reverse key indexes in <strong>Oracle</strong> with regular indexes in SQL Server.
● Converting <strong>Oracle</strong> packages to SQL Server stored procedures.
● Recreating <strong>Oracle</strong>'s profiles (resource and password) functionality using Windows
security.
● Developing Windows auditing functions to replace specific <strong>Oracle</strong> functionality
(session, privilege, and object auditing).

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 53
Develop the Project Plans
The solution design that was created in the Envisioning Phase is used as the baseline
while creating the project plan. The project plan also needs to consider the key success
criteria identified in Chapter 2, "Envisioning Phase." The project plans include:
● Development plan
● Stabilization plan (includes test plan and pilot plan)
● Deployment plan
● Operations plan
● Budget plan
● Training plan
In addition to the above plans, a training checklist needs to be created that will identify
the existing and required skills. This will help you to plan the training that needs to be
provided when you do the work described in Chapter 20, "Operations."
The development plan, test plan, and deployment plan are covered in detail under the
following headings.
Development Plan
The development plan describes different aspects of the development endeavor, such as
tools required, methodologies and practices to be followed, schedule of events, and
resources. The primary tasks of the development plan include:
● Defining team roles
● Identifying team, hardware, and software resources
● Providing training to the team members
Refer to the development plan template provided with this solution to assist in creating
your development plan.
In general, it is recommended that the elements described in the following sections be
included in a development plan.
Development Objectives
These define the primary drivers that were used to create the development approach and
the key objectives of that approach. The development objectives <strong>for</strong> a migration project
differ from that of a new development. Most commonly, the key objectives are to:
● Migrate the application with the least amount of change.
● Create a SQL Server database which is almost identical in design and
implementation to the source <strong>Oracle</strong> database.
● Migrate the entire solution to a Windows and SQL Server environment with the
least amount of change.
Migration List
This provides a detailed listing of the applications and databases that need to be
migrated as part of the current project.

54
Planning Phase
Overall Delivery Strategy
This describes the overall approach to delivering the solution. Examples of delivery
strategy include staged delivery, depth-first, breadth-first, and features-then-per<strong>for</strong>mance.
In migrations, the solution already exists and the delivery strategy consists of deploying
the replacement solution.
Tradeoff Approach
This defines the approach <strong>for</strong> making design and implementation tradeoff decisions. For
example, you might agree to trade features <strong>for</strong> schedule improvements, or to trade
features <strong>for</strong> per<strong>for</strong>mance.
Key Design Goals
These identify the key design goals and the priority of each goal. Examples of design
goals in a migration include interoperability between a UNIX application and the
SQL Server database or rewriting the application using the .NET framework.
Development and Build Environment
This describes the development and build environment and how it will be managed.
Include in<strong>for</strong>mation on items such as source code control tools, design tool requirements,
operating systems, or other software installed. If a development environment <strong>for</strong> the
existing application does not exist, it will need to be created. This situation is common
when the development of the applications to be migrated was originally outsourced.
Development Tools
These tools are used to assist in the development and test environments. For a detailed
discussion of tools, see the "Set Up the Development and Test Environment" section
later in this chapter.
<strong>Guide</strong>lines and Standards
These list and provide references to all standards and guidelines to be used <strong>for</strong> the
project. Standards and best practices could differ substantially from the current
<strong>Oracle</strong>/UNIX environment. However, applying new standards will require a tremendous
rewrite, which could greatly affect the migration timeline. It is recommended that such
standards be applied only to the components that are being rewritten or modified.
Versioning and Source Control
This describes how versioning and source control will be managed. This section includes
identification of the specific tools that will be used and how developers are expected to
use them. Most source control tools work with code irrespective of plat<strong>for</strong>m. Due to the
change in operating systems, new software may need to be acquired. For instance, if
CVS or any other source control software is currently used in the UNIX environment,
consideration should be given to migrating these functions to a Windows-based
alternative, such as Visual Source Safe.
Build Process
This describes the incremental and iterative approach <strong>for</strong> developing code and <strong>for</strong> builds
of hardware and software components. It also describes how the build process will be
implemented and how often it will be implemented.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 55
Components
This provides a high-level description of the set of solution components and how they will
be migrated. In a migration project, most of the solution components should already exist.
Configuration and Development Management Tools
This identifies all the development tools the team will use during the project. This includes
tools <strong>for</strong> all steps in the project: development, testing, documentation, support,
operations, and deployment.
Design Patterns
This identifies the design patterns or templates that the team will use <strong>for</strong> this project and
their sources. The team can acquire design patterns from both external and internal
sources or create new design patterns. This in<strong>for</strong>mation will only be necessary in
development plans that involve rewriting the application.
Development Team Training
This identifies the training necessary to ensure that the development team will
successfully develop the solution. This is a critical necessity in migrations because it is
not common to already have personnel in place that can adequately support both <strong>Oracle</strong>
and SQL Server environments.
Development Team Support
This identifies the various types of support the development team will require, the
sources of that support, the amount of support of each type that the team will require, and
the estimated schedule <strong>for</strong> support. Support may not exist <strong>for</strong> the target Windows
environment, and may need to be developed.
Stabilizing Phase Plans
During the Stabilizing Phase, the testing team conducts tests on a solution whose
features are complete. Testing during this phase emphasizes usage and operation under
realistic environmental conditions. The team focuses on resolving and prioritizing bugs
and preparing the solution <strong>for</strong> release.
During the Planning Phase, the team typically creates the following plans that will be
used during the Stabilizing Phase:
● The test plan
● The pilot plan
Test Plan
The test plan describes the strategy and approach used to plan, organize, and manage
the project’s testing activities. It identifies testing objectives, methodologies and tools,
expected results, responsibilities, and resource requirements. This document is the
primary plan <strong>for</strong> the testing team. A test plan ensures that the testing process will be
conducted in a thorough and organized manner and will enable the team to determine the
stability of the solution. A continuous understanding of the solution’s status builds
confidence in team members and stakeholders as the solution is developed and
stabilized.
The Test Role in the MSF Team Model is responsible <strong>for</strong> creating the test plan. This team
is also responsible <strong>for</strong> setting the quality expectations and incorporating them into the

56
Planning Phase
testing plan. This template is available in the Tools and Templates folder in the zip file
download of this guidance at http://go.microsoft.com/fwlink/?LinkId=45289.
The key sections of a test plan include:
Forms of Testing to Be Per<strong>for</strong>med
These include:
● Code component testing
In a migration, the scope of changes made to the existing application varies from
minor connection string changes to a complete application rewrite. The goal of
testing is to ensure that any component modified matches the original features and
functionality. Instead of basing the test results on a series of requirements, the
existing application can be used as a basis <strong>for</strong> comparison.
● Database testing
This includes:
● Physical architecture of database. Have the data files, transaction logs, and
other components that comprise the database been created correctly?
● Logical architecture of the database. Have the tables, views, stored
procedures, triggers, and other database objects been created successfully?
● Data. Have the contents of the tables been transferred correctly? Do tables
contain the correct number of rows? Is the data valid?
● Functionality. Do the stored procedures, triggers, views, and other items
comprising T-SQL code operate in the same manner as the original <strong>Oracle</strong>
objects?
● Per<strong>for</strong>mance. Do the response times and throughput meet requirements and
match user expectations?
●
●
●
●
●
Infrastructure testing
Infrastructure testing ncludes the development and production environments, as
well as hardware, software, monitoring software, network, backup strategies, and
disaster recovery plans.
Security testing
There are two levels of security testing, network level and application level, that
should be tested:
● Network level. Test access and privileges
● Application level. Ensure that the correct users and permission levels exist in
the application and database.
Integration testing
If the solution is deployed in phases, then test the integration of each phase. Each
incarnation needs to be tested <strong>for</strong> acceptable integration with other components.
User acceptance and usability testing
These tests can often be recreated from the original design solution. The migration
should meet the same goals as the existing solution. Any new or modified
functionality should also be tested.
Stress, capacity, and per<strong>for</strong>mance testing
These tests are important because the migrated solution will reside in a new
environment. The hardware, operating systems, and software will be very different
than the existing solution. Complete testing should be per<strong>for</strong>med on the solution.
Stress testing can also be used to check database coexistence issues that may
occur when there is a heavy load on the system.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 57
●
Regression testing
To ensure that the solution functions correctly while bugs are being corrected, a
set of test cases should be available that can be executed as a regression test.
Each time the test is run, the results should be logged and compared with the
expected results. Testing per<strong>for</strong>med on the original solution can be reused in most
scenarios. Using the same data, test cases should per<strong>for</strong>m identically between the
existing solution and the new solution being tested.
Test Approach and Assumptions
Describe at a high level the approach, activities, and techniques to be followed in testing
the solution. If different approaches are required <strong>for</strong> the solution’s various components,
you need to specify which components will be tested by which approach. This approach
is relevant to migrations, as not all components will have the same amount of change or
trans<strong>for</strong>mation. The test approach should be tempered based on the amount of change.
Major Test Responsibilities
Identify the teams and individuals who will manage and implement the testing process.
Features and Functionality to Test
Identify at a high level all features and functionality that will be tested. Per<strong>for</strong>m the
following tasks on the most common problem areas in an <strong>Oracle</strong> to SQL migration
project:
● Ensure that the SQL Server edition acquired meets application requirements. For
more in<strong>for</strong>mation, see the "Validate the Technology" section in this chapter.
● Verify that the database architecture follows best practices and will meet
per<strong>for</strong>mance goals.
● Ensure functions that have moved from the database into the application (and vice
versa) during the migration are properly documented and tested.
● Check any table design changes due to restrictions on SQL Server row size.
● Test triggers that have been converted from <strong>Oracle</strong> to SQL Server.
Items to include when testing application migration include:
● Code changes
● Security requirements
● User connectivity and remote access
● Connection string changes
● Functionality changes. Consider both application and database <strong>for</strong> specific items.
Some database items will affect the application.
Type of Required Hardware
The type of hardware <strong>for</strong> the test setup should closely resemble the architecture that is
proposed <strong>for</strong> the production environment. The availability of hardware may depend on its
type, its cost, and any other environmental factors that need to be considered at the
location of the test setup. In situations where data does not exist to make a decision on
the production data, the test environment has to be planned to capture such in<strong>for</strong>mation.
In some situations, using virtual machine software (such as Microsoft Virtual Server
2003) to recreate test environments and per<strong>for</strong>m software testing is cost-effective.

58
Planning Phase
Location of Test Setup
Decide on the location of the test setup. If development, testing, and production are in
physically distant (possibly offshore) locations, then decisions have to be made on how to
set up the environments <strong>for</strong> optimal per<strong>for</strong>mance <strong>for</strong> each group. For example, if the test
and production locations are far apart, creating copies of a large production database
across a WAN can be an issue. Also, the test environment should be isolated and should
not interfere with any production activity.
Resources Required
Provide <strong>for</strong> the different equipment required <strong>for</strong> the setup, such as power points; racks or
stands; storage media, such as disks; and a backup system. Software, services, and
tools <strong>for</strong> the test environment have to be procured and set up as per the instructions
provided by the test team.
Expected Results of Tests
Describe the results that should be demonstrated by the tests. This in<strong>for</strong>mation includes
expectations of both the solution team and the testers. This section also defines whether
the results must be exactly as anticipated or whether a range of results is acceptable.
The expected results originate from the existing solution. The migrated solution should
per<strong>for</strong>m the same or better than the original system.
Deliverables
Describe the materials that must be made available or created to aid in conducting the
tests and <strong>for</strong> presenting test results. In many migration situations, existing test scripts can
be reused.
Testing procedures and walk-through
Describe the steps the testing team will per<strong>for</strong>m to ensure quality tests.
Tracking and Reporting Status
Define the in<strong>for</strong>mation that test team members will communicate during the testing
process. This section defines the specific test status in<strong>for</strong>mation that will be created and
distributed. This in<strong>for</strong>mation normally includes status in<strong>for</strong>mation <strong>for</strong> each test case and
the probability of completing the test cycle on schedule.
Bug Reporting Tools and Methods
Describe the overall bug reporting strategy and methodology. This section also defines
what will qualify as a bug in the code, product features, and documentation.
Schedules
Identify the major test cycles, tasks, milestones, and deliverables. This section also
describes who is responsible <strong>for</strong> each test cycle and its tasks. In addition, it identifies the
expected start and completion date <strong>for</strong> each test cycle and the tasks within that cycle.
When planning <strong>for</strong> test cases, identify the sections of code that have changed during
migration and identify the functionality provided.
Create test cases based on these functionality changes. When changes are minimal,
such as a Java application that only requires the database connection string to be
modified, the test case should ensure that the application is connecting properly to the

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 59
SQL Server database. In most migrations, updates to connectivity and APIs represent a
majority of the changes.
In situations where the APIs have been changed, test cases should be created to test this
component change. These cases should test database queries and updates per<strong>for</strong>med
by the application to ensure that results are as expected. Gather various scenarios of
usability and user interaction and repeat <strong>for</strong> each component. Query results and
database updates can be checked against the same functionality in the existing solution.
Refer to the test plan template to assist in creating your test plan. This template is
available in the Tools and Templates folder in the zip file download of this guidance at
http://go.microsoft.com/fwlink/?LinkId=45289.
Pilot Plan
The pilot plan describes how the team will move the candidate release version of the
solution to a staging area and test it. The goal of the pilot is to simulate the equipment,
software, and components that the solution will use when it is active. This plan also
identifies how issues discovered during the pilot will be solved. The pilot plan includes
details about how to evaluate the pilot; the results of the evaluation will facilitate a
decision whether to move the solution to production.
Project teams often conduct one or more pilots to prove the feasibility of solution
approaches, to experiment with different solutions, and to obtain user feedback and
acceptance of proposed solutions. Pilot solutions implement only those subsets or
segments of requirements of the functional specification that are necessary to validate
the solution.
Note Some projects may not require conducting a pilot. For example, if there are few
changes to an application, the consensus may be not to per<strong>for</strong>m a pilot program.
However, even in situations where an application is ported, it is important to remember
that the solution include the application and the new SQL Server database back end.
Because the back end database, environment, and plat<strong>for</strong>m will change in the new
solution, a pilot is recommended <strong>for</strong> highly critical applications. Pilots are also
recommended <strong>for</strong> applications where specific per<strong>for</strong>mance criteria, such as response
times or throughput, must be met. Pilot programs can also be useful in situations where
there is a redesign in the migration and the components work differently on the new
plat<strong>for</strong>m.
In addition, piloting can provide operational and deployment personnel practical
experience with new technologies and can benefit the actual deployment schedule and
operational transition schedules.
The pilot plan provides the means to validate the business requirements and the
technical specification prior to deploying the solution into production. Planning the details
of the pilot ensures that the participating project teams identify their roles, responsibilities,
and resource requirements specific to pilot development, testing, and deployment
activities.
Refer to the pilot plan template <strong>for</strong> assistance in creating your pilot plan. This template is
available in the Tools and Templates folder in the zip file download of this guidance at
http://go.microsoft.com/fwlink/?LinkId=45289.

60
Planning Phase
Deployment Plan
During the Deploying Phase, the team deploys the solution technology and components,
stabilizes the deployment, transitions the project to operations and support, and obtains
final customer approval of the project. Planning <strong>for</strong> deployment starts in the Planning
Phase by developing a detailed deployment plan. This plan should be developed by the
Release Management Role with assistance from the rest of the team. See the
deployment plan template in the Tools and Templates folder in the zip file download of
this guidance at http://go.microsoft.com/fwlink/?LinkId=45289.
Key elements of the deployment plan are described in the following sections.
Deployment Scope
This section describes the solution architecture and scale of deployment. The
deployment team needs to consider deployment of the database, server, and the client
applications. Each has its own challenges that require a different process and set of
tools.
● Seats. This describes the magnitude of the deployment in terms of sites, number
of workstations, countries and regions, and other relevant size factors.
● Components. This lists and describes the components to be deployed and any
critical dependencies among them.
● Architecture. This describes the solution’s architecture and how it might affect
deployment.
Deployment Tools
The database and server deployment will often be on one or a few machines. They can
be deployed manually. However, the clients may have to be deployed over hundreds of
computers across the corporate network. This may require the need <strong>for</strong> software
distribution and deployment tools. These tools are discussed in the "Deploying the Client
Application" section in Chapter 19, "Deploying Phase."
Backups
Backing up of the solution and the source control of scripts must be carried out. The
items that need to be backed up <strong>for</strong> which you need to plan include a snapshot of the
source code of the existing solution and the migrated solution. Include the version
in<strong>for</strong>mation and build in<strong>for</strong>mation.
This ensures that the environment can be recreated later, if required. It also aids during
problems, especially when a fallback is implemented. In a phased migration, backups of
the source should be per<strong>for</strong>med between phases, as well as any other critical junctures,
as deemed necessary. If a partial rollback is needed, backups can save time.
Deployment Schedule
This identifies the critical dates and anticipated schedule <strong>for</strong> the Deploying Phase.
Deployment Resources
This identifies the work<strong>for</strong>ce that will be needed to complete the deployment and the
sources of the personnel.
<strong>Solution</strong> Support
This describes how the users will be supported during the deployment.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 61
●
●
●
●
Help desk. This describes the support provided to users and applications by the
help desk team, including support <strong>for</strong> direct user questions and application issues,
and also in-depth support <strong>for</strong> new or difficult issues.
Desktop. This describes any changes in current workstation application support
that might be required during deployment.
Servers. This describes any changes in current server support that might be
required during deployment.
Telecommunications. This describes any changes in current telecommunication
support that might be required during deployment.
Coordination of Training
This describes how end-user and support staff training is coordinated with the
deployment schedule.
Communication
The necessary in<strong>for</strong>mation, such as the dates <strong>for</strong> deploying and completing the migration
must be communicated to the customers and all those who may directly or indirectly be
affected by the migration. The deployment plan should be made available to the entire
team so that each person is well in<strong>for</strong>med of what actions they are responsible <strong>for</strong> and
when it should occur. This is especially critical in large migrations that have to be
undertaken over a grueling schedule, such as a weekend.
Work Schedules
To prevent the business operations from being affected by the deployment, work
schedules should be set accordingly. The work schedules should consider training the
operations personnel and end users.
Resource Availability
The resources in the production environment should be prepared <strong>for</strong> the solution
deployment. The infrastructure, servers, and workstations should be prepared <strong>for</strong> the
deployment. The necessary installation files should be ready to conduct a smooth and
timely deployment. Spare disk drives, cables, network cards, power points, stands, and
backup power supply should be made available in case of failure in hardware during the
deployment. In many instances, such precautions are not taken until a solution is already
deployed. Hence it is important to produce a plan to capture all these tasks.
● Assembling the team. The rollout team should be assembled and the training to
per<strong>for</strong>m the deployment should be provided. The rollout team members could be
from the project team, but the team should also include members from the
operations staff because they need to develop a thorough knowledge of the
functioning of the solution. Alternate team members should also be selected to
prepare <strong>for</strong> contingencies.
● Training the team. The deployment team should be given the necessary training
and privileges to overcome the difficulties that could arise during the rollout. The
different installation manuals and documentation should be provided to the rollout
team. A special help desk should be set up <strong>for</strong> the users and the rollout team to
revert to while deploying the solution.
● Documenting unplanned procedures. During the rollout, some procedures may
have been implemented which were a part of the rollout plan. The deployment
team may need these procedures to stabilize the deployment or correct
un<strong>for</strong>eseen situations created due to the execution of unplanned procedures.

62
Planning Phase
These emergency procedures should be documented and include the cause and
effect of the procedure adopted.
Because there are risks involved, the risk management plan has to be reviewed
and updated. The risk management template is available in the Tools and
Templates folder in the zip file download of this guidance at
http://go.microsoft.com/fwlink/?LinkId=45289.
Deployment Strategies
The main strategies that need to be considered <strong>for</strong> deployment include:
● Cutover strategy. The critical area in a migration project where the existing
system is shut down and the new system is ready to be implemented in the
production environment. The cutover strategy focuses on the tasks, activities, and
time required during the final days of the project. The cutover strategies available
are:
● Straight cutover. This strategy enables migration of the database from one
environment to another without taking any intermediary steps. This option is
used when downtime does not limit the migration, and the migrated database
does not contain critical in<strong>for</strong>mation.
● Parallel cutover. Replication is a strategy that is used by organizations that do
not have the adequate downtime required to build and migrate a database. A
database is created in the new environment and data is migrated on a
continual basis. A process is put in place to replicate the current database
changes into the new database synchronously or asynchronously.
● Serial cutover. This option enables the database to be migrated in phases.
This approach is usually implemented when multiple databases need to be
migrated or data within the database is portioned based on business functions.
The serial cutover strategy is difficult to implement when the database is
complex and interdependent with other infrastructure elements.
●
●
Phase-out strategies. In large, complex migrations, the solution is rolled out in
phases. This enables the team to assess and reduce the business risks. Phasing
out enables the deployment to take place in small and manageable parts. There
are two types of phase-outs:
● Vertical phase-out. In vertical phase-out, modules are rolled out one at a
time. This implies that both the source solution and the target solution
interoperate. The advantage is that the solution is rolled out in manageable
parts. The disadvantage is that data bridge programs between the two
solutions have to be deployed at each phase-out.
● Horizontal phase-out. The horizontal phase-out covers the rolling out of the
solution in phases over the different geographical areas. While implementing a
horizontal phase-out, the differences in the environment conditions of the
business and applications should be taken care of.
Fallback strategies. A fallback is necessary if the migration encounters difficulties
or delays that impacts business. This could result due to the following reasons:
● Unfeasible migration strategy
● Undocumented requirements or procedures
● Insufficient testing
● Disasters
● Un<strong>for</strong>eseen situations

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 63
Each phase and each action in the rollout has to be associated with an impact to
determine if a fallback is required whenever that action cannot be successfully
completed. Dependencies <strong>for</strong> every action should also be mapped to <strong>for</strong>esee the
impact on tasks further down the chain. Every precaution to ensure that the
fallback is successfully completed has to be undertaken. For example, in case of a
fallback, the licenses of the existing solution need to be still valid, and the
encryption certificates need to be valid.
A fallback plan should enable the solution to be rolled back to a consistent and
stable state. Workaround strategies or contingency plans should be tried be<strong>for</strong>e
deciding to fallback on the original database. The fallback strategies to be
implemented depend on the cutover strategies that are selected. The fallback
strategy should accommodate <strong>for</strong> any transactions that were executed since the
start of deployment. To select the optimal fallback strategy, a list of the possible
failures needs to be documented. The different fallback strategies available are:
● Fallback after straight cutover. In case of a fallback in straight cutover, the
UNIX environment needs to be frozen at the time the cutover started. Thus, in
case of a fallback, it is possible to restart the UNIX environment with minimal
ef<strong>for</strong>t. A fallback may require re-establishment of broken sessions between the
customer computers and the database. To reduce downtime and rework,
during the fallback, checkpoints have to be established be<strong>for</strong>e clients are
migrated. Also, a subset of clients should be cut over and tested be<strong>for</strong>e the
rest of the clients. In addition, adequate time should be provided <strong>for</strong> a fallback
with minimal user disturbance.
● Fallback after parallel cutover. The fallback process involves reversing the
direction of replication that was used in the cutover, that is, SQL Server to
<strong>Oracle</strong> database. Consequently, the <strong>Oracle</strong> database is updated <strong>for</strong> the period
of the cutover. The client side is the main technical area to be addressed
during the fallback. <strong>Migrating</strong> the clients in smaller batches can ease the pain
of reverting to the original environment.
● Fallback after serial cutover. The fallback is similar to that in a straight
cutover, with the entire migration viewed as a collection of smaller cutovers.
The serial or phased cutover enables you to fallback to a previous consistent
state without having to undo all changes. You are also able to solve problems
in small increments.
For more in<strong>for</strong>mation and assistance in developing your deployment plan, refer to the
deployment plan template.
Create the Project Schedules
Based on the functional specification and the project plan, the team creates a project
schedule that defines the release date of the solution. The team may choose to divide the
schedule functionally. For example, different sub test teams will work on testing different
features of the solution. Each subteam will create its own schedule.
A release date is decided after integrating the master project schedule with the schedules
from each team lead. A release date enables the team members to prioritize functions,
assess risk, and plan effectively.
Estimating the Ef<strong>for</strong>t
According to the various functional components, each task is allotted to a team that is
developing the component. Each team prepares plans based on their role and

64
Planning Phase
deliverables. Finally, all the plans are reviewed and dependencies between the plans are
outlined. These various plans are then merged into a master project plan.
Estimating the teams' ef<strong>for</strong>t can be accomplished as follows:
● Each team leader prioritizes the functions, roles, and responsibilities <strong>for</strong> the entire
team.
● The team members are required to estimate their per<strong>for</strong>mance <strong>for</strong> each task
assigned. The time given to per<strong>for</strong>m an individual task should vary from one half
day to one week. If the time duration estimated is short, then the overhead in
managing the task may be too high. If the time estimated is too long, then
managing the scope of work becomes too difficult.
● Per<strong>for</strong>m bottom-up estimating to create accurate schedules. This method enables
the individual per<strong>for</strong>ming the task to estimate the time taken to complete it. The
estimate is usually based on the individual's experience of per<strong>for</strong>ming a similar
task. In addition, individuals that estimate time plans <strong>for</strong> their work feel more
accountable <strong>for</strong> their work schedules.
● Implement risk-driven estimating, which enables the team members to per<strong>for</strong>m the
difficult and highest risk tasks first. It permits individuals to minimize risk and
provides excess time to mitigate risk.
When scheduling a migration, there are many time-related elements to consider. For
instance, the development and test environment need to be set up be<strong>for</strong>e starting the
Developing Phase to maximize team productivity, mitigate risks, and avoid delays. It is
also recommended to migrate the database be<strong>for</strong>e migrating the application. This is due
to object-level differences between the <strong>Oracle</strong> and SQL Server databases that may need
to be modified.
Migration environments also impact the schedule. For instance, projects that involve
porting the application, such as Java, can be accomplished relatively quickly. By contrast,
migration environments that require rewriting the application, such as <strong>Oracle</strong> Forms and
Pro*C, will need a longer development schedule. Also, it is more challenging to migrate
data in OLTP environments than in batch processing environments.
Skills can also affect the scheduling. In an optimal migration, a database administrator on
the team is skilled in both SQL Server and <strong>Oracle</strong> environments. If current database
administrators are only familiar with the <strong>Oracle</strong> environment, extra time should be allowed
<strong>for</strong> job training and skill acquisition. The same applies to application developers. In
addition, pilot testing and migrating smaller applications be<strong>for</strong>e the main application may
be beneficial to the project by providing the entire project team with experience that may
prove helpful while migrating the main application.
After you have defined a schedule, you can allocate resources to it. You should:
● Update the project plan with detailed allocation of resources.
● Check and configure availability of resources, identifying any possible overuse of
resources.
● Establish a baseline and track progress on tasks and budget.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 65
Set Up the Development and Test Environments
The final tasks <strong>for</strong> the Planning Phase are setting up the development and test
environments. Completing these tasks allow <strong>for</strong> a smooth transition into the Development
Phase.
In many ways, the development and test environments are similar. Both are modeled on
the solution environment, and both are used to refine the solution. There are also
differences between the functions of these two environments.
The development environment is used to develop the migration solution <strong>for</strong> the database,
client application, and server applications. In addition, the environment may go through
changes as the solution is developed.
By contrast, the test environment is more strictly controlled to ensure that it emulates the
production environment. The test environment is used to complete all necessary testing
<strong>for</strong> the database and application. The test environment must be as similar as possible to
the production environment so that stress and scalability tests will have a measure of
accuracy.
Often in migration projects, the development environment is used <strong>for</strong> testing once the
Developing Phase has ended. In most situations, the test environment requires a higher
level of per<strong>for</strong>mance than the development environment, and additional hardware will
need to be added.
If you are reusing equipment, it is best to reload all operating systems, applications, and
data. This ensures that testing results will not be skewed by a system setting or error left
from the development environment.
The test environment also has different requirements than the development environment.
For instance, testing tools should be installed <strong>for</strong> tasks such as recording per<strong>for</strong>mance
factors, or to increase the load during stress testing.
The tools required <strong>for</strong> development and testing are:
● Database modeling tools <strong>for</strong> reverse engineering existing databases and
generating data definition statements <strong>for</strong> the new environment. The more popular
modeling tools are AllFusion ERwin from Computer Associates and ER/Studio
from Embarcadero.
● Software development tools such Visual Studio .NET or Visual Basic .NET, Perl,
Python, PHP, and Java
● Software management tools <strong>for</strong> source control and bug tracking — Visual Source
Safe and Concurrent Version Systems (CVS) are the popular ones <strong>for</strong> source
control. PVCS from Merant and ClearQuest from Rational can be used <strong>for</strong> bug
tracking.
● An application debugger (if one is not bundled with the application development
tool). Most applications come with their own built-in debuggers.
● Software <strong>for</strong> administering <strong>Oracle</strong> and SQL Server. Both <strong>Oracle</strong> and SQL Server
offer Enterprise Manager, which contains a comprehensive set of tools <strong>for</strong> all
administrative tasks. There are several third-party tools available, such as Toad
and SQL Navigator from Quest, PL/SQL Developer from Allround Automations,
Unicenter SQL-Station from Computer Associates, and Rapid SQL from
Embarcedero.
● Database and data migration tools. Tools that are aimed specifically at <strong>Oracle</strong> to
SQL Sever migration are available from Microsoft.
● UNIX interoperability tools such as SFU, FreeTDS, and so on.

66
Planning Phase
●
●
●
Scripting tools <strong>for</strong> writing scripts <strong>for</strong> testing. Perl is a popular scripting language
that is portable across UNIX and Windows. Windows Script is available from
Microsoft.
Per<strong>for</strong>mance monitoring and analysis tools <strong>for</strong> the various components of the
solution. Perfmon is a versatile tool <strong>for</strong> monitoring the Windows system and it can
capture statistics <strong>for</strong> any application that runs on a Windows computer. Filemon
and Netmon can be used specifically <strong>for</strong> the file system and internet traffic.
Scheduling tool <strong>for</strong> automating tests and <strong>for</strong> capturing statistics. Windows
scheduler can be used <strong>for</strong> this purpose. Autosys from Computer Associates and
Control-M from BMC are also popular.
For additional in<strong>for</strong>mation on testing, refer to Chapter 18, "Stabilizing Phase."

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 67
4
Developing: Databases —
Introduction
Introduction and Goals
For a migration project, the Developing Phase is the time when the team builds the
solution components — code and infrastructure as well as documentation. Typically, this
work consists of modifying existing code in a way that enables it to work within the new
environment. When new code is written, some aspect of the original component usually
remains unchanged — <strong>for</strong> example, exposed APIs, or specific component behaviors.
Both the modification of existing code and development of new code in this context are
considered to be migrating activities.
Although the development and migration work is the focus of this phase and this
guidance, the entire team is active. For example, some team members are creating
deliverables such as training materials, rollout and site preparation checklists, and
updated pilot and rollout plans while others are doing functional testing. Some
development work may continue into the Stabilizing Phase in response to test results.
This chapter serves as an introduction to the database development-oriented chapters.
Chapters 5 through 8 describe and demonstrate how to implement a Microsoft®
SQL Server database that resembles the source <strong>Oracle</strong> database as closely as
possible. These chapters also describe how to produce a solution that meets your
organization's requirements <strong>for</strong> per<strong>for</strong>mance, functionality, availability, scalability, and
recoverability. The following list provides an overview of the content in each of the
database development-oriented chapters:
● Chapter 4: Developing: Database — Introduction. This chapter prefaces the
different tasks in migrating the <strong>Oracle</strong> database to SQL Server 2000.
● Chapter 5: Developing: Database — <strong>Migrating</strong> the Database Architecture.
This chapter describes the steps in creating an instance of SQL Server which is
equivalent in architecture to the original <strong>Oracle</strong> database.
● Chapter 6: Developing: Database — <strong>Migrating</strong> Schemas. This chapter shows
how to migrate a schema owner and its objects to a SQL Server database.
● Chapter 7: Developing: Database — <strong>Migrating</strong> the Database Users. This
chapter contains detailed steps in creating users in the SQL Server databases and
granting them the same kind of privileges they had in the original <strong>Oracle</strong> database.

68
Developing: Databases — Introduction
●
●
Chapter 8: Developing: Database — <strong>Migrating</strong> the Data. This chapter explores
the different options in migrating the application data from <strong>Oracle</strong> to SQL Server. It
provides details in the usage of each of the options.
Chapter 9: Developing: Database — Unit Testing the Migration. This chapter
contains the processes <strong>for</strong> testing the migrated database, its objects and data.
The Developing Phase <strong>for</strong>mally ends with the Scope Complete Milestone. At this major
milestone, the team gains <strong>for</strong>mal approval from the sponsor or key stakeholders. All
solution elements are built and the solution features and functionality are complete
according to the functional specifications agreed upon during planning. Table 4.1
describes the major tasks that need to take place while migrating the database.
Table 4.1: Major Tasks and Deliverables
Tasks
Migrate the <strong>Oracle</strong> database architecture
Migrate the schemas
Migrate the users
Migrate the data
Deliverables
SQL Server instance that is equivalent in
structure to the source
SQL Server databases housing application
schemas
SQL Server users with similar privileges as
the source
Complete database ready <strong>for</strong> use
<strong>Migrating</strong> the Database
Because they are both relational databases, <strong>Oracle</strong> and SQL Server have more
similarities than differences in their features and functions. Both <strong>Oracle</strong> and SQL Server
provide all the core functionality expected of a RDBMS, including concurrency, security,
backup, recovery, scalability, availability, session management, transaction management,
storage management, resource management, and so on. Both exhibit a moderate degree
of compliance to ANSI standards. Hence migrating from <strong>Oracle</strong> on UNIX to SQL Server
on Windows® poses less of a challenge than would normally be expected when
migrating from one proprietary computing system to another. Because SQL Server and
<strong>Oracle</strong> are relational databases, it is not necessary to redesign the database. It is not
necessary to rearchitect the application <strong>for</strong> per<strong>for</strong>mance or security because the two
DBMSs are very similar in their architecture. The majority of the work involved is in
accommodating the differences in the implementation of items such as indexes, data
types, and SQL and DBMS features, such as partitioning.
To simplify the migration of the database, the entire process can be organized into four
major tasks:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 69
Figure 4.1
Tasks in the migration of a database
Each of the four major tasks includes a set of subtasks as follows:
1. Migrate the database architecture
a. Build the SQL Server instance
b. Configure the server
c. Migrate the storage architecture
2. Migrate the schemas
a. Migrate the schema
b. Migrate the schema objects
3. Migrate the users
a. Create user accounts
b. Create roles and grant privileges
4. Migrate the data
a. Plan the data migration
b. Execute the data migration
In Chapters 5 through 8, examples are provided <strong>for</strong> each of the major tasks and subtasks
at the end of the chapter. The discussion of testing the migrated database is in Chapter
9, "Developing: Databases — Unit Testing the Migration." <strong>Oracle</strong> DBAs who are new to
SQL Server should also read Appendix A, "SQL Server <strong>for</strong> <strong>Oracle</strong> Professionals," which
provides a condensed guide <strong>for</strong> educating <strong>Oracle</strong> DBAs about the internal architecture of
SQL Server by leveraging existing knowledge of <strong>Oracle</strong>. The appendix also provides
in<strong>for</strong>mation about how to per<strong>for</strong>m some of the common administrative functions in
SQL Server.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 71
5
Developing: Databases —
<strong>Migrating</strong> the Database
Architecture
Introduction and Goals
The first task in the migration of the database is to create an instance of SQL Server that
will provide the container (the RDBMS) <strong>for</strong> creating schemas and schema objects to cater
to the needs of applications. Your main focus when creating the database should be on
its architecture: the instance architecture involving server resources, such as processor
power and memory; and storage architecture, including file systems. Your objective <strong>for</strong>
both of these areas is to derive per<strong>for</strong>mance that is equivalent to or better than the
original solution.
The two most common implementations of databases are Online Transaction Processing
(OLTP) systems and Decision Support Systems (DSS). OLTP systems are characterized
by large numbers of short transactions that frequently add or modify data. DSS systems,
on the other hand, contain large volumes of mostly static data imported into them from
OLTP databases, file systems, and other such systems <strong>for</strong> the purposes of analysis and
reporting. There are fewer transactions in DSS systems, but they run much longer. OLTP
system per<strong>for</strong>mance is influenced by locking. DSS per<strong>for</strong>mance is typified by large reads,
sorts, computation, and so on.
The guidance provided in this solution is focused on OLTP systems. The types of
operations per<strong>for</strong>med in OLTP and DSS systems impose different demands on the
database resources. While the architecture <strong>for</strong> OLTP and DSS systems differs, resource
considerations are similar. Though there are some objects that are specialized <strong>for</strong> DSS
systems, most objects are common to both systems. As a result, the guidance provided
applies to DSS systems, as well.
Build the SQL Server Instance
This section discusses the planning and preparation <strong>for</strong> installing the SQL Server
RDBMS software. A more detailed discussion can be found in SQL Server Books Online
under the “Installing SQL Server” topic.

72
Developing: Databases — <strong>Migrating</strong> the Database Architecture
Pre-Installation Planning
You should follow these design guidelines <strong>for</strong> the layout of a SQL Server software
installation and database files:
● Independent subdirectories. Files should be separated by categories and
instance to minimize effects and ease navigation. When named instances of SQL
Server are created, the associated directories are created with instance names <strong>for</strong>
identification purposes.
● Consistent naming convention <strong>for</strong> files. Use the following file name extensions:
.mdf <strong>for</strong> primary datafiles, .ndf <strong>for</strong> secondary datafiles, and .ldf <strong>for</strong> log files. The
default file naming convention is dbname_data.mdf <strong>for</strong> the datafile and
dbname_log.ldf <strong>for</strong> the log file.
● Integrity of home directories. Keep the SQL Server software separate from the
datafiles. This allows the software to be moved or deleted without affecting the
application.
● Separation of administrative in<strong>for</strong>mation <strong>for</strong> each database. Store system data
in the master database separate from other data.
● Separation of tablespace content. Every instance of SQL Server comes with the
system databases master, model, msdb, and tempdb.
● Tune I/O load across all disks. SQL Server has filegroups, each with multiple
files that give the same advantages as tablespaces. In addition, storage allocated
to an object is distributed evenly across all datafiles belonging to the filegroup.
Installation
The following important installation options have to be determined prior to installing SQL
Server:
● Instance name. SQL Server has a provision <strong>for</strong> a default instance where the
instance takes the network name of the server. Multiple instances with assigned
names can also be created. SQL Server naming conventions do not preclude
reuse of <strong>Oracle</strong> instance names.
● Network libraries. SQL Server can communicate using several network protocols.
TCP/IP and named pipes are the most common. To minimize resource utilization,
only configure those protocols that are required.
● Service accounts. Like any other service, both SQL Server and SQL Server
Agent (the SQL Server scheduling service) require a Microsoft Windows® account.
You should run SQL Server under a domain account. It does not have to be a local
administrator or a domain account that has local administrative privileges.
● Authentication mode. Options available in SQL Server are Windows
Authentication or Mixed mode. Mixed mode allows login access to SQL Server
either by a valid Windows account or a valid SQL Server login. The authentication
mode can be changed any time in the future. Changing the authentication mode
requires that the database be restarted to take effect.
● Licensing mode. Indicate whether this SQL Server is licensed by processor or per
seat (Client Access License) and the number <strong>for</strong> the given mode.
● Location of files. With <strong>Oracle</strong>, even though the installer provides the option of
creating a starter database, installing the software and creation of databases are
two independent events. Installing the SQL Server software also creates a
"database system" with databases such as master, model, msdb, northwind,
pubs, and tempdb created by default. The destination location of SQL Server

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 73
application files and the datafiles <strong>for</strong> the default databases can be specified at
installation.
Configure the Server
A SQL Server instance can be configured similar to an <strong>Oracle</strong> instance. The areas that
are covered here include memory, CPU, and listener.
Architecturally, both <strong>Oracle</strong> and SQL Server can be divided into instance and database.
The instance is made up of memory areas and database processes. In SQL Server, the
division of memory pool into sub-caches (buffer cache, procedure cache, log cache,
connection context, and system data structures) based on function closely resembles the
<strong>Oracle</strong> SGA and its components. SQL Server has threads that per<strong>for</strong>m similar work to the
<strong>Oracle</strong> <strong>for</strong>eground and background processes.
In <strong>Oracle</strong>, the characteristics and behavior of the database and the instance are
determined by a large set of parameters stored in the initialization file (init.ora) or server
parameter file (spfile). These parameters cover a diverse set of resources, such as
memory, processes, network, disk, I/O, connections, files, character set, and so on.
The non-default values of the <strong>Oracle</strong> initialization parameters can be obtained from the
parameter file if one is in use. If a server parameter file is in use, the parameter values
can be obtained using one of the following options:
● Convert the server parameter file (spfile) to an initialization parameter file by
executing the following statement:
CREATE pfile FROM spfile
● Query the database by executing the following statement:
SELECT name, value
FROM sys.v$spparameter
WHERE isspecified = 'TRUE'
SQL Server does not have an equivalent <strong>for</strong> every initialization parameter. The
configuration options in SQL Server can be specified using SQL Server Enterprise
Manager or using the sp_configure system stored procedure. Syntax <strong>for</strong> use is shown in
the following statement.
sp_configure [option, [value]]
A discussion of every <strong>Oracle</strong> initialization parameter is beyond the scope of this guide.
The configuration options available in SQL Server can be categorized into userconfigurable
and advanced. The advanced options, which are similar to <strong>Oracle</strong>’s “hidden”
parameters, are either self-configuring or should be manipulated only with the advice of a
certified SQL Server technician.
Examples of <strong>Oracle</strong> parameters that have an equivalent configurable parameter in
SQL Server are provided in Table 5.1:
Table 5.1: Examples of <strong>Oracle</strong> Initialization Parameters with Equivalent in
SQL Server
<strong>Oracle</strong>
Processes
fast_start_mttr_target
Sessions
dml_locks
SQL Server
max worker thread options
recovery interval
User connections
Locks

74
Developing: Databases — <strong>Migrating</strong> the Database Architecture
Sometimes a configuration option can be set at one of several different places. For
example, the SQL Server max degree of parallelism parameter can be set using the
<strong>Oracle</strong> DEGREE clause at the object or query level.
Certain options which are configurable in one database may have a fixed implementation
in the other. For example, the <strong>Oracle</strong> LOG_CHECKPOINT_INTERVAL and
LOG_CHECKPOINT_TIMEOUT parameters used to tune checkpoints do not have
equivalents in SQL Server. In SQL Server, checkpoints occur automatically based on the
number of redo records in the log. Similarly, UNDO_MANAGEMENT,
UNDO_TABLESPACE, and ROLLBACK_SEGMENTS that define the storage <strong>for</strong>
transaction rollback or undo data are implemented in SQL Server as part of the
transaction logs of each database.
Configure Memory
SQL Server has far fewer configuration parameters than <strong>Oracle</strong>. In <strong>Oracle</strong>, there are
several parameters that are used to control memory allocation to the instance and its
sub-components. Some of these parameters are
● SGA_MAX_SIZE
● DB_CACHE_SIZE
● SHARED_POOL_SIZE
● LARGE_POOL_SIZE
● JAVA_POOL_SIZE
● LOG_BUFFER
● SORT_AREA_SIZE
SQL Server offers the parameters min server memory and max server memory, which
can be used to limit the amount of server memory that can be utilized by the database
system. SQL Server cooperates with the operating system to dynamically adjust the
amount of memory used based on the demands on the server from other applications.
However, this behavior puts the burden on the dimensioning of the system so it is
capable of running the database with known loads and peaks and avoiding competing
workloads which might jeopardize the system resources available to the database. All
memory areas within the memory pool are dynamically adjusted by the SQL Server code
to optimize per<strong>for</strong>mance and do not need any administrator input. Hence you will find
very few memory-related configuration parameters in SQL Server.
The amount of memory that can be utilized by SQL Server can be configured either using
Enterprise Manager or through T-SQL. The two options are provided in the following
procedures:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 75
To configure the amount of memory available <strong>for</strong> SQL Server in Enterprise
Manager, follow these steps:
1. Expand the server group.
2. Right-click Server (Server Name\Instance Name), and then click Properties.
3. Select the Memory tab.
4. Select Dynamically configure SQL Server memory to set the memory range
under which SQL Server should operate. Select Use a fixed memory size (MB) to
allocate a fixed amount of memory. The actual values can be selected using the
memory slider graphic.
The code <strong>for</strong> setting a range of memory and a fixed amount of memory <strong>for</strong> SQL Server is
provided in the following procedure.
To configure a range of memory <strong>for</strong> SQL Server using T-SQL, enter the
following commands:
USE master
EXEC sp_configure 'show advanced option', 1
RECONFIGURE
GO
sp_configure 'min server memory', 100 -- 100MB
RECONFIGURE
GO
sp_configure 'max server memory', 4000 -- 4000 MB
RECONFIGURE
GO
To configure a fixed amount of memory <strong>for</strong> SQL Server using T-SQL, enter the
following commands:
USE master
sp_configure 'show advanced option', 1
RECONFIGURE
GO
sp_configure 'min server memory', 400
RECONFIGURE
GO
sp_configure 'max server memory', 400
RECONFIGURE
GO
Note A database restart is required to activate the new settings of all advanced options.
If the amount of physical memory exceeds 3 GB, then the Address Windowing
Extensions (AWE) Windows feature has to be enabled to handle allocation to SQL Server
using the configuration parameter awe enabled. When this feature is enabled,
SQL Server stops dynamic memory management at the server level and the max server
memory parameter has to be set. If the max server memory parameter is set, cache

76
Developing: Databases — <strong>Migrating</strong> the Database Architecture
management is similar to SGA sizing in <strong>Oracle</strong> but without the complications of tuning the
individual cache components.
To configure SQL Server to use more than 3 GB of memory using T-SQL,
enter the following commands:
USE master
sp_configure 'show advanced option', 1
RECONFIGURE
GO
sp_configure 'awe enabled', 1
RECONFIGURE
GO
sp_configure 'max server memory', 6000
RECONFIGURE
GO
Because the memory requirements of a SQL Server instance are not the same as an
equivalent <strong>Oracle</strong> instance, the SQL Server memory size has to be tuned during a
migration. The following Per<strong>for</strong>mance Monitor counters can be used to check the amount
of memory SQL Server is using:
● SQL Server: Buffer Manager: Total Pages
● SQL Server: Memory Manager: Total Server Memory (KB)
● Process: Working Set
The dbcc memorystatus command can be used to view in<strong>for</strong>mation about memory
allocation. For more in<strong>for</strong>mation about memory usage and this command, refer to
http://support.microsoft.com/?id=271624.
The LOCK_SGA initialization parameter can be implemented in SQL Server using set
working set size. The allocated memory stays in physical memory and improves
per<strong>for</strong>mance because swapping is avoided. However, care should be taken that
allocating a fixed amount of memory to SQL Server does not impact the needs of other
applications running on the same server.
Set the CPU Affinity
SQL Server has the capability of defining CPU affinity where CPUs can be dedicated to
an instance. This can be controlled using the affinity mask configuration setting or
Enterprise Manager. The priority boost configuration setting can be used to prioritize
threads. SQL Server SP1 has added an IO_affinity_mask switch, which can used at
instance startup to reserve CPUs to handle disk I/O associated with the instance. Use of
the IO_affinity_mask configuration setting is only recommended <strong>for</strong> machines with more
than 16 CPUs.
For more in<strong>for</strong>mation on setting up the I/O affinity mask, refer to
http://support.microsoft.com/?kbid=298402.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 77
Configure the Listener
The <strong>Oracle</strong> listener can operate on any available port. The well-known default selection is
1521. A default installation of SQL Server uses port 1433. If not configured manually, a
named instance picks up an unused TCP port during startup. Unlike <strong>Oracle</strong>, where a
single listener is shared by all instances, each SQL Server instance listens on its own
port. The SQL Server server name, database name, and port in<strong>for</strong>mation are required by
client applications to configure the data source or the connection string (in non-DNS
connections).
Migrate the Storage Architecture
This section discusses the physical and logical storage structures found in SQL Server.
This discussion is useful in understanding how to configure storage in SQL Server in a
manner similar to the original <strong>Oracle</strong> database.
Database data is physically stored in files. However, allocation of this space to the
database objects is done in logical units such as blocks, extents, and segments. Figure
5.1 provides a comparison of the storage architecture in <strong>Oracle</strong> and SQL Server.
Figure 5.1
Mapping <strong>Oracle</strong> storage structures to SQL Server
The organization of storage and its allocation has great significance on per<strong>for</strong>mance and
maintenance of a database. Due to the similarities in the storage architecture, the
principles on which the source <strong>Oracle</strong> database was organized can be carried over into
the SQL Server database with relative ease. The following sections discuss each level of
the storage hierarchy shown in Figure 5.1.
Blocks
In <strong>Oracle</strong>, the smallest unit of storage is the data block. All data in the database is
retrieved and manipulated in terms of blocks. The SQL Server equivalent of the data
block is called the page. In <strong>Oracle</strong>, the DBA chooses the default page size at database
creation to be any of 2K, 4K, 8K, 16K or 32K. In SQL Server, the page size is fixed at 8K.
With <strong>Oracle</strong> 9i, in addition to the default page size, up to five non-standard (non-default)

78
Developing: Databases — <strong>Migrating</strong> the Database Architecture
page sizes can also be used <strong>for</strong> the tablespaces (and, consequently, the logical storage
structures).
The SQL Server page has similar composition as the <strong>Oracle</strong> data block. The data page
consists of page header, data rows, and row offset array (row directory). The header
leaves 8060 bytes of usable space <strong>for</strong> data rows and row offset. In <strong>Oracle</strong>, a data row
that is larger than the usable space is broken into several row pieces (row chaining) and
stored in multiple blocks. SQL Server does not allow rows larger than 8060 bytes. This
restriction in SQL Server, however, does not apply to rows containing large data types,
such as text, image, and so on, which are stored differently.
Within a SQL Server block, space is managed in a manner similar to that by <strong>Oracle</strong>’s
Automatic Segment Space Management (ASSM) option, where used and free space is
tracked using bitmaps. This has implications with respect to migrating to SQL Server. In
<strong>Oracle</strong>, the choice of block size is driven by the type of database — OLTP or DSS/Data
Warehouse. The advantage of large block size is mainly in terms of I/O per<strong>for</strong>mance
because there is less overall cost <strong>for</strong> setting up fewer I/Os. Better I/O per<strong>for</strong>mance can
be achieved with smaller block sizes by using other techniques, such as multi-block read
(DB_FILE_MULTIBLOCK_READ_COUNT), parallel reads and read ahead, or prefetch.
The maximum I/O size, however, is dependent on the operating system. SQL Server also
uses a technique called scatter I/O that enables multiple unrelated blocks to be read in a
single I/O request.
An advantage of larger block size is reduced amount of row chaining. This is a factor
when tables contain rows with lengths larger than can be accommodated in a block.
Reading of multiple blocks may be necessitated in a SQL Server database as compared
to <strong>Oracle</strong> databases with larger block size, but the per<strong>for</strong>mance can be compensated <strong>for</strong>
by better hardware and I/O techniques.
Based on the environment, large block sizes can impact cache per<strong>for</strong>mance. With large
block sizes, <strong>for</strong> a fixed amount of RAM, the number of blocks in physical memory
reduces. For example, if 1 MB of memory can hold 500 blocks of size 2 KB, it can hold
only 125 blocks of size 8 KB. So the cache per<strong>for</strong>mance is dependent on the density of
the block (number of rows per block) and the access pattern (random or sequential).
Smaller blocks reduce contention while the overhead becomes a larger portion of the
block.
In the migration, the move from differing block sizes in <strong>Oracle</strong> to 8 KB blocks in
SQL Server does not pose any challenge. When migrating from <strong>Oracle</strong> (where multiple
block sizes are in use), the rows will be rearranged into 8 KB blocks. However, solutions
have to be created to accommodate rows with length greater than 8060 bytes. Such
solutions are examined later in this chapter.
Extents and Segments
Data allocation to schema objects (such as tables and indexes) and system data
structures (temporary segment, rollback segment) in <strong>Oracle</strong> and SQL Server is in terms
of logical extents. <strong>Oracle</strong> provides parameters <strong>for</strong> appropriate sizing of the extents.
SQL Server, on the other hand, uses fixed size extents of 8 pages (64 KB). <strong>Oracle</strong>
extents — irrespective of whether they belong to dictionary or locally-managed
tablespaces — are migrated to fixed 64 KB extents.
Extents allocated to <strong>Oracle</strong> objects are dedicated to the object and do not contain blocks
from other objects. This is not the case in SQL Server. SQL Server has two types of
extents: uni<strong>for</strong>m and mixed. In a uni<strong>for</strong>m extent, all pages are allocated to a single object,
while mixed extents can have pages belonging to multiple objects. When a table or index
is created in SQL Server, initially it is allocated two pages out of mixed extent. When the

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 79
table or index grows to eight pages, all future allocations use uni<strong>for</strong>m extents. As a result
of fixed size extents, fragmentation within the tablespace (filegroup in SQL Server) is
eliminated.
Because an extent is a contiguous allocation of blocks, large extents aid in better I/O rate
while reading huge amounts of data. After moving to SQL Server, physical I/O will have
to be configured and tuned, as was the case with the change in block sizes.
In <strong>Oracle</strong>, all extents of an object are collectively called a segment. While the concept of
segment existed in version 6.5, SQL Server does not have an equivalent <strong>for</strong> the segment
from version 7.0 and later. The segment has no bearing on migration or per<strong>for</strong>mance.
Tablespaces and Datafiles
Datafiles are used to store persistent data in the database. For ease of management, one
or more datafiles can be grouped into logical tablespaces. The SQL Server equivalent of
the tablespace is the filegroup. While filegroups are similar in function, their organization
differs from that of tablespaces. <strong>Oracle</strong> tablespaces are at the instance level. SQL Server
filegroups come under and are associated with the individual databases. Figure 5.2
illustrates the tablespace to datafiles hierarchy:

80
Developing: Databases — <strong>Migrating</strong> the Database Architecture
Figure 5.2
Schematic mapping of <strong>Oracle</strong> files and tablespaces to SQL Server

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 81
Table 5.2 captures some of the relations between tablespaces in <strong>Oracle</strong> and databases
in SQL Server that are not obvious in Figure 5.2.
Table 5.2: <strong>Oracle</strong> Tablespaces and SQL Server Functional Equivalents
<strong>Oracle</strong>
System tablespace
Temporary tablespace
Undo (Rollback) tablespace
Online Redo log
"App Data" tablespace
"App Index" tablespace
N/A
N/A
SQL Server
master database
tempdb database
Transaction log
Transaction log
"App" database —"Data" filegroup
"App" database —"Index" filegroup
model database
msdb database
The following list describes how <strong>Oracle</strong> functionality is implemented in SQL Server:
●
●
●
●
●
Each of the SQL Server databases has its own security structures, such as users,
privileges (permissions), and roles.
Each of the SQL Server databases has its own administrative roles that bestow
privileges on the database.
In SQL Server, the system catalog — which is analogous to the <strong>Oracle</strong> data
dictionary — is broken up between the individual databases and the master
database.
In SQL Server, each of the databases has its own transaction log files, which
combine the functions of the <strong>Oracle</strong> online redo logs and rollback segments.
The tempdb database provides temporary storage <strong>for</strong> the entire SQL Server
instance, and the temporary tablespace in <strong>Oracle</strong> is common to the entire <strong>Oracle</strong>
instance.
Tablespaces and filegroups provide the ability to better distribute data across multiple
files <strong>for</strong> the purposes of per<strong>for</strong>mance. The grouping also helps ease administration of
backup and recovery, maintenance, availability, and so on.
Each SQL Server database is created with a primary file belonging to the default primary
filegroup. Optionally, secondary datafiles can be added to the primary filegroup, or
additional filegroups can be created. The location of the files belonging to a database is
recorded in the master database and the primary file <strong>for</strong> the database. Data added to
objects of a filegroup are proportionally filled across all files belonging to the filegroup.
A common concern among users when creating SQL Server databases is the lack of the
multiplexing feature available in <strong>Oracle</strong> <strong>for</strong> control files and redo logs. This is not a
concern because SQL Server recommends the use of striped and mirrored devices
(RAID 0+1) <strong>for</strong> transaction logs to preserve the level of protection against hardware
failure obtained by log multiplexing. SQL Server recommends using RAID 0+1 <strong>for</strong> all
database datafiles. If RAID 0+1 cannot be implemented, at a minimum RAID 5 should be
used to provide tolerance <strong>for</strong> hard disk failure. Apart from file systems, SQL Server also
supports the use of raw partitions.
Storage Definition <strong>for</strong> Tables and Indexes
In <strong>Oracle</strong>, the storage definition is used to specify the characteristics of tables and
indexes. The following list provides in<strong>for</strong>mation on how these characteristics migrate to
SQL Server.

82
Developing: Databases — <strong>Migrating</strong> the Database Architecture
●
●
●
Physical attributes. These include PCTUSED, PCTFREE, INITRANS, and
MAXTRANS. Of these parameters, SQL Server only offers an equivalent <strong>for</strong>
PCTFREE through the FILLFACTOR clause. FILLFACTOR is available <strong>for</strong> indexes
only. A PCTFREE of 10 would correspond to a FILLFACTOR of 90.
Tablespace. This is used in a manner similar to tables. The SQL Server equivalent
is the ON filegroup_name option. A default filegroup can be specified <strong>for</strong> each
database, and the default filegroup functions similar to the default tablespace of an
<strong>Oracle</strong> user. If a filegroup is not specified during index creation, the index is
created in the default filegroup <strong>for</strong> the database.
Storage attributes. These override the defaults specified at the tablespace level,
such as INITIAL, NEXT, MINEXTENTS, MAXEXTENTS, PCTINCREASE, and so
on. Due to the fixed (64 KB) extents, these attributes have no relevance in
SQL Server.
Migrate System Storage Structures
As has already been presented in this chapter, an <strong>Oracle</strong> database has the following
system structures that have a similar role in a SQL Server database. The configuration of
these structures in an <strong>Oracle</strong> database can be used to provide a starting point <strong>for</strong>
configuration in SQL Server.
● System tablespace. In <strong>Oracle</strong>, the system tablespace houses the data dictionary
and the system rollback segments. The master database in SQL Server has a
similar role. The transaction log — which also holds the rollback in<strong>for</strong>mation — is in
a separate file. Also, the data dictionary in the master database does not grow
because user object in<strong>for</strong>mation is stored in the primary file of the contained
database under the decentralized data dictionary model of SQL Server. The
master database also has some of the in<strong>for</strong>mation that is stored in the control file
of an <strong>Oracle</strong> database. Based on these facts, it is appropriate to use the default
master database settings.
● Rollback or undo. In <strong>Oracle</strong>, a separate tablespace exists <strong>for</strong> holding rollback
segments (manual and auto modes) whose size and number is dependent upon
the number of user connections and the amount of changes being made to the
database. These factors should be considered in sizing the transaction log in
SQL Server.
● Redo. There are several factors to consider while choosing the size of a
transaction log. The source <strong>Oracle</strong> database has more than one schema that will
be migrated into separate SQL Server databases. For the same transaction, the
amount of redo and rollback in<strong>for</strong>mation generated in SQL Server and <strong>Oracle</strong> is
different. The frequency of backup or truncation of the transaction log also
influences the size. Hence prototyping is the best way to size the SQL Server
transaction log.
● Temporary. The size of tempdb can be initially set to a conservative size as
compared to its <strong>Oracle</strong> counterpart, the temporary tablespace. The auto-increment
feature should be set to ensure that transactions do not fail due to lack of space.
Setting very small increments will also affect per<strong>for</strong>mance due to constant space
operations. The temporary space needs are based on the application needs, which
may change a little as applications are migrated to a SQL Server environment.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 83
6
Developing: Databases —
<strong>Migrating</strong> Schemas
Introduction and Goals
The next task is to create additional databases to house the application schema objects
and the objects that are migrated.
Apart from the architectural differences mentioned in Chapter 5, there are also
differences in data models between OLTP and DSS systems. OLTP systems have more
complex relations, with constraints used to en<strong>for</strong>ce business rules. DSS systems have
simpler and far fewer relationships between tables. Despite the differences between
systems and schema modeling techniques (such as normalized, star, and snowflake), the
implementation of the physical schema uses the same set of objects, such as tables,
indexes, and views. As a result, migration of the schemas and data is the same <strong>for</strong> all
these types. As in Chapter 5, the examples used in this chapter focus on OLTP systems,
but the guidance is applicable to DSS systems, as well.
A Microsoft® SQL Server database has the characteristics of an <strong>Oracle</strong> schema
because objects can be created inside the database. In <strong>Oracle</strong>, the schema and the
storage (tablespaces) have independent identities — objects of a schema can be created
in different tablespaces, and a single tablespace can accommodate objects from multiple
schemas. In this context, SQL Server databases are similar to <strong>Oracle</strong> tablespaces — an
owner can create objects in different databases, and a database can contain objects from
different owners.
In spite of this fact, the database provides a higher degree of separation of the
application data and security than is provided by schemas. SQL Server has been
designed <strong>for</strong> the isolation of administrative duties at the database level. The system
(catalog and roles) has been divided, with centralized functions that have instance-wide
authority under the master database and database-specific functions under the individual
databases.
Creating a SQL Server database <strong>for</strong> each <strong>Oracle</strong> schema is the ideal choice <strong>for</strong> the
logical separation of objects based on the business function (application) that is provided
by the <strong>Oracle</strong> schemas. Subsequently, the schema's objects can be created under the
database.
Tools are available from Microsoft that can assist in this step of the database migration.
The Microsoft SQL Server Migration Assistant (SSMA) provides the Schema and Data

84
Developing: Databases — <strong>Migrating</strong> Schemas
Migrator, which specializes in the migration of the <strong>Oracle</strong> schema to SQL Server. The
SSMA also provides the SQL Converter tool, which converts SQL code found in <strong>Oracle</strong>
objects (such as stored procedures) to their T-SQL equivalents. The SSMA tool suite can
be downloaded from http://www.microsoft.com/sql/migration. The beta version of SSMA
is available as of the date of publishing this solution. Version 1.0 of SSMA is slated to be
available in June 2005.
Most tools that are employed in the administration of <strong>Oracle</strong> databases are capable of
extracting object definitions. Toad and SQL Navigator from Quest, PL/SQL Developer
from Allround Automations, Unicenter SQL-Station from Computer Associates, Rapid
SQL from Embarcedero, and <strong>Oracle</strong> Enterprise Manager from <strong>Oracle</strong> are examples of
such tools.
Modeling tools such as AllFusion (Erwin) from Computer Associates and ER/Studio from
Embarcadero can also be employed to reverse engineer the <strong>Oracle</strong> database.
The goal of this chapter is to show how an <strong>Oracle</strong> schema and its objects should be
migrated to SQL Server. Scripts should be used <strong>for</strong> per<strong>for</strong>ming most of the tasks in this
step, because scripts make the migration easier to execute compared to the use of GUI
tools.
Scripting Migrated Schema Objects
The development process is built on the requirement that when the development is
complete, the code will be in place <strong>for</strong> unit testing and implementation. These scripts will
allow recreation of the objects in a reliable manner when creating the database in the
Stabilizing Phase and the Deploying Phase. There are some basic rules that should be
followed when scripting the database <strong>for</strong> promotion to a staging environment <strong>for</strong> unit
testing:
● Script everything
● Provide support documentation
● Protect the scripts
Each of these basic rules is discussed under the following headings.
Script Everything
Script everything associated with the database implementation. The Generate SQL Script
feature of SQL Server Enterprise Manager can be used to script each database object in
the migrated database. After the scripts are created, conduct a validation process to
verify that the number of objects scripted is the same as the number of objects that exist
in the development database. This process is very important because it helps to ensure
that the database being promoted to the staging environment is identical to the database
in the development environment.
Provide Support Documentation
Provide support documentation <strong>for</strong> each script. Comment the code to describe what is
happening in the script and include any observations gathered when it was last executed,
such as how long execution took and how many rows were affected.
Protect the Scripts
Protecting the scripts is very important <strong>for</strong> the database implementation. Treat the scripts
like production objects at this point. To ensure that the appropriate scripts are used when
the database is promoted between development, staging, and production environments,

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 85
keep the scripts in a secured directory or under version control. Versioning is very
important because an <strong>Oracle</strong> to SQL Server migration is not a mere mapping of objects
from one database to another. The differences between <strong>Oracle</strong> and SQL Server will
require that some of the SQL statements be rewritten <strong>for</strong> the new environment. These
changes in SQL will also prompt changes to the database objects and their design.
These changes will be driven by the application development (migration) process and not
from within the database migration process described here. Only the development and
deployment teams should have access to the scripts.
Migrate the Schema
This section discusses the necessary steps in migrating the schema owner and setting
up the storage in preparation <strong>for</strong> migrating the schema objects and its data.
The high-level steps <strong>for</strong> migrating the storage architecture of a schema are:
1. Map the storage architecture.
2. Create a database <strong>for</strong> the schema.
3. Create filegroups <strong>for</strong> the tablespaces.
4. Add datafiles to filegroups.
Each of these four high-level steps is discussed in detail under the following
subheadings.
Map the Storage Architecture
The first step in migrating an <strong>Oracle</strong> schema is to understand the storage architecture
and how these architectural components will map to their equivalents in SQL Server.
In<strong>for</strong>mation on the various characteristics of the tablespaces and datafiles in which the
<strong>Oracle</strong> schema is stored has to be gathered.
There are several tools, both from <strong>Oracle</strong> as well as third parties, which are used in
administering <strong>Oracle</strong> databases. Any of these tools can be employed to gather
in<strong>for</strong>mation on the tablespaces and datafiles. In the example migration that is provided at
the end of this section, methods <strong>for</strong> capturing the requisite data purely using SQL are
provided.

86
Developing: Databases — <strong>Migrating</strong> Schemas
Figures 6.1 and 6.2 provide a view of how the storage objects will align in <strong>Oracle</strong> and
SQL Server.
Figure 6.1
<strong>Oracle</strong> schema illustrated
Figure 6.2
SQL Server schema equivalent

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 87
Start by compiling a list of tablespaces that contain objects belonging to the schema and
gather the following related in<strong>for</strong>mation:
● Tablespace name.
● Status. The status of an <strong>Oracle</strong> tablespace may be either ONLINE, OFFLINE, or
READ ONLY. If a tablespace is OFFLINE, then a decision has to be made if it is
required to be migrated. Data in an offline tablespace cannot be accessed and it
has to be brought online <strong>for</strong> migration.
● Tablespace contents. Only tablespaces whose tablespace content attribute is set
to PERMANENT have to be migrated.
● Logging attribute. Tablespaces may be set to LOGGING or NOLOGGING, which
specifies the default characteristic <strong>for</strong> bulk operations against the objects in the
tablespace.
Note In SQL Server, the attributes of status, tablespace contents, and logging are set
at the database level and not the filegroup level. If an <strong>Oracle</strong> schema has tablespaces
with more than one value <strong>for</strong> these attributes, more than one database will have to be
created in SQL Server. For example, if a schema uses two tablespaces (one is
ONLINE and the other READ ONLY), then the two tablespaces have to be mapped to
two separate databases in SQL Server. The two databases can then be set to ONLINE
and READ_ONLY, respectively, using the state options available in SQL Server.
Gather the following in<strong>for</strong>mation <strong>for</strong> each of the datafiles in the tablespaces:
● File name
● File size
● File autoextensibility
● Maximum file size
● File auto extension increment
From the in<strong>for</strong>mation gathered about tablespaces and their datafiles, produce a map <strong>for</strong>
the databases, filegroups. and datafiles to be created in SQL Server as shown in Figure
6.2.
Create Databases <strong>for</strong> the Schema
To migrate the schemas from <strong>Oracle</strong>, databases are created in SQL Server <strong>for</strong> the
schemas. The databases will hold the schema objects and their data. This section
provides details on how to create databases in SQL Server.
To an <strong>Oracle</strong> DBA, creating a database means creating an entire database system that
contains control files, redo logs, data dictionary and temporary tablespace. In
SQL Server, these tasks are accomplished as part of the installation process. Hence
creating a database in SQL Server implies adding a user database to the already existing
system databases. Members of the fixed server roles sysadmin and dbcreator, or any
user with such privileges, can create a database. By default, the creator of the database
becomes the owner of the database.
Databases can be created either through Enterprise Manager or by using the CREATE
DATABASE T-SQL command. Only members of the sysadmin and dbcreator fixed
server roles or users who have been granted the CREATE DATABASE permission can
create a new database.
The following basic characteristics of the database have to be decided be<strong>for</strong>e creating a
database:

88
Developing: Databases — <strong>Migrating</strong> Schemas
●
●
●
●
●
●
Database name. Naming is constrained by the same rules as identifiers. A
meaningful name can be used and need not be the same as the name of the
<strong>Oracle</strong> schema being migrated.
Database owner. By default, the user who created the database becomes the
database owner (dbo). The owner can be changed using sp_changedbowner. To
mimic the <strong>Oracle</strong> schema, a login with the same name as the schema can be
made the database owner. A more detailed account of the implications of database
owner and database object owner is provided in the "Qualifiers and Name
Resolution" section later in this chapter.
Filegroups. These are the equivalents of tablespaces. A default primary filegroup
is created during the database creation.
Primary file. Every database is created with a default primary file belonging to the
default primary filegroup identifiable by the .mdf file name extension. The primary
file contains startup in<strong>for</strong>mation <strong>for</strong> the database and is used to store user data just
as any other datafile. Only the size and growth characteristics can be changed.
Secondary files. Additional files can be created in a database and associated with
the primary file group or any additional filegroup. The recommended file name
extension <strong>for</strong> secondary files is .ndf.
Transaction log. Hold rollback and redo in<strong>for</strong>mation required to recover the
database. Notice that, unlike <strong>Oracle</strong>, where rollback segments and redo logs are
central to the instance, every database has at least one transaction log.
Transaction logs are not part of any filegroup.
There are two ways to create a new database using Enterprise Manager: using the
Database Properties dialog and by using the Create Database Wizard. An example of
each of these procedures is provided here.
To create a database using the Database Properties dialog, follow these
steps:
1. Right-click Databases, and then left-click New Database, or right-click Server
(Server Name\Instance Name), then right-click New, and then left-click Database.
2. In the Database Properties window, enter the database name in the General
pane, the datafile and filegroup configuration in the Data Files pane, and the
transaction log configuration in the Transaction Log pane.
To create a new database using the Create Database Wizard, follow these
steps:
1. Expand a server group, and then expand the server in which to create a database.
2. On the Tools menu, click Wizards.
3. Expand Database.
4. Double-click Create Database Wizard.
5. Complete the steps in the wizard.
SQL Server also offers the CREATE DATABASE statement <strong>for</strong> creating databases.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 89
To create a database using the T-SQL CREATE DATABASE statement, use the
following syntax:
CREATE DATABASE database_name
[ ON
]
[ < filespec > [ ,...n ] ]
[ , < filegroup > [ ,...n ] ]
[ LOG ON { < filespec > [ ,...n ] } ]
[ COLLATE collation_name ]
[ FOR LOAD | FOR ATTACH ]
< filespec > ::=
[ PRIMARY ]
( [ NAME = logical_file_name , ]
FILENAME = 'os_file_name'
[ , SIZE = size ]
[ , MAXSIZE = { max_size | UNLIMITED } ]
[ , FILEGROWTH = growth_increment ] ) [ ,...n ]
< filegroup > ::=
FILEGROUP filegroup_name < filespec > [ ,...n ]
Configure the Databases
SQL Server is very similar to <strong>Oracle</strong> in its architecture and can be similarly configured. In
the discussion of system configuration options, several options that apply to the individual
databases but are set at the instance level are discussed. These options apply uni<strong>for</strong>mly
to all databases in the instance. In contrast, the following five different sets of options are
set at the database level and apply only to the targeted database.
● Auto options
● Cursor options
● Recovery options
● SQL options
● State options
These options are set using the ALTER DATABASE statement. A subset of the available
options can be set using Enterprise Manager. For a description of each of these options,
refer to http://msdn.microsoft.com/library/default.asp?url=/library/enus/createdb/cm_8_des_03_6ohf.asp.
If the source <strong>Oracle</strong> database is in NOARCHIVELOG mode, then the Simple Recovery
model is chosen <strong>for</strong> the database and the Full Recovery model is used if the <strong>Oracle</strong>
database is in ARCHIVELOG mode. If the <strong>Oracle</strong> tablespace is in read-only mode, then
the corresponding database created in SQL Server <strong>for</strong> that database has to be set to
read-only mode. Similarly, if the <strong>Oracle</strong> tablespace is offline, the corresponding database
can be taken offline after the migration is complete. If logging has been turned off <strong>for</strong> the
<strong>Oracle</strong> tablespace, then set the recovery model <strong>for</strong> the database to BULK_LOGGED.
An overview of the SQL Server recovery models is available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsqlmag2k/html/dbRecovery.asp.

90
Developing: Databases — <strong>Migrating</strong> Schemas
Create Filegroups <strong>for</strong> the Tablespaces
Filegroups in SQL Server are similar to tablespaces in <strong>Oracle</strong>. They are used to logically
group storage. When a database is created in SQL Server, it has one filegroup by
default. Based on the number of tablespaces that the schema uses, additional filegroups
have to be created in the newly created database.
Every database is created with a default primary filegroup that cannot be renamed or
dropped. As a result, one of the tablespaces will have to map to the primary filegroup
during migration. Additional secondary or user filegroups can be created with userspecified
names.
In <strong>Oracle</strong>, tablespaces are created as locally managed or dictionary managed. The type
of tablespace determines what storage parameters can be used. Creating filegroups is
similar to creating tablespaces under <strong>Oracle</strong> except that a filegroup is added to a specific
SQL Server database. Filegroups added to a database are called secondary filegroups,
and they can be added to any database. Datafiles are added separately from the
definition of a filegroup.
The following two options are available <strong>for</strong> creating a filegroup.
To create a filegroup using Enterprise Manager, follow these steps:
1. Expand Databases and right-click Properties of the database to which the
filegroup has to be added.
2. In the Database Properties window, left-click the Filegroups pane.
3. Type the filegroup name in the next available empty line that follows the filegroup
listing.
To add a filegroup to a database using T-SQL, execute the following
statement:
ALTER DATABASE database_name
ADD FILEGROUP filegroup_name
Add Datafiles to Filegroups
Storage has to be allocated in the SQL Server database to meet the requirements of the
schema being migrated. Datafiles are added to filegroups much as datafiles are added to
tablespaces in <strong>Oracle</strong>.
Adding a datafile in SQL Server is similar to the process used in <strong>Oracle</strong>. The
characteristics that can be set are related to auto-growth and are similar in function to
<strong>Oracle</strong>'s AUTOEXTEND feature. An additional characteristic that does not exist in <strong>Oracle</strong>
is the logical file name.
Datafiles can be added to the primary filegroup as well as any secondary filegroups either
through Enterprise Manager or using T-SQL.
To add a datafile by using Enterprise Manager, follow these steps:
1. Expand Databases and right-click Properties of the database to which the
filegroup has to be added.
2. In the Database Properties window, left-click the Data Files pane.
3. Add file in<strong>for</strong>mation in the next available empty line in the file listing. In the filegroup
column, select the filegroup name from the drop-down list. Also set the growth
characteristics <strong>for</strong> the file.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 91
To add a datafile to the primary filegroup or secondary filegroups using T-
SQL, use the following syntax:
ALTER DATABASE database
{ ADD FILE < filespec > [ ,...n ] [ TO FILEGROUP filegroup_name ]
where ::=
( NAME = logical_file_name
[ , FILENAME = 'os_file_name' ]
[ , SIZE = size ]
[ , MAXSIZE = { max_size | UNLIMITED } ]
[ , FILEGROWTH = growth_increment ] )
The TO FILEGROUP clause is not required to add datafiles to the primary filegroup.
Add Transaction Logs
In <strong>Oracle</strong>, in<strong>for</strong>mation on transactions and the changes they make is recorded in redo
logs. The redo logs are common to the entire instance. In SQL Server, transactional
changes are logged in the transaction log <strong>for</strong> the database whose objects are involved in
the transaction. A database is created with a single default transaction log. The default
transaction log has to be sized or new ones added based on the update activity against
the database.
Transaction logs can be added using a process similar to that used <strong>for</strong> adding datafiles,
as shown in the following procedure.
To add a datafile by using Enterprise Manager, follow these steps:
1. Expand Databases and right-click Properties of the database to which the
transaction log has to be added.
2. In the Database Properties window, left-click the Transaction Log pane.
3. Add the transaction log file in<strong>for</strong>mation in the next available empty line in the file
listing. Also set the growth characteristics.
To add a transaction log to a database using T-SQL, use the following syntax:
ALTER DATABASE database
{ ADD LOG FILE < filespec > [ ,...n ]
where ::=
( NAME = logical_file_name
[ , FILENAME = 'os_file_name' ]
[ , SIZE = size ]
[ , MAXSIZE = { max_size | UNLIMITED } ]
[ , FILEGROWTH = growth_increment ] )
Sample Schema Migration
This section describes an example schema migration using the four steps that have been
described earlier. The HR schema that is bundled with the <strong>Oracle</strong> installation software is
used to illustrate the steps in migrating a schema. The storage characteristics of the
tablespaces used by the HR schema have been modified to demonstrate some of the

92
Developing: Databases — <strong>Migrating</strong> Schemas
steps that would be common in migrations. This example is conducted using the features
and tools offered by <strong>Oracle</strong> and SQL Server and no third-party tool is employed.
1. Extract the schema storage requirements by following these substeps:
a. Produce a listing of tablespaces in which the schema has objects by using the
following statement:
SELECT DISTINCT tablespace_name "TABLESPACE NAME"
FROM dba_segments
WHERE owner = 'HR'
The owner in the statement is the name of the schema to be migrated. The
output is as follows:
TABLESPACE NAME
____________________________________________________________
EXAMPLE
INDX
b. Obtain the characteristics of each of the tablespaces using the following
statement:
SELECT tablespace_name, status, contents, logging
FROM dba_tablespaces
WHERE tablespace_name IN (SELECT DISTINCT tablespace_name
FROM dba_segments
WHERE owner = 'HR')
The owner in the statement is the name of the schema to be migrated. The
output is as follows:
TABLESPACE_NAME STATUS CONTENTS LOGGING
_______________________________________________________
EXAMPLE ONLINE PERMANENT LOGGING
INDX ONLINE PERMANENT LOGGING
c. Find the datafiles associated with the tablespaces using the following
statement:
SELECT tablespace_name "TS NAME",
file_name "FILE NAME", bytes/1024/1024 "SIZE MB",
autoextensible, maxbytes/1024/1024 "MAX SIZE MB",
increment_by*8192/1024/1024 "INCR SIZE MB"
FROM dba_data_files
WHERE tablespace_name IN (SELECT DISTINCT tablespace_name
FROM dba_segments
WHERE owner = 'HR')
The owner in the statement is the name of the schema to be migrated. The
output is as follows:
TS NAME FILE NAME SIZE AUTO MAX SZ INCR
________________________________________________________________________
EXAMPLE /u02/oradata/oracle92/example01.dbf 1000 YES 1000 100
EXAMPLE /u02/oradata/oracle92/example02.dbf 100 YES 1000 100
INDX /u03/oradata/oracle92/indx01.dbf 1000 YES 1000 50
INDX /u03/oradata/oracle92/indx02.dbf 50 YES 1000 50
Note The output has been re<strong>for</strong>matted to fit the page.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 93
Figures 6.1 and 6.2 provide schematics <strong>for</strong> the hierarchical organization of
storage in <strong>Oracle</strong> and SQL Server. Terminologies such as schema, database,
tablespace, filegroup, datafile and transaction log are used here. These figures
are modified in Figure 6.3 and Figure 6.4 to show instances <strong>for</strong> the
terminologies based on the HR schema:
Figure 6.3
<strong>Oracle</strong> storage map <strong>for</strong> sample HR schema
Figure 6.4
Equivalent SQL Server storage map <strong>for</strong> sample HR schema
Note Instead of putting the HR_DATA files under the required PRIMARY
filegroup, a separate HR_DATA filegroup can be created. This helps make the
filegroup and datafiles correlation easier.
2. Create and configure a new database in the SQL Server instance to hold the
schema objects.
a. Create the database.

94
Developing: Databases — <strong>Migrating</strong> Schemas
Create the database with storage attributes selected using the in<strong>for</strong>mation
gathered in step 1. The location of the files is dependent on the file system of
the target Windows® server on which SQL Server is installed.
Create the database using the following commands:
USE master
GO
CREATE DATABASE HRDATA
ON PRIMARY
( NAME='HRDATA_01',
FILENAME='E:\mssql\Mssql$corp1\data\hr_data_01.mdf',
SIZE=1000MB,
FILEGROWTH=0)
LOG ON
( NAME='HRDATA_LOG_01',
FILENAME='G: \mssql\Mssql$corp1\log\hr_log_01.ldf',
SIZE=10MB,
MAXSIZE=100MB,
FILEGROWTH=10)
GO
All filegroups and files (data and transaction log) can be added at the time of
creation of the database. The following is the syntax <strong>for</strong> doing this:
USE master
GO
CREATE DATABASE HRDATA
ON PRIMARY
( NAME='HRDATA_01',
FILENAME='E:\ mssql\Mssql$corp1\data\hr_data_01.mdf',
SIZE=1000MB,
FILEGROWTH=0),
( NAME='HRDATA_ 02',
FILENAME='E:\mssql\Mssql$corp1\data\hr_data_02.ndf',
SIZE=100MB,
MAXSIZE=1000MB,
FILEGROWTH=100MB),
FILEGROUP HR_INDX
( NAME='HRINDX_01',
FILENAME='F:\mssql\ Mssql$corp1\data\hr_indx_01.ndf',
SIZE=1000MB,
FILEGROWTH=0) ,
( NAME='HRINDX_02',
LOG ON
FILENAME='F:\mssql\Mssql$corp1\data\hr_indx_02.ndf',
SIZE=100MB,
MAXSIZE=1000MB,
FILEGROWTH=50MB)
( NAME='HRDATA_LOG_01',
FILENAME='G:\mssql\Mssql$corp1\log\hr_log_01.ldf',
SIZE=10MB,
MAXSIZE=100MB,

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 95
b.
GO
FILEGROWTH=10)
If the database is in ARCHIVELOG mode, then set the database to Simple
Recovery model; if it is in NOARCHIVELOG mode, then set to Full Recovery
model. If the tablespace corresponding to the database is in NOLOGGING
mode, set the database to Bulk-Logged Recovery model. For more in<strong>for</strong>mation
on the recovery models available in SQL Server, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/adminsql/ad_bkprst_4l83.asp
If the tablespace is in read only or offline mode, set the database to the
respective mode after migration of the schema and data is complete.
In this example, only the required primary filegroup with a primary file and the
transaction log are created as part of the database creation, and additional
filegroups and files are added in subsequent steps to enable demonstration of
functions such as adding filegroups and data files.
Configure the database.
The mode <strong>for</strong> the <strong>Oracle</strong> database can be found using the following query:
SELECT log_mode
FROM v$database
3. Add secondary filegroups.
The HR_INDX filegroup can be added using the following commands:
Use master
GO
ALTER DATABASE HRDATA
ADD FILEGROUP HR_INDX
GO
4. Add secondary datafiles.
The Filename, Current Size, Autoextensibility, Max Size, and Increment Size
values retrieved from the <strong>Oracle</strong> database are used in creating similar datafiles <strong>for</strong>
the HRDATA database. The primary file has already been created to match the
first file in the HR_DATA tablespace.
Create additional datafiles <strong>for</strong> the filegroups using the following commands:
ALTER DATABASE HRDATA
ADD FILE
( NAME='HRDATA_02',
FILENAME='E:\mssql\Mssql$corp1\data\hr_data_02.ndf',
SIZE=100MB,
MAXSIZE=1000MB,
FILEGROWTH=100MB)
GO
ALTER DATABASE HRDATA
ADD FILE
( NAME='HRINDX_01',
FILENAME='F:\mssql\Mssql$corp1\data\hr_indx_01.ndf',
SIZE=1000MB,
FILEGROWTH=0),
( NAME='HRINDX_02',
FILENAME='F:\mssql\Mssql$corp1\data\hr_indx_02.ndf',
SIZE=100MB,

96
Developing: Databases — <strong>Migrating</strong> Schemas
MAXSIZE=1000MB,
FILEGROWTH=50MB)
TO FILEGROUP HR_INDX
GO
In this example, the focus was restricted to migrating a single schema. When migrating
an entire database consisting of multiple schemas, the storage decisions will have to be
made using the best practices in storage allocation that were followed in <strong>Oracle</strong>. Place
temporary files on separate devices, separate data and log files, separate data and index
files, distribute I/O load across all available decisions, and separate tables with high
activity onto separate devices.
For descriptions of best practices <strong>for</strong> the storage component of SQL Server, refer to the
section titled "Optimizing the Storage Component" at
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/enus/part10/c3361.mspx.
Multiple schemas commonly share tablespaces in <strong>Oracle</strong> databases. Conceptually,
SQL Server databases can be viewed more like <strong>Oracle</strong> tablespaces, and objects from
multiple schemas can be created in the same database. From this perspective,
SQL Server databases function similarly to <strong>Oracle</strong> tablespaces. Figure 6.5 shows the
relation between schemas and tablespaces, where a schema's objects can be in multiple
tablespaces and a tablespace can have objects from multiple schemas.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 97
Figure 6.5
Sharing of tablespaces/databases by multiple schemas/owners

98
Developing: Databases — <strong>Migrating</strong> Schemas
Migrate the Schema Objects
In the "Migrate the Schema" section earlier in this chapter, the focus was limited to the
schema and its storage structures. This focus culminated in creation of databases with
appropriate filegroups and datafiles. The database merely <strong>for</strong>ms the shell in which the
schema objects will be enclosed. In this section, the following high-level steps in
migrating the schema objects are taken. These steps cover tasks related to schema
objects and security.
1. Create the schema owner.
2. Create the schema objects.
These steps are discussed in detail under the following subheadings.
Create the Schema Owner
A schema owner in <strong>Oracle</strong> is a user with privileges to create objects. This is true in
SQL Server as well. A user will have to be created in SQL Server in the database in
which the schemas objects will be created. The user is then given privileges in the
database to create objects and populate the data.
Users of <strong>Oracle</strong> and SQL Server databases can be classified as administrative users,
application users, and schema owners.
● Administrative users are users with special roles, such as database administrator
and security administrator.
● Application users are users who manipulate data in the owning user's tables.
● Schema owners are users who create and maintain objects related to an
application.
The basics <strong>for</strong> the creation of all the three types of users are the same and are discussed
in detail here. This knowledge is useful in creating application users and administrative
users in Chapter 7, "Developing: Databases — <strong>Migrating</strong> the Database Users."
A discussion of user accounts <strong>for</strong> each of the categories of users is presented in the rest
of this section. This discussion covers the differences in the logins between <strong>Oracle</strong> and
SQL Server and the associated authentication and password functionality.
Accounts
In terms of logins, all three types of users are created equal and are differentiated only by
the privileges they are bestowed. However, keeping with the practice of isolation and
autonomy of user databases, logins are implemented a little differently in SQL Server. It
is important to understand this difference be<strong>for</strong>e starting the migration of schemas and
users. SQL Server has two levels (not types) of logins. In addition to the instance login,
SQL Server requires separate logins be created <strong>for</strong> each database that the user or
schema needs to connect to.
To avoid confusion while referring to these various logins and accounts, this guide uses
the following terminologies commonly employed <strong>for</strong> the various logins in <strong>Oracle</strong> and
SQL Server.
● <strong>Oracle</strong> — Instance Level — user or username
● SQL Server — Instance Level — login (login ID)
● SQL Server — Database Level — user

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 99
Logins provide access to the instance of SQL Server, whereas the user account controls
privileges to objects inside the database. Figure 6.6 illustrates these relationships.
Figure 6.6
Migration of schema owner security from <strong>Oracle</strong> to SQL Server
The migration of a schema owner from <strong>Oracle</strong> to SQL Server requires a login be created
at the instance level and a user be created at the database level. The impact of this
architectural change is observed in how objects are qualified. In <strong>Oracle</strong>, a schema object
is identified in SQL statements using schema.object_name. While migrating to
SQL Server the schema object has to be fully qualified as database.owner.object_name.
Even though there is no difference between the login aspects of the different types of
users, only the schema owners and their migration are discussed here. A discussion of
application users and administrative users is postponed to the next task of the database
migration, migrating the user, which is discussed in Chapter 7, "Developing: Databases —
<strong>Migrating</strong> the Database Users."
Authentication
<strong>Oracle</strong> offers several options <strong>for</strong> the authentication of users. The two popular methods in
use are authentication by the database and authentication by the operating system. In
SQL Server, the database mode is called SQL Server Authentication Mode and the
operating system mode is called Windows Authentication Mode. The database
authentication modes in <strong>Oracle</strong> and SQL Server are closely compatible and use a user
name and password pair. The operating system authentication is quite different between
<strong>Oracle</strong> and SQL Server. <strong>Oracle</strong>'s operating system mode can only authenticate users
with local accounts on UNIX servers. Windows authentication <strong>for</strong> SQL Server is actually
per<strong>for</strong>med by the domain and not the local account on the Windows server.
Password Management
The <strong>Oracle</strong> RDBMS also provides password management functions, such as account
locking, password lifetime and expiration, password history, and password complexity
verification. The SQL Server RDBMS does not provide these services, and Windows
security is used to provide these features.
Hence the migration of <strong>Oracle</strong> user names to SQL Server logins and users is dependent
on the type of authentication in use as well as the requirements of password

100 Developing: Databases — <strong>Migrating</strong> Schemas
management. Table 6.1 shows the migration options <strong>for</strong> <strong>Oracle</strong> logins based on
authentication mode and the requirements on password management functionality.
Table 6.1: Login Migration Based on Authentication Requirements
<strong>Oracle</strong> Authentication
Mode
<strong>Oracle</strong> Password
Management
Database None Database
Database Required Windows
Operating system N/A Windows
SQL Server
Authentication Mode
As a practice, the schema owner login should not be used <strong>for</strong> connection by the
application instance (three-tier) or the application users (two-tier and three-tier). Hence a
SQL Server authenticated login would be appropriate. However, <strong>for</strong> clients who restrict
authentication to Windows mode only because of security concerns, a domain login
should be created <strong>for</strong> the schema owner.
Based on the security model — either Windows users or groups — review the guidelines
in th e "SQL Server 2000 SP3 Security Features and Best Practices" white paper
available at
http://www.microsoft.com/sql/techinfo/administration/2 000/security/securityWP.asp to
assist with implementation.
The following SQL statement can be used to extract the characteristics of the schema
owner account in the <strong>Oracle</strong> database:
SELECT du.username,
DECODE(du.password,'EXTERNAL','EXTERNAL','DB')
"AUTHENTICATION MODE",
du.default_tablespace, du.temporary_tablespace,
dp.resource_name, dp.limit
FROM dba_users du, dba_profiles dp
WHERE du.profile = dp.profile
AND dp.resource_type = 'PASSWORD'
SQL Server does not have a CREATE USER statement. There are two system stored
procedures to add logins <strong>for</strong> the two modes of authentication, and a separate stored
procedure to add users at the database level.
It is possible to add a new login <strong>for</strong> SQL Server using Enterprise Manager and system
stored procedures.
T o add a new login to a SQL Server instance using Enterprise Manager:
1. Expand the SQL Server Group and expand the Server (Server Name\Instance
Name).
2. Expand Security, right-click Logins, and then click New Login.
3. Provide the login name and authentication method in the General pane. System
and database level privileges can be granted through fixed roles under the Server
Roles pane. Object-level privileges can be granted either directly or through user
roles in the Database Access pane.
If the user is to be authenticated
by the domain, the correct domain should be
picked using the drop-down menu under Windows Authentication in the General
pane. If domain authentication is used, the name of the login is in the <strong>for</strong>m Domain
name\Domain login name. The default database that the user will connect to when
connecting to SQL Server can be set under the Defaults heading in the General
pane. This is different from the default tablespace setting <strong>for</strong> a user in <strong>Oracle</strong>.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 101
By checking the appropriate database, the new user can be granted privileges on specific
databases in the SQL Server instance by checking the appropriate database in the
Database Access pane. This action also creates user accounts of the same name in the
respective databases. For a schema owner, the db_owner role has to be granted <strong>for</strong> the
privilege of creating objects in the target database. The db_owner role has complete
administrative authority over the database and can be considered to be similar to the
<strong>Oracle</strong> dba role but restricted to a single SQL Server database. To give the SQL Server
database object owner equivalent of the resource role in <strong>Oracle</strong>, which grants DDL
privileges, the database role db_ddladmin can be used. SQL Server also has the
CREATE TABLE, CREATE TRIGGER, CREATE VIEW and CREATE PROCEDURE
roles that can be used to further curtail the capabilities of the schema owner.
To add a new Windows authenticated login to a SQL Server instance using T-
SQL, use the following syntax:
sp_grantlogin
[ @loginame = ] 'login_name'
where login_name is of the <strong>for</strong>m domain_name\domain_login_name
To add a new database authenticated login to a SQL Server instance using T-
SQL, use the following syntax:
sp_addlogin [ @loginame = ] 'login_name'
[ , [ @passwd = ] 'password' ]
[ , [ @defdb = ] 'database_name' ]
[ , [ @encryptopt = ] 'encryption_option' ]
where database_name specifies the database the login connects to after logging in
(default database). While passwords are encrypted in SQL Server by default, the option
exists to skip encryption to allow custom password encryption by the application using a
different algorithm.
A user account should be created separately <strong>for</strong> the login in the default database.
To create a user account to a SQL Server database using T-SQL, use the
following syntax:
sp_grantdbaccess [ @loginame = ] 'login_name'
[, [ @name_in_db = ] 'user_name'
The name chosen <strong>for</strong> the user account can be different from that <strong>for</strong> the login account.
Some of the other characteristics associated with a user or schema owner in <strong>Oracle</strong> that
need to be addressed are:
● De fault tablespace. In SQL Server, a default filegroup can be set <strong>for</strong> each
da tabase which has the same function and effect as the <strong>Oracle</strong> default tablespace
using the following syntax.
ALTER DATABASE database_name
MODIFY FILEGROUP filegroup_name DEFAULT
● Temporary tablespace. By default, all users of SQL Server use the tempdb
database.
● Tablespa ce quota. Quotas cannot be set in SQL Server at the instance,
database, or filegroup
level.

102 Developing: Databases — <strong>Migrating</strong> Schemas
Create the Schema Objects
This section discusses the migration of the schema objects from <strong>Oracle</strong> to SQL Server.
The following is a complete list of objects that are classified by <strong>Oracle</strong> as schema objects:
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Tables
Clusters
Object Tables
Index-organized Tables
Constraints
Triggers
Indexes
Views
Object Views
Functions
Stored Procedures
Packages
Synonyms
Sequences
Database Links
Object Types
Table 6.2 provides a high-level view of how the <strong>Oracle</strong> schema objects map to
SQL Server.
Table 6.2: SQL Server Objects that Replace <strong>Oracle</strong> Schema Objects
<strong>Oracle</strong>
Table
Cluster
Object Table
Index-organized Table
Constraints
Triggers
Index
View
Object View
Synonym
Sequence
Database Link
Object Types
Procedure
Function
Package
SQL Server
Table
Table
Cluster
Table (with clustered index)
Constraints
Triggers
Index
View
N/A
View
Identity
Linked Server
N/A
Stored Procedure
Function
Stored Procedure

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 103
Some of these objects fall under broader classifications, such as tables and views. While
the discussion of some of the objects is beyond the scope of this guide, the following are
covered in this chapter:
● Tables
● Comments
● Constraints
● Triggers
● Views
● Indexes
● Stored Programs, including functions, stored procedures, and packages
● Objects not found in SQL Server, including sequences, synonyms, and database
links
The data definition language (DDL) <strong>for</strong> defining objects is in accord with ANSI SQL
standards. Because both <strong>Oracle</strong> and SQL Server maintain compliance with SQL-92 and
SQL-99 standards, the syntax <strong>for</strong> defining objects is very similar.
Identifiers and Naming
<strong>Oracle</strong> object and column names are generally not case-sensitive. However, no
assumptions should be made because they can be <strong>for</strong>ced to be case sensitive by
delimiting them (enclosing them) in double quotation marks (“). For example, the name
TRANSACTION_DATE can be made case sensitive by using “Transaction_Date”. Also,
quotes can be used to create irregular identifiers such as “Transaction Date” (with a blank
space). Similarly, object and column names in SQL Server are not case-sensitive by
default, but this default behavior can be changed by modifying configuration settings.
Nonstandard or delimited identifiers can be created just as in <strong>Oracle</strong> using either
quotation marks (“) or brackets ([ ]). Read the "Using Identifiers" section in SQL Server
Books Online <strong>for</strong> rules about the construction and use of regular and delimited identifiers.
<strong>Oracle</strong> table and column names are stored in data dictionary tables as uppercase strings
unless <strong>for</strong>ced to be case sensitive using delimiters. In contrast, the default SQL Server
behavior is to store them in the case used when they were created. Because scripts <strong>for</strong>
use with <strong>Oracle</strong> are written with such expectations, it is recommended you use
uppercase identifiers while creating the objects in SQL Server (without <strong>for</strong>cing case by
using delimiters).
Qualifiers and Name Resolution
The names of objects are influenced by uniqueness requirements. <strong>Oracle</strong> object names
have to be unique <strong>for</strong> a schema. In SQL Server, the same owner can own objects of the
same name in two different databases, that is, the combination of owner.table_name
needs to be unique only within a database. Hence objects are qualified in <strong>Oracle</strong> as
[schema.]object_name
whereas in SQL Server the complete qualifier is
[database.]owner.]object_name
Rules have been established in both <strong>Oracle</strong> and SQL Server <strong>for</strong> resolving an
object_name that is not qualified.
In <strong>Oracle</strong>, the resolution is governed by synonyms and the concept of namespaces.
Tables, views, snapshots, sequences, synonyms, procedures, functions, and packages
are in a single namespace. Triggers, indexes, and clusters each have their own individual

104 Developing: Databases — <strong>Migrating</strong> Schemas
namespace. The following order is used to resolve an object that falls in the table
namespace:
1. Table namespace of current user's schema
2. Private synonym in the current user's schema
3. Public synonym
The order is different in SQL Server, and resolution occurs as:
1. Current user's schema in the current d atabase (set with USE statement)
2. Database owner dbo of the current database
These relationships h ave to be taken care of during the migration of the users and
application s. Because a user can own obj ects of the same name in multiple databases
and different users can hav e objects of the same name in the same database, it is
recommended that both database name and owner name be used to qualify objects in
SQL Server.
C hanging object identifiers to meet SQL Server standards can affect the applications
using them. However, changing the names of certain objects, such as indexes and
constraints, could be transparent to the business applications. Given the rules <strong>for</strong> naming
in <strong>Oracle</strong> and SQL Server, there is no need to change the names of any of the identifiers.
Note It is recommended that all objects in the migrated SQL Server database be
qualified by database and owner because the rules <strong>for</strong> resolving names could
otherwise lead to the wrong object.
Working with Data Types
<strong>Oracle</strong> and SQL Server offer two types of data types: native data types and user defined
data types. The data types that are provided by the DBMS are called native data types or
system data types. There are four basic cl asses of data: character, numeric, datetime,
and binary. In addition, both <strong>Oracle</strong> and SQL Server have a few data types that are
unique to each syste m. Tables 6.3 through 6.5 provide a complete mapping of <strong>Oracle</strong>
data types to SQL Server data types that you should use when migrating.
Care has been taken to suggest the closest possible data type both in terms of type of
data being considered as well as the scale or size of the data that has to be
accommodated. A bad ch oice in data type can lead to a lot of problems during data
m igration. The choice has to be driven by the definition in the source table and not by the
data in the table. Even when data migration is successful, the application may fail some
time in the future because the table canno t handle data that it was originally designed <strong>for</strong>.
SQL Server data types can com<strong>for</strong>tably provide a close equivalent of the <strong>Oracle</strong> data
types, and over sizing is not recommende d because it drives up the row size and the
storage requirements and will affect per<strong>for</strong>mance.
Character or Alphanumeric Data
Note that <strong>Oracle</strong> and SQL Server differ in the parameter used to define Char (Nchar),
and Varchar (NVarchar) columns. For example, when CHAR(n) is used to specify a
column data type in <strong>Oracle</strong>, n represents the number of characters, while in SQL Server it
represents number of bytes.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 105
Table 6.3 provides the SQL Server data types to use when migrating <strong>Oracle</strong> character
data.
Table 6.3: SQL Server Equiv alent <strong>for</strong> <strong>Oracle</strong> Character-based Data Types
<strong>Oracle</strong> Data
Type
Max Size (Bytes)
SQL Server Data
Type
Char 2000 Char 8000
NChar 2000 NChar 4000
Varchar 4000 Varchar 8000
NVarchar 4000 NVarchar
4000
Varchar2 4000 Varchar2 8000
NVarchar2 4000 NVarchar 4000
LONG 2 31 Text 2 31 –1
CLOB 2 32 Text 2 31 –1
NCLOB 2 32 NText 2 30 –1
Numeric Data
Max Size (Bytes)
<strong>Oracle</strong> has only one numeric data type, NUMBER, that can store zero, positive, negative,
fixed, and floating point numbers, with a precision (p) of 38 digits and a scale (s) ranging
from -84 to 127. Synonyms, such as NUMERIC, DECIMAL, FLOAT, INTEGER, can be
used. SQL Server, on the other hand, has eight distinct named numeric data types that
constrain the range of values they can hold. SQL Server also has three other data types
that are of the number category: BIT, MONEY, and SMALLMONEY. Table 6.4 compares
numeric data types in <strong>Oracle</strong> and SQL Server.
Table 6.4: Finding Closest SQL Server Equivalent to <strong>Oracle</strong> Numeric Data Types
<strong>Oracle</strong>
Number(19,0)
Int or Number(10,0)
SmallInt or Number(6,0)
Number(3,0)
Number(p,0)
Float or DoublePrecision or Number(38)
Real or Number(19) or Float(63)
Number(19,4)
Number(10,4)
SQL Server
BigInt
Int
SmallInt
TinyInt
Decimal or Numeric(p,s)
Float
Real or Float(24)
Money
SmallMoney
Binary Data
<strong>Oracle</strong>'s BLOB replaces the older RAW and LONG RAW data types. The IMAGE data
type in SQL Server is the closest equivalent <strong>for</strong> <strong>Oracle</strong>’s BLOB data type, and it can
support data up to 2 GB in size. The BINARY data type is a fixed size column while
VARBINARY is its variable size counterpart. Table 6.5 provides SQL Server equivalents
<strong>for</strong> <strong>Oracle</strong> binary data types.

106 Developing: Databases — <strong>Migrating</strong> Schemas
Table 6.5: SQL Server Equivalent <strong>for</strong> <strong>Oracle</strong> Binary Data Types
<strong>Oracle</strong> Data
Type
Max Size
SQL Server Data
Type
BLOB 4 GB Image 2 GB
Raw 2000 bytes Image 2 GB
Long Raw 2 GB Image 2 GB
BFile 4 GB (file pointer) N/A
Raw(n) 2000 bytes Binary(n) or
VarBinary(n)
Max Size
8000 bytes
For more in<strong>for</strong>mation about designing <strong>for</strong> and implementing BLOBs in SQL Server, refer
to http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/enus/part3/c1161.mspx.
Date and Time
Historically, <strong>Oracle</strong> has had one data type, Date, which stores both date and time
in<strong>for</strong>mation. In <strong>Oracle</strong> 9i, three new date and time data types have been added to
address these shortcomings. The Timestamp data type can store fractional seconds up
to 9 digits of precision. Time zone aware data types, Timestamp With Time Zone and
Timestamp with Local Time Zone, are also available and they can handle daylight
saving time.
SQL Server has two data types: DateTime and SmallDateTime. DateTime can
represent the date and time in the range January 1, 1753 to December 31, 9999 with a
precision of one-three hundredth of a second. SmallDateTime can represent dates in the
range January 1, 1900, through June 6, 2079 with a precision limited to the minute. The
<strong>Oracle</strong> Date and Timestamp data types should be migrated to the DateTime data type.
T he other two time zone aware data types do not have an equivalent in SQL Server.
User Defined Types
A simple implementation of user-defined data types is the capability to define data types
as simple variations of the primitive data types. For example, defining a data type ZIP as
a native type Char, with a length of 5, prov ides a uni<strong>for</strong>m definition that avoids any
ambiguity between designers and developers.
For example, the user-defined data type ZIP can be created as follows:
CREATE TYPE zip_type AS OBJECT (zip char(5))
/
In SQL Server, the user-defined ZIP data type is:
EXEC sp_addtype zip_type, 'char(5)'
User-defined data types can be recursively used to define other user-defined data types.
However, SQL Server does not support object types and their collections.
Tables
The definition of the table data structure is the same, both in concept and <strong>for</strong>m, in both
<strong>Oracle</strong> and SQL Server. This can be attributed to compliance with ANSI SQL standards.
When designing the table data structure, data integrity is as important as data access. To
serve these purposes, <strong>Oracle</strong> provides several options <strong>for</strong> how data can be organized
within the table. Table 6.6 summarizes them:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 107
Table 6.6: <strong>Oracle</strong> and SQL Server Table Types Compared
<strong>Oracle</strong>
Heap-Organized Table
Clustered Table -
Partitioned Table -
Nested Table -
Temporary Table
External Table -
Object Table -
Index-Organized Table
SQL Server
Heap
Temporary Table
Clustered Index
The most common implementation of the table object is, in its basic <strong>for</strong>m, the heap-
is the focus of the remainder of this organized table, and this table object section.
The CREATE TABLE syntax, which creates a simple heap organized table, has three
major parts:
● Table name
● Body (enclosed in parenthesis) — column name, column properties (data type,
defaults, inline column constraints), out-of-line column constraints, table
constraints
● Storage specification
Table 6.7 compares the structural composition of the CREATE TABLE syntax in <strong>Oracle</strong>
and SQL Server.
Table 6.7: High-level Comparison of Table Definition Syntax
<strong>Oracle</strong>
SQL Server
CREATE TABLE
CREATE TABLE
[schema.]table_name
[[database.]owner.]table_name
(
column name
column data type
(
column name
column data type
default expression
column constraint, …
defaults expression
column constraint, …
out of line or table constraint
out of line or table constraint
) )
[storage_specification]
[storage_specification]
The steps <strong>for</strong> creating a table in SQL Server using both Enterprise Manager and T-SQL
are provided in the following procedures.
To create a new table using Enterprise Manager, follow these steps:
1. Expand Server, then Databases, and then the target database.
2. Right-click Tables and select New Table. A new window appears <strong>for</strong> adding
columns and other objects, such as indexes and constraints related to the table.
This window is called the Table Designer tool.
3. Add new columns in the top grid (column definition grid) along with the column data
type and nullability constraint. Some of the column's properties, such as Default

108 Developing: Databases — <strong>Migrating</strong> Schemas
Value, can be provided in the Columns pane at the bottom. The Identity property
is discussed in greater detail under the "Sequences" heading.
4. Click the Table and Index Properties button found on the Columns window, or
right-click anywhere in the column definition grid and select Properties to bring up
the table Properties window, which can be used to specify table level properties,
constraints, and indexes.
To create a new table using T-SQL, use the following syntax:
CREATE TABLE
[ database_name.[ owner ] . | owner. ] table_name
( { < column_definition >
| column_name AS computed_column_expression
| < table_constraint > } [ ,...n ]
)
[ ON { filegroup | DEFAULT } ]
[ TEXTIMAGE_ON { filegroup | DEFAULT } ]
where < column_definition > ::= column_name data_type
[ COLLATE < collation_name > ]
[ [ DEFAULT constant_expression ]
The following list covers each of the components of the CREATE TABLE syntax:
● Table and column name. As is the case in the "Identifiers and Naming" section
earlier in this chapter, <strong>Oracle</strong> table and column names do not need any changes
when migrated to SQL Server.
● Column data type. The column data type <strong>for</strong>ms part of the table definition and is
an integral part of creating a table. For the sake of reducing the complexity in the
discussion of tables (because there are several components to be dealt with here),
the discussion of data types has been covered in the section "Working with Data
Types" earlier in this chapter.
● Default value. The rules <strong>for</strong> specifying default value are very similar in both
databases, and default values can be specified in most cases. One of the
difficulties that may be encountered while migrating to SQL Server is the lack of an
equivalent <strong>Oracle</strong> system function used <strong>for</strong> defining the default values. In
SQL Server, a default value cannot be specified <strong>for</strong> a column of type timestamp.
While <strong>Oracle</strong> treats defaults as a property of the column, SQL Server defines
defaults as a constraint.
● Constraints. A detailed discussion of constraints appears in the "Constraints"
section later in this chapter.
● Storage properties. A detailed discussion of the storage architecture appears in
the "Migrate the Storage Architecture" section in Chapter 5, Developing:
Databases — <strong>Migrating</strong> the Database Architecture." The only storage property that
can be specified during table creation is the filegroup name. If a filegroup is not
specified, then the table is created in the database's default filegroup.
In the Tab le and Index Properties window, the Table Filegroup drop-down list
can be used pick a filegroup from which the table will be allocated storage. The
T ext Filegroup drop-down list can be used to specify the fi legroup to be used <strong>for</strong>
large objects, such as text and image
columns.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 109
Not e In <strong>Oracle</strong> and SQL Server, tables can be created based on the definition of other
tables.
In <strong>Oracle</strong>, this is accomplished using the following statement
CREATE TABLE table_name AS SELECT …
The same can be achieved in SQL Server using the following syntax:
SELECT … INTO table_name
The various table types found in <strong>Oracle</strong> can be migrated as described in the following list.
Detailed knowledge of each table type is not necessary to accomplish the migration.
● Clustered table. Sometimes simply called clusters, these do not have an
equivalent in SQL Server. The tables in the cluster have to be created as regular
heaps. If rows are frequently accessed using a range search, a clustered index
may be created on such column(s). Only one clustered index can be created on a
table.
This migration of clustered tables in <strong>Oracle</strong> to heaps in SQL Server will be
transparent to the application and users.
● Partitioned table. SQL Server does not have the partitioned table option.
However, SQL Server offers partitioned views that are built using the same
strategy that was used in <strong>Oracle</strong> (be<strong>for</strong>e <strong>Oracle</strong> 8i) when true horizontal
partitioning was not available. This involves creating separate tables <strong>for</strong> each of
the partitions, with a check constraint on the partition key column(s) to en<strong>for</strong>ce a
range of values. A partitioned view is then created as a union of all the constituent
tables. Details on the implementation of partitioned views can be found under the
topic "Creating a Partitioned View" in SQL Server Books Online.
This migration of partitioned tables in <strong>Oracle</strong> to heaps in SQL Server will be
transparent to the application and users.
● Nested table. SQL Server does not support nested tables. The implementation
strategy used in <strong>Oracle</strong> can be imitated in SQL Server <strong>for</strong> migrating them. The
nested table column can be separated out into its own table (denormalized with
similar definition) with a unique identifier used to connect the rows from the parent
table to the child table.
● Minor modification to retrieve the data from the child table will be required in
the code to accommodate this change.
● Temporary table. SQL Server supports both local and global temporary tables.
SQL Server's local temporary table is equivalent to <strong>Oracle</strong>'
s global temporary table
( with the ON COMMIT PRESERVE ROWS ) because it provides the same level of
isolation from other sessions.
Table 6.8 shows the syntax <strong>for</strong> creating temporary tables in SQL Server.
Table 6.8: SQL Statements <strong>for</strong> Creating Temporary Tables in <strong>Oracle</strong> and
SQL Server
<strong>Oracle</strong>
CREATE GLOBAL TEMPORARY TABLE
table_name …
ON COMMIT DELETE|PRESERVE ROWS
SQL Server
CREATE TABLE
# table_name
Local temporary tables in SQL Server work identically to <strong>Oracle</strong> temporary tables
and do not warrant any changes in the code. But the code pieces that assume that
rows are deleted automatically when working with tables with ON COMMIT

110 Developing: Databases — <strong>Migrating</strong> Schemas
●
●
●
●
DELETE ROWS has to be modified to include a DELETE statement in
compensation.
External table. SQL Server does not have the option to create tables whose data
resides in flat files. Hence such data will have to be imported into the database.
Object table. SQL Server does not support objects. The strategy <strong>for</strong> migrating
object tables to SQL Server is to flatten (absorb) the object column into the table
itself. This will induce only a small change in the SQL code that accesses the data.
Index-organized table. The SQL Server clustered indexes are very similar to the
index-organized table (IOT), where the index is merged into the table instead of
two separate structures. Clustered indexes are implemented in a fashion similar to
index-organized tables and have very similar features.
Index-organized tables are sorted on the primary key. To migrate an indexorganized
table to SQL Server, the CLUSTERED keyword can be used in
conjunction with the PRIMARY KEY constraint, as described in the syntax given in
Table 6.9.
In SQL Server, a clustered index can be created on any column(s) of a table, but it
has to be created using the CREATE INDEX clause. If a clustered index is created
with non-unique columns, SQL Server en<strong>for</strong>ces uniqueness by adding an
uniqueifier to the rows with duplicates.
In most cases, the primary key would be the ideal column <strong>for</strong> a clustered index. An
identity column can also be used <strong>for</strong> a clustered key. In SQL Server, it is
recommended that every table should have a clustered index.
Note Clustered indexes should be created be<strong>for</strong>e creating any nonclustered
indexes. If clustered indexes are planned <strong>for</strong> a table, defer creation of nonclustered
indexes (as part of PRIMARY KEY or UNIQUE constraint definition) during the
table creation in this step.
Table 6.9 shows the SQL Server options <strong>for</strong> creating the equivalent of an <strong>Oracle</strong>
index-organized table.
Table 6.9: SQL Statements <strong>for</strong> Creating Index-organized Tables in <strong>Oracle</strong> and
SQL Server
<strong>Oracle</strong>
CREATE TABLE table_name
(
column_name datatype,
…
)
ORGANIZATION INDEX
[ storage_definition ]
SQL Server
CREATE TABLE table_name
(
column_name datatype,
[ CONSTRAINT constraint_name ]
PRIMARY KEY CLUSTERED
[ ON filegroup | DEFAULT ]
)
or
CREATE [UNIQUE] CLUSTERED INDEX
index_name
ON table_name
( column_name [, …] )
[ ON filegroup | DEFAULT ]
Migration of tables is complicated by the referential integrity (<strong>for</strong>eign key) constraints
between tables. There are two options <strong>for</strong> how to migrate tables. Option one is to create

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 111
tables in a specific order based on the <strong>for</strong>eign key constraints (parent tables first). Option
two is to create tables in any order, leaving out the <strong>for</strong>eign key constraints, and adding
them after all the tables have been created.
Comments
This is a property of the table that is often not documented and, hence, easily overlooked
during a migration. SQL Server does not have a comment property associated with tables
and columns. However, SQL Server provides the capability to associate custom
properties, called extended properties, with objects.
Comments can be added to tables and columns using Enterprise Manager and system
stored procedures.
To add a comment on tables and columns using Enterprise Manager, follow
these steps:
1. Expand Server, then Databases, and then the target database.
2. Left-click Tables to display the list of tables.
3. Right-click the target table and left-click Design Table. This brings up the Table
Designer.
4. Comments <strong>for</strong> the individual columns can be added in the Description field of the
Columns pane at the bottom of the Table Designer window.
5. In the Table Designer window, click the Table and Index Properties button found
above the grid.
6. Left-click the Tables pane of the Properties window. Table comments can be
added in the Description field in the Tables pane.
The sp_addextendedproperty system stored procedure can be used to add any userdefined
metadata to any column in SQL Server. This (and any other properties that are
a dded to the column) can be retrieved with the fn_listextendedproperty function.
Table 6.10 shows the syntax <strong>for</strong> adding comments at the table and column levels.
Table 6.10: Comparison of Functionality
<strong>for</strong> Adding Comments in <strong>Oracle</strong> and
SQL Server
<strong>Oracle</strong>
COMMENT ON TABLE table_name IS
comment
COMMENT ON COLUMN
table_name.column_name IS comment
SQL Server
sp_ addextendedproperty 'comment',
comment,
'user', schema_name, 'table',
table_name
sp_addextendedproperty 'comment',
comment,
'user', schema_name, 'table',
table_name, 'column', column_name
Constraints
Constraints are data integrity rules that are defined on the columns of a table to en<strong>for</strong>ce
certain business rules. As an example, the specification of data types in the definition of
the column constitutes a constraint.

112 Developing: Databases — <strong>Migrating</strong> Schemas
Table 6.11 compares the availability of various types of constraints in <strong>Oracle</strong> and
SQL Server:
Table 6.11: Constraints Available in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong>
NOT NULL
UNIQUE
PRIMARY KEY
FOREIGN KEY
CHECK
SQL Server
NOT NULL
UNIQUE
PRIMARY KEY
FOREIGN KEY
CHECK
The functionality provided by <strong>Oracle</strong> and SQL Server to define constraints on columns,
including the syntactic use of inline (or column) constraints and out-of-line (or table)
constraints, is almost identical. The syntax in Table 6.12 illustrates the similarity. Out-of-
have to be used when more than one column is involved in the definition
line constraints
of a constraint. If a constraint name is not specified using the CONSTRAINT clause, a
default name is generated by the database. The default names given by <strong>Oracle</strong> are of the
<strong>for</strong>m SYS_Cn where n is a unique number generated by <strong>Oracle</strong>. The names provided by
SQL Server are more suggestive with respect to the type of constraint (<strong>for</strong> example, CK,
PK, and FK) and the table and column(s) involved. The syntax <strong>for</strong> the two options <strong>for</strong>
defining constraints in SQL Server is provided in Table 6.12.
Table 6.12: T-SQL Statements <strong>for</strong> Defining Inline and Out-of-line Constraints in
SQL Server
Inline (Column) Constraint
CREATE TABLE table_name
(column_name datatype
[ CONSTRAINT constraint_name ] [ [
NOT ] NULL | UNIQUE | PRIMARY KEY |
CHECK (condition) | REFERENCES
ref_table (ref_column) ]
)
Out-of-line (Table) Constraint
CREATE TABLE table_name
(column_name datatype,
[ CONSTRAINT constraint_name ] [
UNIQUE (column_name [, ...]) |
PRIMARY KEY (column_name [, ...]) |
CHECK (condition) | FOREIGN KEY
(column_name [, ...]) REFERENCES
ref_table (ref_column) ]
)
NOT NULL Constraint
In both <strong>Oracle</strong> and SQL Server, the NOT NULL constraint can be specified only as a
column constraint. More often than not, a constraint name is not provided while creating
NOT NULL constraints.
When a column has not been specifically defined as NOT NULL in <strong>Oracle</strong>, it defaults to
being nullable. When NULL or NOT NULL is not specified explicitly <strong>for</strong> a column
definition, SQL Server uses the default of NOT NULL. For ANSI compatibility, setting the
database option ANSI_NULL_DEFAULT to ON changes the database default to NULL. In
SQL Server, database and session settings can override the nullability specified by the
column definition.
Some DBAs like to use meaningful names <strong>for</strong> all constraints so that errors referring to
cons traint violations can be easily recognized in error messages. When migrating from
<strong>Oracle</strong>, NOT NULL constraints with user-defined
names can be queried using the
following syntax:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 113
CREATE TABLE NOT NULL CONSTRAINTS
(constraint_name varchar2(30),
owner varchar2(30)
table_name varchar2(30),
column_name varchar2(30),
search_condition clob);
INSERT INTO NOT NULL CONSTRAINTS
SELECT dc.constraint_name, dc.owner, dc.table_name, dcc.column_name,
to_lob(dc.search condition)
FROM dba_constraints dc, dba_cons_columns dcc
WHERE dc.owner = dcc.owner
AND dc.constraint_name = dc c.constraint_name
AND dc.constraint_type = 'C'
AND dc.owner = 'user_name';
COMMIT;
SELECT *
FROM NOT_NULL_CONSTRAINTS
WHERE dbms_lob.instr(search_condition, 'IS NOT NULL',1,1) > 0;
NOT NULL constraints can be created on tables using Enterprise Manager and the
CREATE TABLE T-SQL statement.
To create a NOT NULL constraint using Enterprise Manager, follow these
steps:
1. In the Table Designer, the Allow Nulls column should be unchecked <strong>for</strong> en<strong>for</strong>cing
the NOT NULL constraint and checked to indicate a NULL constraint.
To create a NOT NULL constraint Using T-SQL, use the following syntax:
CREATE TABLE table_name
(
column_name datatype [ CONSTRAINT constraint_name ]
{ NULL | NOT NULL },
…
)
Check Constraint
Both <strong>Oracle</strong> and SQL Server use the same syntax to define check constraints; both also
have similar restrictions in its usage. CHECK constraints can be defined on a single
column or multiple columns at the table level. The conditions specified in the CHECK
clause should evaluate to a Boolean value of TRUE or FALSE. The conditions can refer
to other columns but are restricted to the row being modified.
Both <strong>Oracle</strong> and SQL Server allow multiple CHECK constraints on a column. A column
constraint can only reference the column it is being created on. Each constraint can have
multiple concatenated conditions. The process to create check constraints on tables
using Enterprise Manager and T-SQL is provided in the following procedures.
To create a check constraint using the Table Designer in Enterprise Manager,
follow these steps:
1. In the Table Designer, click the Manage Constraints button to bring up the table
Properties window with the Check Constraints pane active.
2. Click the New button to add a constraint.

114 Developing: Databases — <strong>Migrating</strong> Schemas
3. A name of the type CK_table_name is inserted by the system in the Constraint
name box. The constraint name can be changed to match the name given in
<strong>Oracle</strong> only after entering a valid condition in the Constraint expression box.
To create a check constraint using T-SQL, use the following syntax:
Table 6.13 provides the syntax <strong>for</strong> the two alternative <strong>for</strong>mats available in SQL to specify
CHECK constraints during table creation. The syntax is the same in <strong>Oracle</strong> and
SQL Server.
Table 6.13: T-SQL Statements <strong>for</strong> Defining Inline and Out-of-line CHECK
Constraints in SQL Server
Inline (Column) Constraint
CREATE TABLE table_name
(column_name datatype
[ CONSTRAINT constraint_name ] CHECK
(condition)
…
)
Out-of-line (Table) Constraint
CREATE TABLE table_name
(column_name datatype,
…
[ CONSTRAINT constraint_name ] CHECK
(condition)
)
Unique Constraints
<strong>Oracle</strong> and SQL Server use indexes to en<strong>for</strong>ce unique constraints. In <strong>Oracle</strong>, if a unique
or non-unique index already exists on the constraint columns, the index is used to
en<strong>for</strong>ce the constraint without creating new ones. There<strong>for</strong>e, if a user-defined index is
preferred instead of a system-defined (and named) one, it is recommended that the index
be created first. Unless a clustered index is explicitly specified, SQL Server creates a
nonclustered index on the unique key column(s).
An important difference in the implementation of the UNIQUE constraint is <strong>Oracle</strong> allows
multiple rows with NULL values in all the columns making up the unique constraint,
whereas SQL Server allows only one row to have a NULL value <strong>for</strong> the UNIQUE column.
In <strong>Oracle</strong>, the UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints can be a
composite of up to 32 columns, while in SQL Server the limit is 16.
Unique constraints can be created using Enterprise Manager as well as T-SQL
statements.
To create a UNIQUE constraint using Enterprise Manager, follow these steps:
1. In the Table Designer, click the Table and Index Properties button.
2. Select the Indexes/Keys tab and click New. A system-assigned index name
appears with the column name, column order, index filegroup, and fill factor filled in
using defaults. You will need to replace these default values with your own.
3. Enter the name of the new index in the Index name text box and select the
columns to be included in the constraint in the correct order in the grid.
4. Check the Create UNIQUE check box and select the Constraint radio button.
5. Check the Create as CLUSTERED box if a clustered index is to be used to
en<strong>for</strong>ce the constraint. If a nonclustered index is chosen, a filegroup can be
specified <strong>for</strong> the index. Because only a single clustered index can be created on a
table, and the filegroup cannot be changed from the primary filegroup.
6. The equivalent of <strong>Oracle</strong>'s PCTFREE can be specified <strong>for</strong> the index that will be
created to en<strong>for</strong>ce the constraint in the Fill Factor box.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 115
To create a UNIQUE constraint using T-SQL, use the following syntax:
The only syntactic difference in the UNIQUE constraint definition between <strong>Oracle</strong> and
SQL Server is with the USING INDEX clause used to define the index that en<strong>for</strong>ces the
constraint. The USING INDEX clause of <strong>Oracle</strong> has an equivalent in SQL Server and can
be used with both column and table constraints. The syntax <strong>for</strong> table constraint is
described in Table 6.14.
Table 6.14: SQL Statements <strong>for</strong> Defining UNIQUE Constraints in <strong>Oracle</strong> and
SQL Server
<strong>Oracle</strong>
SQL Server
CREATE TABLE table_name
CREATE TABLE table_name
(
(
column_name datatype,
column_name datatype,
…,
…,
[ CONSTRAINT constraint_name ] [ CONSTRAINT constraint_name ]
UNIQUE ( column_name [, …] ) UNIQUE [ CLUSTERED | NONCLUSTERED ]
[ USING INDEX [ TABLESPACE
( column_name [, …] )
tablespace_name ]
[ WITH FILLFACTOR = fillfactor ]
[ storage_definition ] ]
[ ON FILEGROUP { filegroup |
DEFAULT } ]
Primary Key Constraint
PRIMARY KEY constraints have all the characteristics of UNIQUE constraints, with the
additional restriction that all primary key columns be NOT NULL. <strong>Oracle</strong> creates a
UNIQUE index and a NOT NULL constraint to implement PRIMARY KEY constraints.
With <strong>Oracle</strong> 9i, an existing non-unique index may be used to en<strong>for</strong>ce the primary key
constraint. In SQL Server, if a clustered index does not already exist on the table, or a
nonclustered index is not explicitly specified, a unique, clustered index is created to
en<strong>for</strong>ce the PRIMARY KEY constraint. The following procedures demonstrate that it is far
easier to use T-SQL than Enterprise Manager when it comes to creating a PRIMARY
KEY constraint.
To create a primary key constraint using Enterprise Manager, follow these
steps:
1. In the Table Designer, click and select the colum n(s) that are part of the primary
key (use the Ctrl key <strong>for</strong> this).
2. Right-clic k anywhere along the selected column(s) and click Set Primary Key. A
check mark appears next to the Set Primary Key option.
3. A unique clustered in dex using the naming convention PK_table_name is
automatically created by the system.
4. The name and properties of the index can be changed from those assigned by the
system through the Indexes/Keys pane of the Table and Index Properties
window.
To create a primary key constraint using T-SQL, use the following syntax:
<strong>Oracle</strong> and SQL Server differ only in the USING INDEX part of the PRIMARY KEY
constraint syntax. The syntax differs from the UNIQUE constraint definition only in the
UNIQUE keyword being replaced with PRIMARY KEY. In both <strong>Oracle</strong> and SQL Server, a
NOT NULL constraint is added by the system <strong>for</strong> all primary key columns when one is not
explicitly
specified.

116 Developing: Databases — <strong>Migrating</strong> Schemas
The CREATE TABLE syntax in Table 6.15 is <strong>for</strong> defining primary key constraints and its
associated index.
Table 6.15: SQL Statements <strong>for</strong> Defining PRIMARY KEY Constraints in <strong>Oracle</strong>
SQL Server
<strong>Oracle</strong>
SQL Server
CREATE TABLE table_name
CREATE TABLE table_name
(
(
column_name datatype,
column_name datatype,
…,
…,
[ CONSTRAINT constraint_name ]
[ CONSTRAINT constraint_name ]
PRIMARY KEY ( column_name [, …] ) [ PRIMARY KEY [ CLUSTERED |
USING INDEX [ TABLESPACE
NONCLUSTERED ] ( column_name [, …] )
tablespace_name ] [ storage specs ] ] [ WITH FILLFACTOR = fillfactor ] [ ON
FILEGROUP { filegroup | DEFAULT } ]
and
Foreign Key Constraint
A <strong>for</strong>eign key constraint en<strong>for</strong>ces the rule that a non-null value in one or more columns of
a table (child) must exist in a corresponding set of columns in the same (self-referential)
or another (parent) table. The referenced key columns must possess a primary key or
unique key index on them.
The number and data types of columns specified in the FOREIGN KEY clause should
match the corresponding columns of the referenced table. FOREIGN KEY constraints in
SQL Server have a restriction of not being able to cross database boundaries. In the
case where <strong>for</strong>eign key constraints existing between different schemas of a source
<strong>Oracle</strong> database are migrated to separate databases in SQL Server, the constraints will
have to be replaced with triggers. In <strong>Oracle</strong>, the ON DELETE clause is used to specify
the actions that will automatically be undertaken if a parent row is deleted. Additionally,
SQL Server has the ON UPDATE clause <strong>for</strong> handling updates to the parent rows.
Table 6.16 shows the availability of various control actions using these clauses in <strong>Oracle</strong>
and SQL Server:
Table 6.16: Functionality Available in <strong>Oracle</strong> and SQL Server with Respect to
Foreign Key Constraint
Operation Action <strong>Oracle</strong> SQL Server
ON DELETE SET NULL Yes No
ON DELETE CASCADE Yes Yes
ON DELETE NO ACTION Yes Yes
ON UPDATE CASCADE No Yes
ON UPDATE NO ACTION No Yes
Note In <strong>Oracle</strong>, the default of NO ACTION (restrict) is assumed only by the absence of
an O N DELETE { SET NULL | CASCADE } clause in the definition. In SQL Server, the
default is NO ACTION <strong>for</strong> both operations. To mimic the action of SET NULL, it has to
be handled programmatically in the application using an appropriate SQL statement.
Foreign key constraints can be created in SQL Server using
Enterprise Manager and T-
SQL.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 117
To create a <strong>for</strong>eign key constraint using Enterprise Manager, follow these
steps:
1. Right-click the table name on the table list, click Design Table, and then click
Table and Index Properties.
2. Select the Relationships tab and click New.
3. A new relationship is created with a default name and current table selected in the
Foreign key table drop-down list. Type in or select (from drop-down list) the
appropriate columns involved in the current table (child table). Also select the
appropriate table <strong>for</strong> the Parent key table and its parent columns.
4. Select appropriate behaviors <strong>for</strong> the trigger in the check boxes at the bottom of the
screen. The important behaviors are Check existing data on creation and
En<strong>for</strong>ce relationship <strong>for</strong> INSERTs and UPDATEs.
To create a <strong>for</strong>eign key constraint using the Database Diagram Wizard, follow
these steps:
1. Expand Server, then Databases, then target database.
2. Right-click Diagrams and click New Database Diagram.
3. The wizard will lead you through adding the tables to be included in the diagram.
See Figure 6.7.
Figure 6.7
Using Database Diagram Wizard <strong>for</strong> creating referentials
4. To add a relationship, select the <strong>for</strong>eign key column of the child table, and drag it to
the primary or unique key column of the parent table.
5. A pop-up dialog will appear with columns filled in based on the columns selected
in
the drag and drop. The actions need not be precise because in<strong>for</strong>mation such as

118 Developing: Databases — <strong>Migrating</strong> Schemas
name, primary key, and <strong>for</strong>eign key columns, can be modified be<strong>for</strong>e saving. See
Figure 6.8.
Figure 6.8
Choosing the right relationship properties
To create a <strong>for</strong>eign key constraint using T-SQL, use the following syntax:
Table 6.17 contains the syntax to add <strong>for</strong>eign key constraints with the actions of ON
DELETE and also the ON UPDATE statement, which do es not exist in <strong>Oracle</strong>.
T able 6.17: SQL Statements <strong>for</strong> Defining FOREIGN KEY Constraints in <strong>Oracle</strong>
SQL Server
Operation <strong>Oracle</strong> SQL Server
ON DELETE
CREATE TABLE
table_ name
CREATE TABLE
table_name
(…,
(…,
column_name datatype,
…,
[ CONSTRAINT
constraint_name ]
FOREIGN KEY
(column_name [,…]
REFERENCES
[schema.]ref_table_name
(ref_column_name[, …])
ON DELETE { SET NULL |
column_name datatype,
…,
[ CONSTRAINT
constraint_name ]
FOREIGN KEY
(column_name [,…]
REFERENCES
ref_table_name
(ref_column_name[, …])
ON DELETE { CASCADE |

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 119
Operation <strong>Oracle</strong> SQL Server
ON UPDATE
CASCADE }
NO ACTION}
CREATE TABLE
table_name
(…,
column_name datatype,
…,
[ CONSTRAINT
constraint_name ]
FOREIGN KEY
(column_name [,…]
REFERENCES
ref_table_name
(ref_column_name[, …])
ON UPDATE { CASCADE |
NO ACTION}
Triggers
Triggers are used to en<strong>for</strong>ce more complex business rules than can be en<strong>for</strong>ced using
constraints. Triggers are stored procedures that are implicitly executed when certain data
modification (using data manipulation language statements, also known as DML) is
per<strong>for</strong>med against tables and views. In <strong>Oracle</strong>, there can be up to twelve combinations of
trigger executions (actions) based on:
● DML operation: INSERT, UPDATE, DELETE
● Timing: BEFORE, AFTER
● Level: ROW, STATEMENT
Table 6.18 evaluates SQL Server support <strong>for</strong> the <strong>Oracle</strong> trigger functionality.
Table 6.18: Functionality of <strong>Oracle</strong> Triggers Mapped to SQL Server
Trigger Feature <strong>Oracle</strong> SQL Server
DML – INSERT Yes Yes
DML – UPDATE Column/Row Row
DML – DELETE Yes Yes
Timing – BEFORE Yes Yes (INSTEAD OF)
Timing – AFTER Yes Yes
Level Row/Statemen t
Row
Views – INSTEAD OF Yes Yes
Multiple triggers per action Yes Yes (first/last specified)
The SQL Server INSTEAD OF triggers are equivalent to <strong>Oracle</strong>’s BEFORE triggers.
When migrating triggers from <strong>Oracle</strong>, the only drawback is that SQL Server does not
support statement-level triggers. However, there are two pseudo-tables, inserted and
deleted, that are populated during the trig ger execution and which can be used to
simulate statement-level operations. These inserted
and deleted pseudo tables are
similar to the :old and :new pseudo-rows in <strong>Oracle</strong> and are populated with all (multiple)
rows affected by the trigger execution. The SQL Server deleted and inserted pseudotables
are available by default and are not specified as part of the trigger definition. In

120 Developing: Databases — <strong>Migrating</strong> Schemas
<strong>Oracle</strong>, the pseudo-rows have to be defined in the trigger using the REFERENCING
clause.
Note This section is concerned only with creation of the trigger object. A detailed
discussion on trigger logic (code) and its migration is found in Chapter 11, "Developing:
Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL" under the "<strong>Migrating</strong> the Data
Access" section.
When multiple triggers exist on a table <strong>for</strong> the same action, <strong>Oracle</strong> does not guarantee
any particular order of execution of multiple triggers. SQL Server has the capability to
specify which trigger should be fired be<strong>for</strong>e (first) and a fter (last) all other triggers using
the system stored pr ocedure sp_ settriggerorder. This feature has been found useful in
e liminating some of the complexities in the code found in <strong>Oracle</strong> triggers to manage the
s equence of events.
Triggers can be defined on tables either using Enterprise Manager or using T-SQL.
To create a trigger using Enterprise Manager, follow
these steps:
1. In the Enterprise Manager, expand Server, then Databases, then target
database, and then Tables.
2. Right-click the table nam e on the table list, click All Tasks, and then click Manage
Triggers. Or, click the Trigge rs button in the Table Designer.
3. Type in the trigger text using the provided template.
4. Click Apply if m ore than one trigger is to be created, or OK to save all changes
and close the dialog box.
To create a trigger using T-S QL, use the following syntax:
Table 6.19 compares the commonly used functionality of the trigger definition CREATE
TRIGGER statement in <strong>Oracle</strong> and SQL Server.
Table 6.19: SQL Statements <strong>for</strong> Creating Triggers in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong>
CREATE TRIGGER trigger_name
{ BEFORE | AFTER | INSTEAD OF } { {
INSERT [ OR ] | DELETE [ OR ] |
UPDATE [ OF column_name [, …] ] } }
ON table_name
REFERENCING [OLD AS :old] [NEW AS
:new]
[ FOR EACH ROW ]
WHEN ( condition )
Pl/ sql_block
SQL Server
CREATE TRIGGER trigger_name
ON table_name | view_name
{ { FOR | AFTER | INSTEAD OF } { [
INSERT ] [ , ] [ UPDATE ] [ , ] [
DELETE ] }
AS
[ { IF UPDATE ( column_name )
[ { AND | OR } UPDATE ( column_name
) ] [ ...n ] |
IF ( COLUMNS_UPDATED ( ) {
bitwise_operator } updated_bitmask
)
{ comparison_ operator }
column_bitmask [ ...n ] } ]
sql_statement [ ...n ]
}
}

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 121
Indexes
There are two major categories of indexes in <strong>Oracle</strong>: B-tree indexes and Bitmap
indexes. All other indexes are variations of these two basic types to provide additional
features. Table 6.20 provides a quick comparison of the indexing schemes available in
<strong>Oracle</strong> and SQL Server:
Table 6.20: Indexing Schemes Available in <strong>Oracle</strong> and SQL Server
Index Scheme <strong>Oracle</strong> SQL Server
B-tree — Unique Yes Yes
B-tree — Non-unique Yes Yes
B-tree — Composite Yes (32 columns) Yes (16 columns)
B-tree — Ascending Yes Yes
B-tree — Descending Yes Yes
B-tree — Cluster Yes No
B-tree — Reverse Key Yes No
B-tree — Key Compressed Yes No
B-tree — Function-based Yes No
B-tree — Index-Organized Yes
Yes (Clustered)
Table
B-tree — Partitioned Yes No
Bitmap Yes (30 columns) No
Bitmap — Join Yes No
B-Tree Indexes
SQL Server offers two types of indexes: clustered and nonclustered. Both these types
are based on the B-tree data structure. Hence assumptions can be drawn as to their
per<strong>for</strong>mance in the two systems. An important difference between the two
implementations is <strong>Oracle</strong> does not index rows when all the key columns have null values
in them, while SQL Server does.
Both <strong>Oracle</strong> and SQL Server support the following basic versions of the B-tree index:
● Comp osite. <strong>Oracle</strong> allows indexes with up to 32 columns, whereas SQL Server
allows up to 16 columns. While indexes with 16 or more columns are rare, the
number of columns will have to be trimmed down if such indexes were to be
migrated to SQL Server.
● Unique. Unique indexes are used to en<strong>for</strong>ce PRIMARY KEY and UNIQUE
constraints. Even though nulls cannot be compared (nor considered equal) <strong>for</strong>
sake of uniqueness, when two rows are identical, null values are considered as
identical. In SQL Server, primary key constraints cannot have null values, whereas
unique indexes allow one row with null value. For more in<strong>for</strong>mation, refer to the
"Unique Constraints" section earlier in this chapter.
● Non-unique. This is the basic <strong>for</strong>m of the B-tree or nonclustered index, where key
values can be repeated.
● Ascending. The key values are sorted and stored in ascending order.
● Descending. The key values are sorted and stored in descending order.
The following list provides variations of the B-tree index, implemented with a modification
to the basic B-tree structure, that provide a specific feature:

122 Developing: Databases — <strong>Migrating</strong> Schemas
●
●
●
●
●
●
Cluster indexes. Such indexes can be found in <strong>Oracle</strong> on clustered tables
(clusters). Clustered tables are not supported by SQL Server and neither are
cluster indexes.
Index-organized tables. The clustered indexes in SQL Server are similar to the
index organized tables. Refer to the discussion under the "Tables" section earlier in
this chapter.
Reverse key indexes. <strong>Oracle</strong> developed these indexes to reduce contention <strong>for</strong>
index blocks by indexes on columns that have sequential values that are written
almost simultaneously. This is achieved by reversing the bytes in the key value to
produce non-sequential numbers. This indexing scheme is not available in
SQL Server. The reverse key index is useful in <strong>Oracle</strong> Real Application Cluster
(RAC) implementations, and there is no disadvantage in migrating such indexes to
clustered or nonclustered indexes.
Partitioned indexes. In <strong>Oracle</strong>, B-tree indexes can be created that are local to the
partition or global to the entire table (partitioned or non- partitioned). This feature is
not available in SQL Server and should be replaced by clustered or nonclustered
indexes.
Key compressed index. In key compression, the leading subsets of a key can be
compressed in a manner similar to clustering by storing the leading subset only
once <strong>for</strong> repeating values. SQL Server does not support key compression.
Function-based index. In <strong>Oracle</strong>, expressions in the WHERE clause that contain
functions do not use indexes as an access path. To overcome this disadvantage,
indexes can be created by applying the function to compute the value of the
expression and storing it in an index. For example, if the column part_name is
accessed using the expression UPPER(part_name), a function-based index can be
defined on UPPER(part_name). SQL Server does not support function-based
indexes. There is no other index type in SQL Server that can provide similar
functionality.
Bitmap Index
The bitmap indexes are specia lly designed <strong>for</strong> improving the retrieval of data based on
columns with very low cardinality. Becaus e maintenance of the bitmap indexes is very
expensive, their utility is restric ted to Data Warehouses and DSS systems where there is
very low or zero update activity.
Bitmap indexes are not available in SQL Server and cannot be substituted with B-tree
indexes.
I n SQL Server and versions of <strong>Oracle</strong> be<strong>for</strong>e 9i, indexes are used only when the leading
subset of key values are involved. In <strong>Oracle</strong> 9i, <strong>Oracle</strong> introduced the concept of fast
index scan, whereby the entire index is scanned <strong>for</strong> matching values in the non-leading
keys by skipping the leading key columns. In SQL Server, additional indexes have to be
created <strong>for</strong> the non-leading columns to provide access paths similar to <strong>Oracle</strong>. This
requirement is not documented inside the database and is dependent on the SQL
statements used in applications. These situations can only be discovered by profiling the
application during testing.
The various types of indexes can be created using Enterprise Manager, the Create Index
Wizard, or T-SQL.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 123
To create an index using Enterprise Manager, follow these steps:
The steps <strong>for</strong> creating an index are very similar to that described <strong>for</strong> UNIQUE key. Creation
of a non-unique, nonclustered index is demonstrated here.
1. Expand Server, then Databases, then target database, and then Tables.
2. Right-click the table nam e on the table list, click Design Table, and then click
Table and Index Properties.
3. Select the Indexes/Keys tab and click New.
4. Enter the name of the new ind ex in the Index name text box. Insert the columns or
the index in grid along with the required sort order fo r the column.
5. Uncheck the Create UN IQUE check box to specify a non-unique index.
6. Select the target filegroup fro m the Index Filegroup drop-down list.
7. Click the desired value <strong>for</strong> Fill factor (equivalent of PCTFREE).
To create an index using the Create Index Wizard, follow these steps:
1. Expand a server group, and then expand the server in which to create the index.
2. On the Tools menu, click Wizards.
3. Expand Database.
4. Double-click Create Index Wizard.
5. Complete the steps in the wizard
To create an index using T-SQL, use the following syntax:
Table 6.21 shows the syntax of the CREATE INDEX statement <strong>for</strong> the features and
functionality discussed here.
Table 6.21: SQL statements available <strong>for</strong> Creating Indexes in <strong>Oracle</strong> and
SQL Server
<strong>Oracle</strong>
CREATE [UNIQUE | BITMAP ]
INDEX index_name
ON table_name ( column_name
[ ASC | DESC ] [, …] )
[ physical_attributes ]
[ { COMPRESS | NOCOMPRESS }
prefix_length ]
[ REVERSE ]
[ TABLESPACE tablespace_name ]
[ storage_description ]
SQL Server
CREATE [ UNIQUE ] [ CLUSTERED |
NONCLUSTERED ] INDEX index_name
ON table_name ( column_name
[ ASC | DESC ] [, … ] )
[ WITH index_options ]
[ ON filegroup ]
Views
Vie ws are used in <strong>Oracle</strong> and SQL Server to hide query complexity and encourage query
reuse. Both <strong>Oracle</strong> and SQL Server have added features, such as updateability and
inde xes to views, to improve their utility and per<strong>for</strong>mance.

124 Developing: Databases — <strong>Migrating</strong> Schemas
Table 6.22 compares the availability of the various types of views in <strong>Oracle</strong> and
SQL Server.
Table 6.22: Types of Views Available in <strong>Oracle</strong> and SQL Server
View Type <strong>Oracle</strong> SQL Server
Simple Views Yes Yes
Join Views Yes Yes
Partitioned Views Yes Yes
Read-only Views Yes No
Updateable Views Yes Yes
Inline Views Yes Yes
Object Views Yes No
The following are the various types of views available in <strong>Oracle</strong> and the support <strong>for</strong> them
in SQL Server:
● Simple views. This view query is based on a single table and their migration is
trivial.
● Join views. This view query is based on more than one table. The join views
available in SQL Server are less restrictive than their <strong>Oracle</strong> counterparts in their
use of aggregate functions in the query. Hence migrating them from <strong>Oracle</strong> to
SQL Server should not pose any problems. When a view is defined with an outer
join and is queried with a qualification on a column from the inner table of the outer
join, the results from SQL Server and <strong>Oracle</strong> can differ.
● Partitioned views. This view query provides a union of partitions of data in
different tables (regular non-partitioned tables). Use of partitioned views was
common in <strong>Oracle</strong> be<strong>for</strong>e the introduction of partitioned tables in <strong>Oracle</strong> 8.
SQL Server supports the entire range of features that are available in <strong>Oracle</strong> with
respect to partitioned views.
● Read-only views. This view query with the WITH READ ONLY clause specified to
curb update activity against the base tables of the view. SQL Server does not have
an equivalent <strong>for</strong> this feature. When migrating a read-only view, care has to be
taken to ensure that only SELECT privileges are granted to the users.
● Updatable views. These are simple, join, or partitioned views against which DML
statements can be executed, subject to certain restrictions. In SQL Server, the
restrictions can be bypassed (except the use of aggregate functions) by defining
INSTEAD OF triggers on the views. The WITH CHECK OPTION clause prevents
modifications to data that violate the criteria in the WHERE clause of the view
query. DML statements on join views can modify data only in one base table.
● Inline views. An inline view is a subquery that is used like a view in the FROM
clause of SQL statements. SQL Server fully supports their definition.
● Object views. Object views are virtual object tables that can be used to
manipulate object data types as well as relational data cast as objects. Object
views are not available in SQL Server
and should be recreated (flattened) as
regular views.
● Indexed views. <strong>Oracle</strong> does not support creation of indexes on views. However,
UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints can be defined on views
which indirectly create indexes. These constraints are a subset of those available
with tables and work similarly. SQL Server allows creation of indexes. However the
first index has to be a unique clustered index. Additional nonclustered indexes can
then be created. Thus, SQL Server can support the migration of indexed views.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 125
Views can be created using Enterprise Manager, the Create View Wizard, or T-SQL.
To create a view using Enterprise Manager, follow these steps:
1. Open Enterprise Manager, expand Server, then Databases, and then the target
database.
2. Right-click Views and click New View.
3. The view can be created using the dia gram and grid panes (top two areas) or by
entering the view query in the SQL pa ne (SELECT area). See Figure 6.9.
Figure 6.9
Using the View Designer of Enterprise Manager
To create a view using the Create View Wizard, follow these steps:
1. Expand a server group and then expand the server in which to create the view.
2. On the Tools menu, click Wizards.
3. Expand Database.
4. Double-click Create View Wizard.
5. Complete the steps in the wizard.

126 Developing: Databases — <strong>Migrating</strong> Schemas
To create a view using T-SQL, use the following syntax:
Table 6.23 offers a comparison of the CREATE VIEW statements in <strong>Oracle</strong> and
SQL Server.
Table 6.23: SQL Statement <strong>for</strong> Creating Views in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong>
CREATE [OR REPLACE] [FORCE |
NO FORCE] VIEW [schema.]view_name
SQL Server
CREATE VIEW [owner.]view_name
name [,…] ) ]
[ ( column_
[ ( column_alias [ inline_constraint ] [,…] [, AS select_statement
out_of_line_constraint ] ) ]
AS select_statement
[ WITH READ ONLY ]
[ [ WITH CHECK OPTION ] [
CONSTRAINT constraint_name ] ]
[ WITH CHECK OPTION ]
In O racle, views can be created without permissions on the base objects, or even without
the base objects existing, by using the FORCE keyword. This is not allowed in
SQL Server. SQL Server also does not allow ORDER BY and GROUP BY clauses in the
view definition.
Note When a view is created in <strong>Oracle</strong> using an asterisk (*) in the SELECT clause, the
asterisk is expanded to the actual column names in the definition of the view.
SQ L Server retains the exact definition used in the DDL. <strong>Oracle</strong> does the same thing
when an asterisk (*) is not used. While converting from <strong>Oracle</strong> to SQL Server, the view
definition may be changed back to an asterisk instead of specifying every column.
Stored Programs
Ora cle and SQL Server have the capability to store complex business logic (beyond
constraints) inside the database. The code to support such requirements cannot be
provided by SQL because it cannot execute commands based on logical conditions. It
also fails to support looping operations. In spite of recent extensions to SQL, such as
inco rporation of a CASE expression, it is still difficult to per<strong>for</strong>m more than one operation
based on a logical condition using these methods. The need to implement control
structures and programming constructs cannot be met with SQL alone. Hence <strong>Oracle</strong>
and SQL Server both offer procedural extensions to SQL, PL/SQL, and Transact-SQL ( T-
SQL), respectively, that offer a more complete environment <strong>for</strong> defining stored programs
(or subprograms).
Stored programs provide modularity (top-down design), encapsulation (logic is hidden),
abstraction (black box approach), security (only execute on subprogram), and
extensibility (user-defined functionality). Additionally, existence inside the database
promotes accessibility (available to all users), reuse (available to all database users),
speed of execution (stored programs are in compiled <strong>for</strong>m), per<strong>for</strong>mance (handling of
large amounts of data close to its source), and reduced resource requirements (reduces
network bandwidth, memory, and so on because only the results are transported).
In <strong>Oracle</strong>, Java can be used to write native stored procedures and user-defined functions.
A PL/SQL procedure can also call external procedures or functions written in the C
programming language and stored in a shared library.
In <strong>Oracle</strong>, there are four types of stored programs: functions, procedures, packages, and
triggers. These objects are very similar in construction, functionality,
and usage to those

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 127
used in SQL Server. Hence the migration of their structures is trivial. However, because
of the vast difference between the syntax in the languages (PL/SQL and T-SQL) used in
these objects, the migration of the embedded code is far from trivial.
Triggers have already been discussed in this chapter. Functions, procedures, and
packages are covered here.
<strong>Oracle</strong> ensures the purity of the actions that are per<strong>for</strong>med inside stored programs.
Hence there are no hidden side effects when migrated to SQL Server and you can
concentrate on reproducing the logic using T-SQL.
Here are a few points that concern all types of stored programs:
● Overloading. SQL Server does not support overloading, and such functions and
procedures will have to be recreated using unique names.
● Execution privileges. <strong>Oracle</strong> stored programs can be defined to execute with
definer-rights (owner) or invoker-rights (user). SQL Server only uses invoker-rights.
<strong>Oracle</strong> stored programs that are built on definer-rights architecture can be
converted to SQL Server invoker-rights subprograms by properly qualifying objects
inside stored programs. With invoker rights, the schema name could also be
passed in and SQL dynamically constructed.
● Parameters. Both <strong>Oracle</strong> and SQL Server support positional, named, or mixed
notation <strong>for</strong> parameters. SQL Server c an handle all the types of para meters that
are found in <strong>Oracle</strong>, including tables.
<strong>Oracle</strong> has three parameter modes: IN, OUT, and IN OUT. SQL Server does not
allow the IN OUT type of parameters, and this type warrants some rework in the
application design when migrating. Hence IN OUT parameters will have to be
replaced with two separate IN and OUT parameters. The keyword OUTPUT is
used in place of OUT, while the keyword IN does not exist and is implied because
it is the default mode. Also, even though it is not a good practice, there is no
restrictio n on the usage of OUT and IN OUT parameters in <strong>Oracle</strong> functions.
Violations of this rule should be trapped and corrected during migration.
In <strong>Oracle</strong> and SQL Server, IN parameters can be given default values. If such
parameters are skipped during a call, the default value is applied. In SQL Server,
this rule holds <strong>for</strong> stored procedures but not <strong>for</strong> functions. With functions, the
keyword "default" has to be used in the call to the function and cannot be skipped
as with stored procedures (which imply the use of the default value).
SQL Server parameters are prefixed by the at (@) symbol.
● Using same name as system. If the first three characters of the procedure name
are sp_, SQL Server searches the master database <strong>for</strong> the procedure. If no
qualified procedure name is provided, SQL Server searches <strong>for</strong> the procedure as if
the owner name is dbo. To resolve the stored procedure name as a user-defined
stored procedure with the same name as a system stored procedure, provide the
fully qualified procedure name.
Only the migration of the object structure is provided in this chapter. Refer to Chapter 11,
"Developing: Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a detailed discussion about
migrating the embedded PL/SQL code to T-SQL.
Functions
While the system provides several built-in
functions, <strong>Oracle</strong> and SQL Server provide the
capability to define custom functions called user-defined functions. These user-defined
extensions to SQL always return a result. They are employed primarily in SQL
statements.
Functions can be created using Enterprise Manager or T-SQL.

128 Developing: Databases — <strong>Migrating</strong> Schemas
To create a function using Enterprise Manager, follow these steps:
1. Expand a server group, and then expand a server.
2. Expand Databases, and then expand the database in which to create the function.
3. Right-click User Defined Functions and select New User Defined Function.
4. In the Text box, enter the text of the function. Use TAB to indent the text of a
function.
5. To check the syntax, click Check Syntax and OK to create.
To create a function using T-SQL, use the following syntax:
Functions can be created in SQL Server using the CREATE FUNCTION statement,
which is very similar to the one found in <strong>Oracle</strong>, as show in Table 6.24.
Table 6.24: SQL Statements <strong>for</strong> Creating Triggers in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong>
CREATE OR REPLACE FUNCTION
[schema.]function_name
[ ({parameter [IN] datatype [=
default]} [, …]) ]
RETURN scalar_expression
{IS | AS}
variable_declaration
BEGIN
statements
RETURN scalar_expression
EXCEPTION
statements
END;
SQL Server
CREATE FUNCTION [owner.]
function_name
[ ({@parameter [AS] datatype [ =
default ]} [, …]) ]
RETURN scalar_expression
[ AS ]
BEGIN
variable_declaration
statements
RETURN scalar_expression
END
Stored Procedures
SQL Server has stored procedures that closely resemble <strong>Oracle</strong>. These stored
procedures provide the capability to pass multiple parameters back to the calling
environment. Another advantage of stored procedures is that they can per<strong>for</strong>m actions in
the database without being tied to a SQL statement.
Stored procedures can be created using the Create Stored Procedure Wizard, Enterprise
Manager, or T-SQL.
To create a view using the Create Stored Procedure Wizard, follow these
steps:
1. Expand a server group and then expand the server in which to create the view.
2. On the Tools menu, click Wizards.
3. Expand Database.
4. Double-click Create Stored Procedure Wizard.
5. Complete the
steps in the wizard.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 129
To create a stored procedure using Enterprise Manager, follow these steps:
1. Expand a server group, and then expand a server.
2. Expand Databases, and then expand the database in which to create the stored
procedure.
3. Right-click Stored Procedures and select New Stored Procedure.
4. In the Text box, enter the text of the stored procedure. Use TAB to indent the text
within.
5. To check the syntax, click Check Syntax and OK to create.
To create a stored procedure using T-SQL, use the following syntax:
Both <strong>Oracle</strong> and SQL Server offer the CREATE PROCEDURE statement, which is very
similar in structure and is shown in Table 6.25.
Table 6.25: SQL Statements <strong>for</strong> Creating Procedures in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong>
CREATE OR REPLACE PROCEDURE
[schema.]procedure_name
[ ({parameter [IN|OUT|IN OUT]
datatype [= default]} [, …]) ]
{IS | AS}
variable_declaration
BEGIN
statements
EXCEPTION
statements
END;
SQL Server
CREATE PROCEDURE [owner.]
procedure_name
[ ({@parameter [AS] datatype [ =
default ] [OUTPUT]} [, …]) ]
AS
BEGIN
variable_declaration
statements
END
Packages
One of the main differentiators between stored procedures and packages is the capability
to declare variables in the package header that act as global variables. SQL Server does
not have packages, and these have to be replaced with stored procedures. However,
SQL Server allows the nesting of procedures, and this capability can be used to simulate
the structure of packages by nesting functions and procedures. Variables can be made
available to all the nested functions and procedures by declaring them in the outmost (or
main) procedure. This, however, does not provide database-wide accessibility to these
variables, a shortcoming which has to be accommodated by migrating the global variable
from the package to the application code.
<strong>Solution</strong>s <strong>for</strong> Objects not Found in SQL Server
Some <strong>Oracle</strong> objects, such as synonyms and sequences, are widely used in <strong>Oracle</strong>
applications. However, there is no equivalent object with similar functionality in
SQL Server. Finding solutions to implement the logic and functionality around these
objects in SQL Server is critical to the migration.
Synonyms
In <strong>Oracle</strong>, synonyms are aliases <strong>for</strong> tables, views, sequences, functions, procedures, and
packages. The primary purpose of using synonyms is <strong>for</strong> location transparency
and
naming transparency. By creating public synonyms or private synonyms (<strong>for</strong> each user),

130 Developing: Databases — <strong>Migrating</strong> Schemas
applications can be written without schema qualification in the SQL code because the
qualifier is defined in the synonyms. The original object names can also be hidden.
Synonyms <strong>for</strong> tables are more easily migrated by substituting them with views. Views
provide the required location and naming transparency as well. For example, a private
synonym, CLINTB.DEPT, which connects to the table HR.DEPARTMENT, can be
r eplaced in SQL Server by a VIEW as follows:
CREATE VIEW CLINTB.DEPT AS SELECT * FROM HR.DEPARTMENT
One of the known drawbacks when creating SELECT * views in <strong>Oracle</strong> is that any
changes that are made to the base table definition in terms of adding, dropping, and
renaming columns are not automatically reflected in the view definition. This is because
<strong>Oracle</strong> converts the query piece:
SELECT * FROM table_name
into
S ELECT column_name [, …] FROM table_name
Consequently, when a column is added to the base table, the view definition does not
change. Dropping or renaming a column invalidates the view. However, SQL Server does
not have this problem because the view DDL is stored as it was written, that is, SELECT
* FROM table_name.
I t is not possible to find an object-based solution <strong>for</strong> synonyms connecting to other types
of objects, such as procedures and sequences. The simplest solution is to qualify the
object schema or owner in the application rather than resolve it at the database login
level.
The inherent quality of SQL Server in resolution of objects can be used <strong>for</strong> providing a
solution. Synonyms are usually employed in situations where there are multiple versions
of the same application being used to support different clients, with each client having its
own schema. The schema that will be used is driven by the user login and not the
application itself. This can be achieved in SQL Server by setting the default database <strong>for</strong>
a user account and giving the login the appropriate privileges at the object level. This
scheme will work as long as all the objects that will be accessed are in a single database
and it is set as the default database <strong>for</strong> the user. For more in<strong>for</strong>mation about these
issues, refer to Chapter 7, "Developing: Databases — <strong>Migrating</strong> the Database Users."
Sequences
In <strong>Oracle</strong>, sequences are autonomous schema objects that can be used to generate
numbers that are in sequential order. In applications, sequences are commonly used to
produce artificial keys <strong>for</strong> tables which do not have a natural key, or the natural key is too
long. SQL Server does not have an equivalent <strong>for</strong> sequences. However, a SQL Server
table can have columns that are defined with the IDENTITY property, which simulates the
behavior of <strong>Oracle</strong> sequences. The IDENTITY column is an <strong>Oracle</strong> sequence and table
column rolled into one, that is, the column definition includes the sequence definition.
The syntax of the SQL Server IDENTITY property is
IDENTITY [(seed, increment)]
The <strong>Oracle</strong> start with is replaced by the SQL Server seed.
The <strong>Oracle</strong> increment by is equivalent to the SQL Server increment
The <strong>Oracle</strong> maxvalue is provided by the SQL Server column data type.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 131
Table 6.26 shows the implementation of the IDENTITY property feature in SQL Server
and what would be the equivalent in <strong>Oracle</strong>.
Table 6.26: Implementation of <strong>Oracle</strong> Sequence in SQL Server
<strong>Oracle</strong>
CREATE SEQUENCE sequence_name
START WITH 1 INCREMENT BY 1
CREATE TABLE table_name (column1
NUMBER DEFAULT
sequence_name.NEXTVAl,
column2 …
);
INSERT INTO table_name (column2, …)
VALUES ( … )
CREATE TABLE table_name (column1
NUMBER,
column2 …
);
INSERT INTO table_name (column1,
column2, …) VALUES
(sequence_name.NEXTVAL, … )
SQL Server
-
CREATE TA BLE table_name (column1
NUMBER IDENTITY(1,1),
column2 …
);
INSERT INTO table_name (column2, …)
VALUES ( … )
CREATE TABLE table_name (column1
NUMBER IDENTITY(1,1),
column2 …
);
INSERT INTO table_name (column2, …)
VALUES ( … )
One of the advantages of sequences being independent objects is that they can be used
to supply a unique identifier across multiple tables. This property of <strong>Oracle</strong> sequences is
not inherent in SQL Server’s IDENTITY property. If an identifier is required to be unique
across tables (or even databases across the globe), use the uniqueidentifier data type,
which can be populated using the NEWID() function. The IDENTITY column can only
handle unique values and hence it cannot support the cycle feature of <strong>Oracle</strong> sequence.
A maximum value also cannot be set but can be en<strong>for</strong>ced by choosing an appropriate
sized data type <strong>for</strong> the IDENTITY column.
Note There is no sufficient in<strong>for</strong>mation inside the <strong>Oracle</strong> database to figure out how
and where a sequence is used. Hence the application's documentation, code, or
developer will have to be consulted to learn which sequence is used to populate a
column. This in<strong>for</strong>mation is then used to define an IDENTITY column in that table.
Database Links
<strong>Oracle</strong> database links are used to <strong>for</strong>m a bridge between databases (instances). Remote
and distributed transactions can be executed against the remote database using the
database link. SQL Server
provides similar functionality under the linked server.

132 Developing: Databases — <strong>Migrating</strong> Schemas
Table 6.27 compares some of the characteristics of database links in <strong>Oracle</strong> and
SQL Server.
Table 6.27: Comparison of Database Links in <strong>Oracle</strong> and SQL Server
Attribute
<strong>Oracle</strong>
SQL Server
Link Types Public and Private Public
Database Types Homogeneous Homogeneous and
Heterogeneous
CREATE [ PUBLIC ] DATABASE
LINK [ CONNECT TO {
sp_addlinkedserver [ @server
= ] 'server'
CURRENT_USER | user [ , [ @srvproduct = ]
IDENTIFIED BY password } ] 'product_name' ]
USING 'connect_string'
[ , [ @provider = ]
'provider_name' ]
[ , [ @datasrc = ]
'data_source' ]
[ , [ @location = ] 'location' ]
[ , [ @provstr = ]
'provider_string' ]
[ , [ @catalog = ] 'catalog'
Note The provider_name <strong>for</strong> an OLE DB-based connection to another SQL Server is
'SQLOLEDB'.
The following example shows the use of sp_addlinkedserver to create a linked server to
connect to another database <strong>for</strong> executing distributed queries:
sp_addlinkedserver
@server='CORP2',
@srvproduct='',
@provider='SQLOLEDB',
@datasrc='SHUTTLE\CORP2'
Sample Schema Object Migration
The following example illustrates the schema owner and schema objects migration task
of the database migration. The HR schema has been used in this example.
1. Create the SQL Server login account (database authenticated).
The following commands create a database-authenticated login with name HR.
Use MASTER
EXEC sp_addlogin
@loginame='HR',
@passwd='HR',
@defdb='HRDATA'
2. Create user account in the database.
The following commands create a user account <strong>for</strong> the HR login in the HRDATA
database in which objects will be created.
Use HRDATA
EXEC sp_grantdbaccess
@loginame='HR',

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 133
@name_in_db='HR'
3. Gra nt privileges to create objects in the database.
Priv ileges can be granted to the schema owner to create objects in a database
using either the CREATE permissions or the db_owner fixed database role.
a.
b.
Grant complete authority on the database.
The following command can be used to grant the db_owner role:
EXEC sp_addrolemember
@rolename='db_owner',
@membername='HR'
Grant privileges to create objects only.
The following commands can be executed to only grant permission to create
objects:
GRANT CREATE FUNCTION TO HR
GRANT CREATE PROCEDURE TO HR
GRANT CREATE TABLE TO HR
GRANT CREATE VIEW TO HR
4. Create sequences.
While sequences cannot be migrated to SQL Server, in<strong>for</strong>mation about the
seq uences in the <strong>Oracle</strong> database should be extracted first. Because sequences
are migrated to IDENTITY columns in tables, the in<strong>for</strong>mation about sequences is
required to appropriately define tables (in the next step).
The following command extracts the required in<strong>for</strong>mation on sequences.
SELECT sequence_name, min_value, max_value, increment_by
FROM dba_sequences
WHERE sequence_owner = 'HR'
The following output is obtained:
SEQUENCE_NAME MIN_VALUE MAX_VALUE INCREMENT_BY
DEPARTMENTS_SEQ 1 9990 10
EMPLOYEES_SEQ 1 999999999999999999999999999 1
LOCATIONS_SEQ 1 9900 100
The three sequences in the HR schema are assumed to be used to populate the
columns DEPARTMENTS.DEPARTMENT_ID, EMPLOYEES.EMPLOYEE_ID and
LOCATIONS.LOCATION_ID, respectively.
5. Create tables.
There are two options <strong>for</strong> how to migrate tables. Option one is to create tables in a
specific order based on the <strong>for</strong>eign key constraints (parent tables first). Option two
is to create tables in any order, leaving out the <strong>for</strong>eign key constraints and then
adding them after all the tables have been created.
a. Obtain a list of tables.
If option one is followed, the dependenci es between tables and the right order
in which to create the tables is required. There are several scripts available
(mostly PL/SQL-based) to produce such a list. Tables without any
dependencies <strong>for</strong>m the first level, and other levels are <strong>for</strong>med based on the
nesting of the dependencies.
Note None of the available scripts will work when there are interdependencies
between tables that <strong>for</strong>m a closed loop. The following script shows such
circular dependencies that
make these scripts not viable.

134 Developing: Databases — <strong>Migrating</strong> Schemas
SELECT table_name parent_table_name, NULL child_table_name
FROM dba_tables ut
WHERE owner = 'HR'
AND NOT EXISTS (SELECT 'x'
FROM user_constraints uc
WHERE constraint_type = 'R'
AND ut.table_name = uc.table_name)
UNION ALL
SELECT p.table_name parent_table_name,
c.table_name child_table_name
FROM dba_constraints p, dba_constraints c
WHERE p.owner = c.owner
AND p.owner = 'HR'
AND p.constraint_type IN ('P','U')
AND c.constraint_type = 'R'
AND p.constraint_name = c.r_constraint_name
Note In the following output there is a parent-child relationship between
EMPLOYEES and DEPARTMENTS in both directions that creates the loop.
PARENT_TABLE_NAME CHILD_TABLE_NAME
JOBS
REGIONS
REGIONS
COUNTRIES
LOCATIONS
DEPARTMENTS
EMPLOYEES
DEPARTMENTS
DEPARTMENTS EMPLOYEES
JOBS
EMPLOYEES
EMPLOYEES
EMPLOYEES
JOBS
JOB_HISTORY
EMPLOYEES
JOB_HISTORY
DEPARTMENTS JOB_HISTORY
COUNTRIES
LOCATIONS
To implement option two, first obtain a list of all tables that need to be migrated
using the following command:
SELECT table_name, tablespace_name, iot_type
FROM dba_tables
WHERE owner = 'HR'
The output obtained is:
TABLE_NAME
COUNTRIES
TABLESPACE_NAME
IOT_TYPE
IOT
DEPARTMENTS EXAMPLE
EMPLOYEES EXAMPLE
JOBS
EXAMPLE
JOB_HISTORY EXAMPLE
LOCATIONS EXAMPLE
REGIONS EXAMPLE

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 135
b.
Extract DDL along with constraints.
There are several scripts and tools that
table object.
can be used to extract the DDL <strong>for</strong> the
For an <strong>Oracle</strong> 9i database, the <strong>Oracle</strong>-supplied package DBMS_METADATA
can be used. First, execute the following in SQL*Plus to define the output style.
set pagesize 0
set long 10000
EXECUTE
DBMS_METADATA.SET_TRANSFORM_PARAM(DBMS_METADATA.SESSION_TRANSFORM,
'STORAGE', FALSE);
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
(DBMS_METADATA.SESSION_TRANSFORM, 'TABLESPACE', TRUE);
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
(DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR', TRUE);
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
(DBMS_METADATA.SESSION_TRANSFORM, 'CONSTRAINTS', TRUE);
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
(DBMS_METADATA.SESSION_TRANSFORM, 'REF_CONSTRAINTS', TRUE);
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
(DBMS_METADATA.SESSION_TRANSFORM, 'CONSTRAINTS_AS_ALTER', TRUE);
Then execute DBMS_METADATA.get_ddl <strong>for</strong> each of the tables. The following
two examples show how to extract the DDL <strong>for</strong> entire tables using this
procedure:
SELECT dbms_metadata.get_ddl('TABLE', 'COUNTRIES', 'HR')
FROM DUAL;
The output is as follows:
CREATE TABLE "HR"."COUNTRIES"
("COUNTRY_ID" CHAR(2) CONSTRAINT "COUNTRY_ID_NN" NOT NULL ENABLE,
"COUNTRY_NAME" VARCHAR2(40),
"REGION_ID" NUMBER,
CONSTRAINT "COUNTRY_C_ID_PK" PRIMARY KEY ("COUNTRY_ID") ENABLE
) ORGANIZATION INDEX
NOCOMPRESS PCTFREE 10 INITRANS 2 MAXTRANS 255 LOGGING
TABLESPACE "EXAMPLE"
PCTTHRESHOLD 50;
ALTER TABLE "HR"."COUNTRIES" ADD CONSTRAINT
"COUNTR_REG_FK" FOREIGN KEY ("REGION_ID")
REFERENCES "HR"."REGIONS" ("REGION_ID") ENABLE;
Execute the following command to obtain the definition of the LOCATIONS
table.
SELECT dbms_metadata.get_ddl('TABLE', 'LOCATIONS', 'HR')
FROM DUAL;
The output returned is:
CREATE TABLE "HR"."LOCATIONS"
("LOCATION_ID" NUMBER(4,0),
"STREET_ADDRESS" VARCHAR2(40),
"POSTAL_CODE" VARCHAR2(12),
"CITY" VARCHAR2(30) CONSTRAINT "LOC_CITY_NN" NOT NULL ENABLE,
"ST ATE_PROVINCE"
VARCHAR2(25),
"COUNTRY_ID" CHAR(2)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
TABLESPACE "EXAMPLE" ;

136 Developing: Databases — <strong>Migrating</strong> Schemas
CREATE UNIQUE INDEX "HR"."LOC_ID_PK" ON
"HR"."LOCATIONS" ("LOCATION_ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
TABLESPACE "INDX" ;
ALTER TABLE "HR"."LOCATIONS" ADD CONSTRAINT
"LOC_ID_PK" PRIMARY KEY ("LOCATION_ID")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
TABLESPACE "INDX" ENABLE;
ALTER TABLE "HR"."LOCATIONS" ADD CONSTRAINT
"LOC_C_ID_FK" FOREIGN KEY ("COUNTRY_ID")
REFERENCES "HR"."COUNTRIES" ("COUNTRY_ID") ENABLE;
c. Convert the extracted <strong>Oracle</strong> DDL to SQL Server syntax.
In this step, the table DDL is converted along with constraint and index
definitions. Foreign key constraints are handled separately in the next step.
Create clustered indexes be<strong>for</strong>e creating any non-clustered indexes. If
clustered indexes are planned <strong>for</strong> a table, defer creation of nonclustered
indexes (as part of PRIMARY KEY or UNIQUE constraint definition) during the
table creation in this step.
The first table in the example, COUNTRIES, is an index-organized table. For
SQL Server, it is converted into a heap with a clustered index on the primary
key, COUNTRY_ID.
Note In <strong>Oracle</strong>, there is a single datatype of the number variety which is
constrained with appropriate scale. While converting to SQL Server, the data
type which is closest in scale needs to be used, as has been demonstrated in
the example.
The following commands are used to create the COUNTRIES and
LOCATIONS tables respectively.
CREATE TABLE HR.COUNTRIES
(COUNTRY_ID CHAR(2) CONSTRAINT NN_COUNTRY_ID NOT NULL,
COUNTRY_NAME VARCHAR(40),
REGION_ID NUMERIC,
CONSTRAINT PK_COUNTRY_C_ID PRIMARY KEY CLUSTERED (COUNTRY_ID)
ON HR_INDX
)
CREATE TABLE HR.LOCATIONS
(LOCATION_ID SMALLINT NOT NULL,
STREET_ADDRESS VARCHAR (40),
POSTAL_CODE VARCHAR(12),
CITY VARCHAR(30) CONSTRAINT NN_LOC_CITY NOT NULL,
STATE_PROVINCE VARCHAR(25),
COUNTRY_ID CHAR(2)
)
ALTER TABLE HR. LOCATIONS ADD CONSTRAINT
PK__ID PRIMARY KEY NONCLUSTERED (LOCATION_ID)
ON HR_INDX

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 137
6.
d.
Create the <strong>for</strong>eign key constraints.
After all the tables have been created, the <strong>for</strong>eign key constraints can be
created in any order.
The following commands create <strong>for</strong>eign keys on the COUNTRIES and
LOCATIONS tables.
ALTER TABLE HR.COUNTRIES ADD CONSTRAINT
FK_COUNTR_REG FOREIGN KEY (REGION_ID)
REFERENCES HR.REGIONS (REGION_ID);
ALTER TABLE HR.LOCATIONS ADD CONSTRAINT
FK_LOC_C_ID FOREIGN KEY (COUNTRY_ID)
REFERENCES HR.COUNTRIES (COUNTRY_ID);
e. Extract and migrate the table comments.
The following command can be used to extract comments in tables in the HR
schema.
SELECT table_name, comments
FROM dba_tab_comments
WHERE owner = 'HR'
AND comments IS NOT NULL
The output returned contains the comments <strong>for</strong> the tables in the HR schema,
such as COUNTRIES, DEPARTMENTS, EMPLOYEES, JOBS,
JOB_HISTORY and LOCATIONS. The output can then be copied into the
statements <strong>for</strong> adding comments to tables in SQL Server.
The following is an example of the use of the sp_addextendedproperty
procedure to add a comment on the COUNTRIES table.
sp_addextendedproperty 'comment', 'country table. Contains 25 rows.
References with locations table.', 'user', HR, 'table', countries
f. Extract and migrate the column comments:
SELECT table_name, column_name, comments
FROM dba_col_comments
WHERE owner = 'HR'
AND comments IS NOT NULL
The output contains the column level comments.
The following is an example of the use of the sp_addextendedproperty
procedure to add a comment on the REGION_ID column of the COUNTRIES
table.
sp_addextendedproperty 'comment', 'Region ID <strong>for</strong> the country. Foreign
key to region_id column in the departments table.' , 'user', hr,
'table', countries, 'column', region_id
Create triggers.
This step demonstrates how to migrate the table triggers from <strong>Oracle</strong> to
SQL Server. The logic (code) that is embedded in the triggers is not discussed
here. For more in<strong>for</strong>mation, refer to the "<strong>Migrating</strong> the Data Access" section in
Chapter 11, "Developing: Databases — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL."
SELECT table_name, 'CRE ATE TRIGGER ' || description header
FROM dba_triggers
WHERE owner = table_owner
AND table_owner = 'HR'
AND base_object_type = 'TABLE'
TABLE_NAME HEADER
EMPLOYEES CREATE TRIGGER secure_employees

138 Developing: Databases — <strong>Migrating</strong> Schemas
BEFORE INSERT OR UPDATE OR DELETE ON employees
EMPLOYEES CREATE TRIGGER update_job_history
AFTER UPDATE OF job_id, department_id ON employees
FOR EACH ROW
The equivalent syntax <strong>for</strong> SQL Server can be generated with the aid of Table 6.24.
The commands <strong>for</strong> creating the secure_ employees and update_job_history
triggers will convert as:
7.
CREATE TRIGGER secure_employees
ON employees
INSTEAD OF INSERT, UPDATE, DELETE
AS
…
GO
CREATE TRIGGER update_job_history
ON employees
AFTER UPDATE
AS
…
GO
IF (UPDATE(job_id) or UPDATE(department_id))
Create indexes.
All indexes related to constraints should have been created in Substep 5.b. This
step covers the indexes that are not related to any constraints.
The following query can be used to retrieve in<strong>for</strong>mation on indexes in <strong>Oracle</strong> that
are not related to any constraints. This query will work only in <strong>Oracle</strong> 9i because
the data dictionary be<strong>for</strong>e this release of <strong>Oracle</strong> does not have the columns used in
this query.
SELECT i.table_name, i.index_name, c.column_name, i.uniqueness,
i.tablespace_name, i.pct_free
FROM dba_indexes i, dba_ind_columns c
WHERE i.table_name = c.table_name
AND i.index_name = c.index_name
AND i.owner = c.index_owner
AND i.owner = 'HR'
AND (i.owner, i.index_name) NOT IN
(SELECT index_owner, index_name
FROM dba_constraints
WHERE owner = 'HR'
AND index_name IS NOT NULL)
ORDER BY i.table_name, i.index_name, c.column_position
The output obtained has been <strong>for</strong>matted as follows:
TABLE_NAME INDEX_NAME
COLUMN_NAME
UNIQUENESS
TABLESPACE_NAME
PCT_FREE
DEPARTMENTSDEPT_LOCATION_IX LOCATION_ID NONUNIQUE
INDX 10
EMPLOYEES EMP_DEPARTMENT_IX
INDX 10
EMPLOYEES EMP-JOB-IX
INDX 10
DEPARTMENT_ID
JOB_ID
NONUNIQUE
NONUNIQUE

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 139
EMPLOYEES EMP_MANAGER_IX MANAGER_ID NONUNIQUE
INDX 10
EMPLOYEES EMP_NAME_IX LAST_NAME NONUNIQUE
INDX 10
EMPLOYEES EMP_NAME_IX
FIRST_NAME
NONUNIQUE
INDX
10
JOB_HISTORYJHIST_ DEPARTMENT_IX DEPARTMENT_ID NONUNIQUE
INDX
10
JOB_HISTORYJHIST_EMPLOYEE_IX EMPLOYEE_ID NONUNIQUE
INDX
10
JOB_HISTORYJHIST_ JOB_IX JOB_ID NONUNIQUE
INDX
10
LOCATIONS LOC_CITY_IX CITY NONUNIQUE
INDX
10
LOCATIONS LOC_COUNTRY_IX COUNTRY_ID NONUNIQUE
INDX
10
LOCATIONS LOC_STATE_PROVINCE_IX STATE_PROVINCE NONUNIQUE
INDX
10
This in<strong>for</strong>mation can be used to create indexes in SQL Server as follows:
CREATE NONCLUSTERED
INDEX hr.dept_location_ix
ON hr.departments(
location_id)
WITH FILLFACTOR = 90
ON HR_INDX
CREATE NONCLUSTERED INDEX hr.emp_name_ix
ON hr.employees(last_name, first_name)
WITH FILLFACTOR = 90
ON HR_INDX
Because indexes have been created over several steps, you should verify that an
equivalent index has been created in SQL Server <strong>for</strong> each index in <strong>Oracle</strong>.
In <strong>Oracle</strong>, generate a listing of all indexes using the following command:
8.
SELECT i.table_name, i.index_name,
c.column_name, i.uniqueness, i. tablespace_name,
i.pct_free
FROM dba_indexes i, dba_ind_columns c
WHERE i.table_name = c.table_name
AND i.index_name = c.index_name
AND i.owner = c.index_owner
AND i.owner = 'HR'
ORDER BY i.table_name, i.index_name, c.column_position
In SQL Server, execute the following command on each table with the table name
substituted <strong>for</strong> name to retrieve in<strong>for</strong>mation on the indexes available <strong>for</strong> the table:
sp_helpindex [ @objname = ] 'name'
Create views.
Extract the views and their definition from <strong>Oracle</strong> using the following command:
SELECT view_name, text
FROM dba_views
WHERE owner = 'HR'
The output provides the view query.

140 Developing: Databases — <strong>Migrating</strong> Schemas
The query <strong>for</strong> DEPT is as follows:
select "DEPARTMENT_ID", "DEPARTMENT_NAME", "MANAGER_ID", "LOCATION_D",
"DEPT_LOC"
from hr.departments
The query <strong>for</strong> EMB_DETAILS_VIEW is as follows:
SELECT
e.employee_id,
e.job_id,
e.manager_id,
e.department_ id,
d.location_id,
l.country_id,
e.first_name,
e.last_name,
e.salary,
e.commission_pct,
d.department_ name,
j.job_title,
l.city,
l.state_province,
c.country_name,
r.region_name
FROM
employees e,
departments d,
jobs j,
locations l,
countries c,
regions r
WHERE e.department_id = d.department_id
AN D d.location_id = l.location_id
AND l.country_id = c.country_id
AN D c.region_id = r.region_id
AND j.job_id = e.job_id
WITH READ ONLY
For the view DEPT, the view text shows capitalized names enclosed in double
quotes <strong>for</strong> the column names:
select "DEPARTMENT_ID", "DEPARTMENT_NAME", "MANAGER_ID", "LOCATION_D",
"DEPT_LOC" from hr.departments
This is an indication that the column names were filled in by the system, and the
original DDL <strong>for</strong> the CREATE VIEW dept is as follows:
select * from hr.departments
As pointed out in the discussion on using views instead of synonyms <strong>for</strong> tables,
SQL Server retains the exact definition used in the DDL. <strong>Oracle</strong> does the same
thing when an asterisk (*) is not used. This behavior is shown in the
EMP_DETAILS_VIEW view text. Thus, while converting the syntax, the DDL may
be changed back to an asterisk
instead of specifying every column.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 141
Note The DEPT view was added to the HR schema to demonstrate this point.
The EMP_DETAILS_VIEW can be created under the HR schema using the
following command:
CREATE VIEW hr.EMP_DETAILS_VIEW AS
SELECT
e.employee_id,
e.job_id,
e.manager_id,
e.department_id,
d.location_id,
l.country_id,
e. first_name,
e.last_name,
e.salary,
e.commission_pct,
d.department_name,
j.job_title,
l.city,
l.state_province,
c.country_name,
r.region_name
FROM hr.employees e INNER JOIN hr.departments d
ON e.department_id = d.department_id
INNER JOIN hr.locations l
ON d.location_id = l.location_id
INNER JOIN hr.countries c
ON l.country_id = c.country_id
INNER JOIN hr.regions r
ON c.region_id = r.region_id
INNER JOIN hr.jobs j
ON j.job_id = e.job_id;
The WITH READ ONLY clause will have to be en<strong>for</strong>ced by ensuring only SELECT
privilege is given to users.
9. Create functions, stored procedures, and packages.
The following command can be used to get a listing of all functions defined by the
schema owner, HR:
SELECT object_name, object_type
FROM dba_objects
WHERE owner = 'HR'
AND object_type IN ('FUNCTION', 'PROCEDURE', 'PACKAGE', 'PACKAGE BODY')
The output retuned is:
OBJECT_NAME OBJECT_TYPE
ADD_JOB_HISTORY PROCEDURE
SECURE_DML PROCEDURE
The source code of each of these objects can be extracted from the data dictionary
using the command:

142 Developing: Databases — <strong>Migrating</strong> Schemas
SELECT text
FROM dba_source
WHERE owner = 'HR'
AND NAME = 'ADD_JOB_HISTORY'
ORDER BY line
The output is:
TEXT
PROCEDURE add_job_history
( p_emp_id job_history.employee_id%type
, p_start_date job_history.start_date%type
, p_end_date job_history.end_date%type
, p_job_id job_history.job_id%type
, p_department_id job_history.department_id%type
)
IS
BEGIN
INSERT INTO job_history (employee_id, start_date,
end_date, job_id, department_id)
VALUES(p_emp_id, p_start_date, p_end_date, p_job_id, p_department_id);
END add_job_history;
An overview of the ef<strong>for</strong>t in migrating functions, stored procedures, and packages
has been given in the "Stored Programs" section of this chapter. For a detailed
discussion of migrating the code, refer to the "<strong>Migrating</strong> the Data Access" section
in Chapter 11.
10. Create synonyms.
Synonyms are used with non-schema users to provide location transparency.
Because SQL Server does not support synonyms, the SQL will have to be
modified to contain a schema prefix.
Note An <strong>Oracle</strong> schema could potentially have objects or properties that are not in
use. Examples of such objects are disabled constraints, invalid views, invalid
synonyms, invalid function, invalid procedures, and dropped column (not purged
from table). Although it is not necessary to migrate these objects to the new
environment, certain clients may differ in this regard.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 143
7
Developing: Databases —
<strong>Migrating</strong> the Database Users
Introduction and Goals
Chapter 6, "Developing: Database — <strong>Migrating</strong> Schemas," concentrated strictly on the
migration of the schema, its owner, and objects. The other class of database users is the
one that accesses the data in the tables of these schemas. These users do not own any
objects, such as tables or views, but may have some synonyms that may point to the
tables and views in the application schema. The ef<strong>for</strong>t in migrating these users to
Microsoft® SQL Server is in creating the users and reproducing the privileges they
possess in the <strong>Oracle</strong> database. The privileges may be granted to the user directly or
through roles. The migration of roles is also discussed in this chapter.
The steps in migrating the users are:
1. Create the user account.
2. Create roles and grant privileges.
Create User Accounts
A detailed discussion of database accounts, authentication, and password management
was provided in the "Create the Schema Owner" section of Chapter 6. The creation of
user accounts does not differ from the creation of schema accounts in any respect. The
difference is in the privileges that they are granted. Figure 7.1 shows the relationship
between database users, roles, and schema objects.

144 Developing: Databases — <strong>Migrating</strong> the Database Users
Figure 7.1
Dependencies in the migration of users from <strong>Oracle</strong> to SQL Server
The following query can be run in the source <strong>Oracle</strong> database to create a list of users that
have privileges on any object in a specific schema. The query has been constrained to
only a specific schema and its users. This aids in situations where only a subset of the
schemas and the related users are migrated from an <strong>Oracle</strong> database.
SELECT grantee
FROM dba_tab_privs
WHERE owner = username
UNION
SELECT grantee
FROM dba_col_privs
WHERE owner = username
The grantee could be a user or a role. As with the case of the schema owner, the
following query can be used to retrieve the characteristics of any login.
SELECT du.username,
DECODE(du.password,'EXTERNAL','EXTERNAL','DB') "AUTHENTICATION MODE",
du.default_tablespace, du.temporary_tablespace,
dp.resource_name, dp.limit
FROM dba_users du, dba_profiles dp
WHERE du.profile = dp.profile
AND dp.resource_type = 'PASSWORD'
AND du.username = username
The system stored procedure sp_grantlogin is used to create a SQL Server login <strong>for</strong> a
domain-authenticated account, and sp_addlogin is used to create a SQL Server
authenticated account. The procedure sp_grantdbaccess is used to create user

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 145
accounts in the individual databases <strong>for</strong> these logins. User accounts should be created in
a database only if there are objects in the database the user needs to access.
Note While migrating <strong>Oracle</strong> accounts, there may be user accounts that are locked.
The <strong>Oracle</strong> DBA of the original environment should be consulted be<strong>for</strong>e making
decisions on whether to migrate these accounts.
Create Roles and Grant Privileges
A privilege is permission (as it is called in SQL Server) to per<strong>for</strong>m work inside the
database. <strong>Oracle</strong> and SQL Server provide two sets of privileges: system privileges and
object privileges.
Table 7.1 provides terms relating to privileges in <strong>Oracle</strong> and SQL Server that can help
avoid any confusion during a migration.
Table 7.1: Privilege Terms Used in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong> Terminology
Privilege
System privilege
Object privilege
Predefined role permission (<strong>for</strong> example,
DBA)
Grantee
SQL Server Terminology
Permission
Statement permission
Object permission
Implied permissions (<strong>for</strong> example,
sysadmin)
Security account
While <strong>Oracle</strong> has several object privileges, the ones commonly granted to users are
SELECT, INSERT, DELETE, and UPDATE on tables and EXECUTE on stored
programs. SQL Server has the same object privileges.
System and object privileges can be granted to users either directly or through roles.
SQL Server also offers the WITH GRANT OPTION clause <strong>for</strong> object privileges.
<strong>Oracle</strong> and SQL Server differ a lot in the system privileges that are available. <strong>Oracle</strong> has
very granular (more than 100) system privileges. SQL Server system privileges, called
statement permissions, are restricted to the following list:
● BACKUP DATABASE
● BACKUP LOG
● CREATE DATABASE
● CREATE DEFAULT
● CREATE FUNCTION
● CREATE PROCEDURE
● CREATE RULE
● CREATE TABLE
● CREATE VIEW
The rest of the <strong>Oracle</strong> system privileges are bundled into several large fixed roles. For
example, the fixed database role db_datareader is equivalent to the SELECT ANY
TABLE system privilege in <strong>Oracle</strong>.
<strong>Oracle</strong> and SQL Server offer predefined roles and user-defined roles. The predefined
roles have powerful system and object privileges on the data dictionary and the instance.

146 Developing: Databases — <strong>Migrating</strong> the Database Users
The "Roles" topic in SQL Server Books Online provides a list of fixed server roles and
fixed database roles and their description. User-defined roles can be granted system as
well as object privileges.
The privileges <strong>for</strong> administrative users should be revisited when migrating to a
SQL Server database because each database is far more self-contained with respect to
administration. Fixed database roles can be granted privileges on a single database
instead of the system-wide powers af<strong>for</strong>ded by the DBA role in <strong>Oracle</strong>. A complete
discussion of the system privileges and their equivalents in SQL Server is beyond the
scope of this guidance. For more in<strong>for</strong>mation about the fixed server roles and fixed
database roles available in SQL Server and their descriptions, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/architec/8_ar_da_3xns.asp.
There are two important stored procedures <strong>for</strong> granting system privileges in SQL Server:
sp_addsrvrolemember can be used <strong>for</strong> granting fixed system roles and
sp_addrolemember can be used <strong>for</strong> granting fixed database roles.
In <strong>Oracle</strong>, roles are available at the instance or server level and can be granted privileges
on more than one schema. SQL Server user-defined roles are local to a database and
owned by a user. Hence, when migrating a role from <strong>Oracle</strong> to SQL Server, a role has to
be created in each of the databases in which privileges have to be granted.
To grant privileges and roles to a user, follow these steps:
1. Create role(s) in each of the SQL Server database(s) that will be used to control
the permission given to users. A role can be created in a database using the
following commands:
Use database
GO
sp_addrole [ @rolename = ] 'role_name'
[ , [ @ownername = ] 'owner' ]
GO
Where role_name is the name of the role to be created and owner is the user who
will own the role (which will normally be the schema owner or a security account
<strong>for</strong> the application).
2. System level privileges can either be granted to the role created in step 1 or
directly to the user. The following statement can be used <strong>for</strong> granting system
privileges to roles and users:
GRANT {ALL | system_privilege_name}
TO {user_name | role_name}
Where system_privilege_name is the system privilege to be granted, user_name is
the name of the user to whom the grant is made, and role_name is the name of the
role through which the privileges will be granted to the user.
3. As with system privileges, object privileges can be granted directly to the user or
through roles. The following statement can be used to grant object privileges to
users and roles:
GRANT {ALL | object_privilege_name}
ON object_name
TO {user_name | role_name}
[WITH GRANT OPTION]
Where object_privilege_name is the object privilege to be granted, object_name is
the object on which the privilege is granted, user_name is the name of the user to
whom the grant is made, and role_name is the name of the role through which the
privileges will be granted to the user.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 147
Object privileges can also be granted at the more granular column level instead of
on the entire table. The following statement can be used to grant privileges on one
or more columns of a table:
GRANT {ALL | object_privilege_name}
ON table_name ( column_name [,…] )
TO {user_name | role_name}
[WITH GRANT OPTION]
Where object_privilege_name is the object privilege to be granted, table_name is
the table to which the column belongs, column_name is the specific column on which
the privilege is being granted, user_name is the name of the user to whom the grant
is made, and role_name is the name of the role through which the privileges will be
granted to the user.
4. If privileges are being granted through a role, the role can be granted to a user
using the following command:
sp_addrolemember [ @rolename = ] 'role_name' ,
[ @membername = ] 'user_name'
Where role_name is the name of the role to be granted and user_name is the target
user.
Sample User Migration
When a user is migrated from <strong>Oracle</strong> to SQL Server, the same security architecture can
be maintained by creating roles and granting privileges in a functionally equivalent
manner. The difference in the implementation is depicted in Figure 7.1.
Privileges on objects in a database are given to a local user account at the database
level and do not transgress database boundaries. This implies that, <strong>for</strong> a server or
instance level login, a user account has to be created in each of the databases that it
needs privileges in (either directly or through roles). The following steps are a practical
example of how to migrate the security architecture of an application and its user from
<strong>Oracle</strong> to SQL Server. This example is an extenuation of the migration of the HR schema
in <strong>Oracle</strong> which was started in Chapter 6.
1. Create the user account in SQL Server <strong>for</strong> each of the <strong>Oracle</strong> users.
In <strong>Oracle</strong>, there is a single user account that is granted privileges on various
schemas. In SQL Server, the single user account translates to a two-tier
implementation.
a. Obtain a list of user accounts in the <strong>Oracle</strong> database that have to be migrated
to SQL Server. The list can be obtained using the following statement:
SELECT grantee
FROM dba_tab_privs
WHERE owner = 'HR'
UNION
SELECT grantee
FROM dba_col_privs
WHERE owner = 'HR'
where owner is the name of the schema whose security is being migrated.
The following is the output <strong>for</strong> the HR schema.
GRANTEE
OE

148 Developing: Databases — <strong>Migrating</strong> the Database Users
b.
Obtain the characteristics of user accounts in <strong>Oracle</strong> that were identified in
substep a.
The following statement can be executed to gather in<strong>for</strong>mation on each of the
use rs to be migrated:
SELECT du.username,
DECODE(du.password,'EXTERNAL','EXTERNAL','DB')
"AUTHENTICATION MODE",
du.default_tablespace, du.temporary_tablespace,
dp.resource_name, dp.limit
FROM dba_users du, dba_profiles dp
WHERE du.profile = dp.profile
AND dp.resource_type = 'PASSWORD'
AND du.username = 'OE'
where OE is the name of the user that is being migrated.
The privileges granted to OE user are:
USERNAME AUTHENTICATION MODE DEFAULT_TABLESPACE
TEMPORARY_TABLESPACE RESOURCE_NAME
LIMIT
OE
DB
EXAMPLE
TEMP
FAILED_LOGIN_ATTEMPTS UNLIMITED
OE
DB
EXAMPLE
TEMP
PASSWORD_LIFE_TIME UNLIMITED
OE
DB
EXAMPLE
TEMP
PASSWORD_REUSE_TIME UNLIMITED
OE
DB
EXAMPLE
TEMP
PASSWORD_REUSE_MAX UNLIMITED
OE
DB
EXAMPLE
TEMP
PASSWORD_VERIFY_FUNCTION NULL
OE
DB
EXAMPLE
TEMP PASSWORD_LOCK_TIME UNLIMITED
OE DB EXAMPLE
TEMP PASSWORD_GRACE_TIME UNLIMITED
c.
Create SQL Server login accounts that provide access to the SQL Server
instance.
Because the <strong>Oracle</strong> account in this example is database-authenticated and
none of the password features are in use, the SQL Server login can be created
as a SQL Server-authenticated login.
The following commands can be executed to create the SQL Server login <strong>for</strong>
the user OE with the password OE in the HRDATA database into which the HR
schema's objects are migrated:
Use MASTER
EXEC sp_addlogin
@loginame='OE',
@passwd='OE',
@defdb='HRDATA'
d. Create a user account in each of the databases in which the schema's objects
have been migrated.
The databases in which user accounts have to be created depend on the
<strong>Oracle</strong> schemas <strong>for</strong> which the user has privileges and the SQL Server

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 149
database to which they have been migrated. The following statement can be
used to see the schemas on which the user OE has been granted privileges.
SELECT owner
FROM dba_tab_privs
WHERE grantee = 'OE'
UNION
SELECT owner
FROM dba_col_privs
WHERE grantee = 'OE'
The output of the statement is as follows:
OWNER
HR
SYS
In Chapter 6, the HR schema was migrated to the HRDATA database in
SQL Server. SYS is the data dictionary owner, which translates to master
database in SQL Server. However, because the data dictionary is divided
between the master database and the application (user-created) databases,
<strong>for</strong> an application user, an account in the master database may not be
necessary and should be created after proper scrutiny of the security
requirements.
The following commands can be used to create a user <strong>for</strong> the OE login in the
HRDATA database:
Use HRDATA
EXEC sp_grantdbaccess
@loginame='OE',
@name_in_db='OE'
2.
Create roles through which the privileges will be granted to users.
Only those roles that are granted to users and schemas that are being migrated
will be created in SQL Server. Also, the role has to be created in each of the
databases with the application schema as the owner.
The following statement can be used to retrieve the roles that have been granted
to the user OE:
SELECT granted_role, admin_option
FROM dba_role_privs
WHERE grantee = 'OE'
The following is the output <strong>for</strong> the OE user:
3.
GRANTED_ROLE
CONNECT
RESOURCE
ADMIN_OPTION
NO
NO
The CONNECT and RESOURCE roles are both system roles. No application roles
are in use <strong>for</strong> this schema. Hence all system and object privileges will be granted
directly to the user. If you want to introduce roles in SQL Server, it should be
per<strong>for</strong>med at this point.
Grant privileges and/or roles to the user.
The roles that were identified in Step 2 are granted here.
The CONNECT role gives the user the capability to connect to the <strong>Oracle</strong>
database. In SQL Server, the same privileges are inherently granted when the
login and user accounts are created. The RESOURCE role gives the capability to
create objects in the database. There
is no role in SQL Server that provides the

150 Developing: Databases — <strong>Migrating</strong> the Database Users
same level of privileges as RESOURCE. As a result, the following privileges are
granted.
GRANT CREATE FUNCTION TO OE
GRANT CREATE PROCEDURE TO OE
GRANT CREATE TABLE TO OE
GRANT CREATE VIEW TO OE
The following statement is used to retrieve
the OE user:
system and object privileges granted to
SELECT do.object_type Lvl, dtp.privilege, dtp.grantable, dtp.owner,
dtp.table_name, NULL column_name
FROM dba_tab_privs dtp, dba_objects do
WHERE dtp.owner = do.owner
AND dtp.table_name = do.object_name
AND grantee = 'OE'
UNION
SELECT 'Column', privilege, grantable, owner, table_name, column_name
FROM dba_col_privs
WHERE grantee = 'OE'
UNION
SELECT 'Sys Priv', privilege, admin_option, NULL, NULL, NULL
FROM dba_sys_privs
WHERE grantee = 'OE'
ORDER BY privilege, grantable,
owner, table name, column name
The following output is returned <strong>for</strong> the OE user:
LVL PRIVILEGE GRANTABLE
OWNER TABLE_NAME COLUMN_NAME
Sys Priv CREATE SNAPSHOT NO
Sys Priv QUERY REWRITE
NO
Sys Priv UNLIMITED TABLESPACE
NO
Table EXECUTE NO SYS DBMS_STATS
Table REFERENCES NO HR COUNTRIES
Table REFERENCES NO HR EMPLOYEES
Table REFERENCES NO HR LOCATIONS
Table SELECT NO HR COUNTRIES
Table SELECT NO HR DEPARTMENTS
Table SELECT NO HR EMPLOYEES
Table SELECT NO
HR JOBS
Table SELECT NO
HR JOB_HISTORY
Table SELECT NO
HR LOCATIONS
Based on the preceding output, grant statements can be devised as follows:
GRANT SELECT ON countries to OE;
GRANT SELECT ON departments to OE;
GRANT SELECT ON employees to OE;
GRANT SELECT ON jobs to OE;
GRANT SELECT ON job_history to OE;
GRANT SELECT ON locations to OE;
SQL Server does not contain equivalents <strong>for</strong> CREATE SNAPSHOT, QUERY
REWRITE, REFERENCES, and UNLIMITED TABLESPACE privileges.
The CREATE SNAPSHOT privilege is related to replication, and the QUERY
REWRITE privilege is related
to data warehousing, and both are beyond the scope

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 151
of this guide. The REFERENCES privilege is <strong>for</strong> creating <strong>for</strong>eign key constraints
across schemas which are not allowed in SQL Server. SQL Server does not
impose storage quotas on schemas; an equivalent <strong>for</strong> REFERENCES is not
needed in SQL Server.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 153
8
Developing: Databases —
<strong>Migrating</strong> the Data
Introduction and Goals
Migration of the data represents the final task in the migration of an <strong>Oracle</strong> database to
Microsoft® SQL Server. Even though SQL Server offers several tools that make the
bulk transfer of data from an external source easier, aspects of the migration that cannot
be automated, such as planning the migration and validating that the data has been
moved completely and without error, should be prioritized.
The data migration task can be broken up into the following three subtasks:
1. Planning. It is important to understand the migration options, evaluate the
characteristics of the source data, and evaluate environmental and business
constraints.
2. Execution. This subtask involves preparing the database and transferring the
data.
3. Validation. This subtask accounts <strong>for</strong> all the data and verifies data integrity.
Planning the Data Migration
There are two planning prerequisites. Be<strong>for</strong>e making any decisions, you should first fully
understand the various options available <strong>for</strong> transferring the data from an <strong>Oracle</strong>
database to a SQL Server database, particularly the advantages and limitations of each
of the options. The second prerequisite is to document all the factors or characteristics of
the original environment that could influence your decision making from the available
options. These prerequisites are discussed in detail under the following headings.
Options <strong>for</strong> Migration
In an <strong>Oracle</strong> to SQL Server migration scenario, the two avenues <strong>for</strong> migrating data are to
either push the data from <strong>Oracle</strong> to SQL Server, or to pull the data from <strong>Oracle</strong> into
SQL Server.
Even though <strong>Oracle</strong> can communicate with heterogeneous databases, the operation is
only at a transactional level and cannot be taken advantage of <strong>for</strong> bulk data operations as
needed in a migration situation. The only specialized utility <strong>Oracle</strong> provides <strong>for</strong> exporting
data out of the database is the export utility exp. This utility can only create dumps in
binary <strong>for</strong>mat that cannot be used <strong>for</strong> importing into a non-<strong>Oracle</strong> database.

154 Developing: Databases — <strong>Migrating</strong> the Data
SQL Server is built <strong>for</strong> bulk copying of data, with specialized features and interfaces to a
larg e host of data sources. Figure 8.1 shows the various paths that offer bulk copy
functions <strong>for</strong> moving data from <strong>Oracle</strong>.
Figure 8.1
Paths <strong>for</strong> accessing an <strong>Oracle</strong> database from SQL Server
Data can be migrated from <strong>Oracle</strong> to SQL Server using one of the following options:
● Bulk Copy Program (bcp). bcp is a command line utility that uses the ODBC bulk
copy API in SQL Server. bcp cannot connect to an <strong>Oracle</strong> database and, when
employed <strong>for</strong> moving data from <strong>Oracle</strong> to SQL Server, the data has to be an ASCII
text file. Multiple copies of bcp can be run in parallel while working on the same
target table. The number of parallel sessions is limited by the number of CPUs on
the server.
For in<strong>for</strong>mation about using the bcp utility with Microsoft SQL Server, refer to the
"bcp Utility" article available at
http://msdn.microsoft.com/library/default.asp? url=/library/enus/coprompt/cp_bcp_61et.asp.
● BULK INSERT. BULK INSERT is a T-SQL statement. This statement has the
same kind of functionality as bcp and can be used to import <strong>Oracle</strong> data that has
been captured in a text file. This operation scales linearly with the number of
CPUs, but it is limited to one thread per CPU.
For in<strong>for</strong>mation on the complete BULK INSERT T-SQL statement and its usage,
refer to http://msdn.microsoft.com/library/default.asp?url=/library/enus/tsqlref/ts_ba-bz_4fec.asp.
● Data Trans<strong>for</strong>mation Service (DTS). DTS is a powerful set of GUI tools that can
be used to extract, trans<strong>for</strong>m, and populate SQL Server databases from <strong>Oracle</strong>

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 155
E ven though the functionality to trans<strong>for</strong>m data during the migration exists, an
assumption made during this discussion is that no trans<strong>for</strong>mation of the source data is
required. The BULK INSERT T-SQL statement has been documented in SQL Server
Books Online as the fastest bulk copy method because it executes with the SQL Server
process. In contrast, bcp and DTS are external utilities that are running as their own
processes. As a result, they have the overhead of having to communicate with
S QL Server (using IPC) and pass it data from the source. When bcp and DTS are run on
a client computer, there is network overhead as well.
bcp is faster than DTS when importing very large quantities of data into SQL Server, but
it lacks some of the features of DTS. Studies have ranked bcp first in speed, followed by
BULK INSERT, and then DTS. Refer to the SQL Server Magazine article "Showdown—
bc p vs. DTS" available at http://www.winnetmag.com/Articles/Print.cfm?ArticleID =19760.
Other factors must be considered in making a migration strategy decision. These factors
are discussed under the following heading.
The Microsoft SQL Server Migration Assistant (SSMA) provides the Schema and Data
Mig rator tool, which can migrate the schema and also move the data. The data is
migrated using the SQL Server Linked Server feature to connect directly to <strong>Oracle</strong>
through the <strong>Oracle</strong> Gateway. For more in<strong>for</strong>mation on the Schema and Data Migrator and
to download the tool refer to http://www.microsoft.com/sq l/migration. The beta version of
this tool is available as of the date of publishing this solution. Version 1.0 of the tool is
slated to be available in June 2005.
Factors in Migration
databases. DTS wizards make the entire process of defining and per<strong>for</strong>ming the
import very easy. DTS provides access to the BULK INSERT statement in the DTS
Bulk Insert task. In addition to working with text files, DTS can use OLE DB and
ODBC providers to connect to an <strong>Oracle</strong> database. The direct connectivity to
<strong>Oracle</strong> provides the capability to work with binary large objects (BLOBs).
For an overview of DTS, refer to
http://msdn.microsoft.com/SQL/sqlwarehouse/DTS/default.aspx?pull=/library/en-
us/dnsql2k/html/dts_overview.asp.
Given the various options <strong>for</strong> migrating data from <strong>Oracle</strong> to SQL Server, the choice is
influenced by several business and environment factors. Some of the important factors
(the more critical ones stated first) are:
● Volume of data. The amount of data that has to be migrated is the number one
factor. High volumes of data require more storage, more processing power, larger
network bandwidth, larger migration window, and increased risk of failure.
For more in<strong>for</strong>mation on how to optimize large data imports in SQL Server, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/optimsql/odp_tun_1a_5gyt.asp.
● Migration window. The time window available <strong>for</strong> migration may necessitate
multiple parallel sessions, more resources, and staging of data.
● Type of data. The existence of BLOBs can be handled only by DTS.
● Server processing capacity. Running bcp on the same server as the database
reduces network overhead of bcp talking to SQL Server, but it consumes CPU on
the server.
● Storage availability. The amount of storage available in both the source and
target environment influences the choice of migration method and strategy. For
example, moving the text files on to the target server reduces network overhead.

156 Developing: Databases — <strong>Migrating</strong> the Data
●
●
●
●
The configuration of storage also affects the speed of migration, such as putting
the source text file and the database files on separate disks or devices.
Data source. The capability to create flat files in the source environment affects
the choice of migration method. A fixed-field <strong>for</strong>mat source file takes a lot more
storage and is considerably slower. Delimited <strong>for</strong>mat is recommended.
Type of database. Batch, OLTP, or DSS database type defines the type of
schema objects and their characteristics.
Recovery Model. Database recovery models should be set to simple or bulk-
Use proven methods. Only use methods and options that have proven to work by
logged to minimize logging of BULK INSERT. The capability to do so can be
affected if there are databases being shared by other applications that are in use
during the migration.
the industry and <strong>for</strong> the environment. For example, OLE DB has been proven to be
faster than ODBC while providing all of the same features.
Migration Strategy
The following are some of the factors that can contribute to the creation of a robust
migration strategy:
● Minimize logging. The actions that should be taken to minimize logging are:
● Set the database recovery model to bulk-logged or simple.
● Use TABLOCK hint during bulk loading.
● The target table should either be empty or no indexes should be defined on it.
● Disable or drop all triggers on the target table.
● Drop replication on the target table.
●
●
●
●
●
●
●
Reduce operations overhead. You should drop indexes, constraints, defaults,
and identity operations. When a clustered index is planned <strong>for</strong> a table, order the
data while creating the output file from <strong>Oracle</strong>. The BULK INSERT statement
accepts the ORDER clause and the bcp utility accepts the ORDER hint to specify
the sort of the data files. Avoid concurrent access by other users to the tables
being loaded. The TABLOCK hint can be used while per<strong>for</strong>ming BULK INSERT or
bcp.
Improve parallelism. With a large amount of data (which is the assumption made
throughout this section), the best per<strong>for</strong>mance can only be achieved by per<strong>for</strong>ming
loads in parallel. The parallelism can be inter-table or intra-table.
Avoid side effects. Turn off triggers, bypass identity, bypass default column
setting, and drop replication.
Reduce complexity. When the source database has a large number of tables,
break it down into logical subsets and stage data, if necessary. Importing static and
historical data can be per<strong>for</strong>med in advance.
Reduce risk. Break down larger source data text files using either an editor or by
specifying ranges in the SQL queries that are used <strong>for</strong> exporting the data into spool
files. Any failures that occur when dealing with large files waste time and
resources. In a migration containing very volatile data, the migration should be
completed in a single stage instead of multiple stages.
Commit more resources. Additional CPU, memory, and storage should be
acquired <strong>for</strong> the migration.
Auditing. Include audit steps during the process. This enables trapping of errors
as they occur
during the transfer of data.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 157
Table 8.1 details the suitable method of data porting <strong>for</strong> different migration environments.
Table 8.1: Data Migration Options
Scenario
Data migration environments that have high per<strong>for</strong>mance
req uirements and have huge volumes of data to be
transferred
Methods of data migration that use a small amount of scripts bcp
Applications that need to use scripts on the data transfer
process
Ap plications that require high-powered trans<strong>for</strong>mation of
moderate volumes of data
Tab les contain large objects (LOB) such as RAW, LONG,
BLOB, and CLOB
Recommended method
bcp or BULK INSERT
BULK INSERT
Here are some additional considerations <strong>for</strong> planning the migration:
● The final strategy should be based on the amount of time available <strong>for</strong> the actual
deployment and cutover.
● The per<strong>for</strong>mance of the load operation should be dependent on the chosen
strategy.
● Instead of sticking to a single method, a combination of methods can be employed
based on the strengths and weaknesses of the individual methods. For example,
DTS need not be used as the migration method just because there are LOB
columns.
● The tables in the migration can be broken up and a combination of methods could
be used, taking advantage of the strengths of each.
● Parallel operation should be applied on large tables.
● The per<strong>for</strong>mance of bcp versus BULK INSERT has been found to vary. Test both
these approaches in your scenario be<strong>for</strong>e making a decision.
● Test data files should be created and the per<strong>for</strong>mance of the various methods
measured in the target environment.
● A prototype of the final strategy should be created and the process should be
practiced and perfected be<strong>for</strong>e deployment.
DTS
DTS
Executing the Data Migration
This section details the steps to be per<strong>for</strong>med <strong>for</strong> migrating data. The section has been
broken into three tasks:
1. Pre-implementation
2. Implementation
3. Post-implementation
Each of these tasks is discussed in detail under the following headings.

158 Developing: Databases — <strong>Migrating</strong> the Data
Pre-Implementation Tasks
The following tasks have to be completed be<strong>for</strong>e per<strong>for</strong>ming the migration:
1. Back up the database.
Delete any test data from the target database and create a full backup of the empty
database. Restoring the backup will be faster than the work involved in rolling back
a failed or incomplete migration.
2.
Export <strong>Oracle</strong> data into text files.
Data from each table that has to be migrated is exported into comma-delimited
ASCII text files.
Note The string data should be optionally enclosed in double quotation marks (")
in case there are commas in the column data. The date fields can be exported in
the desired <strong>for</strong>mat using the TO_CHAR function.
Sample:
In SQL*Plus, connect to the schema and execute the following command:
desc countries
The output is:
Name Null? Type
----------------------------------------- -------- -----------------
COUNTRY_ID
COUNTRY_NAME
REGION_ID
NOT NULL CHAR(2)
VARCHAR2(40)
NUMBER
Create a .sql file (example countries.sql) with the following content:
set pages 0
set lines 10000
set trimspool on
set feedback off
spool /data/dump/countries.csv
select country_id||','||country_name||','||region_id
from countries;
spool off
Executing this file using SQL*Plus produces the following text file that can be
imported into SQL Server.
Note If these commands are typed at the command prompt inside the SQL*Plus
utility in Microsoft Windows®, the output file will contain extraneous prompt
commands at the beginning and end of the file. This does not occur if the
commands are executed from a file.
AR,Argentina,2
AU,Australia,3
BE,Belgium,1
BR,Brazil,2
CA,Canada,2
CH,Switzerland,1
CN,China,3
DE,Germany,1

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 159
DK,Denmark,1
EG,Egypt,4
FR,France,1
HK,HongKong,3
IL,Israel,4
IN,India,3
IT,Italy,1
JP,Japan,3
KW,Kuwait,4
MX,Mexico,2
NG,Nigeria,4
NL,Netherlands,1
SG,Singapore,3
UK,United Kingdom,1
US,United States of America,2
ZM,Zambia,4
ZW,Zimbabwe,4
Note Using SQL*Plus and the spool command is the best way to create commaseparated
(CSV) exports of <strong>Oracle</strong> table data. Other solutions available based on
the functionality currently available in <strong>Oracle</strong> are DBMS_OUTPUT, UTL_FILE, and
Pro*C. For details on the various methods, refer to
http://asktom.oracle.com/~tkyte/flat/index.html
However, these options should be employed only if the data is being manipulated
during the output process because there are per<strong>for</strong>mance overheads in their use.
3. Set the recovery model of the SQL Server database.
Change the recovery model of the target SQL Server database to bulk-logged or
simple. Bulk-logged mode is preferred.
The following command sets the recovery model of a database to bulk-logged:
ALTER DATABASE database_name
SET RECOVERY BULK_LOGGED
where database_name is the name of the database whose recovery model has to be
set.
4. Disable all constraints.
Identify and disable all constraints, including CHECK, PRIMARY KEY, FOREIGN
KEY, and UNIQUE. Create scripts to restore them.
In SQL Server, only FOREIGN KEY and CHECK constraints can be disabled.
The following command can be used to disable FOREIGN KEY and CHECK
constraints of a SQL Server table:
ALTER TABLE table_name NOCHECK CONSTRAINT ALL
where table_name is the name of the table whose constraints have to be disabled.
PRIMARY KEY and UNIQUE constraints have to be dropped.
The following command can be used to drop PRIMARY and UNIQUE by specifying
their name:
ALTER TABLE table_name DROP CONSTRAINT constraint_name
where constraint_name is the name of the constraint and table_name is the name of
the table in which the constraint exists.

160 Developing: Databases — <strong>Migrating</strong> the Data
Note By default, constraints are not checked when using bcp.
5. Disable all triggers.
Disable triggers on all tables into which data will be loaded.
The following command can be used to disable all triggers on a table.
ALTER TABLE table_name DISABLE TRIGGER ALL
where table_name is the name of the table on which the triggers have to be
disabled.
6. Drop all indexes.
Drop all remaining indexes using the following command after saving the script to
recreate them.
DROP INDEX
table_name.index_name
where index_name is the name of the index to be dropped and table_name is the
table on which the index exists.
7. Handle IDENTITY column inserts.
Let explicit values be copied into columns of a table with the Identity property.
SET IDENTITY_INSERT table_name ON
This setting can be used only on a single table at a time. So ensure that this is set
be<strong>for</strong>e importing a table, or use the functionality in the method being used. In bcp,
the same thing can be achieved using the -E switch. In BULK INSERT, use the
KEEPIDENTITY argument.
BULK INSERT 'table_name' FROM 'data file' WITH KEEPIDENTITY
8. Back up the database.
Create a full backup after the data migration be<strong>for</strong>e per<strong>for</strong>ming any validation or
testing.
Implementation Tasks
The implementation is the actual transfer of data from the source <strong>Oracle</strong> database to the
target SQL Server database. The implementation can be per<strong>for</strong>med in one step or in two
steps. In the single step, implementation data is streamed directly from the <strong>Oracle</strong>
database to the SQL Server database. In the two step process, data is extracted from the
<strong>Oracle</strong> database into files and then loaded into the SQL Server database.
S QL Server provides the following three to ols <strong>for</strong> loading data into a database:
● The bulk copy program (bcp)
● The BULK INSERT statement
● Data Trans<strong>for</strong>mation Services (DTS)
The use of these three tools in transferring data into SQL Server is discussed under the
following headings.
Using bcp
The bcp utility can be accessed from the command prompt. The syntax <strong>for</strong> use is
provided here:
bcp database_name.owner.table_name in data_file –t field_terminator –S
server_name\instance_name
–U username –P password –c –t ,

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 161
where database_name.owner.
table_name is the fully qualified name of the table into which
the data is to be loaded, data_file is the name of the text file containing the data,
field_terminator is the character that is used to delimit columns in a row,
server_name\instance_name is the SQL Server instance, username is the login name, and
password is the password <strong>for</strong> the user login.
-c specifies that the data in the file is in the character data type
-t specifies the field terminator
Figure 8.2 shows the results of executing this command at the Windows command
prompt.
Figure 8.2
Importing data from a text file using bcp
To make the bcp process repeatable, a <strong>for</strong>mat file should be created. The <strong>for</strong>mat file can
be created interactively by executing the b cp command, as shown in Figure 8.3.
Figure 8.3
Creating a <strong>for</strong>mat file <strong>for</strong> use with bcp imports

162 Developing: Databases — <strong>Migrating</strong> the Data
The <strong>for</strong>mat file looks like this:
8.0
3
1 SQLCHAR 0 2 "," 1 COUNTRY_ID SQL_Latin1_General_CP1_CI_AS
2 SQ LCHAR 0 40 "," 2 COUNTRY_NAME SQL_Latin1_General_CP1_CI_AS
3 SQLNUMERIC 0 19 "\r\n" 3 REGION_ID ""
Refer to the topic "Using Format Files" in SQL Server Books Online <strong>for</strong> more in<strong>for</strong>mation
about <strong>for</strong>mat files.
Note The <strong>for</strong>mat file will have to be modified to handle text files that contain column
data values and which are enclosed by quotation marks (").
The <strong>for</strong>mat file can be used <strong>for</strong> future imports into the same table by using the -f switch.
This is illustrated in Figure 8.4. In the example, the <strong>for</strong>mat file is assumed to have been
copied to C:.
Figure 8.4
Importing data from a text file using bcp <strong>for</strong>mat file
Table 8.2 contains the additional arguments that are relevant while importing large
volumes of data from <strong>Oracle</strong>.
Table 8.2: Additional Arguments of the bcp Utility
Argument (or option)
Description
-k bypasses DEFAULT definition
-h "hints" bulk copy hints
-E allows Identity insert
-a network packets size 512 to 65536 (default
4096)
-e error_file logs errors during the import
-b batch_size uses default, which is all rows in the file
Note Hidden characters in text files can cause problems such as the "unexpected null
found" error. Care has to be taken when opening and manipulating text files containing
data.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 163
Using BULK INSERT
The BULK INSERT T-SQL statement provides the same functionality as the bcp utility.
The major difference is that this functionality is from within a database session.
The following statement achieves the same work as was demonstrated with bcp:
BULK INSERT hrdata.hr.countries FROM 'c:\countries.csv'
WITH (
DATAFILETYPE = 'char',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n'
)
Note Only members of the sysadmin role can use BULK INSERT.
Table 8.3 contains additional arguments that need to be used while importing large
amounts of <strong>Oracle</strong> data.
Table 8.3: Additional Arguments Available with the BULK INSERT Command
Argument (or option)
Description
-k bypasses DEFAULT definition
TABLOCK
locks
KEEPIDENTITY
allows values to be specified <strong>for</strong> identity
column
FIRE_TRIGGERS trigger execution is not suppressed
CHECK_CONSTRAINTS
constraints on table have to be checked
BATCHSIZE
use default, which is all rows in the file
Note For more in<strong>for</strong>mation about the bulk copy operations and on improving its
per<strong>for</strong>mance, refer to "Optimizing Bulk Copy Per<strong>for</strong>mance" at
http://msdn.microsoft.com/library/en-us/optimsql/od p_tun_1a_5gyt.asp?frame=true,
and "Bulk Copy Per<strong>for</strong>mance Considerations" at http://msdn.microsoft.com/library/en-
us/adminsql/ad_impt_bcp_5zqd.asp.
For in<strong>for</strong>mation on different switches available with Bulk Insert, refer to
http ://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ba-
bz_4fec.asp.
Using DTS
This section is used to demonstrate how DTS wizards can be used to import data into
SQL Server tables from text files and directly from an <strong>Oracle</strong> database.
The DTS Import/Export Wizard can be launched from Enterprise Manager
using the following steps or using the DTS Import Wizard:
1. Expand Server.
2. Right-click Databases, click All Tasks, and then click Import Data.
3. Click the Next button on the wizard's Welcome screen.
4. The next window presented is <strong>for</strong> choosing the data source. In the Data
Source drop-down list choose Text File. Pick the file containing <strong>Oracle</strong> table
data in the File name text box.

164 Developing: Databases — <strong>Migrating</strong> the Data
5. The file <strong>for</strong>mat characteristics are chosen in the next window. The file type
should be ANSI, and the row delimiter should be {CR}{LF}. If column data
values are quoted, it can be specified in the Text qualifier field. The delimiter
character, which is a comma (,), is specified in the next screen.
6. The Microsoft OLE DB Provider <strong>for</strong> SQL Server should be chosen as the
destination and the server and login in<strong>for</strong>mation provided <strong>for</strong> the target
SQL Server instance.
DTS offers the option of executing the import, saving it to a DTS package and
scheduling. For in<strong>for</strong>mation on how to schedule DTS packages, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dtssql/dts_pkgmng_4hm6.asp.
DTS from <strong>Oracle</strong> Database
The steps in creating a DTS package to connect and import data directly from the <strong>Oracle</strong>
database is very similar to the process described in the previous section. Instead of
pointing the source to a file, an <strong>Oracle</strong> database is specified through an OLE DB or
ODBC provider <strong>for</strong> <strong>Oracle</strong>.
The DTS Import/Export Wizard can be launched from Enterprise Manager
using the following steps or using the DTS Import Wizard:
1. Expand Server.
2. Right-click Databases, click All Tasks, and then click Import Data.
3. Click the Next button on the wizard's Welcome screen.
4. The next window presented is <strong>for</strong> choosing the data source. In the Data Source
drop-down list, choose the Microsoft ODBC Driver <strong>for</strong> <strong>Oracle</strong>. Enter the <strong>Oracle</strong>
database alias and login in<strong>for</strong>mation.
5. The Microsoft OLE DB Provider <strong>for</strong> SL Server should be chosen as the destination
and the server and login in<strong>for</strong>mation provided <strong>for</strong> the target SQL Server instance.
6. The next screen offers the option of copying data from a table (or view) or using a
query.
7. If the table or view option is chosen, the next screen provides a list of tables and
views available <strong>for</strong> import. The destination table name and trans<strong>for</strong>mation
in<strong>for</strong>mation has to be provided along with the source table/view.
8. If query option is chosen, the next screen provides a window <strong>for</strong> entering the query
statement. The destination table and trans<strong>for</strong>mation can be entered in the next
screen.
9. The execution of the import can be done immediately or scheduled <strong>for</strong> a later time.
Note DTS has the capability of reading the table description from the <strong>Oracle</strong> database
and creating tables in SQL Server. The wizard has been found to be faulty in its choice
of equivalent data types <strong>for</strong> SQL Server tables.
Data can be migrated directly out of the database instead of through an intermediary file
if the interconnect between the servers hosting the two databases is very fast. Also, no
additional storage is required <strong>for</strong> the data files on the two servers. Use of files can reduce
the deployment time if the data export can be done in advance and staged <strong>for</strong> import.
For a case study on incrementally loading tables using the SQL Server bulk load options,
refer to
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/incbulkload.mspx.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 165
Post-Implementation Tasks
The following tasks have to be per<strong>for</strong>med to ensure the success of the data transfer. The
tasks per<strong>for</strong>med here undo the changes that were made to the schema <strong>for</strong> affecting the
data transfer, such as disabling of constraints and triggers. Chapter 9, "Developing:
Databases — Unit Testing the Migration" has a more detailed discussion of per<strong>for</strong>ming the
first two tasks as a part of testing the migrated database.
1. Validate the data migration.
Th e validation tasks are discussed in detail in the "Validating the Data Migration"
section later in this chapter.
2. Re-enable the constraints.
Enable all constraints, including CHECK, PRIMARY KEY, FOREIGN KEY, and
UNIQUE. Use the scripts that were created while disabling the constraints.
FOREIGN KEY and CHECK constraints can be enabled using the following syntax:
ALTER TABLE table_name CHECK CONSTRAINT ALL
where table_name is the table on which the CHECK constraints have to be enabled.
PRIMARY KEY and UNIQUE constraints will have to be recreated using the
original DDL. <strong>Oracle</strong> allows multiple rows where all columns (nullable) of a
UNIQUE constraint have NULL values. SQL Server treats NULL as duplicates
(instead of an unknown value) <strong>for</strong> the purpose of uniqueness. Hence creating a
UNIQUE constraint would return an error if such a condition exists. Because it
would be difficult to create values, the best way to maintain the status quo would
be to replace the UNIQUE constraint with a trigger that accomplishes the same
thing.
3. Recreate the indexes.
The constraint indexes can be recreated using the saved scripts. Multiple indexes
on a single table can be created in parallel using different client sessions.
4. Enable the triggers.
Identify and enable all triggers by using the following syntax:
ALTER TABLE table_name ENABLE TRIGGER ALL
where table_name is the table on which the triggers are to be enabled.
5. Set the recovery model.
Restore the recovery model of the SQL Server database to the original setting
(normally full) by using the following syntax:
ALTER DATABASE database_name
SET RECOVERY FULL
6. Capture data statistics.
Per<strong>for</strong>m the steps necessary to capture data statistics required by the optimizer.
7. Back up the database.
Create a full backup of the entire server, including the user databases. This is the
first valid backup of the migrated database.
Validating the Data Migration
The following major tasks have to be per<strong>for</strong>med to validate the migrated data:
1. Verify the data transfer.
The logs or audit files <strong>for</strong> the data transfers should be checked <strong>for</strong> errors or
failures. After this process
is complete, row counts of every table in the destination
SQL Server database should be matched to the source <strong>Oracle</strong> database. If any

166 Developing: Databases — <strong>Migrating</strong> the Data
2.
discrepancy is found in the counts, troubleshooting should include identifying the
missing records and viewing the logs and audit files <strong>for</strong> error messages that can
provide reasons <strong>for</strong> the failure. The data transfer process should take into
consideration any changes in the logical model between the source <strong>Oracle</strong>
database and SQL Server. A more stringent check is difficult <strong>for</strong> large databases.
More validation of the data transfer occurs in the next step as part of the data
integrity checks.
Validate the data integrity.
Integrity is automatically checked when creating or enabling constraints. The WITH
CHECK clause has to be used when adding constraints. Data integrity checking is
threatened when migrating databases which lack proper primary key constraints
and <strong>for</strong>eign key constraints. For more in<strong>for</strong>mation on the functionality available with
check constraints, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_aa-
az_3ied.asp.
In many cases, there are no strict equivalents of <strong>Oracle</strong> datatypes in SQL Server.
Hence the integrity of such data has to be tested to ensure that there is no
rounding or truncation, and that the exact value is stored.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 167
9
Developing: Databases — Unit
Testing the Migration
Introduction and Goals
The final task to be per<strong>for</strong>med in the Developing Phase is to test the database. Because
everything except the core database design has been trans<strong>for</strong>med, it is very important to
thoroughly test every aspect of the Microsoft® SQL Server database be<strong>for</strong>e release to
the production environment. Testing should cover the hardware, the SQL Server
installation, security, database objects, data, and per<strong>for</strong>mance.
The descriptions of the testing process <strong>for</strong> databases and applications is divided into
smaller pieces and spread out between the Developing and Stabilizing Phases. Testing
<strong>for</strong> integrity and functionality of the migrated database is covered in this chapter.
Additional application-based testing of the database is per<strong>for</strong>med as part of testing the
application. Per<strong>for</strong>mance can be verified only through the benchmarking and piloting that
is per<strong>for</strong>med in the Stabilizing Phase.
Objectives of Testing
The following areas should be tested:
● Physical architecture of the database. Have the data files, transaction log,
tablespaces, and other items that comprise the database been created correctly?
Has the SQL Server instance been properly configured?
● Security. Have the logins and users been correctly created? Have the appropriate
permissions been assigned? Is the database physically secure?
● Logical architecture of the database. Have the tables, views, stored procedures,
triggers, and other database objects been created successfully?
● Data. Have the contents of the tables been transferred correctly? Do tables contain
the correct numbers of rows? Is the data valid?
● Functionality. Do the stored procedures, triggers, views, and other items
comprising Transact-SQL code operate in the same manner as the original <strong>Oracle</strong>
objects?
● Per<strong>for</strong>mance. Does response time and throughput meet requirements and match
user expectations?

168 Developing: Databases — Unit Testing the Migration
The
Testing Process
The database is tested in three different stages of the migration:
●
●
●
Developing Phase — Database
In this stage, the database is unit tested <strong>for</strong> all the components that have been
migrated, which includes the database architecture, the schema, the users, and
the data. This type of testing is covered in the rest of this section.
Developing Phase — Application
In this phase, the database is tested with respect to the application support. This
primarily tests that all the objects required by the application are present and
per<strong>for</strong>m as expected. The application-related testing is covered in the application
development Chapters 11 through 17.
Stabilizing Phase
In the Stabilizing Phase, more thorough tests are per<strong>for</strong>med <strong>for</strong> integration,
per<strong>for</strong>mance, stress, and scalability. This phase is described in Chapter 18.
This section describes the testing process that is followed during the Developing Phase
<strong>for</strong> the database. The testing is interspersed with the steps in the migration of the
database. The procedure <strong>for</strong> migration and testing is illustrated in the flowchart in Figure
9.1.
Figure 9.1
Data migration test procedure

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 169
The tasks on the left half, namely, migrating the architecture, migrating the schema,
migrating the users, and migrating the data, are part of the database migration and are
covered in chapters 5 through 8. The success of these tasks is validated as database
integrity testing and data validation. Details regarding these two types of testing appear
under the following headings.
Test Database Integrity
After the database schema has been created in the target database, an integrity test
should be per<strong>for</strong>med be<strong>for</strong>e starting the data migration. This should cover the physical
database structure, the schema, and the schema objects.
There is no tool available <strong>for</strong> comparing the integrity and validity of the SQL Server
objects as compared to the original <strong>Oracle</strong> objects. Unit testing has to rely on the
experience and expertise of the database designers or administrators who are per<strong>for</strong>ming
the mapping. However, a true unit test would be to load data from the source objects and
run SQL with identical functionality in the two environments. Any discrepancies should be
only as a known (explainable) consequence of the migration.
The following tasks are per<strong>for</strong>med to ensure database integrity:
● Unit test the schema objects. The type and number of each object in the original
<strong>Oracle</strong> database has to be compared to that in the SQL Server database. Queries
can be written in the two databases (<strong>Oracle</strong> and SQL Server) to produce a count of
each type of object. However, the counts in the two solutions may not match
because there is no one-to-one equivalency <strong>for</strong> every object.
● Verify that data elements have been created as per the mapping. The proper
trans<strong>for</strong>mation of the data type and domain values of the columns — as well as any
constraints, such as NULL and CHECK constraint on the columns — have to be
verified be<strong>for</strong>e per<strong>for</strong>ming the data migration. A representative set of data from the
original <strong>Oracle</strong> database can be used <strong>for</strong> this purpose.
● Verify that all constraints are in place. For each table having a parent-child
relationship, referential integrity is checked.
● Functions, triggers, and stored procedures have been accurately
trans<strong>for</strong>med. Stored procedures, triggers, and views can be tested by using an
identical set of representative data in the source and migrated databases.
Execution of test cases against these objects should produce identical results.
● Verify the data access. Additional indexes may be present in SQL Server to offset
features such as fast full index scans in <strong>Oracle</strong> that can use the non-leading
columns of indexes. It should be verified that all objects in the original <strong>Oracle</strong>
database have been successfully migrated to SQL Server. A complete set of T-
SQL statements should be obtained from the application development team and
each of them verified <strong>for</strong> optimal data access paths.
If the application has been migrated, running a few frequently used business transactions
would ensure whether the schema has been successfully migrated. After the correctness
of the database structure and its objects is guaranteed, data migration can proceed.
Test Security
The security mechanisms available with SQL Server and Windows are significantly
different from those used by UNIX and <strong>Oracle</strong>. The difference in the authentication
mechanisms is especially important because it affects the user login process. For
example, the requirements of password management functionality, such as aging,
locking, and password strength will require that Windows authentication be used in place
of database authentication. The system privileges available in the two databases differ

170 Developing: Databases — Unit Testing the Migration
significantly. You must verify that only authenticated, authorized users have access to the
objects in the database. You must also verify that <strong>Oracle</strong> users and roles have been
correctly mapped to SQL Server users and roles, and that all objects in the database
have the appropriate access rights granted to them.
Validate Data
The existence of indexes and constraints during data migration adversely affects the
per<strong>for</strong>mance of the data migration. The firing of triggers can corrupt the data and produce
undesirable effects. There<strong>for</strong>e, these objects have to be disabled or dropped. A negative
aspect of these actions is that data is not checked <strong>for</strong> correctness or completeness
during the migration and has to be validated after the migration. No special plans are
needed <strong>for</strong> validating data integrity. The database itself checks the integrity of the data
when the constraints are enabled using the WITH CHECK clause. For more in<strong>for</strong>mation
on check constraints in SQL Server, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_aa-az_3ied.asp.
The two types of tests that have to be per<strong>for</strong>med to validate the data are discussed in the
"Validating the Data Migration" section in Chapter 8.
Note One of the common risks involved in data migration is the lack of a proper or
complete set of constraints in the database. In many applications, the constraints are
built into the application. In such cases, the development team will have to be involved
in constructing SQL-based tests to verify data integrity by identifying such rules in the
application.
Validate the Migration
After data migration is complete, tests have to be per<strong>for</strong>med on the database as a whole.
Testing should cover the database architecture, database objects, data, and users. In
addition, the database connectivity, security, and per<strong>for</strong>mance have to be tested. For
in<strong>for</strong>mation on client connectivity to the database, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_1_client_5er7.asp.
A discussion of the security architecture in <strong>Oracle</strong> and
SQL Server is available in Appendix A: "SQL Server <strong>for</strong> <strong>Oracle</strong> Professionals." Appendix
B: "Getting the Best out of SQL Server 2000 and Windows" contains several references
on SQL Server per<strong>for</strong>mance.
While in smaller databases the data migration validation can be exhaustive, in very large
databases, some simpler tests (such as counts using various groupings) may be used.
The following checks are recommended:
● Develop group functions based on type of data.
For example, a business-related check can be implemented by calculating the sum
of the balances in all accounts.
● Develop group functions based on time.
● Check <strong>for</strong> record counts.
● Use the application to compare the summary reports.
● Check <strong>for</strong> ad-hoc control totals.
For example, after ledger data of a financial application has been migrated, adding
up the account numbers in that ledger has no business validity. However, this adhoc
control total could reveal if all the data in the row has been migrated
successfully.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 171
The SQL Server Migration Assistant offers a Migration Tester tool that verifies the
migrated objects (procedures, functions, and views) by generating its own set of test
data. For more in<strong>for</strong>mation on the Migration Tester and to download it refer to
http://www.micro soft.com/sql/migration. The beta version of this tool is available as of the
date of publishing this solution. Version 1.0 of the tool is slated to be available in June
2005.
A test that validates the entire migration is the running of production reports and
application with production-quality data. The same reports should be executed against
the original database and the migrated database using a snapshot (or copy) of production
data. Per<strong>for</strong>mance and other vital database statistics, such as cache per<strong>for</strong>mance and
locking, can be gathered.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 173
10
Developing: Applications —
Introduction
Introduction and Goals
The focus of Chapters 10 through 17 is connecting existing <strong>Oracle</strong> applications in the
UNIX environment to the migrated Microsoft® SQL Server database. This chapter
serves as an introduction to the application-oriented development chapters.
The following list provides an overview of the content in each of the application-oriented
development chapters:
● Chapter 11, Developing: Applications — <strong>Oracle</strong> SQL and PL/SQL. This chapter
provides a detailed discussion of the SQL usage differences between <strong>Oracle</strong> and
SQL Server. Trans<strong>for</strong>mation of PL/SQL to T-SQL is also covered.
● Chapter 12, Developing: Applications — Perl. This chapter discusses the
strategies available <strong>for</strong> migrating a Perl application <strong>for</strong> use with the SQL Server
environment.
● Chapter 13, Developing: Applications — PHP. This chapter discusses the
strategies available <strong>for</strong> migrating a PHP application <strong>for</strong> use with the SQL Server
environment.
● Chapter 14, Developing: Applications — Java. This chapter discusses the
strategies available <strong>for</strong> migrating a Java application <strong>for</strong> use with the SQL Server
environment.
● Chapter 15, Developing: Applications — Python. This chapter discusses the
strategies available <strong>for</strong> migrating a Python application <strong>for</strong> use with the SQL Server
environment.
● Chapter 16, Developing: Applications — <strong>Oracle</strong> Pro*C. This chapter discusses the
strategies available <strong>for</strong> migrating a Pro*C application <strong>for</strong> use with the SQL Server
environment.
● Chapter 17, Developing: Applications — <strong>Oracle</strong> Forms. This chapter discusses
the strategies available <strong>for</strong> migrating an <strong>Oracle</strong> Forms application <strong>for</strong> use with the
SQL Server environment.
No application migration will be successful without a clear understanding of the <strong>Oracle</strong>
technologies that are factors during an <strong>Oracle</strong> database migration to SQL Server. An
overview of these basic technologies and specific migration
considerations is discussed

174 Developing: Applications — Introduction
in the following two sections. The application ecosystem can be broken into the following
two tiers:
● Data access
● Programming language and connectivity tier
Data access comprises the components of the application that interact with the database
data. SQL is the language used <strong>for</strong> retrieving and manipulating the database data. The
application developer is responsible <strong>for</strong> ensuring that applications designed <strong>for</strong> the <strong>Oracle</strong>
source database work the same way with the migrated SQL Server target database. The
changes required vary based on the programming language support and the API libraries
available <strong>for</strong> SQL Server. The migration of SQL and PL/SQL components to T-SQL <strong>for</strong>ms
a common requirement, irrespective of the changes to the rest of the application. The
migrated applications then have to be tested against the migrated SQL Server database
to ensure their original functionality.
From an application developer's perspective, <strong>Oracle</strong> and SQL Server manage data in
similar ways. The internal differences between <strong>Oracle</strong> and SQL Server are significant, but
if managed properly, these differences will have minimal impact on a migrated
application.
Application Migration Strategies
There are four different strategies <strong>for</strong> application migration that are discussed throughout
the development chapters. These strategies include:
● Interoperation. The application components remain in the UNIX environment.
● Port or rewrite the application to the Microsoft .NET plat<strong>for</strong>m. The application
is migrated to run on the .NET framework.
● Port or rewrite the application to the Microsoft Win32® plat<strong>for</strong>m. The
application is migrated to run on the Windows® environment using the Win32 API.
● Quick port using Windows Services <strong>for</strong> UNIX 3.5. The application is ported to
use Interix within the Windows environment.
Each of the four strategies is discussed in more detail under the following headings. One,
some, or all of these solution design strategies <strong>for</strong>ms the basis of the solution concept
that was completed during the Envisioning Phase. Even when the goal is to standardize
on the Windows plat<strong>for</strong>m, some of these strategies may be employed as intermediary
steps in a multi-phased migration.
In general, .NET development is favored over Win32, but a number of recommendations
in the following chapters provide guidance on migrating to a Win32 solution. This
in<strong>for</strong>mation is provided in cases where a Win32 migration is the most cost-effective and
straight<strong>for</strong>ward development route.
For more in<strong>for</strong>mation on these migration strategies, see "Application and Database
Migration <strong>Solution</strong> Design Strategy" in Chapter 2, "Envisioning Phase."
Interoperation
In this strategy, the application remains on the UNIX plat<strong>for</strong>m, while only the database is
migrated to SQL Server on the Windows plat<strong>for</strong>m. This strategy is employed when minor
changes can be made to the source code, connection strings, or the connectivity layer to
allow <strong>for</strong> the change in the back end database.
Often, an interoperation strategy is used as an interim step in a phased migration. This
strategy allows <strong>for</strong> the application to be quickly connected to the solution's SQL Server

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 175
database with minimal risk or ef<strong>for</strong>t. However, this would not be an adequate solution if
one of the business requirements <strong>for</strong> the migration project is elimination of the UNIX
environment.
Port or Rewrite to .NET Framework
The .NET framework is the next generation plat<strong>for</strong>m from Microsoft <strong>for</strong> building,
deploying, and running Windows applications. It provides a highly productive, standards-
environment <strong>for</strong> integrating existing investments with next-
based, multi-language
generation applications and services. When porting or rewriting, migration to the .NET
plat<strong>for</strong>m is preferred because it is the current development plat<strong>for</strong>m <strong>for</strong> Windows
applications.
When migrating an application to the .NET framework, there are two different options.
One is to per<strong>for</strong>m a full port of the application, and the other is to rewrite the application
using the .NET application programming interfaces (APIs).
As of this writing, with the increased adoption of the .NET Framework in the industry, the
availability of the .NET APIs <strong>for</strong> application porting are expanding. For some of the
languages, the drivers are in beta with support being improved to include all functionality.
Verify the stability of the library and the support <strong>for</strong> all the function calls needed <strong>for</strong>
SQL Server when picking a driver.
A rewrite of the application is required when there is no support on the .NET plat<strong>for</strong>m <strong>for</strong>
the language in use. An example of this would be an application based on <strong>Oracle</strong> Forms.
The best option in this case would be to rewrite the application on Windows using Visual
Basic® .NET.
Rewriting an application can potentially pose challenges. It can be a time-consuming,
risky, and costly option. The risk inherent in a rewrite is that the business logic or an
important functionality is inadvertently changed while rewriting the code. Careful testing
and stabilizing of the rewritten application needs to be conducted to ensure proper
business logic and functionality. The following chapters provide detailed in<strong>for</strong>mation on
database connectivity and the code changes needed to migrate to the SQL Server
solution. Rewriting an application requires additional knowledge beyond the scope of this
guide. Where appropriate, this guide provides references to more in<strong>for</strong>mation about
rewriting.
Port or Rewrite to Win32
Th e Win32 API is the primary programming interface to the Windows operating system
family, including Windows® 2003. The Win32 API provides functions <strong>for</strong> processes,
memory management, security, windowing, and graphics.
Considering the benefits of migration to the .NET Framework, the only reason to migrate
to the Win32 plat<strong>for</strong>m is that migration to .NET is not technically feasible <strong>for</strong> your
organization. As with the previous strategy, two migration options are available when
moving to a Win32-based plat<strong>for</strong>m. The first is to per<strong>for</strong>m a port of the application, and
the other is to rewrite the application using the Win32 APIs.
A port can be used <strong>for</strong> most applications that have been developed in Java, Perl, PHP, or
Python, which are available on both the UNIX and Windows plat<strong>for</strong>ms. APIs are available
<strong>for</strong> SQL Server in a majority of cases. A port requires minimum changes to be done to
the source code, and a port uses UNIX-standard compatible libraries and utilities that
exist on the Windows plat<strong>for</strong>m. Compared to a port, the source code in a rewrite requires
considerable changes to operate in the new environment. When possible, consider
rewriting the application using .NET instead of Win32.

176 Developing: Applications — Introduction
Quick Port Using Windows Services <strong>for</strong> UNIX
Applications on UNIX can be rehosted to an environment on Windows (Interix) that is
similar to UNIX. Interix is a complete, POSIX-compliant (Portable Operating System
Interface) development environment that is tightly integrated with the Windows kernel. It
is a part of the Windows Services <strong>for</strong> UNIX 3.5 product suite from Microsoft.
One of the quickest migration paths possible is to port the code directly to
Windows Services <strong>for</strong> UNIX. Interix allows native UNIX applications and scripts to work
alongside Windows applications. The best way to view Interix is to understand it as a
POSIX-compliant version of UNIX built on top of the Windows kernel. Importantly, Interix
is not an emulation of the UNIX environment on the Windows APIs. Migration using
Windows Services <strong>for</strong> UNIX involves obtaining the source code, installing it in the Interix
development environment, modifying the configuration scripts and makefiles, and
recompiling the application. This strategy is referred to as a quick port. As with any other
migration strategies, the data access (SQL, PL/SQL) has to be migrated to target a
SQL Server database. A quick port is preferred if the client application is closely tied to
UNIX utilities that are not available on Windows. This approach cannot rely on special
libraries <strong>for</strong> which the source code is not available. Also, quick ports using
Windows Services <strong>for</strong> UNIX cannot take advantage of most standard Windows
functionality.
The ported application may be successful immediately, or it may require modifications to
account <strong>for</strong> the new hardware plat<strong>for</strong>m, the target operating systems, and local
configuration in<strong>for</strong>mation. It may not be possible to determine whether a quick port is
possible without actually conducting the port. Extensive testing of the application is
essential after the port to ensure that all features have been migrated successfully.
Scenarios and Cases
In the following chapters, these migration strategies are discussed in relation to common
application languages. All four strategies may not be available, feasible, or desirable <strong>for</strong>
each of the languages. For example, per<strong>for</strong>ming a quick port using
Windows Services <strong>for</strong> UNIX is not discussed in the Perl chapter because Perl can run
natively on the Windows plat<strong>for</strong>m. Because the facilities available to Perl on Windows are
much richer (including .NET) than those available to Perl on Windows Services <strong>for</strong> UNIX,
migrating Perl applications to a Windows environment is preferred.
Throughout Chapters 11 through 17, the migration strategies are divided into specific
scenarios that may be similar to existing situations that you will encounter. Each scenario
may be split into individual cases that detail the various options available <strong>for</strong> a given
scenario. For example, the migration strategy of porting may best apply to your situation.
In porting PHP applications to run in the Windows environment scenario, there are three
cases that are discussed based on the database driver being utilized. These individual
cases include detailed in<strong>for</strong>mation regarding the use of ORA, OCI8, or ODBC database
drivers to maintain connectivity in the solution.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 177
11
Developing: Applications —
<strong>Migrating</strong> <strong>Oracle</strong> SQL
and
PL/SQL
Introduction
A lthough <strong>Oracle</strong> and Microsoft® SQL Server both use the ANSI SQL language, each
uses proprietary extensions to add functionality. <strong>Oracle</strong> uses PL/SQL, while SQL Server
uses Transact SQL. This cha pter focuses on application code that may need to be
modified <strong>for</strong> use with SQL Server because of these extensions.
This chapter should be used in conjunction with Chapters 12 through 17. These chapters
provide in<strong>for</strong>mation <strong>for</strong> application-specific languages, including Perl, PHP, Java, Python,
Pro*C, and <strong>Oracle</strong> Forms.
No application migration will be successful without a cle ar understanding of the <strong>Oracle</strong>
technologies that come into play during an <strong>Oracle</strong> database migration to the SQL Server
plat<strong>for</strong>m. The strategy <strong>for</strong> application conversion is broken down into the following two
segments:
● Data access, which is discussed in this chapter.
● Programming language a nd connectivity tier, which are discussed in Chapters 12
through 17.
<strong>Migrating</strong> Data Access
The application conversion development team is responsible <strong>for</strong> ensuring that
applications designed <strong>for</strong> the <strong>Oracle</strong> source database work the same way with the
migrated SQL Server target database.
The application migration process may appear
complicated. Be<strong>for</strong>e doing the migration of
the <strong>Oracle</strong> production database, the DBA or application developer should install a
SQL Server test database. Applications can then be modified and tested, if necessary, to
ensure their original functionality with the SQL Server database. Testing is necessary
because of the core differences between <strong>Oracle</strong> and SQL Server.
There are some architectural differences between each RDBMS. The terminology used
to describe <strong>Oracle</strong> architecture often has a completely different meaning in Microsoft
SQL Server; <strong>for</strong> example, the term database has a different meaning. Additionally, both

178 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
<strong>Oracle</strong> and SQL Server have made many proprietary extensions to the SQL-92 standard.
These extensions are discussed throughout this chapter.
F rom an application develope r's perspective , <strong>Oracle</strong> and SQL Server manage data in
similar ways. The internal differences between <strong>Oracle</strong> and SQL Server are significant, but
if managed properly, have mi nimal impact on a migrated application.
The most signif icant migration issue that confronts the developer is the implementation of
the SQL-92 SQL language standard and the extensions that each RDBMS has to offer.
Some developers use only st andard SQL language statements, preferring to keep their
program code as generic as possible. Generally, this means restricting program code to
the entry-level SQL-92 standard, which is implemented consistently across many
database products, including <strong>Oracle</strong> and SQL Server.
Using RDBMS-specific extensions might produce unneeded complexity in the program
code during the migration. For example, <strong>Oracle</strong>'s DECODE function is a nonstandard
SQL extension specific to Ora cle. The CASE expression in SQL Server is not
implemented in all database products.
B oth the <strong>Oracle</strong> DECODE and the SQL Server CASE expressions can per<strong>for</strong>m
sophisticated conditional evaluations from within a query. The alternative to using these
functions is to per<strong>for</strong>m the function programmatically, which could require substantially
more data be retrieved from the RDBMS.
SQL has seen several sets of standards implemented and embraced by American
National Standards Institute ( ANSI) and International Standards Organization (ISO).
Although there are several enhancement releases of each standard set, the major
releases are S QL-86, SQL-89 (also called SQL1), SQL-92 (also called SQL2) and SQL-
99 (also called SQL3), with SQL-99 merging ANSI and ISO standards into one set.
There are four levels or sets of features in SQL-92: entry-level, transitional, intermediate,
and full. SQL Server 2000 Transact-SQL complies with the entry level of the SQL-92
standard, and it supports many additional features from the intermediate and full levels of
the standard.
SQL-99 has two sets of features: core and non-core. <strong>Oracle</strong> 9i fully supports a majority of
the core SQL-99 features, and it partially supports the n on-core features.
T he SQL-92 entry-level feature set is very similar to the SQL-99 core feature set, which
m eans <strong>Oracle</strong> 9i supports entry level feature s of SQL-92 entry level. Even though both
support many of t he standard features, <strong>Oracle</strong> and SQL Server do not use the same
syntax. In addition, each RDBMS has its own unique functionality and extensions.
<strong>Oracle</strong> SQL statements and Microsoft SQL Server T-SQL are compatible with each other
in several areas with minimal changes in the syntax. All the basic and advanced
functionality furnished by <strong>Oracle</strong> can be achieved in SQL Server with ease.
Though both these RDBMSs can be used to build robust and efficient systems, they differ
r adically in the administrative functions and plat<strong>for</strong>m dependence.
This section shows how to arrive at T-SQL equivalents <strong>for</strong> the most common <strong>Oracle</strong> SQL
u sages, and it includes comprehensive coverage of all a spects of the SQL language
i mplementation.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 179
Sample Tables
The following tables are used in all the exa mples in this chapter.
Table 11.1: Category Table
COLUMN_NAME DATATYPE CONSTRAINT
CATEGORYID VARCHAR(10) Primary Key
CATEGORYNAME
DESCRIPTION
Table 11.2: Customer Table
VARCHAR(40)
VARCHAR(50)
COLUMN_NAME DATATYPE CONSTRAINT
CUSTOMERID VARCHAR(10) Primary Key
COMPANYNAME
CONTACTNAME
CONTACTTITLE
ADDRESS
CITY
REGION
POSTALCODE
COUNTRY
PHONE
FAX
Table 11.3: Employee Table
VARCHAR(40)
VARCHAR(40)
VARCHAR(40)
VARCHAR(50)
VARCHAR(30)
VARCHAR(30)
VARCHAR(10)
VARCHAR(30)
NUMERIC(10.0)
NUMERIC(10.0)
COLUMN_NAME DATATYPE CONSTRAINT
EMPLOYEEID VARCHAR(10) Primary Key
LASTNAME
FIRSTNAME
TITLE
TITLEOFCOURTESY
BIRTHDATE
HIREDATE
ADDRESS
CITY
POSTALCODE
COUNTRY
VARCHAR(40)
VARCHAR(40)
VARCHAR(40)
VARCHAR(50)
DATETIME
DATETIME
VARCHAR(40)
VARCHAR(30)
NUMERIC(10.0)
VARCHAR(10)
REPORTINGTO VARCHAR(10) Foreign Key

180 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
Table 11.4: OrderMaster Table
COLUMN_NAME DATATYPE CONSTRAINT
ORDERID VARCHAR(10) Primary Key
CUSTOMERID VARCHAR(10) Foreign Key
EMPLOYEEID VARCHAR(10) Foreign Key
ORDERDATE
REQUIREDDATE
SHIPPEDDATE
SHIPVIA
FREIGHT
DATETIME
DATETIME
DATETIME
VARCHAR(30)
NUMERIC(10.0)
SHIPNAME
VARCHAR( 30)
SHIPADDRESS
SHIPCITY
SHIPREGION
SHIPPOSTALCODE
Table 11.5: OrderDetails Table
VARCHAR(30)
VARCHAR(10)
VARCHAR(30)
VARCHAR(10)
COLUMN_NAME DATATYPE CONSTRAINT
ORDERID VARCHAR(10) Foreign Key
PRODUCTID VARCHAR(10) Foreign Key
UNITPRICE
QUANTITY
DISCOUNT
Table 11.6: OrderPrice Table
NUMERIC(10.2)
NUMERIC(10.0)
NUMERIC(10.0)
COLUMN_NAME DATATYPE CONSTRAINT
ORDERID VARCHAR(10) Foreign Key
PRODUCTID VARCHAR(10) Foreign Key
REVISEDPRICE
REVISEDON
Table 11.7: Product Table
NUMERIC(10.2)
DATETIME
COLUMN_NAME DATATYPE CONSTRAINT
PRODUCTID VARCHAR(10) Primary Key
PRODUCTNAME
VARCHAR(30)
SUPPLIERID VARCHAR(30) Foreign Key
CATEGORYID VARCHAR(10) Foreign Key
QUANTITYPERUNIT
UNITPRICE
NUMERIC(10.0)
NUMERIC(10.2)
UNITINSTOCK NUMERIC(10.0)
UNITSONORDER
REORDERLEVEL
DISCONTINUED
NUMERIC(10.0)
NUMERIC(10.0)
NUMERIC(10.0)

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 181
Table 11.8: Shippers Table
COLUMN_NAME DATATYPE CONSTRAINT
SHIPPERID VARCHAR(10) Primary Key
COMPANYNAME
VARCHAR(30)
PHONE
NUMERIC(10.0)
Table 11.9: Suppliers Table
COLUMN_NAME DATATYPE CONSTRAINT
SUPPLIERID INT DENTITY Primary Key
COMPANYNAME
VARCHAR(30)
CONTACTNAME
VARCHAR(30)
CONTACTTITLE
VARCHAR(40)
ADDRESS
VARCHAR(40)
CITY
VARCHAR(30)
POSTALCODE
NUMERIC(10.0)
COUNTRY
VARCHAR(40)
PHONE
NUMERIC(10)
FAX
NUMERIC(10)
Table 11.10: ShippedOrders Table
COLUMN_NAME DATATYPE CONSTRAINT
ORDERID VARCHAR(10) Foreign Key
CUSTOMERID VARCHAR(10) Foreign Key
EMPLOYEEID VARCHAR(10) Foreign Key
ORDERDATE
DATETIME
REQUIREDDATE
DATETIME
SHIPPEDDATE
DATETIME
SHIPVIA
VARCHAR(30)
FREIGHT
NUMERIC(10.0)
SHIPNAME
VARCHAR(30)
SHIPADDRESS
VARCHAR(30)
SHIPCITY
VARCHAR(10)
SHIPREGION
VARCHAR(30)
SHIPPOSTALCODE VARCHAR(10)
Migration Process Overview
Recommended high-level steps <strong>for</strong> the migration process include:
1. Extraction of data access. Identify the SQL statements used in the application
and make sure it will work with SQL Server. If some SQL statements are database-
specific, rewrite them <strong>for</strong> SQL Server.
2. Transaction management. Accommodate changes in the transaction because of
the migration.

182 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
3. Fetch strategy. Pay special attention to cursor management and rewrite it in
easier way by making use of effective cursor management available in
SQL Server 2000. Try to avoid cursors being used by <strong>Oracle</strong> application if
possible.
4. Subprograms conversion. Identify all the procedures, functions, and triggers and
rewrite in T-SQL.
5. Job schedul
ing. Batch jobs that are written in PL/SQL should be rewritten.
6. Interface file conversion. For any inbound (text file -> table) jobs, pay attention to
the interface file and make sure there are no problems with the current <strong>for</strong>mat of
the interface file. Pay attention to any outbound interface as well. Keep in mind that
the date <strong>for</strong>mat between <strong>Oracle</strong> and SQL Server are different.
7. Workflow automation. Workflow automation is implemented in the application.
The creation
of Mail Ids is required.
8. Per<strong>for</strong>man ce tuning. Tune the T-SQL statements wherever it is required.
During these steps, the developer should look at the application code and start
converting <strong>Oracle</strong>-specific code into T-SQL compatible code. All major <strong>Oracle</strong> commands
and how to convert them into T-SQL are discussed in detail throughout this chapter.
<strong>Oracle</strong> and SQL Server both provide extensive support <strong>for</strong> XML, whose migration is not
within the scope of this guide. For details on the SML support available in SQL Server
refer to http://msdn.microsoft.com/library/default.asp?url=/library/enus/architec/8_ar_cs_9oj8.asp.
Step 1: Extraction of Data Access
The first step is to identify the SQL used in the application. SQL includes Data
Manipulation Language (DML), Data Query Language (DQL or, simply, queries), and
operators. The majority of SQL syntax is common between <strong>Oracle</strong> and SQL Server with
minor variations.
There are several different types of in<strong>for</strong>mation in the SQL code that will need to be
identified. If these types do not comply with the specifications and syntax of SQL Server,
this in<strong>for</strong>mation will need to be modified. An in-depth discussion of the following topics is
included in this section:
● Operators
● Functions
● Queries
● Data Manipulation Language (DML)
Operators
Operators are used <strong>for</strong> many different purposes in SQL. Table 11. 11 displays these
o perators by type.
Table 11.11 : Commonly Used Operators
Operator Type Example
Arithmetic +, -, *, /
Comparison =, , =
Logical
AND,
OR, NOT , XOR

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 183
These operators may play a role in the SELECT clause of a query ( <strong>for</strong> reporting
purposes), or they may be used in a PL/SQL block <strong>for</strong> per<strong>for</strong>ming various calculations to
complete the transaction.
The in<strong>for</strong>mation under the following heading describes how each of the operators is used
i n <strong>Oracle</strong> and SQL Server.
Operator Precedence
When multiple arithmetic operators are used in a single query, the processing of the
operation takes place according to the precedence of the operators. The precedence
l evel of arithmetic operators in an expression is multiplication (*), division (/), modulo (%),
addition (+), concatenation (+), and subtraction (-). Equations contained within
parentheses take precedence and are per<strong>for</strong>med first. The order of execution is from left
to right.
Concatenation Operators
Concatenation is per<strong>for</strong>med differently between SQL Server and <strong>Oracle</strong>. The
concatenation operator (<strong>for</strong> character strings) used in <strong>Oracle</strong> is “||” or CONCAT(string1,
string2). The following example shows this syntax <strong>for</strong> each usage. Each of these
statements will produce the same result in <strong>Oracle</strong>.
SELECT FI RSTNAME || LASTNAME NAME FROM EMPLOYEE
SELECT CONCAT(FIRSTNAME, LASTNAME) NAME FROM EMPLOYEE;
In these statements, the first name is concatenated with the last name and the label <strong>for</strong>
the field is NAME. SQL Server uses a different operator <strong>for</strong> concatenation. The
concatenation op erator (<strong>for</strong> character strings) used in SQL Server is “+.” The following
example shows the first name concatenated with the last name, along with empty space
in between the names. The label
<strong>for</strong> the field is NAME.
SELECT FIRSTNAME + ‘ ‘ + LASTNAME As NAME FROM EMPLOYEE
Comparison Operators
Conditions are evaluated using comparison operators, including "=", ">" and ">=", “

184 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
Operator Meaning
ALL TRUE if all of a set of comparisons are TRUE
AND
TRUE if both Boolean expressions are TRUE
ANY TRUE if any one of a set of comparisons is TRUE
BETWEEN TRUE if the operand is within a range
EXISTS
IN
TRUE if a subquery contains any rows
TRUE if the operand is equal to one of a list of expressions
LIKE TRUE if the opera nd matches a pattern
NOT Reverses the value of any other Boolean operator
SOME
IS NULL
TRUE if some of a set of comparisons are TRUE
TRUE if operand is NULL
IS NOT NULL TRUE if operand is not NULL
OR
Datatype Precedence
TRUE if either Boolean express ion is TRUE
Each column valu e and constant in a SQL statement has a datatype that is associated
with a specific storage <strong>for</strong>mat, constraints, and a valid range of values. When a table is
created, a datatype is specified fo r each column.
Arithmetic operations per<strong>for</strong>med on columns and constants of different datatypes, such
as INT and SMALLINT, are called as mixed mode arithmetic operations. In mixed mode
arithmetic operations, the lower d atatype value is converted into a h igher datatype value
according to datatype precedence.
Datatype conversion is often needed to attain compatibility during calculation,
concatenation, or comparison of values.
Functions
In many places, built-in functions are used <strong>for</strong> conversion and <strong>for</strong> o ther purposes. Some
commonly used functions are defined and discussed here with examples provided <strong>for</strong>
their use. Some f unctions that are available in <strong>Oracle</strong> are not available in
SQL Server 2000 or earlier versions. However, those functions can
be written in
SQL Server with the same name and the same fun ctionality. They are called user-defined
functions. Some user-defined functions are described later in this chapter.
Number and Mathematical Functions
Table 11.13 details the differences in syntax and usage between <strong>Oracle</strong> and SQL Server.
These functions are all mathematically based.
Table 11.13: Mathematical Functions in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong> Description <strong>Oracle</strong> SQL Server SQL Server
Function Example Function Example
ABS
Returns the ABS (-20) ABS ABS(-20)
absolute value
of n
ACOS
Returns cosine
of n. n must be
between –1
and 1
ACOS (.4) ACOS ACOS(.4)

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 185
CEIL Returns the CEIL (12.3) CEILING CEILING (12.3)
smallest returns 13
returns 13
integer greater
than n
FLOOR Returns the FLOOR (12.3) FLOOR FLOOR (12.3)
smallest
integer smaller
than n
returns 12
returns 12
MOD
Returns the MOD (12,5) % 12%5 returns 2
reminder of m
divided by n
returns 2
POWER Computes the
value of
POWER (10,5)
returns 100000
POWER POWER (10,5)
returns 100000
argument 1
raised to the
power of
argument 2
ROUND
Returns the
nearest value
of the decimal
as per the
precision
specified
Truncates the
decimal
ROUND
(10.125,2)
ROUND
ROUND
(10.125,2)
returns 10.13 returns 10.130
TRUNC TRUNC (12.54) CONVERT
returns 12
CONVERT
(INTEGER,
12.54) returns
12
Character Functions
Table 11.14 details the differences in syntax and usage between <strong>Oracle</strong> and SQL Server.
These functions are all related to text strings and characters.
Table 11.14: Character Functions in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong>
Function
Description <strong>Oracle</strong>
Example
CHR Returns the CHR (65)
character <strong>for</strong> returns A
the ASCII value
CONCAT Appends two CONCAT
string value s ('Tom', 'Mike')
return Tom
Mike
INITCAP Gives
INITCAP ('terry
uppercase to
adams') returns
the title (Title
Terry Adams
case)
SQL Server SQL Server
Function Example
CHAR CHAR (65)
returns A
+ 'Tom' + 'Mike'
returns Tom
Mike
No equivalent
function
An algorithm
can be written
<strong>for</strong> equivalent
functionality

186 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
LOWER
Returns the
lowercase of
the string
LOWER ('TIM')
returns tim
LOWER
LTRIM Trims the LTRIM (' TIM') LTRIM
leading spaces
in a given
returns 'TIM'
String
REPLACE Replaces a REPLACE
REPLACE
matching String ('TIM','I','o')
with a new returns ToM
String in a
given String
RPAD
Pad characters RPAD
No equivalent
to the right side ('USA',5,'*')
function
of the string returns USA**
LPAD
SOUNDEX
SUBSTR
Pad characters
to the left side
of the string
SOUNDEX
function lets
you to compare
words that are
spelled
differently but
sound alike
To take only a
few characters
LPAD
('USA',5,'*')
returns **USA
SOUNDEX
('CHARLOTTE'
) is equal to
SOUNDEX('CH
ARLOTE')
SUBSTRING
('Bikes', 1,4)
No equivalent
function
SOUNDEX
SUBSTRING
LOWER('TIM')
returns tim
LTRIM(' TIM')
returns 'TIM'
REPLACE('TIM
','i','o') returns
ToM
An algorithm
can be written
<strong>for</strong> equivalent
functionality
An algorithm
can be written
<strong>for</strong> equivalent
functionality
SOUNDEX
('CHARLOTTE'
) is equal to
SOUNDEX('CH
ARLOTE')
SUBSTRING
('Bikes', 1,4)
from a string returns Bike returns Bike
TRANSLATE Translate a This function in No equivalent An algorithm
character <strong>Oracle</strong> is used function can be written
string. Used <strong>for</strong> to convert a
<strong>for</strong> equivalent
encryption string into
another <strong>for</strong>m.
functionality
Low level of
encryption is
done using
this.
TRIM
UPPER
ASCII
To remove the
leading and
trailing spaces
of a string
Returns the
uppercase of
the string
Returns the ASCII ('A')
ASCII value of returns 65
TRIM (' THIS
IS TEST ')
returns THIS IS
LTRIM and
RTRIM can be
combined
RTRIM(LTRIM(
' THIS IS TEST
')) returns THIS
TEST
IS TEST
UPPER ('tim') UPPER UPPER('tim')
returns TIM
returns TIM
ASCII
ASCII('A')
returns 65

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 187
the character
INSTR
LENGTH
Used to find
the location of
a sub string or
a character
inside a string
Returns the
length of a
given string
INSTR
('NORTH
CAROLINA','O
R', 1) returns 2
LENGTH
('TOM') returns
3
CHARINDEX
LEN
CHARINDEX
('OR','NORTH
CAROLINA', 1)
returns 2
LEN ('TOM')
returns 3
Date Functions
Table 11.15 details the differences in syntax and usage between <strong>Oracle</strong> and SQL Server.
These functions are all date-based.
Table 11.15: Date Functions in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong> Description <strong>Oracle</strong> SQL Server SQL Server
Function
Example Function Example
ADD_MONTH
S
NEXT_DAY
SYSDATE
TO_CHAR
TO_DATE
To add number
of months <strong>for</strong> a
given date
NEXT_DAY
function returns
the first
weekday later
than the
passed date
Returns the
current date
TO_CHAR is
used when an
INTEGER or
DATE value
needs to be
converted into
String
Any given
string in a valid
date <strong>for</strong>mat can
be converted
into DATE
Datatype
ADD_MONTH
S ('15-NOV-
2004', 1)
returns '15-
DEC-2004'
NEXT_DAY
(SYSDATE,
'FRIDAY')
returns the
date of the
coming Friday
SYSDATE
returns the
current date
TO_CHAR
(sysdate,
'MM/DD/YY')
TO_DATE ('12-
MAY-
2003','DD-
MON-YYYY')
DATEADD
No equivalent
function
DATEADD
(MM, 1,'15-
NOV-2004' )
returns '15-
DEC-2004'
An algorithm
can be written
<strong>for</strong> equivalent
functionality
GETDATE () GETDATE ()
returns the
current date
with time stamp
CAST or
CONVERT
CAST
CONVERT
(char, getdate()
, 1) returns
date in
MM/DD/YY
<strong>for</strong>mat.
CAST ('12-
MAY-2003
12:00:00' as
DATETIME)
The CONVERT function is used in SQL Server to change the date <strong>for</strong>mat. This is
equivalent to the TO_CHAR function of <strong>Oracle</strong>. CONVERT
has three parameters. The

188 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
first parameter is datatype. The second parameter is <strong>for</strong> the column to be <strong>for</strong>matted. The
third parameter is the desired <strong>for</strong>mat. Please see the list of <strong>for</strong>mats and the
corresponding <strong>for</strong>mula in Table 11.16.
Table 11.16: CONVERT Function Formats in SQL Server
WITH CENTURY (YYYY)
INPUT/OUTPUT
0 OR 100 (*) MON DD YYYY HH:MIAM (OR PM)
101 MM/DD/YY
102 YY.MM.DD
103 DD/MM/YY
104 DD.MM.YY
105 DD-MM-YY
106
DD MON YY
107 MON DD, YY
108 HH:MM:SS
9 OR 109 (*)
DEFAULT + MILLISECONDS
110
MON DD YYYY HH:MI:SS:MMMAM (OR
PM)
MM-DD-YY
111 YY/MM/DD
112 YYMMDD
13 OR 113 (*) DD MON YYYY HH:MM:SS:MMM(24H)
114 HH:MI:SS:MMM(24H)
20 OR 120 (*) YYYY-MM-DD HH:MI:SS(24H)
21 OR 121 (*) YYYY-MM-DD HH: MI: SS.MMM (24H)
130* DD MON YYYY HH:MI:SS:MMMAM
131* DD/MM/YY HH:MI:SS:MMMAM
Conditional Functions
Conditional functions are used to compare values or to evaluate a Boolean expression.
Table 11.17 compares these functions between <strong>Oracle</strong> and SQL Server.
Table 11.17: Conditional Functions in <strong>Oracle</strong> and SQL
<strong>Oracle</strong> Description <strong>Oracle</strong> SQL Server SQL Server
Function Example Function Example
NVL To return a NVL (SALARY, ISNULL ISNULL
default value if 0) returns 0 if
(SALARY, 0)
the expression the column returns 0 if the
is null
value (SALARY
column) is null
column value
(SALARY
column) is null
NVL2 To return a NVL2 (Salary, CASE
CASE SALARY
value if the Salary*2, 0) WHEN null
expression is
null or null
returns two
times the
salary if not null
and 0 if null
THEN 0
ELSE
SALARY*2
END

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 189
NULLIF
Returns a null
value if the two
specified
expressions
are equivalent
NULLIF
(SYSDATE,
SYSDATE)
returns NULL
NULLIF
NULLIF
(GETDATE (),
GETDATE ())
returns NULL
DECODE Used to DECODE(DIS CASE
CASE
evaluate the CONTINUED, DISCONTINUE
values with "if- 0, 'No', 1, 'Yes',
D
else" logic. 'NA')
WHEN 0 THEN
'No'
WHEN 1 THEN
'Yes'
ELSE 'NA'
END
CASE
Used to
evaluate the
values with "if-
CASE
discontinued
WHEN 0 THEN
CASE
CASE
discontinued
WHEN 0 THEN
else" logic. 'No'
'No'
WHEN 1 THEN
'Yes'
ELSE 'NA'
END
WHEN 1 THEN
'Yes'
ELSE 'NA'
END
Queries
The SELECT statement is used to query the database and retrieve data. SELECT can be
combined with some DDL and DML statements to per<strong>for</strong>m relational operations. The
following different clauses commonly used with SELECT in <strong>Oracle</strong> and SQL Server are
discussed in the remainder of this section.
● Simple queries
● Joins
● Database links
● Group by
● Case
● Set operators
● Rownum
Optimizer hints are not covered in this guidance. Both <strong>Oracle</strong> and SQL Server use costthat
can be used to influence the optimizer. The
based optimizers and offer hints
optimizer hints used with <strong>Oracle</strong> are not available in SQL Server. For the various types of
hints available in SQL Server refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/acdata/ac_8_qd_03_8upf.asp.
Simple Queries
A simple query is defined as a SELECT statement that retrieves data from a single table
with or without filter condition. Because
this is a standard command, there are no
differences in syntax or usage between <strong>Oracle</strong> and SQL Server. The following example is
a valid statement <strong>for</strong> both <strong>Oracle</strong> and SQL Server.

190 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
SELECT * FROM CUSTOMER;
Joins
Joins play a major role when meaningful in<strong>for</strong>mation needs to be retrieved from more
than one table. Often, reports or intricate queries require data from two or more tables.
The data from multiple tables must be logically related. SQL combines data from multiple
tables using joins into a single result set.
Joins can be of following types:
● Inner join
● Equi-join
● Non-equi join
●
●
Outer join
● Left outer join
● Right outer join
● Full outer join
Self-join
Inner Join
Inner join is the normal join that is per<strong>for</strong>med among tables to fetch the matching data.
Inner join can be either an equi-join or non-equi join. Both equi and non-equi join are
explained under the following headings.
Equi-Join
An equi-join equates fields from two or more tables to fetch matching data from the tables
selected. There is considerable difference in the syntax of an equi-join between <strong>Oracle</strong>
and SQL Server.
The standard <strong>Oracle</strong> equi-join syntax is shown in the following example:
SELECT TABLE1. FIELD1, TABLE2.FIELD1, TABLE2.FILED2
FROM TABLE1, TABLE2
WHERE TABLE1.FIELD3 = TABLE2.FIELD3
AND TABLE1.FIELD4 = TABLE2.FIELD4
<strong>Oracle</strong> 9i equi-joins are slightly different; the syntax is modified to comply with the ANSI
standard. The <strong>Oracle</strong> 9i syntax is shown in the following example:
SELECT TABLE1.FIELD1, TABLE2.FIELD1, TABLE2.FIELD2
FROM (TABLE1 INNER JOIN TABLE2 ON TABLE1.FIELD3 = TABLE2.FIELD3
AND TABLE1.FIELD4 = TABLE2.FIELD4)
The SQL Server syntax is also slightly different, and it is shown in the following example:
SELECT TABLE1.FIELD1, TABLE2.FIELD1, TABLE2.FIELD2
FROM TABLE1 INNER JOIN TABLE2
ON TABLE1.FIELD3_=_TABLE2.FIELD3
AND TABLE1.FIELD4 = TABLE2.FIELD4
For example, a company needs to create a report with the following in<strong>for</strong>mation:
● Product name
● Price
● Supplier’s company name
● Category name

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 191
For a product produced by the example company, the corresponding supplier’s company
name and the corresponding category name have to be displayed. The PRODUCT table
has SUPPLIERID and CATEGORYID, but not their corresponding names. Procedures
<strong>for</strong> using the PRODUCTNAME <strong>for</strong> <strong>Oracle</strong>, <strong>Oracle</strong> 9i, and SQL Server are shown in the
following examples.
In <strong>Oracle</strong>, the inner join will provide the needed in<strong>for</strong>mation:
SELECT A.PRODUCTNAME, A.UNITPRICE, B.COMPANYNAME, C.CATEGORYNAME
FROM PRODUCT A, SUPPLIERS B, CATEGORY C
WHERE A.SUPPLIERID = B.SUPPLIERID
AND A.CATEGORYID = C.CATEGORYID
The following code produces the same inner join in <strong>Oracle</strong> 9i:
SELECT A.PRODUCTNAME, A.UNITPRICE, B.COMPANYNAME, C.CATEGORYNAME
FROM (PRODUCT A INNER JOIN SUPPLIERS B
ON A.SUPPLIERID = B.SUPPLIERID INNER JOIN CATEGORY C
ON A.CATEGORYID = C.CATEGORYID
)
The SQL Server syntax is the same as the preceding <strong>Oracle</strong> 9i syntax.
Self Joins
Self joins can be used when one row in a table relates itself with other rows in the same
table. That is, the same table is used twice <strong>for</strong> comparison. The same table must be
exhibited as two different tables by using different aliases. This function is available in
<strong>Oracle</strong> and SQL Server, though there are slight differences in syntax. The syntax <strong>for</strong>
<strong>Oracle</strong> self joins is provided here:
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A, TABLE1 B
WHERE A.FIELD1 = B.FIELD1
AND A.FIELD2 < B.FIELD2
The SQL Server syntax is shown in the following example. Note the differences in the
third and fourth lines of the statement.
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A JOIN TABLE1 B
ON A.FIELD1 = B.FIELD1
WHERE A.FIELD2 < B.FIELD2
Con sider a case in which the result set must return a list of all companies in the same city
as the company “ABC Inc.”
In <strong>Oracle</strong>, the statement would appear as:
SELECT B.COMPANYNAME
FROM CUSTOMER A, CUSTOMER B
WHERE A.CITY = B.CITY
AND A.COMPANYNAME = 'ABC Inc'
In SQL Server, the same result set can be returned using the following statement:
SELECT B.COMPANYNAME
FROM CUSTOMER A JOIN CUSTOMER B
ON A.CITY = B.CITY
WHERE A COMPANYNAME = 'ABC Inc'

192 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
Non-Equi Joins
Non -equi joins are used when there is not a direct link criterion between the tables. It is
simply a join where the joining criteria are anything other than “=.” The difference in the
syntax between <strong>Oracle</strong> and SQL Server in cases of non-equi join is a minor difference in
the operators used to notify the non-equi join. The <strong>Oracle</strong> syntax is provided in the
following example:
SELECT A.FIELD1, A.FIELD2, A.FIELD3, B.FIELD4
FROM TABLE1 A, TABLE2 B
WHERE A.FIELD1 = B.FIELD1
AND A.FIELD2 B.FIELD2
The SQL Server syntax is provided in the following example. Note the use of the inner
join operator.
SELECT A.FIELD1, A.FIELD2, A.FIELD3, B.FIELD4
FROM TABLE1 A INNER JOIN TABLE2 B
ON A.FIELD1 = B.FIELD1
WHERE A.FIELD2 B.FIELD2
For example, imagine a case where there is a need to retrieve those products listed
under the same category but from different suppliers. In <strong>Oracle</strong>, the statement can be
created as follows:
SELECT A.PRODUCTID, A.PRODUCTNAME, A.UNITPRICE
FROM PRODUCT A, PRODUCT B
WHERE A.CATEGORYID = B.CATEGORYID
AND A.SUPPLIERID B.SUPPLIERID
The same result can be accomplished in SQL Server, as shown in the following example:
SELECT A.PRODUCTID, A.PRODUCTNAME, A.UNITPRICE
FROM PRODUCT A INNER JOIN PRODUCT B
ON A.CATEGORYID = B.CATEGORYID
AND A.SUPPLIERID B.SUPPLIERID
Outer Joins
A join is termed as outer join when the result set contains all the rows from one table and
only the matching rows from the other table.
An outer join can be a left outer join or a right outer join. Outer join syntax in <strong>Oracle</strong> and
SQL Server remained different until the release of <strong>Oracle</strong> 9i. Thereafter, both follow ANSI
standards of using INNER JOIN or OUTER JOIN in words instead of operators.
All rows are retrieved from the left table referenced with a left outer join. Here, the outer
join operator (+) is placed beside the table that is to the left of the "=" operator during the
join.
● <strong>Oracle</strong> — left outer join
The syntax <strong>for</strong> left outer join is as follows:
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A, TABLE1 B
WHERE A.FIELD1(+) = B.FIELD1
Example <strong>for</strong> left outer join is:
●
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B.CONTACTNAME
FROM PRODUCT A, SUPPLIERS B
WHERE A.SUPPLIERID(+) = B.SUPPLIERID
<strong>Oracle</strong> 9i — left outer join

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 193
The ANSI syntax <strong>for</strong> left outer join is as follows:
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A LEFT OUTER JOIN TABLE2 B
ON A.FIELD1 = B.FIELD1
Example <strong>for</strong> ANSI compliant left outer join is:
●
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B.CONTACTNAME
FROM PRODUCT A LEFT OUTER JOIN SUPPLIERS B
ON A.SUPPLIERID = B.SUPPLIERID
SQL Server — left outer join
The syntax <strong>for</strong> left outer join is as follows:
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A LEFT OUTER JOIN TABLE2 B
ON A.FIELD1 = B.FIELD1
Example <strong>for</strong> left outer join is:
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B.CONTACTNAME
FROM PRODUCT A LEFT OUTER JOIN SUPPLIERS B
ON A.SUPPLIERID = B.SUPPLIERID
All rows are retrieved from the right table referenced in a right outer join. A right outer join
is used to furnish null rows to the right side table used during the Join condition.
● <strong>Oracle</strong> — right outer join
The syntax <strong>for</strong> right outer join is as follows:
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A, TABLE1 B
WHERE A.FIELD1 = B.FIELD1(+)
Example <strong>for</strong> right outer join is:
●
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B.CONTACTNAME
FROM PRODUCT A, SUPPLIERS B
WHERE A.SUPPLIERID = B.SUPPLIERID(+)
SQL Server — right outer join
The syntax <strong>for</strong> right outer join is as
follows:
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A RIGHT OUTER JOIN TABLE2 B
ON A.FIELD1 = B.FIELD1
Example <strong>for</strong> right outer join is:
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B.CONTACTNAME
FROM PRODUCT A RIGHT OUTER JOIN SUPPLIERS B
ON A.SUPPLIERID = B.SUPPLIERID
All row s from both tables are returned in a full outer join.
• <strong>Oracle</strong> — full outer join
<strong>Oracle</strong> does not have a separate outer join syntax. The following shows an
example <strong>for</strong> full outer join:
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B.CONTACTNAME
FROM PRODUCT A, SUPPLIERS B
WHERE A.SUPPLIERID = B.SUPPLIERID(+)
UNION

194 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B.CONTACTNAME
FROM PRODUCT A, SUPPLIERS B
WHERE A.SUPPLIERID(+) = B.SUPPLIERID
• SQL Service — full outer join
The syntax <strong>for</strong> full outer join is as follows:
SELECT A.FIELD1, A.FIELD2, B.FIELD1, B.FIELD2
FROM TABLE1 A FULL OUTER JOIN TABLE2 B
ON A.FIELD1 = B.FIELD1
Example <strong>for</strong> full outer join is:
SELECT A.PRODUCTNAME, A.CATEGORYID, B.COMPANYNAME, B. CONTACTNAME
FROM PRODUCT A FULL OUTER JOIN SUPPLIERS B
ON A.SUPPLIERID = B.SUPPLIERID
Subqueries
A subquery is a normal query that is nested inside another query using parentheses.
Subqueries are used to retrieve data from tables that depend on the values on the same
table or a different table. A statement containing a subquery is called a parent statement.
A subquery can be commonly found in the FROM and WHERE clauses of a SELECT
statement. A subquery in the FROM clause is also called an inline view. Inline views in
SQL Server are similar to those in <strong>Oracle</strong>. In SQL Server, inline views have to be aliased
in all cases.
Subqueries found in the WHERE clauses are called nested queries. Subqueries may be
nested in other subqueries. T-SQL queries can use a maximum of 256 tables, including
all subqueries, and a maximum of 32 levels of nesting. In contrast, <strong>Oracle</strong> allows 255
levels of nesting. It is uncommon to use more than two or three levels of nesting in
queries. SQL Server supports most implementations of the nested query in <strong>Oracle</strong>.
Examples of nested queries are found throughout this chapter. SQL Server, however,
does not support the ordered set as shown in the following example:
SELECT productid, revisedprice
FROM OrderPrice
WHERE (orderid, productid) IN (SELECT orderid, productid
FROM OrderDetails)
In such cases, the query can be converted into one using joins instead of the nested
query.
SELECT OP.productid, OP.revisedprice
FROM OrderPrice OP INNER JOIN OrderDetails OD
ON OP.orderid = OD.orderid
AND OP.productid = OD.productid
A nested query in which the nested query references columns in the parent table is called
a correlated subquery. A correlated subquery is executed once <strong>for</strong> each row in the parent
statement. Because <strong>Oracle</strong> syntax and SQL Server syntax are similar, examples are not
provided here.
Grouping Result Set
<strong>Oracle</strong> and SQL Server provide a method of grouping the result set using the GROUP BY
clause. The GROUP BY clause summarizes the result set into the groups defined in the
query using aggregate functions
such as AVG or SUM. Using the HAVING clause can

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 195
further filter the result set by comparing it with the aggregate function's result. The
HAVING clause without a GROUP BY clause behaves like a simple WHERE condition.
HAV ING clauses are used with aggregation functions and cannot be used with single row
functions.
The GROUP BY clause treats the HAVING clause in the same way as SELECT treats
WHERE.
A SELECT statement with a GROUP BY clause cannot have a COLUMN_NAME other
than the columns available in the GROUP BY list. When GROUP BY is specified, either
each column in any non-aggregate expression in the select list should be included in the
GROUP BY list, or the GROUP BY expression must match exactly the select list
expression.
A GROUP BY clause can include an expression as long as it does not include any
agg regate function, and it cannot contain any sub query, either. In SQL Server, GROUP
BY “ALL” can be used, but it is optional. When ALL is specified, null values are returned
<strong>for</strong> the summary columns of groups that do not meet the search condition.
Because <strong>Oracle</strong> and SQL Server SQL are similar, examples are not provided here.
Database Link
When tables are to be joined across databases that are in different servers, the database
link functionality can be used. In the examples provided in this section, the databases are
distributed in two geographical locations. One database is in New York, and another is in
Bos ton. A business user wants to know the total number of orders <strong>for</strong> the month of May,
2004.
● In <strong>Oracle</strong>, databases are linked using the command CREATE DATABASE LINK.
The TNSNAMES.ORA entry <strong>for</strong> the database is required.
SELECT COUNT(*)
FROM
(
SELECT ORDERID FROM ORDERMASTER
WHERE orderdate > sysdate - 30
UNION
SELECT ORDERID FROM ORDERMASTER@BOSTON
WHERE ORDERDATE > sysdate - 30
);
● In SQL Server, some configuration is needed be<strong>for</strong>e accessing remote databases.
Be<strong>for</strong>e querying tables from different databases on different servers, log into the
first database, go to Query Analyzer, and execute the following code.
USE MASTER
GO
EXEC SP_ADDLINKEDSERVER
@SERVER= 'BOSTON',
@SRVPRODUCT= '',
@PROVIDER='SQLOLEDB',
@DATASRC='BOSTON\NWIND'
GO
EXEC SP_ADDLINKEDSRVLOGIN
@RMTSRVNAME ='BOSTON',
@USESELF='FALSE',
@LOCALLOGIN=NULL,

196 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
CASE
@RMTUSER ='ABC',
@RMTPASSWORD ='ABC'
GO
Executing these procedures establishes the link between the servers. Next,
execute the following query to retrieve the data from two databases.
SELECT COUNT(ORDERID)
FROM
(SELECT ORDERID FROM ORDERMASTER
WHERE ORDERDATE > getdate() - 30
UNION
SELECT ORDERID FROM [BOSTON].NWIND.DBO.ORDERMASTER
WHERE ORDERDATE > getdate() - 30
)
CASE is used when there is a need to have "if-else" in this section, a store manager wants to see customer names and segregate
logic. In the example code that
appears
the orders into the three following categories:
● An order value less than $5,000 is small
● An order value between $5,000 and $10,000 is medium
● An order value greater than $10,000 is large
In <strong>Oracle</strong>, this task would be accomplished using CASE as shown in the following code
example:
SELECT ORDERID,
CASE
WHEN SUM(UNITPRICE)

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 197
●
SQL Server
SELECT COMPANYNAME
FROM [NEWYORK].NWIND.DBO.SUPPLIERS
UNION
SELECT COMPANYNAME
FROM [BOSTON].NWIND.DBO.SUPPLIERS
Set Operators: Intersect
The intersect operator will only retrieve the common values from more than one table. In
the following example code, intersect is used to retrieve the supplier names common to
both NEWYORK and BOSTON stores.
● <strong>Oracle</strong>
●
SELECT COMPANYNAME FROM SUPPLIERS@BOSTON
INTERSECT
SELECT COMPANYNAME FROM SUPPLIERS@NEWYORK
clause can be written <strong>for</strong> the same
Set Operators: Minus
A minus operator is used when the difference of values from more than one table needs
to be fetched. In the following example code, this operator is used to list the supplier
names that are only in the BOSTON database and that are not in NEWYORK database.
● <strong>Oracle</strong>
●
SQL Server
In SQL Server, a subquery with an EXISTS
purpose.
SELECT COMPANYNAME FROM [NEWYORK].NWIND.DBO.SUPPLIERS A
WHERE EXISTS
(SELECT 'X'
FROM [BOSTON].NWIND.DBO.SUPPLIERS B
WHERE A.COMPANYNAME = B.COMPANYNAME);
SELECT COMPANYNAME FROM SUPPLIERS@BOSTON
MINUS
SELECT COMPANYNAME FROM SUPPLIERS@NEWYORK;
SQL Server
Because MINUS is not available in SQL Server, NOT EXISTS can be used. The
following example shows how to use the NOT EXISTS operator.
SELECT COMPANYNAME FROM SUPPLIERS A
WHERE NOT EXISTS
(SELECT 'X'
FROM [BOSTON].NWIND.DBO.SUPPLIERS B
WHERE A.COMPANYNAME = B.COMPANYNAME) ;

198 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
ROWNUM
ROWNUM is a special keyword in <strong>Oracle</strong>. Using ROWNUM can limit the number of rows
retrieved without any condition. In the following example, ROWNUM is used to display
the top 10 orders from the ORDERDETAILS table.
● <strong>Oracle</strong>
●
SELECT *
FROM
(SELECT ORDERID, SUM(UNITPRICE)
FROM ORDERDETAILS
GROUP BY ORDERID
ORDER BY SUM(UNITPRICE) DESC
)
WHERE ROWNUM < 11;
SQL Server
SELECT TOP 10 ORDERID, SUM(UNITPRICE)
FROM ORDERDETAILS
GROUP BY ORDERID
ORDER BY SUM(UNITPRICE) DESC
Data Manipulation Language (DML)
DML includes INSERT, UPDATE, and DELETE. The MERGE statement has also been
discussed. The following sections describe how each command is used in <strong>Oracle</strong> and
how the command can be converted into SQL Server-specific syntax.
Insert
The INSERT command is used to add one or more rows to a table. The column values
are separated by commas. Insert can be used in several different ways within <strong>Oracle</strong>. All
of the different <strong>for</strong>ms are explained under the following headings.
Inse rting a row into a table is identical in SQL Server and in <strong>Oracle</strong>. The syntax is shown
here:
INSERT INTO TABLE1 VALUES (FIELD1, FIELD2 …);
Insert Sequences
Compatibility between the <strong>Oracle</strong> tables and the new SQL Server tables should be
checked. If a table in <strong>Oracle</strong> uses SEQUENCES, then SQL Server tables should use
IDENTITY.
IDENTITY will automatically increment a column value so that no two rows will have
same value <strong>for</strong> the column. To enable this facility, a column can be included in the table
which will have its unique value and auto-incrementing defined. This is achieved through
SEQUENCES in <strong>Oracle</strong> and IDENTITY in SQL Server. This column can also be used as
primary key <strong>for</strong> tables that do not have a natural key.
A sequence is a database object that can generate unique, sequential integer values. It
can be used to automatically generate primary key or unique key values. A sequence can
be either in ascending or descending order. The syntax is explained in the following
examples.
● <strong>Oracle</strong>
INSERT INTO SUPPLIERS VALUES

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 199
●
(SUPPLIER_SEQUENCE.NEXTVAL,' Abc Inc.', 'Lingerfelt, Steve', 'Mr.', 'Apt # 104
Andrew''s Drive', 'Charlotte', 28262,'USA',7049654371,7049652300);
SQL Server
SQL Server has a unique way of handling running serial numbers: the IDENTITY
property. This property provides a unique incremental value <strong>for</strong> the column. Its use
in an insert command is explained later in this section. This is equivalent to
<strong>Oracle</strong>'s Sequence. When a column is declared as IDENTITY, a value does not
have to be specified <strong>for</strong> the column. In <strong>Oracle</strong>, the value has to be explicitly
retrieved from a sequence during an insert.
The current value of an IDENTITY can be found using the following code:
SELECT IDENT_CURRENT ('SUPPLIERS')
INSERT INTO SUPPLIERS VALUES
(' A bc Inc.', 'Lingerfelt, Steve', 'Mr.', 'Apt # 104 Andrew''s Drive' ,
'Charlotte', 28262,'USA','7049654371','7049652300');
Using Date Values in Insert Operations
During an insert or update, the date <strong>for</strong>mat can be the same as <strong>Oracle</strong> (DD-MON-YYYY).
However, while retrieving, the <strong>for</strong>mat will be different. A conversion function that was
discussed in the "Functions"
section will have to be used. In <strong>Oracle</strong>, to insert the date with time, a conversion of the
date with date time is needed. This is done with the help of the TO_CHAR function. This
is not required in SQL Server because it already stores the date with time stamp.
The following example illustrates how to insert the current date in an insert operation of
<strong>Oracle</strong> and SQL Server.
● <strong>Oracle</strong>
●
INSERT INTO OrderMaster VALUES(1,1076,121,SYSDATE,'19-AUG-2004', NULL,
'Federal Shipping', 40,'Ernst Handel','2817 Milton Dr.','Dallas','TX','87110')
INSERT INTO OrderMaster VALUES(1,1076,121, GETDATE(),'19-AUG-2004', NULL,
'Federal Shipping', 40, 'Ernst Handel','2817 Milton
Dr.','Dallas','TX','87110')
The following example shows how the time part of a date is handled in <strong>Oracle</strong> and how
this can be converted <strong>for</strong> SQL Server database.
● <strong>Oracle</strong>
●
SQL Server
INSERT INTO OrderMaster VALUES(1,1076,121,TO_DATE('01-MAR-2004 13:45:33', 'DD-
MON-YYYY
HH24:MI:SS'),'19-AUG-2004', NULL, 'Federal Shipping', 40, 'Ernst Handel','2817
Milton Dr.',' Dallas','TX','87110')
SQL Server
INSERT INTO OrderMaster VALUES(1,1076,121, '01-MAR-2004 13:45:33','19-AUG-
2004', NULL, 'Federal Shipping', 40, 'Ernst Handel','2817 Milton
Dr.','Dallas','TX' ,'87110')
Insert with Subquery
In many applications, a subquery is used to return a specific subset of rows which
are then inserted into the table. The subquery can refer to any table, view, or

200 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
even the target table itself. If the subquery returns no rows, then no rows are
inserted into the table.
Update
Update is an imperative DML statement that facilitates the changes to values of fields in
the tables. In an <strong>Oracle</strong> or SQL Server database, an UPDATE is commonly used to
incorporate modifications to an already inserted value. All of the key constraints are
handled by the databases prior to affecting the UPDATE permanently. <strong>Oracle</strong> and
SQL Server have followed the conventional ANSI way of using the UPDATE statement.
The UPDATE statement can be per<strong>for</strong>med in three different ways:
● Simple update. This is a straight<strong>for</strong>ward change to the values of one or more
fields of a table, with or without a condition <strong>for</strong> updating.
<strong>Oracle</strong> and SQL Server use the same syntax <strong>for</strong> UPDATE statement.
● Update with joins. Updates with joins are frequently used when a change is
required in the field value of only the rows matching specific conditions between
two or more tables.
<strong>Oracle</strong> and SQL Server use the same syntax <strong>for</strong> UPDATE statement.
● Update with subqueries. Requirements will sometimes demand a change to a
field value with data from another table. Update with subqueries is useful in
situations where data from one table is set to a field from another table.
<strong>Oracle</strong> and SQL Server use the same syntax conventions <strong>for</strong> UPDATE with
subqueries. An exception is updates involving correlated subqueries.
UPDATE OrderDetails o
SET o.unitprice = (SELECT unitprice
FROM Product p
WHERE p.productid = o.productid)
The preceding <strong>Oracle</strong> update statement can be rewritten using a syntax that is
unique to SQL Server as follows:
Merge
UPDATE o
SET o.unitprice = p.unitprice
FROM OrderDetails o JOIN Product p
ON p.productid = o.productid
This is a new feature in <strong>Oracle</strong> 9i. The MERGE statement is used to update and insert
rows in a table. In the following examples, an ORDERPRICE table exists that stores the
revised price of a product in a particular order. The price can be revised any number of
times. If a record already exists, then the price needs to be updated and the date
changed. If a row <strong>for</strong> that order and product does not exist, then you need to insert a new
row with the revised price of the product in that particular order.
● <strong>Oracle</strong>
MERGE INTO ORDERPRICE A
USING (SELECT ORDERID, PRODUCTID FROM ORDERDETAILS WHERE ORDERID=1
AND PRODUCTID =1) B
ON (A.ORDERID = B.ORDERID AND A.PRODUCTID = B.PRODUCTID)
WHEN MATCHED THEN
UPDATE SET REVISEDPRICE = 120, REVISEDON = SYSDATE
WHEN NOT MATCHED THEN
INSERT INTO
ORDERPRICE VALUES

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 201
●
(B.ORDERID, B.PRODUCTID, 100, SYSDATE);
SQL Server
To achieve this functionality in SQL Server, use a stored procedure with the
following logic. More in<strong>for</strong>mation about writing stored procedures is included later
in this chap ter in the "Subprograms Conversion" section.
declare @orderid char(10)
declare @productid char(10)
declare @count integer
SELECT @count = COUNT(*) FROM ORDERPRICE
WHERE ORDERID= @ORDERID AND PRODUCTID = @PRODUCTID
IF @count > 0
UPDATE ORDERPRICE SET REVISEDPRICE =
120, REVISEDON = GETDATE()
WHERE ORDERID = @ORDERID AND PRODUCTID = @PRODUCTID
ELSE
INSERT INTO ORDERPRICE VALUES(@ORDERID, @PRODUCTID, 100, GETDATE())
Delete
As tables are used, unneeded rows can be removed. DELETE is a DML operation that is
used to eliminate all or certain rows from a table, keeping the table structure intact. Even
though all the rows are deleted, the structure of the table remains and can be populated
with additional rows using INSERT. By using conditional deletion, only selected rows are
eliminated from the table. Conditional deletion is accomplished by using the conventional
WHERE clause. <strong>Oracle</strong> and SQL Server both allow <strong>for</strong> conditional deletion. The ANSI
way of writing the DELETE statement is used in both <strong>Oracle</strong> and SQL Server.
The following types of delete exist:
● Simple delete. A general way of deleting all or selected rows from a table. A
simple delete operation is similar <strong>for</strong> <strong>Oracle</strong> and SQL Server.
● Delete all rows. Both <strong>Oracle</strong> and SQL Server offer the TRUNCATE TABLE
statement.
● Delete with subqueries. Using subqueries in conjunction with the DELETE
operation allows <strong>for</strong> more specificity. The subquery enables the value <strong>for</strong> the
WHERE condition to be fetched from a different table.
<strong>Oracle</strong> and SQL Server use the same methodology to delete the rows in a table.
● Delete duplicate records. It is possible to have exact copies of rows in a table
that does not en<strong>for</strong>ce a strict key structure. These situations demand the deletion
of all the duplicate records from the table. <strong>Oracle</strong> and SQL Server have different
ways to do this:
●
<strong>Oracle</strong>
DELETE FROM TABLE1 WHERE TABLE1.ROWID >
(SELECT MIN (TABLE2.ROWID) FROM TABLE2
WHERE TABLE1.FIELD1 = TABLE2.FIELD1)
● SQL Server
For an example of how to per<strong>for</strong>m this in SQL Server, refer to
http://support.microsoft.com/default.aspx?scid=kb;en-us;139444
• Truncate
Both <strong>Oracle</strong> and SQL Server offer the TRUNCATE command <strong>for</strong> deleting all rows
of a table with minimal logging.

202 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
Step 2: Transaction Management
After identifying all instances of SQL, transactions need to be carefully modified as part of
the data migration process. This section discusses how to handle the transactions in
SQL Server.
To begin, identify all of the transaction commands currently used with <strong>Oracle</strong> and
implement them <strong>for</strong> SQL Server. In <strong>Oracle</strong>, all commands inside two transaction control
language statements are considered as a batch. If a set of statements needs to be
considered as a batch, then all the statements must be inside BEGIN TRANSACTION
and COMMIT TRANSACTION commands. A discussion of these architecture topics is
provided in Appendix A: SQL Server <strong>for</strong> <strong>Oracle</strong> Professionals.
Transaction Control Language (TCL)
A tr ansaction can be defined as a group of statements that must either succeed or fail as
a group. In <strong>Oracle</strong>, transactions are normally implicit in nature and can be explicitly
specified by use of BEGIN and END clauses. In SQL Server, BEGIN TRAN and END
TRAN have to be explicitly used to demarcate a transaction.
Transaction is controlled by any one of these commands:
● COMMIT
● ROLLBACK
● SAVEPOINT
These commands are discussed in detail under the following headings.
COMMIT
The COMMIT command is used to end a transaction. Changes are made permanent in
the database with the COMMIT command. This erases all the savepoints inside the
tran saction and also releases the locks.
After a transaction is committed, the change is permanent and cannot be reverted. Of
course, you can always delete the inserted row. There is no way to undo a committed
transaction.
The syntax is as follows:
● <strong>Oracle</strong>
●
COMMIT;
SQL Server
COMMIT TRANSACTION ;
The COMMIT WORK command functions in the same way as COMMIT TRANSACTION,
except COMMIT TRANSACTION accepts a user-defined transaction name. This
COMMIT syntax, with or without specifying the optional keyword WORK, is compatible
with SQL-92. This command is available in SQL Server using the following command:
COMMIT WORK;
SAVEPOINT
A savepoint is a marker that divides a very lengthy transaction into several smaller ones.
SAVEPOINT is used to identify a rollback point in the transaction. Thus, SAVEPOINT is
used in conjunction with ROLLBACK to revert a portion of current transaction. The syntax
in <strong>Oracle</strong> and SQL Server differs:
● <strong>Oracle</strong>

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 203
●
SAVEPOINT ;
SQL Server
SAVE TRANSACTION ;
ROLLBACK
The ROLLBACK command is used to undo a portion of the current transaction. It is
possible to roll back the entire transaction so that all changes made by SQL statements
are undone, or to roll back a transaction to a save point so that the SQL statements after
the save point are rolled back. The syntax in <strong>Oracle</strong> and SQL Server differs:
●
●
<strong>Oracle</strong>
ROLLBACK;
ROLLBACK TO ;
SQL Server
ROLLBACK TRANSACTION
ROLLBACK TRANSACTION
In addition, the ROLLBACK WORK statement function is similar to the ROLLBACK. The
only difference is that ROLLBACK TRANSACTION accepts a user-defined transaction
name. With or without specifying the optional WORK keyword, this ROLLBACK syntax is
SQL-92-compatible and is available in SQL Server using the following syntax:
ROLLBACK WORK
Ste p 3: Fetch Strategy
Cursors are effective <strong>for</strong> row processing and batch processing. <strong>Oracle</strong>-based applications
can use many c ursors <strong>for</strong> row processing. Analyze the code to determine if it can be
converted without using cursors. Cursor operations are always costly when compared to
SET operations because they use temporary memory area and processes. If the cursors
are not handled properly, it may result in dead processes and locks.
In <strong>Oracle</strong>, a cursor is defined as a work area to execute the SQL statements and to store
processing in<strong>for</strong>mation. <strong>Oracle</strong> creates a work area to process all the SQL statements.
That work area is called an implicit cursor. <strong>Oracle</strong> also allows you to define an explicit
cursor to process and apply business logic.
<strong>Oracle</strong> has implemented the following types of cursors:
● Implicit cursors
● Explicit cursors
Implicit cursors are opened automatically whenever queries or DML are issued in <strong>Oracle</strong>.
SQL Server calls this a default result set.
<strong>Oracle</strong> allows defining a cursor with the help of keyword "cursor." Such explicitly declared
curs ors have a SELECT statement. The output of the select is stored in separate memory
areas and it can be used in a PL/SQL program. Explicit cursors can be parameterized.
Transact SQL Cursors, in SQL Server, are based on the DECLARE CURSOR syntax and
are used mainly in Transact-SQL scripts, stored procedures, and triggers. Transact-SQL
cursors are implemented on the server and are managed by Transact-SQL statements
sent from the client to the server.
Using Transact-SQL Cursors
High-level steps <strong>for</strong> using Transact-SQL cursors inside the code include:

204 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
1. Declare Transact-SQL variables to contain the data returned by the cursor. Declare
one variable <strong>for</strong> each result set column. Declare the variables to be large enough
to hold the values returned by the column.
2. Associate a Transact-SQL cursor with a SELECT statement using the DECLARE
CURSOR statement. The DECLARE CURSOR statement also defines the
characteristics of the cursor, such as the cursor name and whether the cursor is
read-only or <strong>for</strong>ward-only.
3. Use the OPEN statement to execute the SELECT statement and populate the
cursor.
4. Use the FETCH INTO statement to fetch individual rows and have the data <strong>for</strong>
each column moved into a specified variable. Other Transact-SQL statements can
then reference those variables to access the fetched data values. Transact-SQL
cursors do not support fetching blocks of rows.
5. When you are finished with the cursor, use the CLOSE statement. Closing a cursor
frees some resources, such as the cursor's result set and its locks on the current
row, but the cursor structure is still available <strong>for</strong> processing if you reissue an OPEN
statement. Because the cursor is still present, you cannot reuse the cursor name at
this point. The DEALLOCATE statement completely frees all resources allocated to
the cursor, including the cursor name. After a cursor is de-allocated, you must
issue a DECLARE statement to rebuild the cursor.
Th e cursor syntax differs between <strong>Oracle</strong> and SQL Server:
● <strong>Oracle</strong>
●
DECLARE
CURSOR IS < SELECT STATEMENT>
BEGIN
FOR IN CURSOR_NAME
LOOP
-- Business Logic
END LOOP;
END;
SQL Server
DECLARE
DECLARE CURSOR FOR
BEGIN
OPEN
FETCH NEXT FROM INTO
WHILE @@FETCH_STATUS = 0
BEGIN
-- business logic goes here
FETCH NEXT FROM INTO
END
CLOSE
DEALLOCATE
END
<strong>Oracle</strong> allows the entire cursor record to be transferred into a user-defined data structure
defined using ROWTYPE. In SQL Server, the record values need to be assigned into an
individual variable. The following example uses ROWTYPE to process the SHIPPERS
table record by
record.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 205
●
●
<strong>Oracle</strong>
DECLARE
CURSOR SHIPPER_CURSOR IS SELECT * FROM SHIPPERS;
SHIPPER_REC SHIPPERS%ROWTYPE;
BEGIN
OPEN SHIPPER_CURSOR;
LOOP
FETCH SHIPPER_CURSOR INTO SHIPPER_REC;
EXIT WHEN SHIPPER_CURSOR%NOTFOUND;
DBMS_OUTPUT.PUT_LINE('SHIPPER NAME IS '||SHIPPER_REC.COMPANYNAME);
DBMS_OUTPUT.PUT_LINE('SHIPPER PHONE IS '||SHIPPER_REC. PHONE);
END LOOP;
CLOSE SHIPPER_CURSOR;
END;
SQL Server
DECLARE @SHIPPER_NAME VARCHAR(50),@PHONE VARCHAR(50)
DECLARE SHIPPER_CURSOR CURSOR FOR SELECT COMPANYNAME,PHONE FROM SHIPPERS;
BEGIN
OPEN SHIPPER_CURSOR;
FETCH NEXT FROM SHIPPER_CURSOR INTO @SHIPPER_NAME, @PHONE
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT 'SHIPPER NAME IS ' + @SHIPPERNAME
PRINT 'SHIPPER PHONE IS ' + @PHONE
FETCH NEXT FROM SHIPPER_CURSOR INTO @SHIPPER_NAME, @PHONE
END
CLOSE SHIPPER_CURSOR
DEALLOCATE SHIPPER_ CURSOR
END
Transact SQL Extensions
SQL Server extends the following functionality with cursors. Some of the key features
include:
●
●
●
●
●
●
FETCH FIRST
Fetches the first row in the cursor.
FETCH NEXT
Fetches the row after the last row fetched.
FETCH PRIOR
Fetches the row be<strong>for</strong>e the last row fetched.
FETCH LAST
Fetches the last row in the cursor.
FETCH ABSOLUTE n
Fetches the nth row from the first row in the cursor if n is a positive integer. If n is a
negative integer, the row n rows be<strong>for</strong>e the end of the cursor is fetched. If n is 0, no
rows are fetched.
FETCH RELATIVE n
Fetches the nth row from the current position of the cursor. If n is positive, the nth
row after
the last row fetched is fetched. If n is negative, the nth row be<strong>for</strong>e the last

206 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
row fetched is fetched. If n is 0, the same row is fetched again. It also allows
retrieving one row or block of rows from the current position in the result set.
It supports data modifications to the rows at the current position in the result set.
Step 4: Subprograms Conversion
The next step is to migrate the procedures, functions, and triggers. This section
discusses how each component can be converted <strong>for</strong> use with SQL Server.
<strong>Migrating</strong> Procedures
A stored procedure is a precompiled object. This means that a procedure is compiled
be<strong>for</strong>ehand and is readily available <strong>for</strong> the various applications to execute. As a result,
time is not wasted parsing and compiling the procedure again. However, the procedure
will be compiled every time if it contains dynamic SQL. Stored procedures in SQL Server
are very similar to procedures in <strong>Oracle</strong> PL/SQL. Some similarities include:
● Both can accept parameters and return multiple values in the <strong>for</strong>m of output
parameters (OUT parameter) to the calling procedure.
● Both contain programming statements that per<strong>for</strong>m operations in the database,
including calling other procedures.
● Both can overwrite existing procedures. <strong>Oracle</strong> uses the keyword REPLACE, while
SQL Server uses ALTER.
The syntax between <strong>Oracle</strong> and SQL Server procedures differs. The differences are
shown in the following examples:
● <strong>Oracle</strong>
●
CREATE OR REPLACE PROCEDURE
(PARAMETER1 DATATYPE [IN OUT],
PARAMETER2 DATATYPE [IN OUT],)
IS
VARIABLE1 DATATYPE;
VARIABLE2 DATATYPE;
BEGIN
EXECUTABLE STATEMENTS;
EXCEPTION
EXECUTABLE STATEMENTS;
END;
SQL Server
CREATE PROCEDURE [ ; number ]
[ { @PARAMETER DATATYPE }
[ VARYING ] [ = default ] [ OUTPUT ]
] [ ,...n ] AS
EXECUTABLE STATEMENTS
In the following example, a stored procedure calculates the number of months remaining
until retirement <strong>for</strong> each employee. Retirement age is passed as a parameter to the
procedure. The output needs to be written into a table named RETIRE. The RETIRE
table has two columns. The columns are EMPLOYEEID and MONTHS_REMAINING.
The number of months remaining is calculated and inserted into this table. Be<strong>for</strong>e starting
the operation, the table needs to be flushed.
● <strong>Oracle</strong>

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 207
CREATE OR REPLACE PROCEDURE CALCULATE_RETIRE_MONTHS(RETIRE_AGE NUMBER) IS
CURRENT_AGE NUMBER;
MONTHS_REMAINING NUMBER;
CURSOR EMP_CURSOR IS SELECT EMPLOYEEID, BIRTHDATE FROM EMPLOYEE;
BEGIN
EXECUTE IMMEDIATE 'TRUNCATE TABLE RETIRE';
FOR CUR_VAL IN EMP_CURSOR
LOOP
CURRENT_AGE := ROUND(ROUND(SYSDATE - CUR_VAL.BIRTHDATE)/30)
MONTHS_REMAINING := (RETIRE_AGE * 12) - CURRENT_AGE;
INSERT INTO RETIRE VALUES(CUR_VAL.EMPLOYEE_ID,MONTHS_REMAINING);
END LOOP;
COMMIT;
END;
● SQL S erver
IF EXISTS (SELECT NAME FROM SYSOBJECTS
WHERE NAME = 'CALCULATE_RETIRE_YRS' AND TYPE = 'P')
DROP PROCEDURE CALCULATE_RETIRE_YRS
GO
CREATE PROCEDURE CALCULATE_RETIRE_YRS @RETIRE_AGE INTEGER AS
DECLARE @CUR_AGE INTEGER,@MONTHS_REMAINING INTEGER
DECLARE @V_DOB DATETIME,@V_EMPLOYEEID VARCHAR(30)
DECLA
RE EMP_CURSOR CURSOR FOR
SELECT EMPLOYEEID,BIRTHDATE FROM EMPLOYEE
BEGIN
TRUNCATE TABLE RETIRE;
OPEN EMP_CURSOR
FETCH NEXT FROM EMP_CURSOR INTO @V_EMPLOYEEID,@V_DOB
IF @@FETCH_STATUS 0
BEGIN
PRINT 'NO EMP'
END
ELSE
BEGIN
WHILE (@@FETCH_STATUS = 0)
BEGIN
SET @CUR_AGE = ( SELECT DATEDIFF(MONTH,@V_DOB,GETDATE()) )
SET @MONTHS_REMAINING = (SELECT (@RETIRE_AGE * 12) -
@CUR_AGE)
INSERT INTO RETIRE VALUES
(@V_EMPLOYEEID,@MONTHS_REMAINING)
FETCH NEXT FROM EMP_CURSOR INTO @V_EMPLOYEEID,@V_DOB
END
END
CLOSE EMP_CURSOR
DEALLOCATE EMP_CURSOR
END

208 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
Functions
While si milar to procedures, functions return a value. There may be some mathematical
calculation needed <strong>for</strong> the application that is readily available in the database server. If
you need the result of a complex algorithm as part of a SQL statement, you need to write
a functio n that per<strong>for</strong>ms the required calculation and returns a value.
The syntax between <strong>Oracle</strong> and SQL Server functions differs, as shown in the following
examples:
● <strong>Oracle</strong>
●
CREATE OR REPLACE FUNCTION
(PARAMETER DATATYPE,
PARAMETER DATATYPE ETC ..) RETURN DATATYPE
IS
BEGIN
RETURN
EXCEPTION
;
END;
SQL Server
CREATE FUNCTION @PARAMETER DATATYPE,@PARAMETER DATATYPE ETC ..
RETURNS AS
BEGIN
RETURN
END
The difference between built-in functions in <strong>Oracle</strong> and SQL Server are discussed here.
<strong>Oracle</strong> also has a function called NEXT_DAY that returns the date of the first weekday
named by char that is later than the current date. The char argument must be a day of
the week in the date language of the session, either the full name or the abbreviation.
The minimum number of letters required is the number of letters in the abbreviated
version. Any characters immediately following the valid abbreviation are ignored and the
return value has the same hours, minutes, and seconds component as the argument
date.
By default, this function is not available in SQL Server. But the following example shows
one way to provide this function in SQL Server, and it can be expanded to meet your
needs:
CREATE FUNCTION NEXT_DAY(@D DATETIME,@DAY VARCHAR(10)) RETURNS DATETIME AS
BEGIN
DECLARE @DAY_NUMBER INTEGER
DECLARE @NEWDATE DATETIME
IF UPPER(@DAY)='SUNDAY'
BEGIN
IF ( 1 - DATEPART(DW,@D))=0
SET @NEWDATE = @D + 7
ELSE IF ( 1 - DATEPART(DW,@D)) < 0
SET @NEWDATE = @D + 1 + ( 7 - DATEPART(DW,@D))
ELSE

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 209
END
SET @NEWDATE = @ D + 1 - DATEPART(DW,@D)
ELSE IF UPPER(@DAY)='MONDAY' OR UPPER(@DAY)= ‘MON’
BEGIN
IF ( 2 - DATEPART(DW,@D)) = 0
SET @NEWDATE = @D + 7
ELSE IF ( 2 - DATEPART(DW,@D))< 0
SET @NEWDATE = @D + 2 + ( 7 - DATEPART(DW,@D))
ELSE
SET @NEWDATE = @D + 2 - DATEPART(DW,@D)
END
ELSE IF UPPER(@DAY)='TUESDAY' OR UPPER(@DAY)= ‘TUE’
BEGIN
IF ( 3 - DATEPART(DW,@D)) = 0
SET @NEWDATE = @D + 7
ELSE IF ( 3 - DATEPART(DW,@D))< 0
SET @NEWDATE = @D + 3 + ( 7 - DATEPART(DW,@D))
ELSE
SET @NEWDATE = @D + 3 - DATEPART(DW,@D)
END
ELSE IF UPPER(@DAY)='WEDNESDAY' OR UPPER(@DAY)= ‘WED’
BEGIN
IF ( 4 - DATEPART(DW,@D)) = 0
SET @NEWDATE = @D + 7
ELSE IF ( 4 - DATEPART(DW,@D))< 0
SET @NEWDATE = @D + 4 + ( 7 - DATEPART(DW,@D))
ELSE
SET @NEWDATE = @D + 4 - DATEPART(DW,@D)
END
ELSE IF UPPER(@DAY)='THURSDAY' OR UPPER(@DAY)= ‘THU’
BEGIN
IF ( 5 - DATEPART(DW,@D)) = 0
SET @NEWDATE = @D + 7
ELSE IF ( 5 - DATEPART(DW, @D))< 0
SET @NEWDATE = @D + 5 + ( 7 - DATEPART(DW,@D))
ELSE
SET @NEWDATE = @D + 5 - DATEPART(DW,@D)END
ELSE IF UPPER(@DAY)='FRIDAY' OR UPPER(@DAY)= ‘FRI’
BEGIN
IF ( 6 - DATEPART(DW,@D)) = 0
SET @NEWDATE = @D + 7
ELSE IF ( 6 - DATEPART(DW,@D))< 0
SET @NEWDATE = @D + 6 + ( 7 - DATEPART(DW,@D))
ELSE
SET @NEWDATE = @D + 6 - DATEPART(DW,@D)END
ELSE IF UPPER(@DAY)='SATURDAY' OR UPPER(@DAY)= ‘SAT’
BEGIN
IF ( 7 - DATEPART(DW,@D)) = 0

210 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
SET @NEWDATE = @D + 7
ELSE IF ( 7 - DATEPART(DW,@D))< 0
SET @NEWDATE = @D + 7 + ( 7 - DATEPART(DW,@D))
ELSE
SET @NEWDATE = @D + 7 - DATEPART(DW,@D)
END
ELSE
SET @NEWDATE = NULL
RETURN @NEWDATE
END
Triggers
<strong>Oracle</strong> and SQL Server provide two primary mechanisms <strong>for</strong> en<strong>for</strong>cing business rules
and data integrity through constraints and triggers. A trigger is a special type of stored
procedure that automatically takes effect when an event occurs. The event can be
INSERT, UPDATE, or DELETE. The trigger and the statement that triggers are treated as
a single transaction, which can be rolled back from within the trigger. If an error is
detected, the entire transaction is automatically rolled back.
<strong>Oracle</strong> uses two types of triggers on tables: table-level triggers and row-level triggers. If
the key word FOR EACH ROW is specified, then it is a row-level trigger. Row-level
triggers are fired <strong>for</strong> each row when it is affected. For example, if an update statement
changes 5 rows, then the trigger will be fired 5 times. Table-level triggers are only fired
once. In a table-level trigger, individual values cannot be captured. Row-level triggers
capture the individual rows with the help of the keywords :NEW and :OLD. Unlike <strong>Oracle</strong>,
SQL Server does not have two types of triggers. The individual values can be captured
from a special table called INSERTED. Old values can be fetched from the DELETED
table and the new changed values can be retrieved from the INSERTED table.
The deleted values can be referred with the special variable :OLD in <strong>Oracle</strong>. SQL Server
has a special table called DELETED. The DELETED table stores copies of the affected
rows during DELETE and UPDATE statements. During the execution of a DELETE or
UPDATE statement, rows are deleted from the trigger table and transferred to the
DELETED table. The DELETED and INSERTED tables in SQL Server are only
conceptual; they do not physically exist.
A mapping of the functionality of triggers in <strong>Oracle</strong> and SQL Server as well as a
comparison of the syntax is available under the topic "Triggers" in Chapter 6:
"Developing: Databases — <strong>Migrating</strong> Schemas."
The syntax <strong>for</strong> the triggers differs as follows:
● <strong>Oracle</strong> triggers
Separate syntax is used <strong>for</strong> each trigger command:
● INSERT trigger syntax
CREATE OR REPLACE TRIGGER
[ BEFORE | AFTER ] INSERT ON
[ FOR EACH ROW ]
DECLARE
BEGIN
EXCEPTION
END;

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 211
●
UPDATE trigger syntax
CREATE OR REPLACE TRIGGER
[ BEFORE | AFTER ] UPDATE OF ON
[ FOR EACH ROW ]
DECLARE
BEGIN
EXCEPTION
●
END;
DELETE trigger syntax
CREATE OR REPLACE TRIGGER
[ BEFORE | AFTER ] DELETE ON
[ FOR EACH ROW ]
DECLARE
BEGIN
EXCEPTION
END;
●
SQL Server
Unlike <strong>Oracle</strong>, only one syntax is needed <strong>for</strong> trigger functions in SQL Server:
CREATE TRIGGER ON
{FOR|AFTER|INSTEAD OF}
{[INSERT][,][UPDATE][,][DELETE]}
AS
[{IF UPDATE(column)[{AND|OR}UPDATE(column)]}]
EXECUTABLE STATEMENTS
The following example further illustrates the use of trigger functions. In this example, the
PRODUCT tables need to be updated when an order is issued against any product. The
following code uses an INSERT trigger to per<strong>for</strong>m this task.
● <strong>Oracle</strong>
●
CREATE TRIGGER UPDATE_STOCK
AFTER INSERT ON ORDERDETAILS
FOR EACH ROW
BEGIN
UPDATE PRODUCT SET UNITINSTOCK = UNITINSTOCK - :NEW.QUANTITY
WHERE PRODUCTID = :NEW.PRODUCTID;
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
SQL Server
CREATE TRIGGER UPDATE_STOCK ON ORDERDETAILS
AFTER INSERT AS
BEGIN
UPDATE PRODUCT SET UNITINSTOCK = UNITINSTOCK – QUANTITY

212 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
FROM INSERTED WHERE PRODUCT.PRODUCTID = INSERTED.PRODUCTID
END
INSTEAD OF Triggers
In gene ral, complex views are not updateable. Complex views are defined as normal
views that include more than one table or have GROUP BY expressions. Complex views
can b e updated using INSTEAD OF triggers. Both SQL Server and <strong>Oracle</strong> have the
option of INSTEAD OF triggers. The INSTEAD OF trigger is generally defined on the
view instead of on a table. In <strong>Oracle</strong>, INSTEAD OF triggers can be applied only to the
view and not to tables. In SQL Server, INSTEAD OF triggers can be applied to views and
tables. When an insert, update or delete statement is executed against the table, the
INSTEAD OF trigger is executed in place of the triggering statement.
Also, INSTEAD OF triggers are executed instead of the triggering action. These triggers
are executed after the inserted and deleted tables are created, but be<strong>for</strong>e any other
actions are taken. They are executed be<strong>for</strong>e any constraints, so they can per<strong>for</strong>m
preprocessing that supplements the constraint action.
The triggering mechanism on INSTEAD OF triggers is implemented such that the trigger
is not called recursively. The statement is processed as if there is no INSTEAD OF
trigger defined <strong>for</strong> the table.
If an UPDATE statement is executed on a view that has an INSTEAD OF trigger, the
trigger will be called, but it is not executed recursively. The UPDATE statement is
resolved against the base tables underlying the view. In this case, the view definition
must meet all of the restrictions <strong>for</strong> an updateable view. The UPDATE executed by the
trigger is processed against the view as if the view did not have an INSTEAD OF trigger.
The columns changed by the UPDATE must be resolved to a single base table. Each
modification to underlying base tables starts the chain of applying constraints and firing
AFTER triggers defined <strong>for</strong> the table.
SQL Server provides most of the functionality present in <strong>Oracle</strong> with respect to triggers
with very little differences in their implementation. SQL Server, however, does not have
the BEFORE triggers and can be programmed using the INSTEAD OF triggers on tables.
In SQL Server triggers on views have the same kind of features as seen on triggers on
tables as shown by the following syntax:
CREATE TRIGGER ON
{FOR|AFTER|INSTEAD OF}
{[INSERT][,][UPDATE][,][DELETE]}
AS
BEGIN
[{IF UPDATE(column)[{AND|OR}UPDATE(column)]
EXECUTABLE STATEMENTS
END
An example of the use of INSTEAD OF triggers on view is given in:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vdbt7/html/dvconusinginsteadoftriggersonviews.asp.
Error Handling
Run-time errors in <strong>Oracle</strong>'s PL/SQL programs are done through exceptions and
exception handlers. Exceptions are raised when errors occur. Although there are predefined
system errors, users can also define their own errors in the declaration section
using the syntax:
exception_name
EXCEPTION;

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 213
The user-defined exceptions can be triggered using the syntax:
RAISE exception_name;
Each BEGIN … END block has an associated
end whose syntax is as follows.
EXCEPTION WHEN exception_name THEN
… statements …
END;
exception handler section defined at the
Although these exception handler sections are absent in SQL Server at the block level,
error handling is per<strong>for</strong>med through the use of the global variable @@Error, which is
passed to the calling program and can be handled there. SQL Server sets the value of
the @@Error variable after each TSQL statement. For example:,
INSERT ….
IF @@Error 0
BEGIN
END
SELECT 'Unexpected error occurred: Insert failed', @@Error
Return @@Error
<strong>Oracle</strong> has many predefined exceptions, such as NO_DATA_FOUND,
TOO_MANY_ROWS, ZERO_DIVIDE, INVALID_CURSOR, etc. The predefined exception
OTHERS is of special interest because it can be used as a catch-all exception <strong>for</strong> any
exceptions <strong>for</strong> which there is no definition in the exception section.
SQL Server error messages can be viewed by selecting sysmessages system table.
Each SQL Server internal error is qualified into various severity levels. The severity of
errors ranges from 1 to 25. Errors with severity 19 and above are considered critical and
may result in complete abortion of the batch. In such cases, @@ Error may not capture
the
error raised.
Similar in functionality to user-defined exceptions and the
RAISE_APPLICATON_ERROR function in <strong>Oracle</strong>, SQL Server provides ways to create
customized error messages that can be raised within TSQL code. These are called user-
defined errors and can be raised using RAISERROR statement. If you are referencing an
error number in the RAISERROR function in TSQL, you must create the user-defined
message. You can also dynamically specify a text message in the RAISERROR function.
This is done by using sp_addmessage system stored procedure. For more in<strong>for</strong>mation
on how
to create and raise user-defined errors, see
http:/ /msdn.microsoft.com/library/defa ult.asp?url= /library/enus/acdata/ac_8_
con_05_3f76.asp.
Step 5: Job Scheduling
<strong>Oracle</strong> uses application code and OS utilities to schedule a job. SQL Server uses
SQL Server agent to per<strong>for</strong>m these jobs. The in<strong>for</strong>mation in this section describes
creating a job and scheduling it in SQL Server.
Scheduling Functions and Jobs
Some frequently used scheduling functions that are packaged with <strong>Oracle</strong> are discussed
in this section. They include:
● DBMS_JOB. This is an <strong>Oracle</strong> supplied package <strong>for</strong> scheduling jobs. Several
different procedures are packed inside this package.
Included are:

214 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
●
●
●
●
DBMS_JOB.INSTANCE. This procedure is used to assign a particular instance
to execute a job
DBMS_JOB.CHANGE. This is used to alter the schedule of a job.
DBMS_JOB.SUBMIT. After the creation of job, this procedure submits a job to
the <strong>Oracle</strong> instance.
DBMS_JOB.RUN. Jobs can be executed on demand using this procedure.
●
cron: cron is a daemon, which means that it only needs to be started once, and
will lay dormant until it is required. Generally, a SQL file is written that calls a
particular procedure. This SQL file is called from a shell script and this script is
scheduled using cron. This is how a job is scheduled in <strong>Oracle</strong> running on UNIX.
In SQL Server, jobs can be executed in the following ways:
● Using the Enterprise Manager
● Using the stored procedures SP_ADD_JOB and SP_ADD_JOBSCHEDULE
Using SQL Server Enterprise Manager
A job can be scheduled by using the following steps.
To execute a job in the background on scheduled basis, SQL Server agent must be running.
1. Log in to Enterprise Manager.
2. Expand the server group and then expand the server. Expand Management.
Expand SQL Server Agent and select the Jobs node.
3. Create a new job by right-clicking Jobs.
4. Enter a name <strong>for</strong> the job in the Name field.
5. Check the Enabled check box to make the job available <strong>for</strong> execution either
immediately or by scheduling it. A disabled job runs only if a user explicitly
executes it..
6. In the Owner list, select a user to be the owner of the job.
7. Write the description about the job in Description text area.
8. Select the Steps tab. A job step is an action that the job takes on a database or a
server. Every job must have at least one job step. Job steps can be operating
system commands, Transact-SQL statements, or ActiveX Scripts.
9. Click New to get the job step dialog box. Enter a job step name in the Job step
name box. Select the type in the Type list, For example, you can click Operating
system command (CmdExec).
10. Enter a value from 0 to 999999 in the Process exit code dialog box.
11. Enter the operating system command or executable program in the command box.
If you select Transact-SQL statements or ActiveX scripts, you need to specify the
commands as per the selection.
12. In the Schedules tab, the schedule can be specified. Jobs can be scheduled to run
weekly, daily, or recursive.
13. In the Notifications tab, you can specify an e-mail address to send a notification if
a job fails or succeeds. Messages can also be sent to a pager.
Using SP_ADD_JOB
Jobs in SQL Server can also be scheduled using the stored procedure SP_ADD_JOB.
This simply adds a job in SQL Agent service. Job steps and scheduling can be done only
with other procedures. The syntax <strong>for</strong> use and descriptions are provided in the following
example:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 215
SP_ADD_JOB [ @JOB_NAME = ] 'JOB_NAME'
[ , [ @ENABLED = ] ENABLED ]
[ , [ @DESCRIPTION = ] 'DESCRIPTION' ]
[ , [ @OWNER_LOGIN_NAME = ] 'LOGIN' ]
[ , [ @NOTIFY_LEVEL_EVENTLOG = ] EVENTLOG_LEVEL ]
[ , [ @NOTIFY_LEVEL_EMAIL = ] EMAIL_LEVEL ]
[ , [ @NOTIFY_LEVEL_NETSEND = ] NETSEND_LEVEL ]
[ , [ @NOTIFY_LEVEL_PAGE = ] PAGE_LEVEL ]
[ , [ @NOTIFY_EMAIL_OPERATOR_NAME = ] 'EMAIL_NAME' ]
[ , [ @NOTIFY_NETSEND_ OPERATOR_NAME = ] 'NETSEND_NAME' ]
[ , [ @NOTIFY_PAGE_OPERATOR_NAME = ] 'PAGE_NAME' ]
[ , [ @DELETE_LEVEL = ] DELETE_LEVEL ]
[ @JOB_NAME = ] 'JOB_NAME'
@JOB_ NAME is the name of the job. The name must be unique and cannot contain the
percent (%) character. The commonly used parameters include:
● [ @ENABLED = ] ENABLED
@ENABLED indicates the status of the added job. ENABLED has a default of 1
(enabled). If 0, the job is not enabled and does not run according to its schedule,
but it can be run manually.
● [ @DESCRIPTION = ] 'DESCRIPTION'
@DESCRI PTION is the description of the job. This description can be a maximum
of 512 characters.
● [ @OWNER_LOGIN_NAME = ] 'LOGIN'
@OWNER_LOGIN_NAME is the name of the login that owns the job.
● [ @ NOTIFY_LEVEL_EVENTLOG = ] EVENTLOG_LEVEL
@NOTIFY_LEVEL_EVENTLOG is a value indicating when to place an entry in the
Windows® application log (Event viewer) <strong>for</strong> this job. The value can contain one of
the values described in Table 11.18:
Table 11.18: Values <strong>for</strong> EVENTLOG_LEVEL <strong>for</strong> SP_ADD_JOB
Value
Description
0 Never
1 On success
2 (default) On failure
3 Always
●
●
●
●
[ @NOTIFY_LEVEL_EMAIL = ] EMAIL_LEVEL
The value indicates when to send e-mail upon the completion of this job. This uses
the same values as listed in Table 11.18.
[ @NOTIFY_LEVEL_NETSEND = ] NETSEND_LEVEL
The value indicates when to send a network message upon the completion of this
job. This uses the same values as listed in Table 11.18.
[ @NOTIFY_LEVEL_PAGE = ] PAGE_LEVEL
The value indicates when to send a page upon the completion of this job. This
uses the same values as listed in Table 11.18.
[ @NOTIFY_EMAIL_OPERATOR_NAME = ] 'EMAIL_NAME'

216 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
●
●
●
This is the e-mail address of the person to send e-mail to when EMAIL_LEVEL is
reached.
[ @NOTIFY_NETSEND_OPERATOR_NAME = ] 'NETSEND_NAME'
Name of the operator to whom the network message is sent upon completion of
this job.
[ @NOTIFY_PAGE_OPERATOR_NAME = ] 'PAGE_NAME'
Name of the person to page upon completion of this job.
[ @DELETE_LEVEL = ] DELETE_LEVEL
This value indicates when to delete the job. This uses the same values as listed in
Table 11.18.
The following example shows how to create a job from the stored procedure. This creates
a job named FILE2. The job is enabled with the notification level of zero. No notifications
will be created upon success or failure. Operator DBO is assigned as owner <strong>for</strong> this job.
USE MSDB
EXEC SP_ADD_JOB @JOB_NAME = 'FILE2',
@ENABLED = 1,
@DESCRIPTION = 'FILE DUMP JOB',
@OWNER_LOGIN_NAME = 'DBO',
@NOTIFY_LEVEL_EVENTLOG = 0,
@NOTIFY_LEVEL_EMAIL = 0,
@NOTIFY_LEVEL_NETSEND = 0,
@NOTIFY_LEVEL_PAGE = 0,
@DELETE_LEVEL = 0
After the job is created, it must have some steps to execute. The steps define the
function of the job. The following example runs a Data Trans<strong>for</strong>mation package by using
the DTSRUN utility. SUBSYSTEM should be CMDEXEC to run any utility from a job.
USE MSDB
EXEC SP_ADD_JOBSTEP @JOB_NAME = 'FILE2',
@STEP_NAME = 'STEP1 IN FILE2',
@SUBSYSTEM = 'CMDEXEC',
@COMMAND = 'DTSRUN /S "(LOCAL)" /N "FILETRANSFER" /U "SA" /P "SA" ',
@RETRY_ATTEMPTS = 5,
@RETRY_INTERVAL = 5
@SUBSYSTEM is used by the SQL Server agent service. The available values are
described in Table 11.19.
Table 11.19: Values <strong>for</strong> @SUBSYSTEM <strong>for</strong> SP_ADD_JOB
Subsystem Type
ACTIVESCRIPTING
CMDEXEC
DISTRIBUTION
SNAPSHOT
LOGREADER
MERGE
'TSQL' (default)
Description
Active Script
Operating-system command or executable program
Replication Distribution Agent job
Replication Snapshot Agent job
Replication Log Reader Agent job
Replication Merge Agent job
Transact-SQL statement
@COMMAND
is the actual command to execute. In the following example, the DTSRUN
utility is used. Any executable can be called using @COMMAND.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 217
Any number of steps can be added to a single job. The sequence of the steps is
determined by the parameter @STEP_ID in this procedure.
After the steps have been created, the job can be either executed manually or scheduled.
If it needs to be scheduled, then SP_ADD_JOBSCHEDULE is used with a set of
parameters.
This example highlights how to schedule a job FILE2 to occur everyday at 1:00 A.M. in
SQL Server.
USE MSDB
EXEC SP_ADD_JOBSCHEDULE @JOB_NAME = 'FILE2',
@NAME = 'DAILY LOAD',
@FREQ_TYPE = 4, -- DAILY
@FREQ_INTERVAL = 1,
@ACTIVE_START_TIME = 10000
@FREQ_TYPE is the frequency type. It can accept any one of the values listed in Table
11.20:
Table 11.20: Values <strong>for</strong> @FREQ_TYPE <strong>for</strong> SP_ADD_JOB
Value Description
1 Once
4 Daily
8 Weekly
16 Monthly
32 Monthly, relative to freq interval
64 Run when SQL Server Agent service starts
128 Run when the computer is idle
@FREQ_INTERVAL acts depend upon the value of @FREQ_TYPE. For example, if
@ FREQ_TYPE is set as once, then @ FREQ_INTERVAL has no impact. If
@FREQ_INTERVAL is set to run weekly, then @FREQ_INTERVAL is used to indicate
on which day the job should run.
For more in<strong>for</strong>mation on this topic, refer to the MSDN library at http://www.msdn.com.
Step 6: Interface File Conversion
Any application will have inbound and outbound interface files. During application
migration, it is the application developer's responsibility to consider all inbound as well as
outbound files. External applications will use specified <strong>for</strong>mats. Even after the conversion
from <strong>Oracle</strong>, the external application will still need the interface file in the same <strong>for</strong>mat.
Similarly, the external application might send some interface files to the database.
Considering that the <strong>for</strong>mat might remain the same, application code must be converted
in such a way that the application will handle the file, even though it is not in a
SQL Server-specific <strong>for</strong>mat.
Step 7: Workflow Automation
When per<strong>for</strong>ming the application migration, workflow must also be examined. This
section discusses how to send
mail from the SQL Server database.

218 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
Sending Mail
Sending mail from an application is a very common requirement. <strong>Oracle</strong> includes a
package named UTL_SMTP to provide e-mail functions. Using UTL_SMTP, application
developers write their code to send notification mails from PL/SQL programs. Some
setup is needed in the server side be<strong>for</strong>e UTL_SMTP can be used.
SQL Server has several options to send e-mail. Be<strong>for</strong>e using these options, the mail
accounts and mail service in the server where SQL Server resides needs to be set up
and configured. After this is set up, the XP_SENDMAIL stored procedure can be used to
send notification mails. XP_SENDMAIL has all the options of mail services, including
attachments. For example, the error log file can be sent to the administrator in case of
server side errors.
Be<strong>for</strong>e using mail options, set up SQL Mail in SQL Server Enterprise Manager
using the following steps:
1. Expand the server group and then expand the server.
2. Expand Support Services, right-click SQL Mail, and then click Properties.
3. In the Profile list, select the profile that you created earlier.
4. Click Test if you want to test the SQL mail.
After SQL mail is set up, jobs can be configured to send mail alerts on job
completion to indicate whether the job succeeded or failed. To configure the
jobs, follow these steps:
1. Go to Jobs, select a particular job, and then click Properties.
2. On the Notification tab, you can enable the mailing option upon success or failure.
3. To send mail from Jobs, the Mail component needs to be started. This can be
started automatically whenever SQL Server agent starts. Alternatively,
XP_STARTMAIL can be used to start the mail agent of SQL Server.
In addition, XP_SENDMAIL can be used to send mail from T-SQL batches, triggers, or
procedures. The syntax is shown in the following example:
XP_SENDMAIL {[@RECIPIENTS =] 'RECIPIENTS [;...N]'}
[,[@MESSAGE =] 'MESSAGE']
[,[@QUERY =] 'QUERY']
[,[@ATTACHMENTS =] 'ATTACHMENTS [;...N]']
[,[@COPY_RECIPIENTS =] 'COPY_RECIPIENTS [;...N]'
[,[@BLIND_COPY_RECIPIENTS =] 'BLIND_COPY_RECIPIENTS [;...N]'
[,[@SUBJECT =] 'SUBJECT']
The following example sends a mail to the mail ID SQLDBA@ABC.COM and a copy to
another mail ID SQLDBA1@ABC.COM. This also sends an attachment with the name
"error.log" that is in the directory C:\.
XP_SENDMAIL @RECIPIENTS='SQLDBA@ABC.COM', @MESSAGE='Test mail from SQL Mail',
@ATTACHMENTS='C:\ERROR_LOG', @COPY_RECIPIENTS='@SQLDBA1@ABC.COM', @SUBJECT='Test
Subject'
Step 8: Per<strong>for</strong>mance Tuning
After the code changes have been incorporated, the next step is to review and tune the
per<strong>for</strong>mance. Make sure proper joins are in place and all possible indexed columns are
used while executing the query.
General techniques and guidelines are discussed in this
section.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 219
After following these optimization techniques, test the application with a test database. If
possible, use a copy of production data while testing so that the real response times can
be recorded and more time can be spent tuning the application.
The goal of per<strong>for</strong>mance tuning is to minimize the response time <strong>for</strong> each query and to
maximize the throughput of the entire database server by reducing network traffic, disk
I/O, and CPU time. This goal is achieved through understanding application
requirements, the logical and physical structure of the data, and tradeoffs between
conflicting uses of the database. Per<strong>for</strong>mance strategies vary in their effectiveness, and
systems with different purposes, such as operational systems and decision support
systems, require different per<strong>for</strong>mance skills.
System per<strong>for</strong>mance is designed and built into a system. It does not just happen.
Per<strong>for</strong>mance issues should be considered throughout the development cycle, not just at
the end when the system is implemented. Many per<strong>for</strong>mance issues that result in
significant improvements are achieved by careful design from the outset.
Per<strong>for</strong>mance problems are usually the result of competition <strong>for</strong>, or exhaustion of, system
resources.
When a system resource is exhausted, the system is unable to scale to higher
levels of per<strong>for</strong>mance. Although other system-level per<strong>for</strong>mance issues, such as memory
or hardware, are certainly candidates <strong>for</strong> study, experience shows that the per<strong>for</strong>mance
gains from tuning a query are only incremental when there are fundamental problems in
its design.
This section describes how SQL Server queries can be optimized when migrating from
<strong>Oracle</strong> applications.
For example, in <strong>Oracle</strong>, there are several areas where a DBA concentrates on tuning the
database and queries, such as:
● Memory tuning
● I/O tuning
● SQL tuning
● Managing data and transactions
SQL Server automatically manages available hardware resources, reducing the need <strong>for</strong>
extensive system-level manual tuning. Apart from this automatic management,
SQL Server provides several ways to optimize per<strong>for</strong>mance during the development and
after the system is released into production. These methods are discussed under the
following headings.
Query Tuning
It may be tempting to address a per<strong>for</strong>mance problem solely by system-level server
per<strong>for</strong>mance tuning; <strong>for</strong> example, by altering memory size, type of file system, and
number and type of processors. Generally, most per<strong>for</strong>mance problems cannot be
resolved this way. They must be addressed by analyzing the application, queries, and
updates that the application is submitting to the database, and how these queries and
updates interact with the database schema.
Unexpected long-lasting queries and updates can be caused by:
● Slow network communication
● Inadequate memory in the server computer
● Lack of useful statistics
● Out-of-date statistics
● Lack of useful indexes

220 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL
●
●
Lack of useful data striping
Improper database design
These issues can be resolved only by looking at the query and its path of execution.
SQL Server has several ways to identify all of these issues. Two of the commonly used
methods, SQL Profiler and the SET SHOWPLAN statement, are discussed here. Refer to
Appendix B <strong>for</strong> a list of references about improving per<strong>for</strong>mance.
SQL Profiler
This graphical tool allows system administrators to monitor events in an instance of
SQL Server. Each event can be captured to a file or another table. Using this data, the
query can be analyzed. A stored procedure that hampers the per<strong>for</strong>mance can also be
monitored.
Only use the SQL Profiler <strong>for</strong> suspicious events. As SQL Profiler is used, it can slow
down the server and increase the trace file size. Specific events can be filtered so only a
subset of data can be monitored.
After you have traced the events, SQL Profiler allows captured event data to be replayed
against an instance of SQL Server, effectively re-executing the saved events as they
occurred originally.
SQL Profiler can be used to:
● Monitor the per<strong>for</strong>mance of an instance of SQL Server.
● Debug Transact-SQL statements and stored procedures.
● Identify slow-executing queries.
● Test SQL statements and stored procedures in the Developing Phase of a project
by going through statements to confirm that the code works as expected.
● Troubleshoot problems in SQL Server by capturing events on a production system
and replaying them on a test system. This is useful <strong>for</strong> testing or debugging
purposes and allows users to continue using the production system without
interference.
● Audit and review activity that occurred on an instance of SQL Server. This allows a
security administrator to review any of the auditing events, including the success
and failure of a login attempt and the success and failure of permissions in
accessing statements and objects.
• Provide input to the Index Tuning Wizard to determine index usage suggestions.
Using SET SHOWPLAN in SQL Server
SET SHOWLAN is similar to the <strong>Oracle</strong> EXPAIN PLAN command, and it is used to
display detailed in<strong>for</strong>mation about a query. SET SHOWPLAN_ALL causes SQL Server
not to execute Transact-SQL statements. Instead, SQL Server returns detailed
in<strong>for</strong>mation about how the statements are executed and provides estimates of the
resource requirements <strong>for</strong> the statements. The syntax <strong>for</strong> this command is:
SET SHOWPLAN_ALL {ON | OFF}
When SET SHOWPLAN_ALL is ON, SQL Server returns execution in<strong>for</strong>mation <strong>for</strong> each
statement without executing it, and Transact-SQL statements are not executed. After this
option is set ON, in<strong>for</strong>mation about all subsequent Transact-SQL statements is returned
until the option is set OFF.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 221
For example, if a CREATE TABLE statement is executed while SET SHOWPLAN_ALL is
ON, SQL Server returns an error message. When SET SHOWPLAN_ALL is OFF,
SQL Server executes the statements without generating a report.
Use SET SHOWPLAN_TEXT to return readable output <strong>for</strong> Microsoft MS-DOS
applications, such as the osql utility.
SET SHOWPLAN_TEXT and SET SHOWPLAN_ALL cannot be specified inside a stored
procedure; they must be the only statements in a batch.
SET SHOWPLAN_ALL returns in<strong>for</strong>mation as a set of rows that <strong>for</strong>m a hierarchical tree
representing the steps taken by the SQL Server query processor as it executes each
statement. Each statement reflected in the output contains a single row with the text of
the statement, followed by several rows with the details of the execution steps.
For a more detailed view of the output obtained by turning on SET SHOWPLAN_ALL,
refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_set-
set_365o.asp.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 223
12
Developing: Applications —
<strong>Migrating</strong> Perl
Introduction and Goals
This chapter contains a detailed discussion of changes that must be made to Perl
applications to work with Microsoft® SQL Server. At the conclusion of this chapter, the
Perl application should be capable of successfully connecting to the SQL Server
database that was migrated from <strong>Oracle</strong> and the solution can be tested.
As discussed in the "Define the <strong>Solution</strong> Concept" section of Chapter 2, "Envisioning
Phase", there are four different strategies available <strong>for</strong> transitioning applications in an
<strong>Oracle</strong> to SQL Server migration project. The strategies are:
● Interoperate the application with UNIX.
● Port or rewrite the application to the Microsoft .NET plat<strong>for</strong>m.
● Port or rewrite the application to the Microsoft Win32® plat<strong>for</strong>m.
● Quick port using the Windows® Services <strong>for</strong> UNIX 3.5 plat<strong>for</strong>m.
Perl is an interpreted scripting language that runs on both UNIX and Windows. Because
of the cross-plat<strong>for</strong>m capabilities of Perl, some of these strategies are more logical than
others.
For example, because Perl can be ported to Windows, there is no need to rewrite the
application in the .NET framework or <strong>for</strong> the Win32® environment. Also, because the
application can run within the Windows environment, a quick port using
Windows Services <strong>for</strong> UNIX is not necessary and would only prevent the application from
tightly integrating with Windows.
Based on available migration strategies, two scenarios can be developed to migrate Perl
applications. The solution scenarios are:
● Scenario 1: Interoperation of Perl on UNIX with SQL Server
If the business requirements do not include eliminating the UNIX environment, an
interoperation strategy can be implemented quickly. Few changes need to be
made to the source code, and installing a new driver allows the Perl application to
connect to a SQL Server database. Interoperation can also be used as an interim
step if the migration is per<strong>for</strong>med in phases.
● Scenario 2: Port the Perl Application to Win32

224 Developing: Applications — <strong>Migrating</strong> Perl
Perl applications can also be ported to run natively on the Windows plat<strong>for</strong>m. As
with interoperation, few changes need to be made to the source code.
Note If your Perl applications use UNIX system calls extensively (such as frequent use
of syscall and exec), porting them to Windows Services <strong>for</strong> UNIX/Interix may be a
suitable option because Interix has more support <strong>for</strong> the desired system calls. Chapter
2, "Envisioning Phase," provides a more detailed discussion of when choosing
Services <strong>for</strong> UNIX would be more appropriate when moving to a Windows-based
plat<strong>for</strong>m.
You will need the following to implement this option (porting Perl applications to Services
<strong>for</strong> UNIX/SQL Server):
● A port of Perl <strong>for</strong> Interix (downloadable from Interop Systems at
http://www.interopsystems.com/tools/warehouse.htm), which ships with the
necessary DBI, DBD::ODBC and DBD::Sybase modules.
● A connectivity driver to the SQL Server database. This is provided by the port of
FreeTDS on Interix and is downloadable from Interop Systems at
http://www.interopsystems.com/tools/db.htm. FreeTDS provides two connectivity
options <strong>for</strong> the Perl application to connect to the SQL Server database. One is a
library called CTlib, which can be accessed through the DBD::Sybase module. The
other is an odbc driver, which can be accessed though the DBD::ODBC module.
● If you use the ODBC driver, you will also need an ODBC driver manager. Two
different ODBC driver managers iODBC and unixODBC are available <strong>for</strong> Windows
Services <strong>for</strong> UNIX from http://www.inte ropsystems.com/tools/warehouse.htm.
This technology option, however, has not been fully tested as a part of development of
this solution and there<strong>for</strong>e has not been detailed further.
Introduction to the Perl DBI Architecture
There are several different modules
available <strong>for</strong> use with Perl that extend the capabilities
of the language. One of these modules, the Database Independent Interface (DBI),

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 225
provides a common programming interface <strong>for</strong> several different proprietary databases,
including <strong>Oracle</strong> and SQL Server. DBI offers a single set of functions or methods that can
interact with the databases. These functions <strong>for</strong>m an abstraction layer that allows the
programmer to write code using generic DBI calls without needing specific API
knowledge <strong>for</strong> the particular database. This layer makes the Perl code portable across
databases.
These generic DBI calls are then interpreted into RDBMS-specific functions using
specialized Database Driver (DBD) modules. A DBD is a database-specific driver that
translates DBI calls to the target database. The DBI API <strong>for</strong>wards the call to the
appropriate database driver module, which then provides support, such as the dynamic
load ing of drivers, error-checking, and management. Figure 12.1 provides a visual
representation of path from a Perl script to the backend database using DBI-DBD.
Figure 12.1
Perl communication with databases using DBI API and DBD drivers
DBI also supports the Open Database Connectivity (ODBC) interface. While DBI itself is
an abstraction layer, ODBC <strong>for</strong>ms another additional abstraction layer. This layer,
consisting of an ODBC driver and ODBC driver manager mirrors the functions of the DBI
and DBD within Perl. If the current solution utilizes ODBC, then a port using ODBC may
provide the most direct solution. In other instances, ODBC may simply duplicate other
laye rs and add additional processing overhead. In these situations, ODBC is not
recommended. Figure 12.2 shows the path from Perl script to backend database
involving ODBC drivers.
Figure 12.2
ODBC adds additional layers of connectivity between the application and database
Scenario 1: Interoperation of Perl on UNIX with
SQL Server
Interoperation between a UNIX-based Perl application and a SQL Server database is
possible because of the availability of a driver that interfaces between these
technologies. Because of the DBI API, this type of migration is usually a relatively simple
process. Only minimal changes may need to be made to the Perl application's source

226 Developing: Applications — <strong>Migrating</strong> Perl
code.
The cases described in this section discuss options available <strong>for</strong> Perl applications
using ODBC or <strong>Oracle</strong> drivers. The following cases assume that the Perl application
currently uses either the ODBC DBD or the <strong>Oracle</strong> DBD within the existing solution.
Case 1: Interoperating an ODBC DBD Application
If the original application was written using ODBC DBD, then the best migration option is
to continu e to use this driver. Because ODBC is not database-specific, no changes
should need to be made to the application's source code. The only changes that need to
be made concern connectivity with the SQL Server database.
T o interoperate the Perl application using ODBC, follow these common steps:
1. Install the ODBC driver.
The DBD::ODBC module requires a driver manager and a driver to interact with
SQL Server. DBD::ODBC is packaged with the Independent ODBC (iODBC) driver
manager from OpenLink Software (http://www.openlinksw.com/). For more
in<strong>for</strong>mation about this driver, refer to
http ://www.freetds.org/userguide/perl.htm#DBD.ODBC. Another driver manager,
unixODBC, that could be used in an interoperation scenario is available from
http://www.freetds.org/user guide/prepodbc.htm.
FreeTDS is a popular ODBC driver used to connect to SQL Server from a UNIX-
source implementation of Tabular Data
based application. FreeTDS is an open
Stream (TDS) protocol that allows the application native access to SQL Server.
OpenLink also offers drivers <strong>for</strong> SQL Server that use the FreeTDS implementation
of TDS. Detailed instructions <strong>for</strong> building and configuring this driver are available at
http://www.freetds.org/userguide/perl.htm.
For detailed steps on installing the unixODBC or FreeTDS drivers, see Appendix
D: "Installing Common Drivers and Applications." Even though the discussion is
related to installing FreeTDS in a Windows Services <strong>for</strong> UNIX environment, it
applies equally to UNIX as well.
2. Create a SQL Server data source.
To function, ODBC needs a data source to connect to the database. The Data
Source Name (DSN) is generally defined in an odbc.ini file that is used by the
driver manager. The DSN is used by the driver manager to load the ODBC driver.
iODBC offers a graphical user interface to set up the DSN. Complete instructions
are available from http://www.iodbc.org/index.php?page=docs/odbcstory.
The DSN can also be configured by manually modifying the odbc.ini file. The
following example file uses an <strong>Oracle</strong> DSN.
[ODBC Data Sources]
ORA_HR_DB=Sample <strong>Oracle</strong>8 dsn
[ORA_HR_DB]
Driver=/opt/odbc/lib/ivor8x01.so
Description=<strong>Oracle</strong>8
ServerName=uxdbp1
LogonID=daveb
Password=cougar
This configuration file can be modified to use the SQL Server DSN, as shown in
the following example. Note that the [ORA_HR_DB] section is replaced with
[SS_HR_DB]. Though most of the keys remain, the values are modified to allow <strong>for</strong>
the SQL Server data source.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 227
[ODBC Data Sources]
SS_HR_DB=Sample MS SQLServer
[SS_HR_DB]
Driver=/usr/local/freetds/lib/libtdsodbc.so
Description=SQL Server 2000
Database=hrapp
UID=daveb
PWD=cougar
Address=win2kdbp1,1433
Note The isql command line utility can be used to check the validity of the DSN
entry when using unixODBC. This allows you to ensure that the entries in the
odbc.ini are correct. The syntax <strong>for</strong> use is:
isql -v DSN username password
3.
Test the connectivity.
iODBC contains a utility named odbctest which can be used to test the DSN
entries and interact with the database by connecting and issuing queries directly
without any code. The syntax <strong>for</strong> per<strong>for</strong>ming this test is:
odbctest "DSN=SS_HR_DB;UID=daveb;PWD=cougar"
4. Change the existing application to use SQL Server as data source.
The following sample source Perl program from an <strong>Oracle</strong> environment contains
functions to connect, prepare, execute, bind, and disconnect. Compare these
functions with the Perl code in the following example. Minor adjustments are made
to allow <strong>for</strong> the data source change.
#Load the DBI module
use DBI;
my $connectstring_oracle = 'ora_hr_db';
my $username = 'daveb';
my $password = 'cougar';
my $tablename = 'Employee_Info';
#Connecting to <strong>Oracle</strong> DB using ODBC
my $dbh = DBI->connect(" dbi:ODBC:$connectstring_oracle", "$username",
"$password");
#Preparing the SQL statement
$sth = $dbh->prepare("insert into $tablename (last_name) values (?)");
#Binding the value to the parameter at run time.
$sth->bind_param( 1,"LName);
#Executing the query
$sth->execute() or warn $sth->errstr(); # check <strong>for</strong> error
$sth->finish();

228 Developing: Applications — <strong>Migrating</strong> Perl
#Disconnect from <strong>Oracle</strong> database
$dbh->disconnect or warn "Can't disconnect from the <strong>Oracle</strong>
$connectstring_oracle database: $DBI::errstr\n";
The same functions are modified to use a SQL Server data source in the following
example:
my $connectstring_oracle = 'ora_hr_db';
my $username = 'daveb';
my $password = 'cougar';
my $tablename = 'Employee_Info';
#Connecting to <strong>Oracle</strong> DB using ODBC
my $dbh = DBI->connect("dbi:ODBC:$connectstring_oracle", "$username",
"$password")
to
my $connectstring_ss = 'ss_hr_db';
my $username = 'daveb';
my $password = 'cougar';
my $tablename = 'Employee_Info';
#Connecting to SQL Server DB using ODBC
my $dbh = DBI->connect("dbi:ODBC:$connectstring_ss", "$username", "$password")
5. Change all embedded SQL statements to T-SQL.
This is a step common to all migrations. Refer to Chapter 11, "Developing:
Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a detailed discussion on modifying
<strong>Oracle</strong> SQL to be SQL Server-compliant.
Case 2: Interoperating an <strong>Oracle</strong> DBD Application
If the original application was written using the <strong>Oracle</strong> DBD, there are two possible
options that can be evaluated. The recommended option is to replace the <strong>Oracle</strong> DBD
with a Sybase DBD. The second option is to migrate to an ODBC framework similar to
the one seen in "Case 1: Interoperating an ODBC DBD Application." Sybase DBD offers
better per<strong>for</strong>mance than ODBC.
Migrate to SQL Server Using Sybase DBD
Becau se SQL Server was originally based on the Sybase data structure, it is possible to
use the Sybase DBD to connect to SQL Server using a SQL Server driver.
To use the Sybase DBD to connect to SQL Server using a SQL Server driver,
follow these steps:
1. Install SQL Server library support.
The FreeTDS driver is needed <strong>for</strong> this method. Instructions <strong>for</strong> installing and
configuring the driver are located in Appendix D, "Installing Common Drivers and
Applications." Even though the discussion is related to installing FreeTDS in a
Windows Services <strong>for</strong> UNIX environment, it applies equally to UNIX as well.
Because the driver is not being used with ODBC, the -disable-odbc switch can be
used with the configure command while installing FreeTDS. Details on the use of
this command are availa ble at http://www.freetds.org/userguide/config.htm.
2. Configure the data source.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 229
After FreeTDS is installed, the freetds.conf file should be modified to include the
SQL Server database in<strong>for</strong>mation. A sample entry is shown in the following
example:
[SS_HR_DB]
host = win2kdbp1 # or IP address
port = 1433
tds version = 8.0
3. Install the Sybase DBD module.
For more in<strong>for</strong>mation on installing this Perl module, refer to
http://search.cpan.org/~mewp/DBD-Sybase/Sybase.pm.
In addition, the SYBASE environment variable should be set to the location of the
FreeTDS installation. If using bash or ksh, the following commands can be used:
4.
export SYBASE=/usr/local/freetds
Modify the application's source code.
Minor changes will need to be made to the source code to allow <strong>for</strong> the data
source change. The following sample code shows some different implementation
options of the Perl language that may appear in your existing source code.
Compare these to the second code sample that has been modified to use the
Sybase DBD.
# load the DBI module
use DBI;
# Connect to the <strong>Oracle</strong> Database
my $dbh = DBI->connect("dbi:<strong>Oracle</strong>: ora_hr_db ",
'userName',
'password',
{
RaiseError = > 1,
AutoCommit => 0
}
) || die "Database connection not made: $DBI::errstr";
#Prepare a SQL statement
my $sql = qq{ SELECT id, name, title,
my $sth = $dbh->prepare( $sql );
phone FROM employees };
#Execute the statement
$sth->execute();
my( $id, $name, $title, $phone );
# Bind the results to the local variables
$sth->bind_columns( undef, \$id, \$name, \$title, \$phone );
#Retrieve values from the result set
while( $sth->fetch() ) {
print "$name, $title, $phone\n";
}

230 Developing: Applications — <strong>Migrating</strong> Perl
#Close the connection
$sth->finish();
$dbh->disconnect();
5. Change the connection to the Sybase DBI and SQL Server DSN.
The script in Step 4 has been rewritten to use DBD::Sybase. Note that the changes
have been made in the header <strong>for</strong> the DBD and in the connection string <strong>for</strong>
SQL Server. The rest of the Perl code is untouched by this change. This modified
code is shown in the following example.
# load the DBI module
use DBI;
use DBD::Sybase;
BEGIN
{
$ENV{SYBASE} = "/usr/local";
}
# Connect to the SQL Server Database
my $dbh = DBI->connect( “dbi:Sybase:server=ss_hr_db;database=hrapp”,
'userName',
'password',
{
RaiseError => 1,
AutoCommit = > 0
}
) || die "Database connection not made: $DBI::errstr";
#Prepare a SQL statement
my $sql = qq{ SELECT id, name, title, phone FROM employees };
my $sth = $dbh->prepare( $sql );
#Execute the statement
$sth->execute();
my( $id, $name, $title, $phone );
# Bind the results to the local variables
$sth->bind_columns( undef, \$id, \$name, \$title, \$phone );
#Retrieve values from the result set
while( $sth->fetch() ) {
print "$name, $title, $phone\n";
}
#Close the connection
$sth->finish();
$dbh->disconnect();

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 231
6.
Change all embedded SQL statements to T-SQL.
Refer to Chapter 11, "Developing: Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a
detailed discussion on modifying <strong>Oracle</strong> SQL to be SQL Server-compliant.
Migrate to SQL Server Using ODBC
To migrate an <strong>Oracle</strong> DBD connection to ODBC, follow these steps:
1. Install the ODBC driver.
FreeTDS should be installed. For more in<strong>for</strong>mation see Appendix D, "Installing
Common Drivers and Applications." Even though the discussion is related to
installing FreeTDS in a Windows Services <strong>for</strong> UNIX environment, it applies equally
to UNIX as well.
2. Configure the DSN settings.
The steps <strong>for</strong> creating an ODBC DSN have been shown in "Case 1: Interoperating
an ODBC DBD Application."
3. Install the ODBC DBD module.
Installation instructions are available at http://search.cpan.org/dis t/perl/INSTALL
and http://www.easysoft.com/products/2002/perl_dbi_dbd_odbc.phtml#3_0
In addition, the following environment variables need to be set:
● ODBCHOME. The directory where ODBC driver manager is installed.
● DBI_DSN. The dbi data source.
● DBI_USER. The username to connect to the database.
● DBI_PASS. The password <strong>for</strong> the database username.
4. Modify the source code.
The original script written <strong>for</strong> use with DBD::<strong>Oracle</strong> has to be changed to connect
to SQL Server through the ODBC DSN. Changes are limited to the connect()
method as shown in the following code.
# load the DBI module
use DBI;
# Connect to the <strong>Oracle</strong> Database
my $dbh = DBI->connect("dbi:ODBC:ss_hr_db",
'userName',
'password',
{
RaiseError => 1,
AutoCommit => 0
}
) || die "Database connection not made: $DBI::errstr";
#Prepare a SQL statement
my $sql = qq{ SELECT id, name, title, phone FROM employees };
my $sth = $dbh->prepare( $sql );
#Execute the statement
$sth->execute();
my( $id, $name, $title, $phone );

232 Developing: Applications — <strong>Migrating</strong> Perl
# Bind the results to the local variables
$sth->bind_columns( undef, \$id, \$name, \$title, \$phone );
#Retrieve values from the result set
while( $sth->fetch() ) {
print "$name, $title, $phone\n";
}
#Close the connection
$sth->finish();
$dbh->disconnect();
Note ODBC connections can also be made without using DSN sources. The
difference from a DSN is that the required configuration in<strong>for</strong>mation is embedded
in the Perl code instead of residing in a separate initialization file. The following
example shows a non-DSN connection:
my $dsn = 'DBI:ODBC:Driver={SQL Server}';
my $host = 'hostname';
my $database = 'dbname';
my $user = 'username';
my $auth = 'password';
my($dbh) = DBI->connect("$dsn;$host;$database",$user,$auth,
{ RaiseError => 1, AutoCommit => 1});
5. Change all embedded SQL statements to T-SQL.
Refer to chapter 11, "Developing: Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a
detailed discussion on modifying <strong>Oracle</strong> SQL to be SQL Server-compliant.
Scenario 2: Porting the Perl Application to Windows
The migration of Perl applications in a UNIX environment to Windows and moving the
backend to a SQL Server database is not much more ef<strong>for</strong>t than that needed under the
interoperation scenario. It is possible to port the Perl application to both the .NET and the
Win32 environment. The port to .NET is made possible by the availability of the utility
PerlNET, which can wrap Perl programs into a .NET component. However, the
app lication has to be ported from the UNIX environment to Windows environment be<strong>for</strong>e
the conversion to .NET can be per<strong>for</strong>med. Details about PerlNET are available at
http://aspn.activestate.com/ASPN/docs/PDK/6.0/PerlNET.html#perlnet_top.
There are a few additional steps that should be followed to successfully move the Perl
application to Win32. These steps are discussed in the following two cases.
Case 1: Porting a Perl Application using ODBC DBD
To port the Perl application to the Windows environment, follow these steps:
1. Install Perl in the target Windows environment.
ActiveState Perl is available from http://www.activestate.com. For more in<strong>for</strong>mation
on installing ActivePerl, see Appendix D, "Installing Common Drivers and
Applications."
2. Install DBI and DBD::ODBC.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 233
The DBI and DBD::ODBC modules can be installed using Perl Package Manager
(PPM), which is installed with ActivePerl. PPM is an interactive command line utility
which can be launched from the command line by typing ppm.
Download the DBI and DBD::ODBC files to a local directory—<strong>for</strong> example,
c:\perlppd. These files can be downloaded from
http://ppm.activestate.co m/PPMPackages/zips/ .
The modules can be installed by typing the following commands:
PPM> rep add new c:\perlppd
PPM> install DBI
PPM> install DBD-ODBC
PPM> quit
3. Install the ODBC driver.
There are several available options <strong>for</strong> acquiring and installing an ODBC driver <strong>for</strong>
SQL Server. These options include:
● An ODBC driver <strong>for</strong> SQL Server is included as part of the SQL Server
distribution CD and is installed as part of the SQL Server client install. Refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/howtosql/ht_install_029l.asp <strong>for</strong> in<strong>for</strong>mation on installing the SQL Server
client.
● OpenLink software offers an ODBC solution that eliminates the need to install
SQL Server client software on the server on which the Perl application will run.
Details on this driver are available at http://uda.openlinksw.com/odbc/st/odbc-
sqlserver-st/.
● DataDirect offers Connect <strong>for</strong> ODBC drivers that also provide clientless access
to SQL Server. Details are available at
http://www.datadirect.com/products/odbc/index.ssp.
4.
Configure the ODBC data source.
An ODBC data source can be configured by modifying odbc.ini as shown in the
"Case 1: Interoperating an ODBC DBD Application" section of Scenario 1. The
data source can also be configured using the ODBC Data Source Administrator
utility that is bundled with Windows. This utility can be accessed by accessing from
the Control Panel by choosing Administrative Tools, then Data Sources
(ODBC). Some
database vendors also provide utilities to configure DSNs.

234 Developing: Applications — <strong>Migrating</strong> Perl
Figure 12.3
Configuring the ODBC System DSN
Note In Windows, DSNs should be created as a System DSN and not as a User
DSN because of permissions restrictions associated with the latter.
Further steps <strong>for</strong> creating a data source are available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/howtosql/ht_6_odbcht_1oqc.asp.
5. Change the application to use SQL Server as the data source.
The move to Windows does not add any overhead in terms of modifications to the
application. The changes are driven by the change in DSN and are similar to
changes discussed in the "Case 1: Interoperating an ODBC DBD Application"
section of Scenario 1.
6. Change all embedded SQL statements to T-SQL.
This is a step common to all migrations. Refer to Chapter 11, "Developing:
Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a detailed discussion on modifying
<strong>Oracle</strong> SQL to be SQL Server-compliant.
Case 2: Porting a Perl Application Using <strong>Oracle</strong> DBD
When migrating from a UNIX plat<strong>for</strong>m to a Windows plat<strong>for</strong>m, there are two options to
replace the DBD::<strong>Oracle</strong> module. One option is to use the DBD::ODBC module. The
other is to use ActiveX Data Objects (ADO) through the DBD::ADO module.
Using DBD::ODBC is recommended in most instances and is discussed in greater detail
in the "Case 1: Interoperating an ODBC DBD Application" section of Scenario 1.
DBD::ADO is a DBI driver that acts as an interface to other lower-level database drivers

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 235
within Windows. DBD::ADO requires the DBD::ODBC module to function. Using
DBD::ADO will add an additional connectivity layer to the solution and should only be
implemented if the application needs to take advantage of the OLE DB APIs. This driver
can then be used to connect to and access data from any ADO data source.
Migrate to DBD::ADO
To migrate to DBD::ADO, follow these steps:
1. Install ActivePerl.
ActivePerl is a Windows-based Perl engine available from
http://www.a ctivestate.com. For detailed installation instructions, see Appendix D,
"Installing Common Drivers and Applications."
2. Install DBI.
The DBI module can be installed using Perl Package Manager (PPM), which is
installed with ActivePerl.
3. Install DBD::ODBC using PPM.
4. Install the ODBC driver.
5. Configure the ODBC data source.
6. Install ADO.
The DBD::ADO module requires Microsoft ADO version 2.1 or later to work
reliably. ADO drivers are available from Microsoft as part of the Microsoft Data
Access Component (MDAC) available at
http://msdn.microsoft.com/data/technologyinfo/mdac.
Download the DBD::ADO module files to a local directory—<strong>for</strong> example, c:\perlppd.
The ADO module can be downloaded from
http://ppm.activestate.com/PPMPackages/zips/.
This module can be installed from Perl Package Manager (PPM).
Type ppm at the command line to start the package manager, and then type the
following commands:
PPM. Rep add new c:\perlppd
PPM> install DBI
PPM> install DBD-ADO
PPM> quit
7. Modify the connection string to use ADO. No other changes should need to be
made to the source code. A sample ADO connection string is shown in the
following example:
use DBI;
my $dsn ="Provider=sqloledb;Trusted_Connection=Yes;Server=
win2kdbp1;Database=hrapps";
$dbh = DBI->connect("dbi:ADO:$dsn", $user, $passwd);
Calling stored procedures is supported by DBD::ADO using the ODBC style call
procedure_name(). An example <strong>for</strong> calling a procedure is
my $sth = $dbh->prepare("{call procedure name (?)}");
Parameters can be either input or output parameters. Parameters are bound as
seen in earlier examples.
8. Change all embedded SQL statements to T-SQL.
This is a step common to all migrations. Refer to Chapter 11, "Developing:
Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a detailed discussion on modifying
<strong>Oracle</strong> SQL to be SQL Server-compliant.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 237
13
Developing: Applications —
<strong>Migrating</strong> PHP
Introduction and Goals
This chapter explores the options available to maintain connectivity of PHP: Hypertext
Preprocessor (PHP) applications as part of the <strong>Oracle</strong> to Microsoft® SQL Server
migration project. In PHP, the logic to interact with databases is provided by database-
functions to per<strong>for</strong>m
specific modules (or drivers). These modules have specialized
database-related tasks and can be replaced to accommodate a SQL Server backend with
relative ease.
PHP is an open source, server-side, cross-plat<strong>for</strong>m scripting language used to create
dynamic Web pages. Like any other Common Gateway Interface (CGI), PHP can provide
dynamic, data-driven characteristics to static HTML <strong>for</strong>ms or pages.
As discussed in Chapter 2, "Envisioning Phase," there are four different strategies
available <strong>for</strong> transitioning applications in an <strong>Oracle</strong> to SQL Server migration project. The
strategies are:
● Interoperate the application with the UNIX environment.
● Port or rewrite the application to the Microsoft .NET plat<strong>for</strong>m.
● Port or rewrite the application to the Microsoft Win32® plat<strong>for</strong>m.
● Quick port using the Microsoft Windows® Services <strong>for</strong> UNIX 3.5 plat<strong>for</strong>m.
Because of the unique characteristics of PHP, some of
than others.
these strategies are more feasible
For example, because PHP can be ported to Windows, there is no need to rewrite the
application <strong>for</strong> .NET or Win32 unless the existing solution's source code is not available.
Because the available drivers <strong>for</strong> .NET are still in beta, the porting has to be done to a
Win32 environment, Also, because the application can run within the Windows
environment, a quick port using Windows Services <strong>for</strong> UNIX is not necessary in most
cases.
Bas ed on the available migration strategies, two scenarios can be developed to migrate
PHP applications. These scenarios include:
● Scenario 1: Interoperating PHP on UNIX with SQL Server
If the business requirements
do not include eliminating the UNIX environment, an
interoperation strategy can be implemented quickly. Few changes need to be

238 Developing: Applications — <strong>Migrating</strong> PHP
●
made to the source code and installing a new driver allows the PHP application to
connect to a SQL Server database. If the migration is per<strong>for</strong>med in phases,
interoperation can be used as an interim step.
Scenario 2: Porting the Application to Win32
PHP applications can also be ported to run natively on the Windows plat<strong>for</strong>m. As
with interoperation, few changes need to be made to the source code.
Available options are discussed <strong>for</strong> each scenario in separate cases. Each case lists
steps required to connect the PHP application to the SQL Server data source. Also
included are discussions on the differences between the various <strong>Oracle</strong> and SQL Server
functions. When applicable, sample source code is provided to illustrate changes that
need to be made.
Note If your PHP scripts use UNIX system calls extensively (such as frequent use of
exec, passthru, popen, or the backtick (`)), porting them to Windows Services <strong>for</strong>
UNIX/Interix may be a suitable option because Interix has more support <strong>for</strong> the desired
system calls. Chapter 2, "Envisioning Phase," provides a more detailed discussion of
when choosing Windows Services <strong>for</strong> UNIX would be more appropriate when moving
to a Windows-based plat<strong>for</strong>m.
You will need the following to implement this option (porting PHP applications to
Windows Services <strong>for</strong> UNIX/SQL Server):
● A port of PHP <strong>for</strong> Interix downloadable from Interop Systems at
http://www.interopsystems.com/tools/warehouse.htm, which includes the capability
of using DBLib, CTLib and ODBC. The PHP distribution will have to be compiled
<strong>for</strong> using a specific database connectivity library.
● A connectivity driver to the SQL Server database. This is provided by the port of
FreeTDS on Interix and is downloadable from Interop Systems at
http://www.interopsystems.com/tools/db.htm. FreeTDS provides three connectivity
options <strong>for</strong> the PHP application to connect to the SQL Server database. Two
options go through the libraries DBLib and CTLib, which provide connectivity to
both Sybase and SQL Server. The third is the ODBC driver, which can be used to
access any ODBC database (including SQL Server).
This technology option, however, has not been fully tested as a part of development of
this solution and there<strong>for</strong>e has not been detailed further.
PHP Modules
PHP contains a rich set of options <strong>for</strong> interfacing with common proprietary databases,
including <strong>Oracle</strong> and SQL Server. These interfaces are available through PHP as internal
functions or extensions. The database-related functions are grouped into modules which

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 239
must be compiled into the PHP installation be<strong>for</strong>e use. These modules are enabled by
specifying them in the configuration file (php.ini).
Figure 13.1
PHP modules (functions) that can access <strong>Oracle</strong>
Figure 13.2
PHP modules (functions) that can access SQL Server
The following modules are commonly used with <strong>Oracle</strong> databases. Each is discussed in
detail in this chapter:
● <strong>Oracle</strong>
(ORA) functions
ORA is a set of functions used to access <strong>Oracle</strong> databases.
The php_oracle value in the php.ini file (extension=php_oracle.dll) is used to
enable functions. The functions in this module can be identified by the ora_ prefix,
such as ora_logon().
● <strong>Oracle</strong> 8 (OCI8) functions

240 Developing: Applications — <strong>Migrating</strong> PHP
●
OCI8 is a set of functions based on <strong>Oracle</strong> Call Interface (OCI) used to access
<strong>Oracle</strong> databases, including 8i and 9i releases. This module is more flexible than
the standard <strong>Oracle</strong> functions.
The php_oci8 value in the php.ini file (extension=php_oci8.dll) is used to enable
the functions. The set of functions that are in this module can be identified by the
oci_ prefix, such as oci_logon(). Be<strong>for</strong>e PHP 5.0, every oci_ function was named
with an oci prefix. Although the functions with the oci prefix are still available, they
are now deprecated.
ODBC functions
A modified version of ODBC that provides a unified driver <strong>for</strong> native support <strong>for</strong>
several databases is available <strong>for</strong> PHP. ODBC support is integrated with PHP and,
unlike the modules needed <strong>for</strong> ORA and OCI8, no extensions need to be specified.
ODBC has the advantage of allowing applications to be written which, theoretically,
are independent from the RDBMS. If the RDBMS changes, only the driver will
need to be changed, not the code.
ODBC function calls are handled by a driver manager that passes the calls to a
specific driver <strong>for</strong> the target database <strong>for</strong> execution. The iODBC driver manager is
commonly used with PHP to connect to databases on Windows. iODBC
(h ttp://www.iodbc.org) is an open source ODBC driver manager and the SDK is
maintained by Open Link Software (http://www.openlinksw.com). iODBC calls use
an odbc_ prefix. For example, odbc_connect() utilizes the ODBC driver manager.
Another open source project, named after the unixODBC project, has developed a
driver manager called unixOD BC (http://www.unixodbc.org). The unixODBC calls
use the three-letter SQL prefix. For example, SQLconnect() uses the unixODBC
driver manager.
Note The function phpinfo() can be called to reveal the extensions that have been
loaded into PHP. A simple script containing the following line is sufficient to implement
this call:
Scenario 1: Interoperating PHP on UNIX with
SQL Server
It is possible to interoperate between PHP applications in a UNIX environment and
SQL Server databases using Microsoft® SQL Server functions or through an ODBC
interface. Each API has its own function calls to connect to the database and execute
statements. These APIs vary in support <strong>for</strong> common functions such as those related to
cursors and statements.
Case 1: Interoperating a PHP Application Using ORA
Functions
If the existing PHP solution uses ORA functions, then the best alternative is to replace
them with Microsoft SQL Server (MSSQL) functions. This modification will require
replacing the current driver with one that supports the MSSQL functions. One of the
drivers that can be used is FreeTDS (http://www.freetds.org).
FreeTDS is a set of libraries <strong>for</strong> UNIX and Linux that allows programs to interact with
Microsoft SQL Server. Using the FreeTDS libraries, PHP's mssql_xxx() functions can be
used to directly access a SQL Server database
from a UNIX or Linux computer. FreeTDS

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 241
is an open source implementation of the Tabular Data Stream protocol used by
SQL Server <strong>for</strong> its clients. The FreeTDS C libraries are freely available under the terms of
the GNU GPL license.
The protocol version also affects how database servers interpret commands. Microsoft
SQL Server 2000 is known to behave differently with versions 4.2 and 8.0 of FreeTDS.
version 8.0 is recommended <strong>for</strong> compatibility with SQL Server tools.
To interoperate a PHP application using ORA functionality, follow these
common steps:
1. Install the FreeTDS SQL Server libraries.
D ownload the source code from http://www.freetds.org/software.html. The
installation process is very similar to that detailed in Appendix D, "Installing
Common Drivers and Applications," except that the installation is occurring in UNIX
instead of Windows Services <strong>for</strong> UNIX.
Note FreeTDS should be compiled with the --enable-msdblib option.
2. Recompile PHP to use MSSQL functions.
Refer to http://www.free tds.org/userguide/php.htm <strong>for</strong> more in<strong>for</strong>mation on
compiling PHP.
Note PHP should be configured with the --with-mssql[=DIR] switch, where DIR is
the location of the FreeTDS libraries. For example, from the PHP source directory,
type:
./configure --with-mssql=/usr/local/freetds
3. Enable MSSQL functions.
Be<strong>for</strong>e MSSQL functions can be used, they must be enabled and initialized <strong>for</strong> use
by uncommenting or adding the following line in the initialization file php.ini.
extension=php_mssql.dll
4. Verify the installation.
Verify that the module i s installed by executing the phpinfo() function. MSSQL
should appear in the list of modules.
5. Change all embedded SQL statements to T-SQL.
Refer to chapter 11, "Developing: Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a
detailed discussion on modifying <strong>Oracle</strong> SQL to be SQL Server-compliant.
6. Modify the PHP application code.
The following sample sour ce code is used to illustrate the changes required when
migrating PHP code from ORA functions to MSSQL functions. Pay special
attention to the differences between these code sections.
Note MSSQL does not have functions to create and drop cursors. Implicit
cursors
are used to handle results returned.

242 Developing: Applications — <strong>Migrating</strong> PHP
The following example is sample ORA-based PHP code that executes a simple
query and retrieves results using a cursor operation:
The following example is the same code modified to MSSQL-based PHP code:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 243
$mycursor = mssql_query($sql);
// Display in<strong>for</strong>mation
while ($row = mssql_fetch_array($mycursor)){
echo "RESULT: " . $row['last_name'] . ", " . $row['salary'] . "\n";
}
// Close connection
mssql_close($conn);
?>
Database server in<strong>for</strong>mation can also be referenced from freetds.conf, as shown in
the following configuration in<strong>for</strong>mation.
/* freetds.conf
[SQLServer]
host = win2kss1
port = 1433
tds version = 8. 0
*/
To use the freetds.conf entry, the connection code will change as follows:
// specify path to file
putenv(FREETDSCONF=/usr/local/freetds.conf’)
$conn=mssql_connect(‘SQLServer’, $username, $password);
The following table provides a mapping between key ORA functions and the respective
MSSQL functions. ORA functions that do not have a matching MSSQL function are
denoted with a hyphen. A discussion of handling these disparate functions appears in the
"Common Function Translation Issues" section later in this chapter.
Table 13.1: Mapping Between ORA and MSSQL Functions
Operation Task ORA function MSSQL function
Connection Open connection ora_logon() mssql_connect()
Close connection ora_logoff() mssql_close()
Persistent ora_plogon() mssql_pconnect()
connection
Cursor
Open cursor ora_open() -
Close cursor ora_close() -
Pa rsing Parse statement ora_parse( ) -
Binding Bind variable ora_bind() mssql_bind()
Execution
Execute statement ora_exec() mssql_execute()
mssql_query()
Prepare and ora_do() mssql_execute()
execute
mssql_query()
Fet ching Fetch row
ora_fetch()
ora_fetch_into
mssql_fetch_row()
mssql_fetch_array()
Fetch column ora_getcolumn() mssql_fetch_field
Transaction
Commit
ora_commiton() -
Management
ora_commitoff()

244 Developing: Applications — <strong>Migrating</strong> PHP
Operation Task ORA function MSSQL function
ora_commit()
Rollback
ora_rollback() -
Error Handling Error checking ora_error()
-
ora_errorcode()
Others
Name of result ora_columnname() mssql_field_name()
column
Size of result ora_columnsize() mssql_field_length()
column
Datatype of result ora_columntype() mssql_field_type()
column
Number of rows
effected
ora_numrows() mssqp_num_rows()
Number of columns ora_numcols() mssql_num_fields()
returned
Case 2: Interoperating a PHP Application Using OCI8
Functions
To interoperate using OCI8, follow these common steps:
As with Case 1 "Interoperating a PHP Application Using ORA Functions", the best alternative
<strong>for</strong> OCI8 functions is to replace them with MSSQL calls. Most of the steps are the same
between this procedure and the p rocedure in the "Case 1: Interoperating a PHP Application
Using ORA F unctions" section of this scenario. As a result, these steps are not described in
detail here.
1. Install the FreeTDS SQL Server libraries.
2. Compile PHP to use MSSQL
APIs.
3. Enable MSSQL functions within php.ini.
4. Verify the installation using phpinfo().
5 . Change all embedded SQL statements to T-SQL.
Refer to Chapter 11, "Developin g: Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a
detailed discussion on modifying <strong>Oracle</strong> SQL to be SQL Server-compliant.
6. Modify application code to reflect the new drivers.
The following sample source code is used to illustrate the changes required in PHP
code when replacing OCI8 functions with MSSQL functions.
The following example is the original OCI8-based PHP code:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 245
$sql1 = OCIParse($conn, "INSERT INTO countries VALUES (‘US‘,‘United States of
America’, 2)");
OCIExecute($sql1);
// Insert SQL statement with binding
$var1 = ‘MX’;
$var2 = ‘Mexico”;
$var3 = 3;
$sql2 = OCIParse($conn, "INSERT INTO countries VALUES (:bind1, :bind2,
:bind3); ");
OCIBindByName($sql2, ":bind1", $var1);
OCIBindByName($sql2, ":bind2", $var2);
OCIBindByName($sql2, ":bind3", $var3);
OCIExecute($sql2);
echo OCIRowCount($sql2) . " rows inserted. ";
// Commit
OCICommit($conn);
// Close connection
OCILogoff($conn);
?>
The following example is the same PHP source code modified to use the MSSQL
drivers. Note the difference in the commit function.

246 Developing: Applications — <strong>Migrating</strong> PHP
// Close connection
mssql_close($conn);
?>
Table 13.2 maps the equivalent calls between OCI8 and MSSQL functions. A hyphen is
used when a similar function does not exist in MSSQL. A discussion on handling these
disparate functions is available in the "Common Function Translation Is sues" section later
in this chapter.
Table 13.2: Mapping Between OCI8 and MSSQL Functions
Operation Task OCI8 Functions MSSQL Functions
Connection Open connection ociLogon() mssql_connect()
Close connection ociLogoff() mssql_close()
Persistent ociPLogon() mssql_pconnect()
connection
Cursor Open cursor ociNewCursor() -
Close cursor ociFreeCursor() -
Statement Free statement oci_free_statement() mssql_free_statement()
Parsing Parse statement ociParse() -
Execution
Execute
ociExecute()
mssql_execute()
statement
mssql_query()
Fetching Fetch row ociFetch() mssql_fetch_row()
Transaction
Management
Commit
Rollback
ociCommit()
ociRollback()
-
-
Error Error checking ociError()
-
Handling
Others
Name of result ociColumnName() mssql_field_name()
column
Size of result ociColumnSize() mssql_field_length()
column
Datatype of ociColumnType() mssql_field_type()
result column
Number of rows ociRowCount() mssql_num_rows()
effected
Number of ociNumCols() mssql_num_fields( )
columns returned
Case 3: Interoperating a PHP Application Using
ODBC Functions
While migrating from <strong>Oracle</strong> to SQL Server, no cha nges will be needed to the ODBC
calls themselves; the availability of SQL Server-specific drivers <strong>for</strong> the UNIX environment
and the capabilities of the dr iver manager to work with these drivers define
the changes
that must be made. The best choice <strong>for</strong> interoperating with SQL Server is offered by the

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 247
FreeTDS driver, which is supported by the iODBC driver manager of the source
environment.
Other options available include Easysoft's ODBC-ODBC Bridge (OOB) and OpenLink's
Universal Data Access drivers.
To interoperate using ODBC functions, follow these common steps:
The following steps are required to interoperate PHP applications with SQL Server.
1. If needed, install ODBC software.
It is assumed that the iODBC driver manager is alre ady installed and is being used
to connect to <strong>Oracle</strong>. If this is not true, then either the iODBC or the unixODBC
driver manager must be installed.
The iODBC driver manager can be downloade d from
http://www.openlinksw.com/iodbc/. Installation instru ctions are available
in
Appendix D, "Installing Common Drivers and Applications."
The unixODBC driver manager can be downloaded from http://www.u nixodbc.org/ .
Installation instructions are also available in Appendix D, "Installing Common
Drivers and Applications."
2. Install the SQL Server driver.
The most popular ODBC driver to connect to SQL Server from a UNIX operating
system is FreeTDS. FreeTDS is an open source implementation of TDS that allows
UNIX-based programs native access to SQL Server. OpenLink also offers drivers
<strong>for</strong> SQL Server that use the FreeTDS implementation of TDS. Installation
instructions are located in Appendix D, "Installing Common Drivers and
Applications."
An ODBC-ODBC bridge to SQL Server is available from Easysoft. For detailed
instructions on enabling ODBC support under PHP, refer to
http://www.easysoft.com/produ cts/2002/apache.phtml.
OpenLink (http://www.openlinks w.com) also offers single-tier and multitier
Universal Data Access drivers.
3. Recompile PHP to use ODBC functions.
To be capable to use the SQL Server driver, PHP must be recompiled with ODBC
functions. This procedure will vary based on the ODBC driver that is installed.
Refer the following resources <strong>for</strong> more in<strong>for</strong>mation.
● FreeTDS — http: //www.freetds.org/userguide/php.htm
● Easysoft — http://www.easysoft.com/products/2002/apache.phtml
● OpenLink — http://docs.openlinksw.com
4. Configure the Data Source Name (DSN).
ODBC needs an ODBC data source to connect to the database. The DSN is
generally defined in an odbc.ini file that the driver manager uses to load the ODBC
driver.
When using FreeTDS, the DSN can also be configured by modifying the odbc.ini
file. A SQL Server DSN should be similarly configured to the following example.
[ODBC Data Sources]
SS_HR_DB=Sample MS SQLServer
[SS_HR_DB]
Driver=/usr/local/freetds/lib/libtdsodbc.so
Description=SQL Server 2000
Server=win2kdbp1

248 Developing: Applications — <strong>Migrating</strong> PHP
Port=1433
Database=hrapp
LogonID=daveb
Password=cougar
5. Check the connection.
In iODBC, the command line query program odbctest can be used to test the DSN
connectivity. If using unixODBC, the isql utility can be used to do this.
6. Modify the application source code to reflect the new data source.
Because ODBC is a generic interface to any database, no changes are required in
the application code except to connect to the SQL Server database. The proper
DSN has already been set up in an earlier step.
The following PHP code snippet uses the ODBC module to connect to an <strong>Oracle</strong>
data source, and it should be similar to code in the existing solution.
When migrated to connect to SQL Server, the connection string will reflect the
changes that follow.
Change all embedded SQL statements to T-SQL.
Refer to Chapter 11, "Developing: Applications — <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a
detailed discussion on modifying <strong>Oracle</strong> SQL to be SQL Server-compliant.
Table 13.3 is a listing of the ODBC function calls that are used in PHP code to work with
databases.
Table 13.3: ODBC Function Calls in PHP
Operation Task ODBC Function
Connection Open connection odbc_connect()
Open persistent connection odbc_pconnect()
Close connection
odbc_close()
Get connection in<strong>for</strong>mation odbc_data_source()
Parsing Prepare statement odbc_prepare()
Cursor Get cursor name odbc_cursor()
Execution Execute statement odbc_execute()
Prepare and execute odbc_exec()
odbc_do()

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 249
Operation Task ODBC Function
Fetching Fetch row odbc_fetch_row()
odbc_fetch_array()
odbc_fetch_into()
odbc_fetch_object()
Fetch column -
Transaction Management Commit odbc_commit()
Rollback
odbc_rollback()
Error Handling Error Checking odbc_error()
Get last error odbc_errormsq()
Others Name of result column odbc_field_name()
Name of table column odbc_columns()
Size of result column odbc_field_len()
Datatype of result column odbc_field_type()
Number of rows effected odbc_num_rows()
Number of columns odbc_num_fields()
returned
Common Function Translation Issues
Though SQL Server and <strong>Oracle</strong> share a great deal of functionality, some database
operations differ. This section discusses some of the differences between coding with
PHP extensions <strong>for</strong> <strong>Oracle</strong> and SQL Server.
Handling Transactions
The <strong>Oracle</strong> PHP extension module supports transactions using the following function
calls:
● ora_commit()
● ora_commitoff()
● ora_commiton()
● ora_rollback()
The OCI PHP extension module supports transactions using the following function calls.
● OCICommit()
● OCIRollBack()
MSSQL API does not provide commit or rollback functions. These functions can be
achieved using the following example code:
// Here $db is a PHP variable <strong>for</strong> connection object
//To begin transaction
$sql = "begin tran";
$result
= mssql_query($sql,$db);
//To commit transaction
$sql = "commit tran";
$result = mssql_query($sql,$db);

250 Developing: Applications — <strong>Migrating</strong> PHP
//To rollback transaction
$sql = "rollback tran";
$result = mssql_query($sql,$db);
<strong>Migrating</strong> Cursors
$conn=mssql_connect("myhost","user","pwd");
mssql_select_db("hr",$conn);
// create the select statement
$sqlquery="SELECT companyName FROM Customers;";
// activate the query and retrieve the result set
$results= mssql_query($sqlquery);
// Do a row fetch from the result set <strong>for</strong> display
while ($row=mssql_fetch_array($results)){
echo $row['companyName']."\n";
}
<strong>Oracle</strong> requires using cursors with SELECT statements, regardless of the number of
rows requested from the database. In SQL Server, a SELECT statement that is not
disclosed on a cursor returns rows to the client as a default result set. This is an efficient
way to return data to a client application.
When porting a PL/SQL procedure from <strong>Oracle</strong>, first determine whether cursors are
needed to per<strong>for</strong>m the same function in Transact-SQL. If the cursor is used only to return
a set of rows to the client application, use a non-cursor SELECT statement in Transact-
local procedure variables, use cursors in Transact-SQL.
Unlike <strong>Oracle</strong> and OCI8 (which have methods <strong>for</strong> explicit use of cursors), MSSQL uses
SQL to return a default result set. If the cursor is used to load data a row at a time into
implicit cursors. Functions such as mssql_query() and mssql_execute() associate a
handle to the returned result, which can be traversed similar to an explicit cursor. The
following code shows the use of result set to achieve the same functionality as that of a
cursor.
SQL Server cursors may also be used <strong>for</strong> one of the following reasons:
● Updateable cursors
● Scrollable, read-only cursors
Note ODBC Cursor Library cursors build on top of default result sets. Be sure to fetch
to the end of the result set quickly to free up locks.
When you use server cursors, use SQLExtendedFetch to fetch in blocks of rows
instead of a single row at a time. This is the same thing as array-type fetching in
<strong>Oracle</strong>. This saves on round-trip fetches to the server. For more in<strong>for</strong>mation on
SQLExtendedFetch, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/odbc/htm/odbcsqlextendedfetch.asp.
Use result sets when you think it will fetch all rows at one time, but use server cursors
when
you know a result set would not fetch all rows at once.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 251
Connection Pooling
While PHP does not offer connection pooling, persistent <strong>Oracle</strong> connections can
opened with the following API function calls.
● <strong>Oracle</strong> API: ora_plogon()
● OCI8 API: ociPLogon()
To interoperate with SQL Server, these functions should be replaced by one of the
following functions, depending upon the API used:
● ODBC API: odbc_pconnect()
● MSSQL API: mssql_pconnect()
Unlike connection pooling, a persistent connection is local to a process and cannot be
shared between different processes.
Stored Procedures
Sto red procedures can be handled by the MSSQL API as well as the ORA and OCI8
APIs. The following example shows sample stored procedures using MSSQL calls.
// Create Query <strong>for</strong> Stored Procedure In Code
// Stored procedure name: CustOrdersDetail from Northwind database
$stmt = mssql_init("CustOrdersDetail",$conn);
be
mssql_select_db("Northwind", $conn);
// Parameter values
$orderid = 1;
// Binding parameter value to stored procedure
mssql_bind($stmt, "@OrderID", $orderid, SQLINT4);
// Execute SQL Statement & Capture Results
$result = mssql_execute($stmt);
// Fetch return data and place into array <strong>for</strong> access
while($row = mssql_fetch_array($result)){
// Assign Variables
$unitprice = $row["UnitPrice"];
echo "Unit Price" . $unitprice;
$quantity = $row["Quantity"];
echo "Quantity" . $quantity;
$discount = $row["Discount"];
echo "Discount" . $discount;
$price = $row["ExtendedPrice"];
echo "Price" . $price;
}

252 Developing: Applications — <strong>Migrating</strong> PHP
Scenario 2: Porting the Application to Win32
Because PHP is a cross-plat<strong>for</strong>m language, porting applications from a UNIX
environment to Windows is not much more complex than the steps required <strong>for</strong>
interoperation. The strategy, steps, and actual changes required are very similar to those
discussed <strong>for</strong> interoperation. The only additional step is installing PHP and the application
code in the Windows environment.
Case 1: Porting a PHP Application using ORA Functions
Most of the following steps are covered in more detail in the "Case 1: Interoperating a
PHP Application Using ORA Functions" section of Scenario 1.
To port the application using ORA functions, follow these common steps:
1. Install PHP on target Windows server.
For more in<strong>for</strong>mation on installing PHP, refer to
http://uk2.php.net/manual/en/install.php.
2. Install SQL Server libraries.
Instead of the FreeTDS libraries, the Windows-based libraries offered by Microsoft
in SQL Client Tools can be installed on the system where PHP is installed. The
Client Tools can be installed from the MS SQL Server CD or by copying
ntwdblib.dll from \winnt\system32 on the server to \winnt\system32 on the target
Windows server. However, copying ntwdblib.dll will only provide access.
Configuration of the client will require installation of all the tools.
3. Compile PHP to use the MSSQL module.
4. Enable MSSQL functions in php.ini.
5. Verify the installation using phpinfo().
6. Transport source code to target server.
7. Modify the application's source code to reflect the MSSQL API instead of ORA
functions..
Case 2: Porting a PHP Application Using OCI8 Functions
Most of the steps needed to migrate this application are discussed in more detail in the
"Case 2: Interoperating a PHP Application Using OC18 Functions" section of Scenario 1.
The following steps are required to migrate PHP applications to Windows using OC18
functions.
To port the application using OCI8 functions, follow these common steps:
1. Install PHP on target Windows server.
2. Install SQL Server libraries from SQL Client Tools.
3. Compile PHP to use the MSSQL module.
4. Enable MSSQL functions in php.ini.
5. Verify the installation using phpinfo().
6. Transport the source code to the target Windows server.
7. Modify the application code to reflect the MSSQL API instead of OCI functions.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 253
Case 3: Porting a PHP Application Using ODBC Functions
Most of the steps listed as follows are discussed in more detail in the "Case 3:
Interoperating a PHP Application Using ODBC Functions" section of scenario 1. The
following steps are required to migrate PHP applications to Windows using ODBC
functions.
To port the application using ODBC functions, follow these common steps:
1. Install PHP on target Windows server.
2. Install ODBC software.
For installation instructions, refer to
http://support.microsoft.com/default.aspx?scid=kb;en-us;313008.
3. Install the SQL Server driver.
In addition to the drivers mentioned <strong>for</strong> interoperation, the Microsoft ODBC driver
<strong>for</strong> SQL Server may also be used. This driver is available along with the
SQL Server client CD. Installation instructions are available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/howtosql/ht_install_029l.asp.
4. Compile PHP to use ODBC in the php.ini file.
5. Configure the DSN to connect with the SQL Server database.
6. Check the connection using command line utilities.
7. Transport the source code to the target Windows environment.
8. Modify the application source code to reflect the MSSQL API.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 255
14
Developing: Applications —
<strong>Migrating</strong> Java
Introduction and Goals
This chapter contains a detailed discussion of changes that must be made to Java
applications when the database is migrated from <strong>Oracle</strong> to Microsoft® SQL Server. At
the conclusi on of this chapter, the Java application should be capable to successfully
connect to t he SQL Server database that was migrated from <strong>Oracle</strong>. The solution can
then be tested.
Java is a po rtable language. The capability <strong>for</strong> the Java programming language to
interact with an RDBMS such as <strong>Oracle</strong> and SQL Server is provided by the Java
Database Connectivity (JDBC) API. Applications written in Java can execute SQL
statements, retrieve results, and propagate changes back to the underlying data source
using the JDBC API.
The combination of the Java plat<strong>for</strong>m and JDBC API allows a program to operate on a
number of plat<strong>for</strong>ms, and with any number of SQL-supported databases, without
modifying the source code.
When migrating from an <strong>Oracle</strong> to a SQL Server environment, there will still be some
alterations made to the application. These basic changes will need to be made whether
the Java application interoperates with SQL Server from a UNIX environment, or if the
Java application is ported to Windows®.
As discussed in the "Define the <strong>Solution</strong> Concept" section of Chapter 2, "Envisioning
Phase," there are four different strategies available <strong>for</strong> transitioning applications in an
<strong>Oracle</strong> to SQL Server migration project. The strategies are:
● Interoperate the application with UNIX
● Port or rewrite the application to the Microsoft .NET plat<strong>for</strong>m
● Port or rewrite the application to the Microsoft Win32® plat<strong>for</strong>m
● Quick p ort using the Microsoft Windows Services <strong>for</strong> UNIX 3.5 plat<strong>for</strong>m
Because of some of the unique characteristics of Java, some of these strategies are
more logical than others. For instance, because Java can be ported to Windows, there is
no need to rewrite the application in the .NET framework or <strong>for</strong> the Win32 environment.

256 Developing: Applications — <strong>Migrating</strong> Java
Based on the available migration strategies, two scenarios can be developed to migrate
the Java application. These scenarios are:
● Scenario 1: Interoperating Java on UNIX with SQL Server
If the business requirements do not include eliminating the UNIX environment, an
interoperation strategy can be implemented quickly. Few, if any, changes need to
be made to the source code and it may be necessary to install a new driver to
allo w the Java application to connect to a SQL Server database. If the migration is
per<strong>for</strong>med in phases or <strong>for</strong> multiple applications, interoperation can be used as an
interim step.
● Scenario 2: Porting the Application to Win32
Java applications can also be ported to run natively on the Windows plat<strong>for</strong>m. As
with interoperation, few changes need to be made to the source code.
Scenario 1: Interoperating Java on UNIX with
SQL Server
Interoperation between a UNIX-based Java application and a SQL Server database is
possible because of the availability of a driver that interfaces between these
technologies. The JDBC driver provides the cross-RDBMS connectivity needed.
Case 1: Interoperating a Java Application Using the JDBC
Driver
Because of the construction of the JDBC API, which exposes a common set of methods
that are not affected by the change of source database, this type of migration is usually a
simple process. Most changes made relate to the connectivity.
To interoperate a Java application using the existing JDBC driver, follow
these steps:
1. Evaluate the current driver.
Be<strong>for</strong>e beginning the migration process, evaluate the existing JDBC driver that is in
use and its capability to operate with SQL Server. Some considerations include:
● Will the current JDBC driver interoperate with SQL Server? If this in<strong>for</strong>mation is
not known, check with the vendor. Sun Microsystems also maintains a
database of SQL Server compliant JDBC drivers. For more in<strong>for</strong>mation, refer
to http://servlet.java.sun.com/products/jdbc/drivers.
● If the current JDBC driver will interoperate with SQL Server, what are the
per<strong>for</strong>mance characteristics of the driver in the SQL Server environment?
Try to per<strong>for</strong>m prototype tests of the driver to ensure that the level of
per<strong>for</strong>mance is acceptable.
● What features of the driver are utilized by the Java application, and are
these supported <strong>for</strong> SQL Server? For more in<strong>for</strong>mation on specific Java
extensions used by your JDBC driver, refer to your vendor documentation.
● What type of JDBC driver is required (Type 1, 2, 3, 4)?
If a new driver is needed, there are several different JDBC drivers
commercially available. Each has slightly different features and characteristics.
Some commonly used JDBC drivers include:
● JSQLConnect from JNetDirect, which is available at
http://www.jnetdirect.com/products.php?op=jsqlconnect.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 257
●
SQL Server 2000 Driver <strong>for</strong> JDBC. Microsoft offers this native driver which
will work on both UNIX and Windows. This driver is available at
http://www.microsoft.com/downloads/details.aspx?FamilyId=07287B11-
0502-461A-B138-2AA54BFDC03A&displaylang=en.
2. Determine how the application connects to the data source. Connections can be
achieved using the DriverManager class or with a datasource implementation.
●
If connectivity is obtained using the DriverManager class, two changes are
needed to connect with the SQL Server database. These changes are:
● Loading the JDBC driver
● Making the connection
The following example shows these changes:
// Loading the driver
Class.<strong>for</strong>Name("DriverClassName");
// Making the Connection
String url = "jdbc:odbc:DSN";
String user = "sUser";
String password = "sPwd";
Connection con = DriverManager.getConnection(url, user, password);
//……………
//…………
// Closing the Connection
con.close();
In this example code, the URL uses the syntax
jdbc::. Using the connection object con, you can
create JDBC statements and pass them to the RDBMS.
●
If connectivity is obtained through a datasource, the application server should
be appropriately configured.
Be<strong>for</strong>e using a datasource object, it must be deployed. The following list
describes the deployment steps:
1. Create an instance of the DataSource class.
2. Set the datasource properties.
3. Register the datasource with a naming service that uses the Java Naming
and Directory Interface (JNDI) API.
Datasource deployment is usually per<strong>for</strong>med by the system administrator.
A JDBC driver that supports JDBC 2.0 API will provide different types of
datasource implementations which can be used <strong>for</strong> connection pooling and
distributed transactions.
To obtain connectivity, the Java application per<strong>for</strong>ms a lookup of the
logicalName. This in<strong>for</strong>mation can be retrieved by passing the user name
and password through the getConnection() method. An example of this
method is presented as follows:
Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("jdbc/dbServer");
Connection con = ds.getConnection("sUser", "sPwd");
3. Configure the application server.
If third-party JDBC drivers are used to connect to SQL Server, the drivers must be
set in the CLASSPATH variable so the driver classes can be loaded. The JDBC

258 Developing: Applications — <strong>Migrating</strong> Java
driver installed <strong>for</strong> SQL Server will install a driver jar file, which contains driver
classes <strong>for</strong> the database interaction. If the jar file is missing in the classpath, then
the application will flag a 'class not found' exception.
Based on the application's architecture, the CLASSPATH must be set. The syntax
of this setting can vary between applications, servlets, JSPs, EJBs, and applets.
a. For applications run directly from the operating system prompt, make sure that
the driver can be found in the system's CLASSPATH. This can be per<strong>for</strong>med
by moving the file to its original location, which is already listed in the
classpath, or adding the driver's current location to the CLASSPATH.
b. For applications run within the IDE, the driver classpath has to be set in the
vendor's IDE classpath. Refer to your vendor’s IDE documentation.
c. For servlets and JSPs run within a servlet/JSP engine such as Tomcat, the
classpath can be set in the vendor's classpath setup screens or by copying the
driver jar file into the LIB folder of the engine’s installation.
d. For EJBs, the JDBC driver jar file should also be set in the EJB vendor's
classpath.
e. For applets that run within a Web browser, copy the JDBC driver jar to the
Web server root and specify the driver jar file in the applet’s HTML archive tab.
The following HTML code example shows this option used on an applet tag.
4. If the SQL statements passed to the JDBC methods use any <strong>Oracle</strong>-specific
syntax, then these items will need to be updated to reflect T-SQL syntax. Migration
of PL/SQL to T-SQL is covered in detail in Chapter 11, "Developing: Applications
— <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL."
5. The metadata in<strong>for</strong>mation returned by the metadata methods should refer to
SQL Server and the new JDBC Driver.
To discover in<strong>for</strong>mation about a database, a DatabaseMetaData object must be
obtained. ResultSetMetaData provides in<strong>for</strong>mation about the ResultSet, such as
number of columns returned, an individual column's suggested display size,
column names, and column types. If any of these metadata are used in the
application, they have to be validated <strong>for</strong> integrity of the return values.
To discover in<strong>for</strong>mation about a database, a DatabaseMetaData object must be
obtained. The getMetaData method on the Connection object returns a
DatabaseMetaData object.
DatabaseMetaData dbmd = con.getMetaData();
ResultSetMetaData provides in<strong>for</strong>mation about the ResultSet. Use the
getMetaData method on the resultSet to get the ResultSetMetaData.
ResultSetMetaData rsmd = rs.getMetaData();
6. After the application changes are complete, create a new release build and fully
test the application.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 259
Scenario 2 —
Porting the Application to Win32
Java is portable, so when the application is migrated to Windows, the Java language
features remain the same. Changes should be minimal. Most of the changes listed in the
following procedure are similar to those per<strong>for</strong>med under the interoperation scenario
described in the "Scenario 1: Interoperating Java on UNIX with SQL Server " section
earlier in this chapter.
To port the application to Win32, follow these common steps:
1. Install Java on the Windows server.
If the migration path includes porting the Java application to the Windows
environment, then the Java application server should be installed on Windows.
Ensure that the hardware satisfies the installation prerequisites <strong>for</strong> the application
server.
2. Determine if the existing JDBC driver will per<strong>for</strong>m the needed functions, or if a new
JDBC driver will be required.
3. Configure the application server <strong>for</strong> use with Windows. Update the path and
classpath in<strong>for</strong>mation.
4. Test the installation of the application server using the test utility provided with the
application server.
5. Determine how the application connects to the data source.
SQL Server has two types of authentication, Windows authentication and
SQL Server authentication. When the application exists on the UNIX plat<strong>for</strong>m, the
Windows authentication method is not possible without the installation of additional
software such as the Vintela Authentication Services (VAS) product from Vintela
(http://www.vintela.com/products/vas/). However, with the application migrated to
the Windows plat<strong>for</strong>m, the Windows authentication feature of SQL Server can be
taken advantage of.
Windows authentication is specified using the connection property
trustedAuthentication. The property may be set in either a driver manager
connection string or a datasource. There is no need to specify the user and
password properties when using trusted authentication.
Windows authentication can be used by the JDBC clients on Windows only.
6. Move the Java code from UNIX to Windows. All the files and folders which the
Java application interacts with should be migrated to Windows. Make sure that the
paths in the Java application and the configuration files point to the corresponding
folders in the Windows file system. If the Java application uses any native code
written in other languages, then that code also has to be migrated to Windows.
7. <strong>Oracle</strong>-specific SQL and stored programs will need to be rewritten in T-SQL
syntax. Migration of PL/SQL to T-SQL is covered in detail in Chapter 11,
"Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL."
8. The metadata in<strong>for</strong>mation returned by the metadata methods should refer to
SQL Server and the new JDBC Driver.
9. After the application changes are complete, create a new release build and fully
test the application.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 261
15
Developing: Applications —
<strong>Migrating</strong> Python
Introduction and Goals
This chapter contains a detailed discussion of changes that must be made to existing
Python applications to work with Microsoft® SQL Server. At the conclusion of this
chapter, the Python application should be capable to successfully connect to the
SQL Server database that was migrated from <strong>Oracle</strong>. The solution can then be tested.
As discussed in the "Define the <strong>Solution</strong> Concept" section of Chapter 2, "Envisioning
Phase," there are four different strategies available <strong>for</strong> transitioning applications in an
<strong>Oracle</strong> to SQL Server migration project. The strategies are:
● Interoperate the application with UNIX
● Port or rewrite the application to the Microsoft .NET plat<strong>for</strong>m
● Port or rewrite the application to Microsoft Win32® Plat<strong>for</strong>m
● Quick port using the Microsoft Windows® Services <strong>for</strong> UNIX 3.5 plat<strong>for</strong>m
Pyt hon is a portable, plat<strong>for</strong>m-independent, and general-purpose language with support
<strong>for</strong> writing database client applications. Database capabilities are modularized, and they
can be augmented through the use of additional APIs.
Python database modules that are based on the Database API (DB-API) specification
can be used to access relational databases, including SQL Server and <strong>Oracle</strong>. As long as
the data base module used to access the <strong>Oracle</strong> database adheres to the DB-API
specification, porting to SQL Server is straight<strong>for</strong>ward and can be done with minimal
changes. If the existing database drivers do not meet DB-API specifications, the driver
will need to be replaced and configured.
Because of the cross-plat<strong>for</strong>m capabilities and the use of modular database drivers,
some of the migration strategies are more feasible than others. For example, because
Python can be ported to Windows, there is no need to rewrite the application in the .NET
framework or <strong>for</strong> the Win32 environment. Also, because the application can run within the
Windows environment, a quick port using Windows Services <strong>for</strong> UNIX is not necessary in
most cases.
Based on the available migration strategies, two scenarios can be developed to migrate
the Python application. These scenarios include:

262 Developing: Applications — <strong>Migrating</strong> Python
●
●
Scenario 1: Interoperating Python on UNIX with SQL Server
If the business requirements do not include eliminating the UNIX environment, an
interoperation strategy can be implemented quickly. Few changes need to be
made to the source code, and installing a new driver allows the Python application
to connect to a SQL Server database. Interoperation can also be used as an
interim step, if the migration is per<strong>for</strong>med in phases.
Scenario 2: Port the Python Application to Win32
Python applications can also be ported to run natively on the Windows plat<strong>for</strong>m. As
with interoperation, few changes need to be made to the source code. These
changes are usually related to connectivity issues.
Note: If your Python applications use UNIX system calls extensively (such as
frequently calling exec), porting them to Windows Services <strong>for</strong> UNIX/Interix may be a
suitable option because Interix has more support <strong>for</strong> the desired system calls. Chapter
2, " Envisioning Phase," provides a more detailed discussion of when choosing
Windows Services <strong>for</strong> UNIX would be more appropriate when moving to a Windowsbased
plat<strong>for</strong>m.
You will need the following to implement this option (porting Python applications to
SFU/SQL Server):
● A port of Python <strong>for</strong> interix has been made available by Interop Systems and can
be downloaded from http://www.interopsystems.com/tools/warehouse.htm.
● A c onnectivity driver to the SQL Server database. This is provided by the port of
FreeTDS on Interix and is downloadable from Interop Systems at
http://www.interopsystems .com/tools/db.htm. FreeTDS provides two connectivity
options <strong>for</strong> the Python applications to connect to the SQL Server database. One is
a library called CTlib, The other is an ODBC driver.
● If you chose the CTLib option <strong>for</strong> your database connectivity driver, you will need
the Sybase Connectivity Module <strong>for</strong> your Python application to make appropriate
calls to CTLib. The source code <strong>for</strong> this Sybase Connectivity Module can obtain
from Object Craft at http://www.object-craft.com.au/projects/sybase/ . This solution
is not available pre-compiled from Interop Systems but is a simple port <strong>for</strong> a UNIX
developer.
● If you chose ODBC <strong>for</strong> your database connectivity, you will need an additional
interface <strong>for</strong> the Python application to make ODBC calls. This is available as a
commercial package called mxODBC and can be obtained from
http://www.egenix.com.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 263
● If you use the ODBC driver, you will also need an ODBC driver manager. Two
different ODBC driver managers iODBC and unixODBC are available <strong>for</strong>
Windows Services <strong>for</strong> UNIX from
http://www.interopsystems.com/tools/warehouse.htm.
This technology option (porting Python applications to SFU), however, has not been
fully tested as a part of development of this solution and there<strong>for</strong>e has not been
detailed further.
Scenario 1: Interoperating Python on UNIX with
SQL Server
Two com mon modules used <strong>for</strong> connecting a Python application to an <strong>Oracle</strong> database in
the UNIX environment are:
● DC<strong>Oracle</strong>2
● mxODBC
DC<strong>Oracle</strong>2 (http://www.zope.org/Products/DC<strong>Oracle</strong>/) does not support SQL Server, but
mxODBC ( http://www.egenix.com/) supports the ODBC interface and can be used with
SQL Server. If the existing application uses DC<strong>Oracle</strong>2, this interface will need to be
replaced to allow connectivity with SQL Server.
Because ODBC is not database-specific, only minor modifications are needed to connect
to the migrated database.
Case 1: Interoperating Using the mxODBC Module
To interoperate a Python-based application using DC<strong>Oracle</strong>2 module with
SQL Server, follow these steps:
Note that these steps assume that a DC<strong>Oracle</strong>2 module will be replaced with the mxODBC
module.
1. Install the ODBC driver.
In order <strong>for</strong> mxODBC to connect to SQL Server, an ODBC driver manager must be
installed. Two available driver managers are:
● iODBC, available at http://www.iodbc.org/.
● DataDirect ODBC <strong>for</strong> UNIX Plat<strong>for</strong>ms, available at
http://www.datadirect.com/techzone/use_case/odbc-unix-sqlservermain/index.ssp.
For detailed installation instructions, refer to
http://www.datadirect.com/techzone/use_case/odbc-unix-sqlserverinstall/index.ssp.
2. Install the mxODBC module based on the Python version being used.
For installation instructions, refer to http://www.egenix.com/files/python/mxODBC-
Zope-DA.html#Installation.
3. Configure the ODBC driver to work with mxODBC through the driver manager.
4. Create a SQL Server data source.
To function, ODBC needs a data source to connect to the database. The Data
Source Name (DSN) is generally defined in an odbc.ini file that is used by the
driver ma nager. The DSN is used by the driver manager to load the ODBC driver.
iODBC offers a graphical user interface to set up the DSN. Complete instructions
are available at http://www.iodbc.org/index.php?page=docs/odbcstory.

264 Developing: Applications — <strong>Migrating</strong> Python
The DSN can also be configured by manually modifying the odbc.ini file. The
following example file uses a SQL Server DSN.
[ODBC Data Sources]
SS_ HR_DB=Sample MS SQLServer
[SS_HR_DB]
Driver=/opt/odbc/lib/mxODBC.so
Description=SQL Server 2000
Database=hrapp
LogonID=daveb
Password=cougar
Address=win2kdbp1,1433
5. Test the connectivity.
iODBC contains a utility named odbctest which can be used to test DSN entries
and interact with the database by connecting and issuing queries directly without
any code.
The mxODBC package consists of a test script that can also be used to verify the
database connectivity. To per<strong>for</strong>m the test, execute the following command:
python mx/ODBC/Misc/test.py
6. Modify the application to use mxODBC instead of the existing DC<strong>Oracle</strong>2 API.
Note The examples in this section use the iODBC driver. Syntax may vary slightly
based on the ODBC driver that is used in your solution.
There are several, minor changes that may need to be made to the existing Python
application to allow connectivity with the SQL Server database. These common
issues that should be modified include:
● Import statements
The import statement, generally found at the head of the application code,
should be modified to include the new database module.
If the application currently uses the DC<strong>Oracle</strong>2 module, the import statement is
as follows:
●
import DC<strong>Oracle</strong>2
This entry should be modified to allow <strong>for</strong> the mxODBC module. The import
statement should be changed as follows:
import mx.ODBC.iODBC
Connection objects
The connection object will also need to be modified to point to the new data
source. The current entry should be similar to the following example:
db = DC<strong>Oracle</strong>2.Connect('scott/tiger@orahrdb')
This entry should be modified to reflect the new data source. In the following
example, the DriverConnect() API is used to pass additional in<strong>for</strong>mation to
SQL Server.
db = mx.ODBC.iODBC.DriverConnect('DSN=sqlserverDSN;UID=scott;PWD=tiger')
This iODBC string will have to be modified based on the driver manager in use.
There are other connection methods, such as ODBC() and connect(), which
are also supported by mxODBC. The advantage with DriverConnect() is that it
allows more configuration in<strong>for</strong>mation, such as the log file name, to be passed
as part of the connection string.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 265
●
Cursor Execution
Change the cursor object execute() and executemany() method calls to use a
question mark (?) <strong>for</strong> parameters instead of numeric parameters (:1) or named
parameters (:column_name). The following example should be similar to your
existing Python code being used with <strong>Oracle</strong>.
c = db.cursor()
custId = "ALFKI"
c.execute("Select * from customers where customerID = :1", custId)
...
id = "123"
name = "Bill"
desc = "CoffeeShop"
●
c.execute("insert into categories " + \
" (categoryid, categoryName, description)" + \
"values (:cid,:cname,:cdesc)" \
,cid = id , cname = name ,cdesc= desc \
)
The code should be modified <strong>for</strong> use with SQL Server. In the following code,
note that numeric and named parameters have been replaced.
c= db.cursor()
custId = "ALFKI"
c.execute("Select * from customers where customerID = ?",(custId,))
...
id = "123"
name = "Bill"
desc = "CoffeeShop"
c.execute("insert into categories" + \
" (categoryid, categoryName, description)" + \
"values (?,?,?)" \
,(id, name, desc) \
)
Cursors — multiple executions
The executemany() function is used with DC<strong>Oracle</strong>2 to per<strong>for</strong>m multiple inserts
with a single call by passing a list of parameters. For example,
cursor.executemany("insert into inventoryinfo values (:1,:2)",\
[('Bill','Dallas'),('Bob','Atlanta'),('David','Chicago'), \
('Ann','Miami'),('Fin','Detroit'),('Paul','Dallas'),\
('Scott','Dallas'),('Mike','Dallas'),('Leigh','Dallas')])
For using multiple cursors on a connection to SQL Server, use the
setconnectoption() method to set the SQL.CURSOR_TYPE to
SQL.CURSOR_DYNAMIC as shown as follows and replace the parameter
specification style in the executemany() call:
# Connect to the database
db = mx.ODBC.iODBC.DriverConnect('DSN=sqlserverDSN;UID=scott;PWD=tiger'
# Set SQL Server connection option
DB.setconnectoption(SQL.CURSOR_TYPE, SQL.CURSOR_DYNAMIC)
cursor = db.cursor ()
cursor.executemany("insert into inventoryinfo values (?,?)",\
[('Bill','Dallas'),('Bob','Atlanta'),('David','Chicago'), \

266 Developing: Applications — <strong>Migrating</strong> Python
●
('Ann','Miami'),('Fin','Detroit'),('Paul','Dallas'),\
('Scott','Dallas'),('Mike','Dallas'),('Leigh','Dallas')])
Stored Procedures
The DB API 2.0 callProc() method <strong>for</strong> executing stored procedures is not
implemented in mxODBC. To overcome this deficiency, a stored procedure
can be executed similar to a SQL statement using one of the execute methods.
However, a requirement in this case is that the stored procedure returns some
result. All calls to callProc() need to change to use cursor.execute, as shown
in the following example:
c.execute("{call proc_name(?,?)}", (1,2)})
7. Change all embedded SQL statements to T-SQL.
This is a step common to all migrations. Refer to Chapter 11, "Developing:
Applications — <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL," <strong>for</strong> a detailed discussion on
modifying <strong>Oracle</strong> SQL to be SQL Server-compliant.
Scenario 2: Port the Python Application to Win32
Because Python is a cross-plat<strong>for</strong>m language, porting applications from a UNIX
environment to Windows is not much more complex than the steps required <strong>for</strong>
interoperation. The API used in the discussion on porting to the Windows environment is
the mxODBC. The strategy, steps, and actual changes required are very similar to those
discussed <strong>for</strong> interoperation. Zope offers an ADO adapter <strong>for</strong> SQL Server on the
Windows plat<strong>for</strong>m which can give better per<strong>for</strong>mance than the use of ODBC. Details on
this can be obtained from http://zope.org/Members/freiser/ZADODA.
Case 1: Porting a Python Application using mxODBC
Most of the following steps are covered in more detail in the "Case 1: Interoperating
Using the mxODBC Module" section discussed in scenario 1.
To port the application to Windows, follow these steps:
1. Download Python <strong>for</strong> Windows from http://www.python.org.
2. Install Python on Windows.
3. Add the Python folder to the Windows CLASSPATH environment variable.
4. Install the appropriate mxODBC <strong>for</strong> the version of Python installed.
5. Create an ODBC DSN <strong>for</strong> the target database.
Create an ODBC data source to connect to SQL Server. After the DSN is created,
a Python application using mxODBC can connect to SQL Server and run queries.
6. Transport source code to the target server.
7. Update the application code.
If your application uses DC<strong>Oracle</strong>2, then the application changes required will be
similar to those discussed in the "Scenario 1: Interoperating Python on UNIX with
SQL Server" section earlier in this chapter. Some variations based on the Windows
environment include the import statement and the connection object as shown in
the following examples.
● The import statement should be changed from:
import DC<strong>Oracle</strong>2
to
import mx.ODBC.Windows

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 267
●
The connection object must be initialized as in the following example:
db = mx.ODBC.Windows.DriverConnect('DSN=sqlserverDS')
Note This DSN uses Windows Authentication Mode to connect to SQL Server.
8. Change all embedded SQL statements to T-SQL.
This is a step common to all migrations. Refer to Chapter 11, "Developing:
Applications— <strong>Migrating</strong> <strong>Oracle</strong> SQL and PL/SQL" <strong>for</strong> a detailed discussion on
modifying <strong>Oracle</strong> SQL to be SQL Server-compliant.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 269
16
Developing: Applications —
<strong>Migrating</strong> <strong>Oracle</strong> Pro*C
Introduction and Goals
Thir d generation languages (3GL) such as C and C++ do not have the capability to
interface with databases. Databases can only communicate using the SQL fourth
generation language (4GL). Using embedded SQL allows a database to interface directly
with the 3GL languages. Pro*C is <strong>Oracle</strong>'s proprietary interface to the C language which
permits the use of embedded SQL.
As discussed in the "Define the <strong>Solution</strong> Concept" section of Chapter 2, "Envisioning
Phase," there are four different strategies available <strong>for</strong> transitioning applications in an
<strong>Oracle</strong> to Microsoft® SQL Server migration project. The strategies are:
● Interoperate the application with UNIX
● Port or rewrite the application to the Microsoft .NET plat<strong>for</strong>m
● Port or rewrite the application to the Microsoft Win32® plat<strong>for</strong>m
● Quick port using the Microsoft Windows® Services <strong>for</strong> UNIX 3.5 plat<strong>for</strong>m
Because Pro*C is specific to <strong>Oracle</strong>, migration strategies are limited. Interoperation and
porting cannot be utilized because no methods exist that allow Pro*C to communicate
with SQL Server. A complete rewrite is the only option.
This chapter focuses on the preferred scenario that can be used in Pro*C application
migrations: Scenario 1: Rewriting the application to the .NET plat<strong>for</strong>m.
Rewriting an application is a challenging endeavor because a one-to-one mapping from
the source environment to the target environment is very difficult to achieve. When an
application is rewritten, there is always a risk that some functionality from the original
application may be lost during the transition. Commonly, Pro*C programs are procedural
and do not have a graphical user interface. <strong>Migrating</strong> procedural code is easier than
migrating GUI-based applications. Extensive testing needs to be per<strong>for</strong>med on the
rewritten application to ensure that all of the business logic and functionality has
accurately been recreated.
This chapter only discusses the trans<strong>for</strong>mation that needs to occur to the most common
database-related components when rewriting a Pro*C application <strong>for</strong> the .NET
environment. A comprehensive study of the entire rewrite is beyond the scope of this
guidance.

270 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Pro*C
Understanding the Technology
Pro*C is available on the Windows plat<strong>for</strong>m. Un<strong>for</strong>tunately, there are no methods
available to allow Pro*C code to interface with SQL Server. Microsoft offers a product
similar to Pro*C called Embedded SQL <strong>for</strong> C (ESQL/ C) which allows Transact-SQL
statements to be embedded in C language programs. ESQL/C can be used as the target
language <strong>for</strong> rewriting Pro*C programs because of its close resemblance to Pro*C.
However, using this language is not recommended because Microsoft no longer develops
this product, and future versions of SQL Server will not support ESQL/C.
Visual Basic .NET is recommended <strong>for</strong> rewriting the application. Visual Basic .NET
provides a robust scripting language and can easily be interfaced with SQL Server.
When migrating the database from <strong>Oracle</strong> to SQL Server, the Pro* C code and its
interactions with <strong>Oracle</strong> should be examined to ensure that the functions can be
recreated in the rewritten application.
Understanding Pro*C
Be<strong>for</strong>e the application can be rewritten, you must evaluate the functionality currently
provided by the Pro*C application. While the computational and business logic is
provided by the host C language, Pro*C provides the syntax to implement the database
transactions. The embedded SQL in Pro*C offers the following functionality that will have
to be migrated:
● Connect to and maintain a connection to <strong>Oracle</strong> database.
● Declare, open, and use cursors to manipulate data.
● Interact with <strong>Oracle</strong> databases through SQL statements.
● Provide mechanisms (host variables) to interface between the host code and the
database code.
● Close any open cursors.
● Handle any database exceptions.
● Close the connection to the database.
Each of these functions will need to be recreated in the new application. Pro*C is mostly
used as an imperative programming language and is used <strong>for</strong> constructing programs
which involve computation. The target programming environment should have
programming capabilities and features that are similar to those of C/C++ and also
interface with SQL Server <strong>for</strong> retrieving and manipulating data. The GUI capabilities will
not be discussed in this guide.
Understanding .NET and ADO.NET
The Microsoft .NET Framework provides a programming infrastructure <strong>for</strong> building,
deploying, and operating applications and services. When working with databases,
ADO.NET is a key component.
ADO.NET is a set of libraries included with the Microsoft .NET Framework that enables
communication with various data stores from .NET applications. The ADO.NET libraries
include classes <strong>for</strong> connecting to a data source, submitting queries, and processing
results. ADO.NET provides the tools to efficiently implement data access and
functionality provided by Pro*C. Data access in ADO.NET relies on the following two
entities:
● DataSet

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 271
●
Data provider
DataSet
The DataSet is a copy of the data retrieved from the database cached in memory. Data
can be loaded into a DataSet from any valid data source, such as a SQL Server
database, or an XML file. The DataSet persists in memory, and the data therein can be
manipulated and updated independent of the database. When appropriate, the DataSet
can then be used <strong>for</strong> updating the database.
Data Provider
A data provider <strong>for</strong>ms the link between the Visual Basic .NET program and the database.
A data provider is not a single component; rather it is a set of related components that
work together to provide data in an efficient, per<strong>for</strong>mance-driven manner.
Two data providers are available <strong>for</strong> Visual Basic .NET. The SQL Server Data Provider is
designed specifically to work with SQL Server 7 or later, and the OLE DB Data Provider,
which can also connect to other types of databases. Each data provider consists of
versions of the following generic component classes:
● The Connection object provides the connection to the database.
● The Command object executes a command against a data source. It can execute
non-query commands, such as INSERT, UPDATE, or DELETE, or return a
DataReader with the results of a SELECT command.
● The DataReader object provides a <strong>for</strong>ward-only, read-only, connected recordset.
● The DataAdapter object populates a disconnected DataSet or DataTable with data
and per<strong>for</strong>ms updates.
The following classes are also offered: Transaction, CommandBuilder, Parameter,
Exception, Error, and ClientPermission.
For more in<strong>for</strong>mation on data provider components, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconusingadonetproviderstoa ccessdata.asp.
Even though the syntax and use of the functions differ, ADO.NET provides equivalent
database functions <strong>for</strong> SQL Server. It is important to ensure that these functions are
translated to the new environment during the rewriting process.
Scenario 1: Rewriting Pro*C to the .NET Plat<strong>for</strong>m
Rewriting the application <strong>for</strong> Windows makes use of native SQL Server APIs, ADO.NET,
Microsoft ActiveX Data Objects (ADO), or Open Database Connectivity (ODBC) running
natively in the Windows subsystem. Rewriting the application can result in a more stable
and integrated configuration after the project is complete.
Case 1: Rewrite the Application using Visual Basic.NET
Visual Basic.NET provides all the functionality of the C programming language as well as
several interfaces to SQL Server databases to execute SQL statements. This scenario
describes how to rewrite a Pro*C application with Visual Basic .NET.
The figure that follows shows a graphical representation of how
the Pro*C code will
migrate over to Visual Basic .NET during the rewrite.

272 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Pro*C
Figure 16.1
Database access in Pro*C and Visual Basic .NET
Each function that currently resides in Pro*C code will need to be rewritten, from the user
interface to the database connection. There are two options available to connect to the
SQL Server data source from the .NET framework.
These options are:
● The SQL Server .NET Data Provider is implemented in the SQLClient namespace.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 273
● The OLE DB provider is in the OLE DB namespace. There are OLE DB providers
<strong>for</strong> both <strong>Oracle</strong> and SQL Server.
To rewrite an application using Visual Basic .NET, follow these steps:
For more in<strong>for</strong>mation on data access services available with ADO.NET, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconaccessingdatawithadonet.asp.
The examples used in these procedures are based on SQL Server .NET DataProvider and
DataReader objects. If an OLE DB provider is used, there may be slight variations to the
following steps.
1. Install the .NET Framework SDK and redistribution. The SDK contains the
reso urces <strong>for</strong> building, testing, and deploying .NET Framework applications. For
access to the latest SDK, refer to
http://msdn.microsoft.com/netfram ework/downloads/updates/default.aspx.
The Microsoft Visual Basic .NET software is required <strong>for</strong> programming the
application. For more in<strong>for</strong>mation, refer to
http ://www.microsoft.com/downloads/details.aspx?FamilyID=dd6ec730-fd9a-4e36-
8552-8accc4cd8fb3&DisplayLang=en.
At t his point, it is assumed that you have all the components in place to write a VB
.NET application using the SQL Server .NET DataProvider. It is also assumed that
the migrated SQL Server database is in place.
For access to several references <strong>for</strong> creating Windows <strong>for</strong>ms applications, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconCreatingWindowsFormsApplicat ions.asp.
2. Rewrite connectivity statements within application code.
● In Pro*C, database open and close statements are similar to the following
example:
/* assign username and password to host variables */
strcpy(username.arr,"SCOTT");
username.len=strlen(username.arr);
strcpy(password.arr,"TIGER");
password.len=strlen(password.arr);
/* execute connect statement */
EXEC SQL CONNECT :username IDENTIFIED BY :password;
●
/* execute close statements */
EXEC SQL COMMIT WORK RELEASE;
These same functions can be recreated using ADO.NET. Here are examples
of the same functions as written <strong>for</strong> .NET.
' declare a connection object
Dim cn As New SqlConnection
' define a connection string
Dim strConn As String
'This is the connection string
strConn = "Data Source=(local)\DataSourceName;" & _
"Initial Catalog=databaseName;" & _
"Trusted_Connection=Yes;"
' instantiate connection object

274 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Pro*C
cn = SqlConnection(strConn)
' open connections
cn.Open()
' close connections
cn.Close()
For more details on SqlConnection, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpref/html/frlrfsystemdatasqlclientsqlconnectionclasstopic.asp
3. Rewrite the queries and cursor functions.
Pro*C uses embedded SQL to store the output of a query statement in a cursor
from which rows can be fetched. Visual Basic.NET does not support cursors;
instead, it uses several other methods <strong>for</strong> retrieving data sets from SQL queries.
One of these data retrieval methods is the DataReader object, which is a
ligh tweight object that is read-only and, hence, ideal <strong>for</strong> queries. The following link
provides access to more in<strong>for</strong>mation on retrieving data using DataReader object:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpcontheadonetdatareader.asp.
● Here are some common cursor operations encountered in Pro*C applications:
Defining a cursor:
●
EXEC SQL DECLARE cust_cursor FOR
SELECT CustomerID, CompanyName FROM Customers;
Opening the cursor:
EXEC SQL OPEN cust_cursor;
Fetching rows using the cursor:
<strong>for</strong> (;;){
EXEC SQL WHENEVER NOT FOUND DO break;
EXEC SQL FETCH cust_cursor INTO :customerid, :companyname;
printf("CustomerID: %s – CompanyName: %s\n", customerid,
companyname);
}
Closing the cursor:
EXEC SQL CLOSE cust_cursor;
Although SQL Server does not support cursors, equivalent functions can be
created using ADO.NET:
Defining the query:
strSQL = "SELECT CustomerID, CompanyName FROM Customers"
Creating a command object:
Dim cmd As New SqlCommand(strSQL, cn)
Creating a data reader object:
Dim rdr As SqlDataReader = cmd.ExecuteReader()
Displaying the data reader result set:
While rdr.Read()
Console.WriteLine(rdr("CustomerID") & " – " & rdr("CompanyName"))
End While
Do While rdr.Read()
Console.WriteLine(rdr.GetInt32(0) & " " & _
“ rdr.GetString(1) & " " & rdr.GetFloat(2))

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 275
For more in<strong>for</strong>mation on implementing a DataReader, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconimplementingdatareader.asp.
4. Rewrite the embedded DML statements
The embedded DML is used to insert, update, and delete data. The SqlCommand
object can be used to per<strong>for</strong>m these SQL operations. The DataAdapter and
DataSet objects are required <strong>for</strong> executing DML and stored procedures. Migration
of these operations is shown in the following examples:
● The DML operations using Pro*C:
Executing an INSERT DML statement:
Loop
Closing the data reader object:
rdr.Close()
●
EXEC SQL INSERT INTO Customer VALUES (:newcompanyname, :customerid);
Executing an UPDATE DML statement:
EXEC SQL UPDATE Customer
SET CompanyName = :newcompanyname
WHERE CustomerID = 'ACME';
Executing a DELETE DML statement:
EXEC SQL DELETE FROM Customer
WHERE CustomerID = 'ACME';
For each of the DML operations shown, the equivalent operations can be
per<strong>for</strong>med using ADO.NET:
Executing an INSERT DML statement:
Dim strSQL As String
strSQL = " INSERT INTO Customer VALUES " & _
" (@newcompanyname,@customerid)"
Dim cmd As New SqlCommand(strSQL, cn)
Dim param1, param2 As SqlParameter
Param1 = cmd.Parameters.Add("@newcompanyname",
SqlDbType.VarChar, 10)
Param2 = cmd.Parameters.Add("@customerid", SqlDbType.NChar, 5)
Param1.Value = ”COMPANY1"
Param1.Value = "VALUE1"
cmd.ExecuteNonQuery()
Executing an UPDATE DML statement:
Dim strSQL As String
strSQL = "UPDATE Customer SET CompanyName = @newcompanyname " & _
"WHERE CustomerID = 'ACME'"
Dim cmd As New SqlCommand(strSQL, cn)
Dim param1 As SqlParameter
Param1 = cmd.Parameters.Add("@newcompanyname", SqlDbType.VarChar, 10)
Param1.Value = "NewName"
Dim InsertRecordsAffected As Integer = cmd.ExecuteNonQuery()
Executing a DELETE DML statement:
Dim strSQL As String
strSQL = " DELETE FROM Customer WHERE CustomerID = 'ACME'"
Dim cmd As New SqlCommand(strSQL, cn)
Dim InsertRecordsAffected As Integer = cmd.ExecuteNonQuery()

276 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Pro*C
5. Rewrite Transaction Management operations
●
The Transaction Management operations in Pro*C are:
Beginning a transaction:
EXEC SQL SET TRANSACTION READ ONLY;
Committing a transaction:
EXEC SQL COMMIT WORK RELEASE;
Setting a savepoint:
EXEC SQL SAVEPOINT save_point;
Rollback a transaction:
EXEC SQL ROLLBACK WORK RELEASE;
Rollback to a savepoint:
EXEC SQL ROLLBACK TO SAVEPOINT save_point;
● Transaction Management in ADO.NET
Changes are made through the DataSet object. The Update method is used <strong>for</strong>
copying the changes made to the dataset back to the database which implicitly
commits the changes.
6. Rewrite calls to stored procedures.
● Stored procedures are executed in Pro*C using the syntax shown in the
following example. In this example, the host variables represent IN or OUT
parameters.
EXEC SQL EXECUTE
●
BEGIN
GET_ROOM_DETAILS(:HotelId, :RoomType, :AvailableRooms,
:StandardRate);
END;
END-EXEC;
Stored procedure calls in ADO.NET: SqlCommand objects can be used to call
SQL Server and MSDE stored procedures. The SqlCommand object exposes
a CommandType property that can be used to help simplify the code to call
stored procedures. Set SqlCommand object’s CommandText property to the
stored procedure name, and the CommandType property to StoredProcedure,
and then call the stored procedure, as shown in the following code:
Dim strConn As String
strConn = "Data Source=(local)\NetSDK;Initial Catalog=Northwind;" & _
"Trusted_Connection=Yes;"
Dim cn As New SqlConnection(strConn)
Dim cmd As New SqlCommand("GET_ROOM_DETAILS", cn)
cmd.CommandType = CommandType.StoredProcedure
Dim param As SqlParameter
param = cmd.Parameters.Add("@HotelId", SqlDbType.NChar, 5)
param.Value = "HOTEL1"
………
………
cn.Open()
Dim rdr As SqlDataReader = cmd.ExecuteReader()
Do While rdr.Read()
Console.WriteLine(rdr("OrderID"))
…………
Loop

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 277
rdr.Close()
A more detailed discussion on using stored procedures in Visual Basic.NET is
available at http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnadvnet/html/vbnet09102002.asp.
7. Rewrite exception handling.
●
●
There are two ways to handle <strong>Oracle</strong> errors in Pro*C:
●
●
SQL
EXEC
embedded statements. The syntax is:
SQL WHENEVER [condition] [action];
Checking error codes in SQLCA
The generic syntax is
if ( sqlca.sqlcode == [a value i.e., -1] )
{
Handler code
}
Exception handling in Visual Basic .NET
Use a Try block to add exception handling to a block of code. Add Catch
blocks, as necessary, to trap individual exceptions. The .NET runtime handles
Catch blocks in order, looking <strong>for</strong> an "is a" match against the current exception.
It uses the first block it finds that matches. You can nest Try blocks, making it
easy to effectively push and pop exception-handling states. Add a Finally block
to your Try block to run code unconditionally, regardless of whether an error
occurs or not.
You can create your own exception classes that inherit from the base
exception class (or any class that inherits from that class) to add your own
functionality:
Try
' Code that throws exceptions
Catch E As OverflowException
' Catch a specific exception
Catch E As Exception
' Catch the generic exceptions
Finally
' Execute some cleanup code
End Try
A more detailed discussion of error handling in VB.NET can be found at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnvbdev01/html/vb01f1.asp.
8. Change all embedded SQL statements to T-SQL. This is a step common to all
migrations. Refer to Chapter 11, "Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong>
SQL and PL/SQL," <strong>for</strong> a detailed discussion on modifying <strong>Oracle</strong> SQL to be
SQL Server-compliant.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 279
17
Developing: Applications —
<strong>Migrating</strong> <strong>Oracle</strong> Forms
Introduction and Goals
<strong>Oracle</strong> Forms are applications built using <strong>Oracle</strong> Developer, a Rapid Application
Development (RAD) environment available from <strong>Oracle</strong>. <strong>Oracle</strong> Forms-based
applications can retrieve and manipulate data in <strong>Oracle</strong> databases. These <strong>for</strong>ms can also
be deployed across the Web.
It is not possible to modify an <strong>Oracle</strong> Forms application <strong>for</strong> interoperation with a
Microsoft® SQL Server database, and it is recommended that applications of this type
are rewritten. Microsoft Visual Basic® .NET is an ideal choice <strong>for</strong> rewriting an <strong>Oracle</strong>
Forms application because it is very similar in nature to <strong>Oracle</strong> Developer, both in terms
of the development tools and wizards, as well as the end product itself.
This chapter is <strong>for</strong> developers who want to migrate their <strong>Oracle</strong> Forms application running
on an <strong>Oracle</strong> database to Visual Basic .NET running on SQL Server. The tools,
processes, and techniques required <strong>for</strong> a successful conversion are described.
In this guide, the <strong>Oracle</strong> Forms application is first analyzed <strong>for</strong> its components, and then
a similar analysis of the Visual Basic .NET application environment is conducted.
Strategies <strong>for</strong> migrating from <strong>Oracle</strong> Forms to Visual Basic .NET are then examined. A
detailed discussion on how to per<strong>for</strong>m the migration is beyond the scope of this guide.
The goal of this chapter is to provide a blueprint <strong>for</strong> per<strong>for</strong>ming the migration.
Migration Approach
<strong>Migrating</strong> an <strong>Oracle</strong> Forms application to Visual Basic .NET is complex, and the
treatment of the subject here should be seen as a design sketch from which a detailed
analysis and plans <strong>for</strong> an application migration can be made.
The basic approach is feasible <strong>for</strong> the following two reasons:
1. <strong>Oracle</strong> Forms and Visual Basic user interfaces share many common elements.
2. The <strong>Oracle</strong> Forms Designer is capable to generate Visual Basic code.
The <strong>for</strong>m is the basis <strong>for</strong> the user interface (UI) in both <strong>Oracle</strong> Forms and Visual Basic.
The <strong>for</strong>m is graphical in nature and is used to present data and accept user input, and the
<strong>for</strong>m can contain elements which are both graphical and non-graphical in nature. <strong>Oracle</strong>

280 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
Forms and Visual Basic have several common elements between them. However, their
organization, naming, and properties differ.
Figure 17.1 illustrates how different components of <strong>Oracle</strong> Forms map to components in
Visual Basic .NET.
Figure 17.1
Mapping of <strong>Oracle</strong> Forms to Visual Basic .NET WinForm
This diagram shows how all the high-level components of an <strong>Oracle</strong> Forms application
map to components in Visual Basic .NET. This mapping serves as a convenient guide <strong>for</strong>
the work to be done and also helps maintain the logical composition of the application.
The mapping also helps avoid introducing too many unintended side effects, such as
firing of triggers at the wrong time and complicating the migration. This diagram is used in
this chapter to
document the source <strong>Oracle</strong> Forms application, define the target
Visual Basic .NET application, and plan <strong>for</strong> per<strong>for</strong>ming the migration.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 281
Examining <strong>Oracle</strong> Forms
<strong>Oracle</strong> Forms applications are <strong>Oracle</strong> database optimized transactional applications built
using the tools provided by <strong>Oracle</strong>'s Developer Suite. <strong>Oracle</strong> Forms Builder, a part of
<strong>Oracle</strong> Developer suite, enables you to quickly and easily create database <strong>for</strong>ms and
business logic. The development is done using wizards, drag-and-drop components, and
built-in functions. A visual editor can be used to refine the <strong>for</strong>ms with graphics and other
components. The coding language is PL/SQL. A client/server Forms application can run
on the Web with very little or no modification.
Like most GUI applications, an <strong>Oracle</strong> Forms application is composed of two parts: the
application logic and the user interface. <strong>Oracle</strong> Forms maintains this separation
throughout its design. Hence the Forms Runtime is the same in both the two-tier and
three-tier architectures.
An understanding of the basic concepts and components that make up a <strong>for</strong>m is
important to planning an application migration. Figure 17.2 shows a simplified view of the
<strong>Oracle</strong> Forms environment.
Figure 17.2
High-level organization of <strong>Oracle</strong> Forms components
An <strong>Oracle</strong> Forms application is an organization of items. The organization of the items
has two perspectives: that of the developer, called the <strong>for</strong>m view; and that of the user,
called the visual (or presentation) view. In the <strong>for</strong>m view, the items are organized into
logical blocks and have no visual structure. The visual structure is provided by
constructing the visual view where items are placed on a canvas and presented to the
user in windows. It is very important to maintain the same visual view when an <strong>Oracle</strong>
Forms application is migrated. The Visual Basic .NET developers need to look at the
visual view to understand how many screen layouts they need in Visual Basic .NET.
Each item in a canvas will correspond to one control in .NET.
The migration should be attempted by creating two models: one is based on the
<strong>for</strong>m
view, called the Form Model; and the other is based on the visual view, called the Visual
Model. Figure 17.1 shows the <strong>for</strong>m view of the mapping from <strong>Oracle</strong> Forms to
Visual Basic .NET. The equivalent visual view is shown in Figure 17.3.

282 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
Figure 17.3
Mapping of visual view of <strong>Oracle</strong> Forms to Visual Basic .NET
The <strong>for</strong>m view is used by the developer to access the business logic and the data
access. The visual view is used to build the user interface.
Note Providing a complete description of how to trans<strong>for</strong>m every item and every piece
of code from an <strong>Oracle</strong> Forms application to a Visual Basic .NET application is beyond
the scope of this guide.
In this section, the entire <strong>Oracle</strong> Forms application is examined, with an emphasis on
understanding the database-related components.
An <strong>Oracle</strong> Forms application is built using components called modules. The following four
types of modules are visible when a <strong>for</strong>m application is opened up in <strong>Oracle</strong> Forms
Builder:
1. Object Library
2. PL/SQL Library
3. Form Module
4. Menu Module
Figure 17.4 shows the details of an <strong>Oracle</strong> Forms application as seen in the Ownership
View using <strong>Oracle</strong> Forms Builder. This tool will be employed in documenting the current
application.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 283
Figure 17.4
An <strong>Oracle</strong> Form as visible in <strong>Oracle</strong> Forms Builder
An application can be built using multiple <strong>for</strong>ms, menus, and library modules. The <strong>Oracle</strong>
Forms Builder can be used to browse the component model and understand the modules
and their characteristics so that the Forms Model can be built. The elements offered by
these modules account <strong>for</strong> the capabilities, features, and functioning of the application
and should be the focus of the developer involved in migrating an application.

284 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
Table 17.1 is a compilation of the files that make up an <strong>Oracle</strong> Forms application.
Table 17.1: <strong>Oracle</strong> Forms File Extensions
Module Extension Characteristic
Form .fmb Form design file
.fmx
.fmt
Form executable runfile
Form text export file
Menu .mmb Menu design file
.mmx
Menu executable runfile
.mmt Menu text export file
PL/SQL Library .pll PL/SQL library design file (can also be executed
— contains both source and executable code)
.plx
PL/SQL library executable runfile (contains no
source code)
.pld
PL/SQL library text export file
Object Library .olb Object library design file
.olt
Object library text export file
<strong>Oracle</strong> Forms Builder can be used to view all the components in a Forms application by
opening the <strong>for</strong>m and clicking View, and then Show PL/SQL only.
Object Library
The object-oriented programming concept of reusing code is implemented in <strong>Oracle</strong>
Forms by the object library and PL/SQL library modules. The Object library contains
reusable objects and the PL/SQL library contains reusable code. Hence, these are
examined first <strong>for</strong> a migration.
The Object library is a collection of <strong>for</strong>ms objects that can be used in other <strong>for</strong>m, menu, or
library modules. The Object Library is used to store, maintain, and distribute standard
<strong>for</strong>ms objects, which can then be reused across the entire application. They also help
conserve runtime memory and encourage reuse. The objects in an Object Library are
commonly organized as folders. The organization may be by type of item or by
application functional area.
A good example of the use of an object library is a control block used to enter complex
search criteria in a query-only <strong>for</strong>m. This control block is then used in multiple <strong>for</strong>ms.
<strong>Oracle</strong> Forms Builder allows creation of a subclassed version of a library object <strong>for</strong> reuse
in any desired module. To be able to tell whether an object is subclassed or not, look at
the subclass in<strong>for</strong>mation property of the data block.
The object-oriented features of Visual Basic .NET allow you to model library object
inheritance closely to maintain
the same structure. The object library can be viewed as a
DLL.
PL/SQL Library
The PL/SQL library contains reusable code invoked by other <strong>for</strong>m, menu, or library
modules. The code, also called a program unit, can be user-named functions,
procedures, or packages. The program unit is stored and executed on the client. The
program units are not <strong>for</strong> database-related code alone. They may contain purely business
logic. For example, the code could be used to check the validity of a user input in a <strong>for</strong>m.
Any SQL contained in these program units is passed to the database.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 285
Libraries make all the PL/SQL code available to the <strong>for</strong>m without being part of the <strong>for</strong>m.
The libraries are loaded dynamically. Multiple <strong>for</strong>ms can attach the same PL/SQL library.
Table 17.1 identifies the files that are related to the PL/SQL
needs to be migrated.
Form Module
Library that contain code that
A <strong>for</strong>m (or <strong>for</strong>m module) is the main component that anchors an application and provides
the necessary code to interact with the datasource and the user interface. The underlying
database data is reflected in multiple items, including fields, check boxes, and radio
groups. A <strong>for</strong>m is logically organized into blocks.
Blocks
A block is a container <strong>for</strong> a group of related items such as text boxes, lists, and buttons.
The block itself does not have a visual representation.
<strong>Oracle</strong> Forms Builder consists of two main types of blocks. These are:
1. Data blocks
2. Control blocks
These two kinds of blocks are very different from each other. The data block serves as a
bridge to the underlying data and provides an abstraction <strong>for</strong> how the data is reached.
The control blocks are more like programming units that can organize controls into logical
groups <strong>for</strong>ming part of the same user interface navigation cycle. Whether a block is a
data block or a control block can be determined by verifying the Database Data Block
property <strong>for</strong> the block. It is a data block if the setting is "Yes" and a control block if the
setting is "No."
Data Block
A data block can be associated with a specific database table (or a view), a stored
procedure, a FROM clause query, or a transactional triggers. By default, the association
between a data block and the database allows <strong>for</strong> automatic access and manipulation of
data in the database. Triggers are used when a data block needs access to tables not
directly associated with it (non-base tables).
Various relationships can exist between data blocks and their underlying base tables. A
common relationship is the master-detail relationship where each row in the master table
corresponds to one or more rows in the detail table. The master-detail relationship
allows the primary key and <strong>for</strong>eign key values to be linked across data blocks. <strong>Oracle</strong>
Forms Builder automatically generates the objects and the PL/SQL code needed to
support the master-detail relationships when these blocks are built using the Data Block
Wizard.

286 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
Figure 17.5 shows the different components that make up a master-detail block as
created by the Data Block Wizard.
Figure 17.5
Code generated by <strong>Oracle</strong> Forms Builder Data Block Wizard in creating a master-detail block
By capturing a query on a table, a block can also be designed to show one or more
records at a time. These are called single-record blocks or multi-record blocks,
respectively.
Visual Basic .NET developers can use <strong>Oracle</strong> Forms Builder to look at the generated
code to find out about the relationships between the blocks. For example, in Figure 17. 5,
code in the ON-POPULATE-DETAILS trigger on the DEPT block suggests that it is the
master block of the EMP block.
In Visual Basic .NET, the equivalent of an <strong>Oracle</strong> Form data block is a Dataset into which
data can be read from the database, and on the visual side, a DataGrid control bound to
the Dataset will be capable to display the data. Dataset is just one option. In addition to
the Dataset, ADO.NET offers DataReader <strong>for</strong> read-only data access.
Additional properties convey the association between a data block and a table, such as
the WHERE clause and ORDER BY clause that will be used to create SQL <strong>for</strong> the
Visual Basic .NET Dataset. The Insert Allowed, Update Allowed, and Delete Allowed
properties will tell the Visual Basic .NET developer whether the block will insert, update,
or delete any records.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 287
Figure 17.6 shows all the properties of a data block.
Figure 17.6
Properties of a data block
Control Block
The second type of block is the control block. The items in a control block are not
associated with the database, and its items do not relate to any columns within any
database table. The items in a control block are called control items. For example,
buttons in a module can initiate certain actions and can be logically grouped in a control
block. The control block is only a logical grouping and the physical or visual placement
may differ. It is also a mechanism to segregate the control block items from the items that
are dependent on the database. Control items are used to per<strong>for</strong>m functions, such as
accepting input from the user and displaying calculated values and look values.
Program Units
Program units are part of <strong>for</strong>ms modules and they contain named procedures, functions,
or packages. The program units are similar to the program units created in the libraries
but are local to the <strong>for</strong>m in which they are created. They are stored and executed on the
client with any embedded SQL passed to the database <strong>for</strong> processing. If this code
contains database interactions, then it needs to be converted to T-SQL. If it contains only
non-database related code, then it needs to be converted to its equivalent in
Visual Basic .NET.
Triggers
The trigger object is a PL/SQL block executed on an event. Triggers can be owned by the
<strong>for</strong>m module, a data block, or an item, depending upon their scope.

288 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
If this code contains database interactions, then it needs to be converted to T-SQL. If it
contains only non-database code, then it needs to be converted to its equivalent in
Visual Basic .NET.
When a trigger is activated, it executes the code it contains. Each trigger’s name defines
what event will fire it; <strong>for</strong> example, a WHEN-BUTTON-PRESSED trigger executes its
code each time the user clicks the button to which the trigger is attached.
A trigger can be replaced by an equivalent event in Visual Basic .NET. The equivalent of
an <strong>Oracle</strong> Forms WHEN-BUTTON_PRESSED trigger in Visual Basic .NET is the Click
event procedure. Double-click the page Button control in design view to open the code
behind the page and create a Click event procedure.
List of Values (LOV)
A LOV is a pop-up window that provides the user with a selection of values. The values
can be static or populated by querying the database. LOVs are populated using columns
returned by record groups. Check the Record Group property of the LOV <strong>for</strong> the record
group which is used to provide values. Visual Basic .NET offers pop-up windows that can
be programmed to display a list of values obtained by the DataReader.
Record Groups
A record group is a data structure in the <strong>for</strong>m module which behaves like a local table <strong>for</strong>
data retrieved from the databases. Record groups are a way to share small List of Values
(LOV). The values can be retrieved using a query or a subprogram. Look into the
property Record Group Query to see the SQL statement upon which the record group is
based. A record group can be replaced by DataReader in Visual Basic .NET.
Menu Module
The menu module consists of a hierarchy of menus. Each menu consists of the items that
can be selected. Menu modules are usually attached to <strong>for</strong>m modules. Every <strong>for</strong>m
module has a default menu that includes the commands <strong>for</strong> all basic database
operations, such as insert, update, delete, and query. Visual Basic .NET offers a wide
range of functionality involving menus.
After inserting, updating, or deleting records from an <strong>Oracle</strong> <strong>for</strong>m, changes are not made
in the underlying database until the changes are committed with a save command. While
rewriting this module in Visual Basic .NET, it is important to know whether inserts,
updates, and deletes are permitted on a data block. The data block properties of Insert
Allowed, Update Allowed, and Delete Allowed determine these.
Any item in a menu can also be referenced through PL/SQL code to enable/disable menu
items, attach commands to menu items, initialize check or radio menu items, and change
menu start-up code.
Windows and Canvases
Windows and canvases <strong>for</strong>m the basis <strong>for</strong> the visual presentation of the <strong>for</strong>m. The visual
model is built by looking at the windows and canvases through Form Builder. The
developer can then create an identical representation in Visual Basic .NET based on the
visual model using <strong>for</strong>ms.
<strong>Oracle</strong> Forms has two types of windows: document windows (the main application areas)
and dialog windows (messages and other actions).The end user interacts with the
application using these windows. In addition to incorporating all the functionality in the
original application, it is also important to maintain the general look and feel of the
application.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 289
The document window is composed of work areas called canvases where visual objects
such as graphics and items are arranged. Several canvases can be located in a <strong>for</strong>m
module. All canvases may appear in a single window (by default) or spread across
multiple windows (to view simultaneously).
From the start, a new document window or dialog has a relationship with a <strong>for</strong>m in which
relationships to blocks tie the visual representation together with the underlying database
data. Figure 17.7 shows a window which displays the master-detail view of the data. The
Dept part is the header and the Employees part is the detail.
Figure 17.7
Sample application window
Frames
A frame is a visual object found on a canvas. Frames are used to arrange items in terms
of blocks. The frame defines visual characteristics such as margins, offsets, and
distances between items. Frames may also be defined in the Object Library to en<strong>for</strong>ce
standards across the application. The equivalent of frames in Visual Basic .NET is the
panel.
Item
Items are interface objects that present the data values to the users. Items also enable
the user to interact with the <strong>for</strong>m. The type of interaction varies according to the type of
item. Visual Basic .NET offers a wide range of equivalents <strong>for</strong> the <strong>for</strong>m items called
controls.
The type of an item can be examined by locating the Item Type property of the item.
Items have both a visual representation and a <strong>for</strong>ms representation (code) and will
appear in both models. However, the properties captured in each of the models will differ.
Only the common items, such as text item, check box, and radio groups, which could be
dependent on the database are discussed here. For each of the items, the visual and
functional characteristics are attached to the visual model and the logical characteristics
are captured in the <strong>for</strong>m model. For example, the height, width, font size, and <strong>for</strong>mat
mas k are the visual characteristics. The database item (table and column) that is used to
populate the text item is the <strong>for</strong>m characteristic.
Text Item
Text items allow <strong>for</strong> text to be displayed and manipulated. Text items are called by the
name TextBox in Visual Basic .NET. When examining text items, Visual Basic .NET
developers need to determine whether this item corresponds to a column in a database
tabl e by looking at the Database Item property. If so, it needs to be tied to a dataset or
other data source in Visual Basic .NET. The name of the text item is not necessarily the
same as the name of the database column. Look at the Column Name property <strong>for</strong> the
name of database column.

290 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
Check Box Item
A check box provides the user with a Boolean control that has just two values, such as
true and false, or on and off. The check box values can be set by fetching from the
database. When creating the equivalent Check Box control, Visual Basic .NET
developers need to look at the following three properties of a check box item: Value
When Checked, Value When Unchecked, and Check Box Mapping of Other Values.
Radio Group Item
A radio group provides the user with a fixed set of options that are mutually exclusive,
Radio group item values can also be set using database columns. Under the radio
button, the developer should look at the Radio Button Value property <strong>for</strong> the value
assigned to the button. In Visual Basic .NET the radio group can be replaced by a
combination of GroupBox and RadioButtons.
Buttons
Buttons are interface items that can display list of values, commit data in a <strong>for</strong>m, query
the database, or invoke PL/SQL blocks. The WHEN-BUTTON-PRESSED trigger holds
the code <strong>for</strong> these actions. Buttons are also found in Visual Basic .NET.
Understanding Visual Basic .NET
Visu al Basic.NET offers Windows® Forms (WinForms) Designer, which is very similar in
natu re to <strong>Oracle</strong> Forms Builder. The product of the Windows Forms Designer is a
Windows-based <strong>for</strong>m application that is similar in nature to an <strong>Oracle</strong> Forms application.
Forms are the fundamental elements of the application on which controls (same as items
in <strong>Oracle</strong> Forms) can be placed <strong>for</strong> user interaction. As in <strong>Oracle</strong> Forms, menus and
toolbars provide a structure <strong>for</strong> the user to control the application. For readers who are
unfamiliar with VB.NET, there is a lot of in-depth technical in<strong>for</strong>mation available at
http://msdn.microsoft.com/vbasic/using/
If the conversion of the <strong>for</strong>ms is done correctly, then the WinForm is simply the
presentation layer with all of the database access logic and rules put into a business
object layer. The conversion to a Web Form solution, as a result, only requires
associating the appropriate Web server control to an object holding the data retrieved
from the business object layer.
The controls on a <strong>for</strong>m simply provide an interface to the event-driven model that is the
equ ivalent of the triggers system in <strong>Oracle</strong> Forms. As changes are made to textbox input,
the pressing of buttons, or the selection of items in a list, additional code is triggered (see
"Triggers" in the "Form Module" section earlier in this chapter). The code is in the <strong>for</strong>m of
subroutines that handle the call from the raised event to provide some specific action.
The PL/SQL routines will map to these subroutines. The action is typically defined as an
algorithm or a business rule. In most applications, the business rules extract in<strong>for</strong>mation
from the database.
A summary of the entire array of controls in WinForms is available at
http://msdn.microsoft.com/library/en-us/vbcon/html/vboriControlsForWinForms.asp.
The .NET Framework is so extensible that numerous Independent Software Vendors
(ISVs) have created unique controls or have enhanced the functions in existing .NET
con trols. Developers themselves can generate their own controls <strong>for</strong> personal needs.
Man y of the most common controls emulate functionality that has been used in visual
<strong>for</strong>m s <strong>for</strong> years, whether in classic Visual Basic, Delphi, or <strong>Oracle</strong>. One of the most
beneficial properties of most controls is the capability to bind them to data sources.
Data

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 291
sources do not have to be ADO.NET objects. Sources can come from arrays and other
collection-type objects.
Scenario 1: Rewriting to Visual Basic .NET
Con verting from <strong>Oracle</strong> Forms to Visual Basic .NET is non-trivial. There is no tool that
automates the conversion to VB.NET. In <strong>Oracle</strong> Forms, an application can be separated
into a visual or presentation component and a code component. This separation makes
the migration easier and is the approach used in this guidance.
Two methods are available to convert <strong>Oracle</strong> Forms to Visual Basic.NET:
● Case 1: Using <strong>Oracle</strong> Designer
● Case 2: Manually Redesigning the application
Case 1: Using <strong>Oracle</strong> Designer
Visual Basic code is generated from the <strong>Oracle</strong> Form application using the Visual Basic
Generator, which is a function of <strong>Oracle</strong> Designer. The Visual Basic code is then
upgraded to Visual Basic.NET using the guidance available from Microsoft at
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vbcon/html/vbconupgradingapplicationscreatedinpreviousversionsofvisualbasic.asp.
At the time of publication, this method is not perfect. Many manual changes will still need
to be made after the automated conversion. Using <strong>Oracle</strong> Designer is still a useful
exe rcise because it provides a valuable template structure of the migrated Visual Basic
application even though subsequent changes to the code will be necessary.
Case 2: Manually Redesigning the Application
In this method, the entire <strong>Oracle</strong> Forms application is documented and the new
application is built in an orderly fashion.
To document and redesign the application, follow these steps:
1. Create a list of <strong>for</strong>ms found in the application and note the relationship between
them.
2. Create two models <strong>for</strong> each <strong>for</strong>m.
The first model, which is called the Forms Model, will contain all the <strong>for</strong>ms components. The
Forms Model will document the four modules: <strong>for</strong>ms module, menu module, object libraries,
and PL/SQL libraries. The second model, called the Visual Model, will document all the
layout-related components: windows, canvases, frames, and items
3. Document the Forms Model.
Open a <strong>for</strong>m in the Ownership View using <strong>Oracle</strong> Forms Designer and note the
components under each module with their hierarchy from module down to items.
Per<strong>for</strong>m the following actions:
a. Start with documenting all the modules: <strong>for</strong>ms modules, menu modules, object
libraries, and PL/SQL libraries using Figure 17. 1 as reference.
b. For each module, incrementally refine the model with the next level of detail
using multiple passes.
c. Document all the supporting components, such as LOVs, record groups, and
program units, found under the <strong>for</strong>m module.
d. Based on the size of the <strong>for</strong>m, submodels or documents may be prepared <strong>for</strong>
subsections of the model.

292 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
e. A block document may be created <strong>for</strong> just the data blocks and control blocks.
Use <strong>Oracle</strong> runtime in debug mode to understand the flow. When you run
<strong>Oracle</strong> Forms in debug mode, the runtime environment displays the name of
each trigger when it fires. Operate the <strong>for</strong>m as a user and document the flow of
execution in the blocks document.
f. A procedures document containing a compilation of PL/SQL code or program
unit found in triggers, user-named subprograms, packages, PL/SQL-type menu
items, and menu startup code. All places in a <strong>for</strong>m which contained PL/SQL
code can be conveniently viewed by switching the <strong>for</strong>m view to Show PL/SQL
Only. For each program unit, note the existence of SQL or calls to database
stored programs.
4. Document the Visual Model.
Open the <strong>for</strong>m in the Visual View using <strong>Oracle</strong> Forms Designer and note the
components under each module, capturing the hierarchical relationship as
shown in Figure 17.3. Document all the visual characteristics <strong>for</strong> each of the
components.
5. Convert the shared code.
Start the migration by converting the shared components that are under the object
libraries and PL/SQL libraries. While migrating from <strong>Oracle</strong> Forms to
Visual Basic .NET, continue to maintain the same logical grouping and
organization of the various <strong>for</strong>ms components, including the shared libraries.
In Visual Basic .NET, create a class library project, one each <strong>for</strong> the object libraries
and the PL/SQL libraries.
● Migrate the PL/SQL libraries.
The procedures document contains the required in<strong>for</strong>mation <strong>for</strong> migrating the
PL/SQL libraries. For each PL/SQL library, create a Visual Basic .NET class in
the target project. Each program unit in a library can be migrated into methods
with the equivalent functionality.
● Migrate the object libraries.
The migration of the object libraries can be per<strong>for</strong>med using the Forms Model.
For each object library, create a Visual Basic .NET class in the target project.
Each object in a library can be migrated into an equivalent method in the class.
6.
Convert the Visual Model.
Create a Visual Basic .NET Windows application project. The goal in this step is
only to build the shell visually identical to the <strong>Oracle</strong> Forms application. In this step,
you are concerned with the <strong>for</strong>m and not the function. The functionality will be
addressed in the next step. For example, a DataGrid control will be added to a
<strong>for</strong>m in this step while the tasks to connect to SQL Server and access data are
per<strong>for</strong>med in the next step.
For each window found in the Visual Model, create a <strong>for</strong>m in the project. In
Visual Basic .NET, the concept of canvas is handled by the <strong>for</strong>m itself. The frames
in the <strong>Oracle</strong> Forms application should be converted to panels in
Visual Basic .NET. The items in a frame should be replaced with its equivalent
controls. Also add the menu controls to match the <strong>Oracle</strong> Forms application.
For steps on adding <strong>for</strong>ms to a project, refer to
http://msdn. microsoft.com/library/default.asp?url=/library/enus/vbcon/html/vbtskadding<strong>for</strong>mtoproject.asp.
For more in<strong>for</strong>mation on how to add Windows Forms Controls, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/vbcon/html/vboriwin<strong>for</strong>mscontrols.asp.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 293
For more in<strong>for</strong>mation about learning the techniques <strong>for</strong> arranging the various
controls on a Windows Form, refer to
http://msdn.microsoft.com/library/default.asp?url= /library/en-
us/vbcon/html/vbcon<strong>for</strong>msdesigner.asp.
For guidance on adding menus, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/vbcon/html/vbconwindowsaccessories.asp.
7. Convert the Form Model.
At this stage, all the pieces are in place to code the business logic and application
functionality. The majority of the work is related to converting the code in the
blocks and items, which was documented in the block document. Because an
almost one-to-one mapping of the shared libraries and its objects has been
per<strong>for</strong>med, the code in Visual Basic .NET can be written as a parallel to the code in
the source application.
a. Start by converting the components, such as control blocks, program units,
record groups, LOVs, and triggers that could be tied to multiple controls.
b. Code all the data components in the <strong>for</strong>m because these could be possibly
associated with multiple controls. A detailed account on how to per<strong>for</strong>m this is
provided in the "Adding Data Components to a Windows Form" section later in
this chapter.
c. Complete the migration of the data block by adding code to read data and bind
the grid.
d. Although the grid is bound to the dataset you created, the dataset itself is not
automatically filled in. Instead, you must fill the dataset by calling a datas
class file in the
adapter method. Double-click the page to display the page'
Code Editor. In the <strong>for</strong>m's event handler, call the data adapter's Fill method,
passing it the dataset you want to populate: SqlDataAdapter1.Fill(dsDept).
e. For more details on data binding and Windows Forms, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/vbcon/html/vboriwindows<strong>for</strong>msdataarchitecture.asp.
f. The number of lines of code generated by the Data wizard is far in excess of
what would be required if using Data Access Application Block (DAAB) <strong>for</strong>
.NET.
g. Examine every control and add code to the control and its event.
h. Achieve the proper flow of execution through navigation rules similar to that
seen when executing the <strong>Oracle</strong> Form application in the debug mode.
Adding Data Components to a Windows Form
You do not directly add a dataset to a page. Access to the dataset can be created in one
of several ways. There are two preferred methods. One method is to use the set of visual
objects available in the Toolbox under the Data tab. The other is to take advantage of
the Microsoft Data Access Application Block <strong>for</strong> .NET.

294 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
Using the Visual Studio .NET Data Wizards
Visual Studio® .NET Data Wizards are ADO.NET code generators <strong>for</strong> creating access
to SQL Server, OLEDB, <strong>Oracle</strong>, and ODBC data solutions. There is a small series of data
objects needed to generate datasets to sources under ADO.NET. They are
DataAdapters, connections, commands, and the datasets themselves. Connections
provide the necessary in<strong>for</strong>mation about data sources, authentication, and pooling
options. Commands define whether the source is queried through stored procedures,
direct table access, or through T-SQL Statements. DataAdapters provide a specific pipe
<strong>for</strong> accessing data and trans<strong>for</strong>ming it back to the source by creating the Select, Update,
Insert, and Delete commands; creating stored procedures; or using existing stored
procedures. DataSets act as the virtual database to the client.
To use the wizards to access SQL Server, follow these steps:
1. Create the SqlAdapter.
From the Toolbox within VS.NET, choose the Data tab and drag the
SqlDataAdapter onto the <strong>for</strong>m area. If other data providers are needed, choose the
appropriate OLEDB or ODBC Data Adapter. The wizard will start, and a
SqlDataAdapter1 object will be created in the Component Tray area beneath the
<strong>for</strong>m.
2. Reference the connection.
The next step of the wizard is to choose from a drop-down list of pre-existing
connections used with VS.NET or to generate a new connection. Clicking New
Connection brings up the DataLink Properties dialog box to create the new
connection object.
3. Choose a query type.
The wizard then allows the developer to choose between SQL statements or
stored procedures. As previously mentioned, it is best to use stored procedures
when possible.
4. Generate the SQL statements, stored procedures, or bind the commands.
Depending on the choice in the previous step, the developer will be given the
opportunity to provide or create an appropriate SQL statement. Inspecting the
PL/SQL code is described earlier in the section "PL/SQL Library."
5. Finish the wizard.
Now the Component Tray contains both the SqlDataAdapter1 and SqlConnection1
objects. The in<strong>for</strong>mation created from the wizard can be viewed in from the
Properties window of the designer or by looking at the generated code. The
Properties window of the DataAdapter shows the commands chosen (Delete,
Insert, Select, Update) and their respective properties.
6. Generate the DataSet.
Now that the reference has been made to the source and the pipe has been
created to work with the source, it is necessary to provide the client with the result.
The container necessary <strong>for</strong> this is a dataset. Because the dataset is based on the
in<strong>for</strong>mation provided by the adapter, Visual Studio .NET has a wizard to take
advantage of the in<strong>for</strong>mation stored within the adapter. This is done by rightclicking
the SqlDataAdapter1 inside the component tray, clicking Generate
dataset, and then choosing most of the defaults (except when the object is
renamed).
Using the Microsoft Data Access Application Block
The Data Access Application Block encapsulates per<strong>for</strong>mance and resource
management preferred practices <strong>for</strong> accessing SQL Server databases. If used, it will
reduce the amount of custom code needed to create, test, and maintain.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 295
Specifically, the Data Access Application Block helps you:
●
●
●
Call stored procedures or SQL text commands.
Specify parameter details.
Return SqlDataReader, DataSet or XMLReader objects.
Instead of using the wizards (which create numerous references to adapter, command,
and connection objects), the Data Access Application Block (DAAB) helps limit the
creation of datasets to as little as one line of code.
The Data Access Application Block is available at
http://www.microsoft.com/downloads/details.aspx?FamilyId=F63D1F0A-9877-4A7B-
88EC-0426B48DF275&displaylang=en. After downloading, compile the assembly in the
VB assembly. It will now be available to be referenced by any Visual Basic .NET
application.
Calling T-SQL Stored Procedures from Windows Forms
To call a stored procedure, you first need to identify the stored procedure, and then
create a DataReader or DataAdapter object. Each requires a database connection and a
reference to the stored procedure name through the CommandText property. Next, you
set the CommandType property to CommandType.StoredProcedure. Finally, any
stored procedure parameters need to be defined <strong>for</strong> input and/or output in a collection of
parameter objects. If the DataReader is used, then the developer must fill the appropriate
controls by iterating though the collection of rows returned and applying the values to the
controls. If the DataAdapter is used, then a DataSet must be filled and the controls must
be bound through the DataSource or DataBinding properties.
Testin g the Visual Basic .NET Application
The Visual Basic .NET application is a newly written application instead of a migrated
application. Even though <strong>Oracle</strong> Forms and Visual Basic are architecturally and
functionally similar, none of the code is reusable. Hence the application should undergo
unit testing using a procedure that would be followed <strong>for</strong> new development. However, this
newly developed Visual Basic .NET application does differ from other new development
projects. Remember that the Visual Basic .NET application was designed to mimic the
<strong>for</strong>m and function of the <strong>Oracle</strong> Forms application, while most applications are develop ed
based on documented requirements.
The objective of unit testing is to verify that the user interface closely resembles the
<strong>Oracle</strong>
Forms application and every component functions correctly. Start by visually
comparing every frame in th e <strong>Oracle</strong> Forms application to the corresponding window in
Visual Basic .NET. Ensure that all panels are present. E nsure that all the controls (items)
are accurately presented on the panel. Crosscheck all the visual components against the
Visual Model.
The event models differ from <strong>Oracle</strong> Forms to Visual Basic .NET. <strong>Oracle</strong> Forms contains
a nested hierarchy, with events being fired when moving through the window and its
objects. These have to be duplicated in Visual Basic . NET. Verify the behavior by
per<strong>for</strong>ming a walk-through of the entire application with tracing and debugging enabled.
The logs can later be reviewed <strong>for</strong> errors and execution sequences. Visual Basic .NET
p rovides a set of methods and properties that help you trace and debug the execution.
Interactive debuggers are also available in the Visual Studio .NET SDK.
The application should then be tested <strong>for</strong> functionality. Start with testing the menus and
then drilling down window-by-window. Test the functionality
of every control. Use the

296 Developing: Applications — <strong>Migrating</strong> <strong>Oracle</strong> Forms
same set of test cases in both applications. Populate the test data in the <strong>for</strong>m and click all
the controls. Verify that all the functional areas and navigation match the old application.
Validate that the presentation domain screens are all called by the application.
For detailed guidance about all aspects of testing your Visual Basic .NET application and
the available tools, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/vsent7/html/vxoriTestingOptimizing.asp.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 297
18
Stabilizing Phase
Introduction and Goals
During this phase, the test team verifies that the solution meets the defined quality levels
and that the risk of bugs is eliminated or minimized. Any existing bugs should not affect
critical functionality or per<strong>for</strong>mance. After the solution has been stabilized, it will be ready
<strong>for</strong> deployment into the production environment. This chapter highlights the processes of
stabilization as they relate to an <strong>Oracle</strong> on UNIX to Microsoft® SQL Server on
Windows® migration project.
The main goals <strong>for</strong> the Stabilizing Phase include:
● Improve the overall quality of the migrated solution and stabilize <strong>for</strong> release.
● Ensure that the solution meets the requirements of the project outlined in the
Envisioning and Planning Phases.
● Assemble all of the components of the solution and test the entire system be<strong>for</strong>e
deployment.
● Complete and validate documentation that is required <strong>for</strong> deployment, operations,
and end users.
● Evaluate and mitigate the risks involved in releasing the solution <strong>for</strong> deployment.
The deliverables produced during the Stabilizing Phase are listed in Table 18.1.
Table 18.1: Deliverables <strong>for</strong> the Stabilizing Phase
Task Deliverables Owner
Testing the solution Release versions of source Test Role
code, executables, release
version of scripts, and
installation documentation
Testing the solution Release versions of enduser
User Experience Role
training materials and
operations documentation
Testing the solution Release notes Release Management
Bug tracking and reporting Testing and bug reports Test Role
Piloting the solution Pilot Review Release Management
Piloting the solution Project documents Program Management
Piloting the solution Sign off document Project team

298 Stabilizing Phase
Testing
The Stabilizing Phase consists of two major activities: testing the solution and piloting the
solution. During testing, the entire ecosystem is evaluated, including the hardware,
software, database, connectivity layer, and the application. As a result of the testing,
bugs and issues will be tracked and resolved.
The second major activity of the Stabilizing Phase pertains to piloting the solution to a
select group consisting of end users, deployment, and operations personnel in the
production environment. Pilot testing also helps anticipate and resolve any issues that
may occur during deployment. While piloting the solution is optional, this activity is highly
recommended because components are deployed into the Windows environment that
were originally developed <strong>for</strong> another plat<strong>for</strong>m.
Testing is an iterative refinement process and is initiated every time there is a change to
the solution (including bug fixes). The occurrence of second and third iterations is
common in data migrations involving complex data integrity rules. Application testing will
vary based on the amount of modifications needed to migrate the solution application.
Fo r example, when an application is ported, the code coverage tests may be given
limited importance because the code base has not changed from the existing application.
The test team should accumulate complete knowledge of the software's functionality and
the tests that should be per<strong>for</strong>med to verify them. Often, the original design
considerations and approach used to create the existing solution are not available to the
migration team. This limits the effective knowledge of the test team. Testing should not
be limited only to the parts that the developers have identified as affected by the
migration. Changes in the backend database and the environment can manifest itself in
unpredictable places.
The project team should reuse test cases from the existing solution. If none exist, new
test cases can be created from the business requirements of the existing solution. Tests
can then be run against both the source and target systems in the migration project and
the results compared to identify deviations and bugs in the new solution.
Logs and audit reports that document any defects associated with the applications need
to be created and published to the entire team in conjunction with the tests per<strong>for</strong>med.
This is because the source of the bug and the place where it manifests itself may be
different. For example, even though a problem may be detected in the application, the
source may be a database configuration or a hardware setting.
Each iteration of testing helps make the subsequent iteration more robust and complete
than the previous one. This process must continue until an iteration has no exceptions.
The number of tests completed and the defect rate are used to measure progress and
schedule con<strong>for</strong>mance.
A c omprehensive series of tests is key to meeting the goals of the Stabilizing Phase.
The se tests provide assurances of the quality and stability of the solution. The following
sections provide in<strong>for</strong>mation about:
● Best practices
● Preparing <strong>for</strong> testing
●
●
●
the <strong>Solution</strong>
Types of testing
Bug tracking and reporting
User Acceptance Testing (UAT) and signoff

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 299
This in<strong>for</strong>mation will help you assure the quality and stability of the solution you have
developed.
Best Practices
When testing a solution, two important best practices are clearly defining the success
criteria and approaching testing with a zero-defect mindset.
Success Criteria
Judging whether a project has been successful is almost impossible without something to
measure the project's results against. Success criteria, also called key per<strong>for</strong>mance
indicators (KPIs), can be created by defining conditions under which the proposed
solution will achieve its goals. In a migration project, the success criteria can be gauged
by the effectiveness of the new solution. Does it effectively replace the existing solution in
terms of features, per<strong>for</strong>mance, and function based on results from the test cases?
Note Though measured in the Stabilizing Phase, success criteria <strong>for</strong> a project is
established during the Envisioning and Planning Phases.
Zero-defect Mindset
The concept of a zero-defect mindset should encompass the project team's commitment
to p roducing the highest quality product possible. Each member is individually
responsible <strong>for</strong> helping achieve the desired level of quality.
The zero-defect mindset does not mean that the deployed solution must be flawless;
rather, it specifies a predetermined quality bar <strong>for</strong> the deliverables. Oftentimes, the
project schedule will play a determining factor in achieving a zero-defect solution. In
situations where schedule does not allow <strong>for</strong> complete testing, tests should be prioritized
to ensure that all critical functionality is evaluated.
In addition, the zero-defect mindset concept should be carried throughout the dynamic
life cycle of the solution. For example, as the database scales over time, additional tuning
will be required to ensure optimum per<strong>for</strong>mance.
Preparing <strong>for</strong> Testing
Preparation <strong>for</strong> testing involves creating two key items:
● Test environment
● Bug tracking system
Each of these items is discussed under the following headings.
The Test Environment
The development and test plans provide a list of requirements that must be met by the
test environment, and the test environment should be set up according to them. The test
environment should be completely separate from the production environment. Although it
may not mirror the production environment, it is best if it does.
If the development phase is completed, the same hardware and software may be used to
test the solution. If the needs <strong>for</strong> the testing environment are more demanding, then
additional resources may be required. In some situations, it may be necessary to scale
the testing based on the available hardware.
In MSF, setting up the test environment starts toward the end of the Planning Phase. This
is to make sure that a test environment is available to the development team while

300 Stabilizing Phase
individual components are being developed. However, a full-scale test environment to
verify all aspects of an integrated solution will only be required in the Stabilizing Phase.
Another consideration of the testing environment is ensuring that it is properly tuned
be<strong>for</strong>e testing commences. Some recommended best practices <strong>for</strong> optimal tuning of
SQL Server running under Windows 2003 include:
● Format disk partitions using NTFS 5.0. This file system provides per<strong>for</strong>mance
enhancements in Windows 2003.
● Configure SQL Server as a stand-alone server. If configured as a domaincontroller,
additional resources are utilized, and per<strong>for</strong>mance is reduced.
● Set the Application Response setting to optimize <strong>for</strong> background services. This
setting allows background services to run at a higher priority than <strong>for</strong>eground
applications and is accessed through the System icon in the Control Panel. This
setting will improve the per<strong>for</strong>mance of SQL Server.
● Turn off additional security auditing. This will reduce I/O activities.
● Set the size of PAGEFILE.SYS. Monitor the usage of this swap file used by
SQL Server and resize the resources slightly larger than your needs.
● Turn off unnecessary services. Review all services and determine which can be
turned off.
● Turn off unnecessary network protocols.
For more in<strong>for</strong>mation on tuning the test environment, refer to
http://www.microsoft.com/windowsserver2003/evaluation/per<strong>for</strong>mance/tuning.mspx.
Bug Tracking <strong>Solution</strong>
An effective bug tracking system is needed to make sure that bugs are identified and
issues are not dropped until they have been completely resolved. Projects typically have
several hundreds or thousands of bugs. It is imperative to have a robust bug tracking
system in place to address these issues.
The bug tracking software <strong>for</strong> the project was selected during the Planning Phase. Using
this software from the beginning of testing allows all bugs identified through the life cycle
of the solution to be tracked in one location. This testing history can also be a useful
reference <strong>for</strong> future releases after the solution has been deployed.
Bug categorization is an important consideration during the configuration process of the
bug tracking solution. Variables required by the categorization may affect the
configuration of new and existing bug tracking solutions. These variables include:
● Repeatability. This is a variable that measures how repeatable the issue or bug is.
Repeatability is the percentage of the time the issue or bug manifests itself.
● Visibility. This is a variable that measures the situation or environment that must
be established be<strong>for</strong>e the issue or bug manifests itself. For example, if the issue or
bug occurs only when the user holds down the Shift key while right-clicking the
mouse and viewing the File menu, the percentage of obscurity is likely to be high.
● Severity. This is a variable that measures how much impact the issue or bug will
produce in the solution, in the code, or to the users. For example, a bug that
causes the application to crash would rank higher than situations that allow the
application to recover.
These three variables are estimated and assigned to each issue or bug by the project
team and are used to derive the issue or bug priority.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 301
Note The priority of a bug can be calculated by using the following <strong>for</strong>mula:
(repeatability + visibility) * severity = priority
Types of Testing
Often, the test environment is the first place that all of the separate components (that
have been unit tested in the Development Phase) are combined into a fully functional
version of the solution. The first task is to ensure that the disparate components of the
solution integrate properly. Next, ensure that the solution per<strong>for</strong>ms as expected. The next
series of tests check to ensure that the solution will work properly under heavy
workloads. The final set of tests check the solution <strong>for</strong> operational aspects.
The following types of testing are useful in an <strong>Oracle</strong> to SQL Server migration:
● Integration testing. Does the solution work as a cohesive unit?
● Per<strong>for</strong>mance testing. Does the solution meet the baseline requirements?
● Stress testing. How does the solution react to stresses and workloads?
● Scalability testing. How far will the solution scale? Can the system handle
increased load by adding new hardware as required?
● Operational testing. Do the operational aspects of the system per<strong>for</strong>m as
expected?
Each of these testing types is described under the following headings.
Integration Testing
The first level of testing in the Stabilizing Phase is integration testing, an iterative process
in which separate components are combined into larger solutions until the system is
complete. In integration testing, the focus is on the interfaces between components.
Integration testing proves that all areas of the system interface with each other correctly
and that there are no gaps in communication. The final integration test proves that the
enti re system works as an integrated unit.
Integration testing will also reveal any issues with shared resources. For instance, if
Pretty Good Privacy (PGP) encryption is used by more than one application, instead of
having a separate key <strong>for</strong> each application, multiple applications could potentially share a
single key.
If server consolidation is a business goal <strong>for</strong> this solution, then it has to be per<strong>for</strong>med at
this stage. For more in<strong>for</strong>mation on server consolidation, refer to
ht tp://www.microsoft.com/downloads/details.aspx?FamilyId=0F70695E-5D0B-4781-
8966-84BE43216F9E&displaylang=en.
Resolving Integration Issues
The major reasons issues arise during integration testing are incompatibilities or
inconsistencies in the design or implementation of the interfaces between components. In
a migration project, such issues are bound to occur because of interoperation between
applications, changes in command usage, and differences in protocols between the two
plat<strong>for</strong>ms. Such issues should be logged and <strong>for</strong>warded to the development team <strong>for</strong>
resolution. Another commonly encountered issue is resource shortage because several
components are being assembled <strong>for</strong> the first time. Additional resources, such as
processor, memory, and storage, should be made available to complete the testing.

302 Stabilizing Phase
Per<strong>for</strong>mance Testing
Per<strong>for</strong>mance testing involves evaluating how well the solution meets the expected
criteria. Testing <strong>for</strong> per<strong>for</strong>mance can be further defined by two sub-types:
● Application per<strong>for</strong>mance testing
● Hardware utilization per<strong>for</strong>mance testing
Application per<strong>for</strong>mance testing in a migration focuses on comparing various speed and
efficiency factors between the existing solution and the migrated solution. This ensures
that the migrated solution complies with the expected level of per<strong>for</strong>mance.
These key speed and efficiency factors include:
● Throughput. Database throughput measures the total number of transactions that
the server can handle in a given time frame. Baseline figures from the existing
solution are needed <strong>for</strong> comparison. Per<strong>for</strong>mance testing must be executed using
a workload that represents the type of operations that are most frequently
per<strong>for</strong>med in the production environment.
Note For a detailed discussion of baselines, see Appendix C, "Baselining."
●
Response time. Response time measures the length of time required to return the
first row of the result set.
The following resources can be used to conduct per<strong>for</strong>mance testing:
● Checklist: SQL Server Per<strong>for</strong>mance
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnpag/html/scalenetcheck08.asp.
● Windows 2003 Per<strong>for</strong>mance and Scalability
http://www.microsoft.com/windowsserver2003/evaluation/per<strong>for</strong>mance/perfscaling.
mspx
● Testing tools
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_perfmon_1qgj.asp.
● CPU Monitor
http://www.sysinternals.com/ntw2k/freeware/cpumon.shtml
● Disk Monitor
http://www.sysinternals.com/ntw2k/freeware/diskmon.shtml
Testing hardware per<strong>for</strong>mance in a cross-plat<strong>for</strong>m migration is recommended because
additional adjustments may need to be made to the proposed solution. There are no
reliable benchmarks that can provide equivalency per<strong>for</strong>mance statistics between the
UNIX and Windows plat<strong>for</strong>m. The results of benchmarks of the popular Transaction
Processing Per<strong>for</strong>mance Council (http://www.tpc.org/) can be used as a guideline. You
should ask the assistance of the vendors in per<strong>for</strong>ming lab testing of your solution to get
more accurate numbers on the proposed hardware. This testing validates the hardware
requirements <strong>for</strong> the solution.
While conducting per<strong>for</strong>mance tests, capture data regarding the utilization of resources
such as CPU, memory, disk I/O, and network bandwidth. This is important because if
your testing environment is not the same scale as the production load, then bottlenecks
in these resources may not be discovered until deployment. Resource utilization data,
captured at various load levels, can be used to draw conclusions about resource
requirements at production loads.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 303
●
●
Network Monitor
http://msdn.microsoft.com/library/default.asp?url=/library/enus/netmon/netmon/about_network_monitor_2_0.asp
File Monitor
http://www.sysinternals.com/ntw2K/source/filemon.shtml
Resolving Per<strong>for</strong>mance Issues
Per<strong>for</strong>mance problems can occur because of several reasons: application code,
database implementation, hardware configuration, software configuration, or resource
availability. The testing team should be able to solve configuration and resource
problems themselves, while issues with the application and database should be logged
and <strong>for</strong>warded to the development team, along with any analysis and supporting
evidence <strong>for</strong> resolution. Additional resources may have to be procured to solve resource-
related hardware issues.
Per<strong>for</strong>mance tuning can be an ongoing series of refinements and improvements. A large
amount of in<strong>for</strong>mation regarding per<strong>for</strong>mance tuning is available. For more in<strong>for</strong>mation,
refer to the following resources:
● The Data Tier: An Approach to Database Optimization
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/enus/part10/c3361.mspx
● Improving SQL Server Per<strong>for</strong>mance includes schemas, queries, indexes,
transactions, stored procedures, execution plans and tuning topics.
http://msdn.microsoft.com/sql/default.aspx?pull=/library/en-
us/dnpag/html/scalenetchapt14.asp
● How To: Optimize SQL Queries
http://msdn.microsoft.com/sql/default.aspx?pull=/library/enus/dnpag/html/scalenethowto04.asp
● How To: Optimize SQL Indexes
http://msdn.microsoft.com/sql/default.aspx?pull=/library/enus/dnpag/html/scalenethowto03.asp
● Microsoft SQL Server 2000 Index Defragmentation Best Practices
http://www.microsoft. com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx
● Using Views with a View on Per<strong>for</strong>mance
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/en-
us/part10/c3661.mspx
● Microsoft Storage <strong>Solution</strong>s — The Right Storage and Productivity <strong>Solution</strong>
http://www.microsoft.com/windowsserversystem/storage/solutions/rightsolution/righ
tsolution.mspx
Stress Testing
Stress testing is per<strong>for</strong>med to determine the load at which the per<strong>for</strong>mance is
unacceptable or the system fails. This involves loading the system beyond the use it was
designed <strong>for</strong> and checking <strong>for</strong> issues. When
per<strong>for</strong>ming stress tests, new bugs or issues
often may surface because of the high stress and load levels. At a minimum, stress
testing should load the system as defined in the business goals.
If the test environment is scaled down in relation to the production environment, the
limitations of the testing environment in relation to the production environment should be
considered in the results.

304 Stabilizing Phase
For example, with respect to applications, there may be a failure when the number of
simultaneous connections hit 100. This could be because of the limitation of some
variable associated with the code segment related to connection handling. Similar
problems may be encountered only during stress testing because there will be
differences in resource consumption and low-level implementation of the same functions
between the UNIX and Windows plat<strong>for</strong>m.
Resolving Stress Issues
Stress testing should be per<strong>for</strong>med only after all issues encountered during per<strong>for</strong>mance
testing have been fixed. Bugs encountered during stress testing can be because of the
application, the hardware configuration, or resource availability. Issues or bugs found with
the application have to be sent to the development team with any pertinent in<strong>for</strong>mation. If
the issues relate directly to hardware or hardware resources, they can be solved by
configuration or adding additional resources.
For example, SQL Server is not configured to take advantage of memory more than 2 GB
by default. If your hardware contains additional memory, this issue can be resolved by
correctly configuring SQL Server to take advantage of the server's available memory.
Microsoft offers two utilities, Read80Trace and OSTRESS, to assist in stress testing
SQL Server. To learn more or download these utilities, refer to
http://support.microsoft.com/?kbid=887057.
For detailed in<strong>for</strong>mation on scalability, refer to the following resources:
● Scaling out on SQL Server
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/en-
us/part10/c3861.mspx.
● SQL Server Scalability FAQ
http://www.microsoft.com/sql/techinfo/administration/2000/scalabilityfaq.asp.
● Microsoft SQL Server 2000 Scalability Project — Server Consolidation
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsql2k/html/sql_asphosting.asp.
● Windows 2003 Per<strong>for</strong>mance and Scalability
http://www.microsoft.com/windowsserver2003/evaluation/per<strong>for</strong>mance/perfscaling.
mspx.
Scalability Testing
Scalability testing is per<strong>for</strong>med to determine if the solution scales to handle an increasing
workload. The workload may be increased size, as in Very Large Databases (VLDB), or
more activity, such as transactions. Activity scalability is measured in number of user
connections, requests, reports, <strong>for</strong> example. The overall scalability is also dependent on
the hardware and the application. The application's throughput change as the load is
increased is a measure of its scalability. Also, the throughput may be measured with
increased resources along with the increased load.
Scalability testing, while similar to stress testing, provides additional in<strong>for</strong>mation to assist
in future solution expansion plans. Scalability testing is conducted to record how well the
migrated solution will scale or increase throughput as the user workload increases. It
differs from stress testing because scalability testing will generally load the solution far
past the minimum load levels defined in the Planning Phase.
If additional hardware is available, it is worthwhile to determine whether exceeding the
limits of the current solution requires a simple addition of hardware or a complete
redesign of the system.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 305
Resolving Scalability Issues
Issues of scaling should be documented as constraints of the system. If it is imperative
that the entire system scale to a certain point based on business goals, but the solution
does not meet these goals, then the resources (mostly hardware) have to be reevaluated
by experts. In most cases, vendors can provide support and in<strong>for</strong>mation in this
area.
Operational Testing
Operational testing is required to ensure that day-to-day functionality and maintainability
is developed and tested. This type of testing includes items such as:
● Backup routines
● Database maintenance tasks and schedules
● Documentation and processes developed <strong>for</strong> ongoing support
● Alert and monitoring processes
● Disaster recovery plans
If the solution is not going to be piloted, operational testing can be expanded to ensure
that the operations team is com<strong>for</strong>table with the processes and procedures needed to
maintain the system.
Resolving Operational Issues
Issues during operational testing are normally because of incomplete documentation of
the system requirements and configuration with respect to components that are found
only in the production environment. In most cases, the issues will have to be handled by
the operations staff who may seek in<strong>for</strong>mation and expertise from the project team.
Bug Tracking and Reporting
There are several important interim milestones in the iterative process of testing and
refining the solution be<strong>for</strong>e release. The interim milestones guide the tracking and testing
process. These milestones include:
● Bug convergence
● Zero bug bounce
● Release candidates
● Golden release
These milestones are discussed under the following headings.
Bug Convergence
Bug convergence is the point at which the team makes visible progress against the active
bug count. It is the point at which the rate of bugs that are resolved exceeds the rate of
bugs that are found.
Figure 18.1 illustrates bug convergence.

306 Stabilizing Phase
Figure 18.1
Bug convergence graph
Because the bug rate will still vary — even after it starts its overall decline — bug
convergence usually manifests itself as a trend instead of a fixed point in time. After bug
convergence, the number of bugs should continue to decrease until the zero bug bounce.
Zero Bug Bounce
Zero bug bounce (ZBB) is the point in the project when development resolves all the
bugs raised by the Test role and there are no active bugs — <strong>for</strong> the moment. Figure 18. 2
illustrates ZBB.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 307
Figure 18.2
Zero bug bounce
After ZBB, the bug peaks should become noticeably smaller and should continue to
decrease until the product is stable enough to release.
Careful bug prioritization is vital because every bug that is fixed creates the risk of
creating a new bug or regression issue. Achieving ZBB is a clear sign that the team is in
the final stage as it progresses toward a stable product.
Note New bugs will certainly be found after this milestone is reached. But it does mark
the first time that the team can honestly report that there are no active bugs — even if it
is only temporary. This can help the team maintain focus on a zero-defect mindset.
Release Candidates
After the first achievement of zero bug bounce, a series of release candidates are
prepared <strong>for</strong> release to the pilot group. Each of these releases is marked as an interim
milestone. The release candidates are made available to the pilot group so they can test
it. The users provide feedback to the project team, and the project team in turn continues
to improve the product and resolve bugs that appear during the pilot. As each new
release candidate is built, there should be fewer bugs to report, prioritize, and resolve.
The pilot group is discussed in m ore detail in the "Piloting the <strong>Solution</strong>" section later in
this chapter
Golden Release
Golden release is the release of the product to production. Golden release is a milestone
in the Stabilizing Phase that is identified by the combination of zero-defect and success
criteria metrics. At golden release, the team must select the release candidate that they
will release to production. The team uses the testing data that is measured against the
zero-defect and success criteria metrics to make this selection.

308 Stabilizing Phase
User Acceptance Testing and Signoff
User acceptance testing (UAT) is an additional testing process to determine if the
solution meets the customer acceptance criteria. Because this is a migration project, the
database and the existing solution have already passed these criteria. In most cases,
only the solution's operating environment has changed.
In migration projects, UAT should test whether the new solution produces the same
results from use cases as the existing solution. Whenever possible, use acceptance tests
from the existing solution as a base.
UAT can also affect the database. Part of testing should ensure that the SQL Server
database can be accessed by the client applications.
User signoff is obtained when the users agree that the solution meets the needs of the
end user. The user signoff is proof that the solution meets the user acceptance criteria in
relation to their business requirements. The user signoff indicates that the solution
con<strong>for</strong>ms to the requirements of the end-user (functionality) and the enterprise
(per<strong>for</strong>mance), and that the solution is ready to be deployed into production.
Piloting the <strong>Solution</strong>
A pilot program is a test of the solution in the production environment, and a trial of the
solution by installers, systems support staff, and end users. The primary purposes of a
pilot are to demonstrate that the design works in the production environment as expected
and that it meets the organization's business requirements. Pilot deployments are often
characterized by a reduced but key feature set of the system or a smaller end-user
group.
The pilot is the last major step be<strong>for</strong>e a full-scale deployment. Be<strong>for</strong>e the pilot, all testing
must be completed. This provides the opportunity to integrate and test other pieces of the
production environment that do not have any equivalent in the test environment.
The pilot also provides an opportunity <strong>for</strong> users to provide feedback about how the
solution works. This feedback must be used to resolve any issues or to create a
contingency plan. The feedback can help the team determine the level of support that
they are likely to need after full deployment. Some of the feedback can also contribute to
the next version of the application.
Note The success of the pilot contributes heavily to the deployment schedule. Issues
discovered during the pilot can delay deployment until the problems are resolved.
Every migration situation is unique, and some scenarios may not require a pilot program.
The pilot helps minimize the risks involved with the Deployment Phase. For instance, if
the migration involves a Perl application that is ported to run natively on the Windows
plat<strong>for</strong>m, the differences within the application could be minimal and, depending on other
mitigating factors, a decision may be made not to pilot the solution.
A pilot program is highly recommended in situations where any of the following instances
apply:
● The deployment plan is highly complex and the deployment team requires the
experience of the pilot deployment.
● The solution is prominent or critical to the organization. If the rollout must go
exactly as planned, a pilot will provide additional assurance.
● There is a large difference between the production and test environments.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 309
●
There are elements in the production environment that cannot be adequately
verified in the test environment.
Preparing <strong>for</strong> the Pilot
A pilot deployment needs to be rehearsed to minimize the risk of disruption <strong>for</strong> the pilot
group. At this stage, the development team is per<strong>for</strong>ming last-minute checks and
ensuring that nothing has changed since pre-production testing. The following tasks need
to be completed be<strong>for</strong>e starting the pilot:
● The development team and the pilot participants must clearly agree on the success
criteria <strong>for</strong> the pilot. In a migration project, the main success criterion is that the
new solution effectively replaces the existing solution.
● A support structure and issue resolution process must be in place. This process
may require that the support staff be trained. The procedures used <strong>for</strong> resolution
during a pilot can vary significantly from those used during the deployment and
when in full production.
● To identify any issues and confirm that the deployment process will work, it is
necessary to implement a trial run or a rehearsal of all the elements of the
deployment.
● It is necessary to obtain customer approval of the pilot plan. Work on the pilot plan
starts early during the Planning Phase so that the communication channels are in
place and the participants are prepared by the time the test team is ready to deploy
the pilot.
● Ensure that the plan effectively mirrors the deployment process. For instance, if the
migration solution is scheduled to be deployed in phases, the entire process
should be replicated <strong>for</strong> the pilot.
Note It is important to remember that a pilot program tests and validates the
deployment process as well as the solution.
A pilot plan should include the following:
● Scope and objectives
● Participating users, locations, and contact in<strong>for</strong>mation
● Training plan <strong>for</strong> pilot users
● Support plan <strong>for</strong> the pilot
● Known risks and contingency plans
● Rollback plan
● Schedule <strong>for</strong> deploying and conducting the pilot
Conducting the Pilot
Conducting the pilot involves deploying the applications and databases that have been
chosen to be part of the pilot. The golden release of the solution is used <strong>for</strong> pilot testing
against an audience consisting of actual users using real-world scenarios. When the pilot
is conducted in a production environment, care has to be taken to ensure that the existing
application and databases are not jeopardized. Hence, adequate support has to be
provided while conducting the pilot to monitor and fix any issues that arise.
Conducting a pilot also includes testing the accuracy of supporting documentation,
training and other non-code elements, such as cutover and fallback procedures. Any

310 Stabilizing Phase
changes made to these documents during the pilot have to be noted and the
documentation updated accordingly.
Note Ultimately, the pilot leads to a decision to either proceed with a full deployment
or to delay deployment so that issues can be resolved.
Evaluating the Pilot
At the end of the pilot, its success is evaluated to determine whether deployment should
begin. The project team then needs to decide whether to continue the project beyond the
pilot.
It is important to obtain in<strong>for</strong>mation about both the design process and the deployment
process. Review what worked and what did not work so that it is possible to revise and
refine the plan be<strong>for</strong>e deployment. Examples of in<strong>for</strong>mation to be gathered include:
● Training required <strong>for</strong> using the solution
● Rollout process
● Support required <strong>for</strong> the solution
● Communications
● Problems encountered
● Suggestions <strong>for</strong> improvements
The feedback is used to validate that the delivered design meets the design specification,
and the business requirements. After the data is evaluated, the team must make a
decision. The team can select one of following strategies:
● Stagger <strong>for</strong>ward. Prepare another release candidate and release it to the original
pilot group, then to additional groups. The release to more than one group might
have been part of the original plan or might have been a contingency triggered by
an unacceptable first pilot.
● Roll back. Return the pilot group to their pre-pilot state.
● Suspend the pilot. Put the solution on hold or cancel it.
● Patch and continue. Fix the build that the pilot is running and continue.
● Proceed to the Deploying Phase. Move <strong>for</strong>ward to deploy the pilot build to the full
live production environment.
Finalizing the Release
The Stabilizing Phase culminates in the Release Readiness Approved Milestone. This
milestone occurs when the team has addressed all outstanding issues and has released
the solution and made it available <strong>for</strong> full deployment. This milestone is the opportunity
<strong>for</strong> customers and users, operations and support personnel, and key project stakeholders
to evaluate the solution and identify any remaining issues they need to address be<strong>for</strong>e
beginning the transition to deployment and, ultimately, release.
After all of the stabilization tasks are complete, the team must <strong>for</strong>mally agree that the
project has reached the milestone of release readiness. As the team progresses from the
release milestone to the next phase of deploying, responsibility <strong>for</strong> on-going management
and support of the solution officially transfers from the project team to the operations and
support teams. By agreeing, team members signify that they are satisfied with the work
that is per<strong>for</strong>med in their areas of responsibility.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 311
Project teams usually mark the completion of a milestone with a <strong>for</strong>mal sign-off. Key
stakeholders, typically representatives of each team role and any important customer
representatives who are not on the project team, signal their approval of the milestone by
signing or initialing a document stating that the milestone is complete. The sign-off
document becomes
a project deliverable and is archived <strong>for</strong> future reference.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 313
19
Deploying Phase
Introduction and Goals
After envisioning, planning, developing, and stabilizing, the solution is ready to be
deployed. The Deploying Phase implements the tested solution in the production
env ironment. The migration project Release Management team deploying the solution
works with the operations team to successfully deploy and stabilize the solution. At the
close of the Deploying Phase, customer approval <strong>for</strong> the migration is obtained, and the
solution is transferred to the operations team. It is also possible that the operations team
handles the deployment with the aid of the project team. Irrespective of which team does
the deployment, the key goal of the Deploying Phase is to successfully migrate the new
solu tion into the production environment as smoothly as possible, and with the least
amount of disruption to the business environment or the end users.
The deployment rollout should be conducted as a series of activities. Though you can
abbreviate or combine some of these activities, you cannot skip any of them completely
with out increasing risk to the project's success.
Nearly all of these activities are per<strong>for</strong>med in conjunction between the project team and
the operations team. Coordination between the two teams is now a critical success
fact or. All decisions should be agreed upon by both of the teams to minimize risk. Both
team s are involved with completing the tasks and producing the deliverables shown in
Table 19.1.
Table 19.1: Major Tasks and Deliverables <strong>for</strong> the Deploying Phase
Tasks Deliverables Responsible Roles
Deploy the solution Deployment Checklist Release Management
Stabilize the deployment Deployment Checklist Release Management
Obtain the solution signoff Customer Sign Off Product Management
Transfer ownership Project Documents Program Management
Deploying the <strong>Solution</strong>
At the close of the Stabilizing Phase, the database and applications (server side and
client side) are fully tested and are ready <strong>for</strong> deployment. The release versions of the
source code, executables, scripts, and other installation in<strong>for</strong>mation are complete and
delivered to the deployment team.

314 Deploying Phase
While deployment is often discussed and planned singularly, there are actually three
separate components and technologies that must be deployed into the production
environment. These solution components are:
● Database server
● Server side application(s)
● Client side application(s)
Each of these components is discussed in this section. Each of these topics is divided
into two subtopics: process and technology. The process subtopics provide an overview
of the intricacies involved with the deployment of each of the solution components. The
technology subtopics include in<strong>for</strong>mation on software tools that can assist with the
deployments of the solution components.
Deploying the Database Server
The database should be deployed first because the server side and client side
applications are dependent on it. The process and technology required <strong>for</strong> setting up
database server and implementing databases are discussed under the following
headings.
Process
During the Planning Phase of the migration, all hardware needs are evaluated and any
required new equipment is acquired. During the Deploying Phase, the server must be set
up and configured <strong>for</strong> the Windows Server 2003 environment. The following procedure
describes the steps <strong>for</strong> deploying the database and its server:
1. The server should be built and delivered by your hardware vendor based on
specifications defined during the Planning Phase. If the server will be built from
existing equipment, ensure that the server is available and has the required
capacity to host the solution.
2. Install any necessary hardware. Commonly, items such as additional memory,
interface cards, additional storage, tape drives, or FDDA gigabit switches will need
to be installed to meet operational specifications.
3. Install the operating system, including any necessary service packs and patches.
This step can be per<strong>for</strong>med manually or by using imaging software. This topic is
discussed in greater detail in the technology portion of this section.
4. Configure any additional hardware that was installed. For instance, if NIC cards are
installed, they must be configured to match the settings of the network switch they
will connect to.
5. Install any additional applications needed <strong>for</strong> the server, such as monitoring
applications, backup software, asset management software, and software delivery
applications.
6. Select the deployment mechanism <strong>for</strong> the database. Some possible options
include:
● Use automated processes, such as installation and configuration scripts,
where possible.
● Use manual processes <strong>for</strong> some installation and configuration. These must
have detailed, step-by-step instructions.
7. Create the database deployment package by putting together the following:
● Microsoft® SQL Server installation and configuration scripts.
● Database
administration tools and utilities.
a

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 315
●
●
●
●
●
●
Database administration scripts and a scripting language such as Perl.
User database migration scripts.
Database administration tasks and packages, such as a maintenance plan,
jobs, and backup and restore procedures.
Windows® domain user accounts configuration scripts.
Scripts <strong>for</strong> configuring ODBC data sources, ADO, and OLE DB connection
strings.
Scripts <strong>for</strong> configuring COM+ components <strong>for</strong> database connection.
8. Create rollback scripts to undo or remove changes introduced by the deployment.
If a parallel cutover strategy is being employed, the scripts should disable the
replication. Not every aspect of the fallback can be scripted. A checklist of tasks
with detailed instructions should be prepared.
9. Add the deployment package to the configuration management database (CMDB).
Maintain change control of the release. Where a CMDB does not exist, a simplified
one should be created <strong>for</strong> release-tracking. The purpose of updating the CMDB is
to ensure that accurate knowledge is stored regarding all of the components or
configuration items that make up the releases.
10. Execute deployment package <strong>for</strong> the databases being migrated as per the phase-
12. If a straight cutover strategy is used, shut down the <strong>Oracle</strong> databases. If a parallel
out strategy.
11. Execute the scripts to create the database and its objects. The serial cutover
strategy will dictate the order in which the databases are migrated.
cutover is used, the databases may not be shut down. However, a quiet period is
required to enable the replication and ensure that the replication mechanism is
working properly. Start migrating the data.
13. Monitor the data migration <strong>for</strong> errors. If the migration has to be aborted, the
rollback scripts and other fallback steps should be per<strong>for</strong>med <strong>for</strong> each of the
databases affected by the failure (if the databases are related and have to be
migrated together).
Note If you must deviate from these scripts in the production environment, make
sure to alter the scripts to reflect the change and enter a note in the script or
documentation regarding what was altered, why, and whether you noticed any
issues afterward.
Technology
Setting up and configuring servers can be time-consuming, especially if additional
applications are needed <strong>for</strong> operations, monitoring, reporting, or other purposes. Based
on the needs of the deployment, there are two ways to deploy the server: manual
deployment and automated deployment using imaging tools. Imaging tools allow <strong>for</strong>
applications, operating systems, configurations, or drivers to be installed in one package,
instead of as individual installations. However, imaging can only be useful when setting
up identical servers using
identical hardware, as in a clustered set.
Manual Deployment
If a manual deployment is a consideration, a few guidelines should be noted. Often,
hardware vendors will provide customized installation CDs that contain specific drivers
and software needed <strong>for</strong> the configuration. Using these installation discs can reduce the
time needed <strong>for</strong> installation.

316 Deploying Phase
For the detailed manual installation procedure and configuration of
Windows® 2000 Professional, Windows® XP, Windows Server 2000 Advanced
Server, and Windows 2003 Server Enterprise Edition, refer to the help documentation
provided with the Windows operating system CD.
Note Manual installations of the operating system can be partially automated using an
answer file. This file provides the input that the setup needs to per<strong>for</strong>m the installation
and reduces the amount of user interaction needed during the installation process. For
details about creating an answer file and the options available in an answer file, refer to
http://www.microsoft.com/resources/documentation/windows/2000/server/reskit/enus/deploy/dghn_ans_wten.asp.
Another tool that can be utilized to assist in manual deployments is Microsoft Remote
Installation Services (RIS). RIS enables you to per<strong>for</strong>m system installations across a
network using an Active Directory service. For more in<strong>for</strong>mation on RIS, refer to
http://www.microsoft.com/windows2000/techinfo/planning/management/remote steps.asp.
The RDBMS should be installed manually using the Microsoft SQL Server Software
Distribution CD or a network installation tool such as RIS. For more in<strong>for</strong>mation on the
installation process <strong>for</strong> SQL Server 2000, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/instsql/in_overview_0v3l.asp.
Creation of the databases and database objects can be per<strong>for</strong>med using Data Definition
Language (DDL) scripts that have been generated from the test environment. This
in<strong>for</strong>mation can also be recreated manually using the Enterprise Manager GUI, but in
most instances the large number of objects that need to be created would make this
ef<strong>for</strong>t too time-consuming.
To create a database using the CREATE DATABASE command, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/tsqlref/ts_create_1up1.asp.
To create a database using the Create Database Wizard in Enterprise Manager, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/howtosql/ht_7_design_4g8p.asp.
DDL scripts can be run using Query Analyzer, a utility installed as part of SQL Server.
Third-party SQL Server tools can also be used. For more in<strong>for</strong>mation on Query Analyzer,
refe r to Appendix B.
Automated Deployment
Imagin g is an alternate method of deploying the operating system and all applications
and configurations simultaneously. Imaging captures a snapshot of the entire system,
including the operating system, applications, desktop settings, and user preferences.
Imagin g tools should be a serious consideration <strong>for</strong> deployments that consist of multiple
serv ers that require the same configuration. Creating images can greatly reduce the time
needed to prepare servers <strong>for</strong> deployment and also ensure consistent configuration.
To create an image, a master system must be manually configured with all necessary
software. After the server has been properly configured, the image is created using
imaging software. Finally, the image can be deployed to as many servers as required.
Each will be a clone of the master system.
The major benefits of using the imaging tools include:
● Deployments can be per<strong>for</strong>med simultaneously. All systems can be running in a
short time.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 317
●
All applications are bundled into the image.
The major drawback of imaging is that each type of hardware configuration requires a
separate image. You can only install images on target computers that have a compatible
hardware abstraction layer (HAL) to the reference computer. For instance, if a server
contains a different graphics card, it would require a separate image.
There are many different tools and utilities available that provide the capability to record
and deploy images. Here is a listing of some of these tools:
● Symantec Ghost (also called Norton Ghost) captures a complete system image <strong>for</strong>
redistribution. For detailed in<strong>for</strong>mation on using Symantec Ghost, refer to
http://service1.symantec.com/SUPPORT/ghost.nsf/pfdocs/.
● Automated Deployment Services (ADS) is designed to deploy Microsoft Windows
2000 Server, Advanced Server and Datacenter Server, and
Windows Server 2003 (all 32-bit editions). Other operating systems are not
currently supported. For detailed in<strong>for</strong>mation on how to use ADS, refer to
http://www.microsoft.com/windowsserver2003/technologies/management/ads/defa
ult.mspx.
Deploying the Server Side Applications
The steps <strong>for</strong> building the servers described in the previous section can also be used to
prepare the servers <strong>for</strong> the server-side applications. Detailed guidance <strong>for</strong> setting up the
server-side applications is discussed under the following headings.
Process
Though the server will be set up to meet the needs of your specific applications,
additional steps may be needed to prepare the hardware <strong>for</strong> deployment.
To deploy server-side applications, follow these steps:
1. Install the operating system and third-party components on the server as required
by the application.
2. Configure the server-side application components.
3. Install the server-side components on the server.
4. Add all configuration in<strong>for</strong>mation into the configuration management database
(CMDB) and maintain change control of the release. If a CMDB does not exist, a
simplified one should be created <strong>for</strong> release-tracking. Updating the CMDB ensures
that accurate knowledge is stored regarding all of the components or configuration
items that make up the releases.
5. Deploy the applications in conjunction with the deployment strategy being
employed <strong>for</strong> the databases.
6. After the database migration has been confirmed, per<strong>for</strong>m configuration changes to
the environment to activate the application.
7. If a fallback is required, then the application should be shut down and the original
configuration that points all users back to the original application should be
restored.

318 Deploying Phase
Technology
The server side application components can be either deployed manually or by using
imaging as discussed in the "Automated Deployment" section.
Manual Deployment
If manual deployment is chosen, each of the components of the server-side application
should be individually installed. First, install the language environments (such as Perl and
PHP) and any third-party utilities using the vendor's software distribution. Then install the
server-side application using the golden version of the source code from the project
team.
Automated Deployment
The deployment of the server-side applications can be automated by bundling it into the
image. The technology is the same as discussed <strong>for</strong> deploying the database.
Deploying the Client Application
After the server-side applications and databases have been deployed to production and
tested, the client application should be released. Often, this stage of the deployment can
be complex because of the number of users and components involved.
This is usually the point in the deployment process where the end users are affected. In
many cases, this is the first time that they are involved in the migration process. While
this guidance focuses on the application and database aspects of the migration, keep in
mind that there are many other items to consider. For instance, documentation, training,
and help desk support also need to be in place at the time of this deployment.
It is quite likely that the client computers are already in use. If not, build the hardware <strong>for</strong>
the client computers and deploy the required software.
Process
As with the other stages of deployment, the client application can be deployed manually
or through the use of automated tools. Consider the following steps when deploying the
client application.
1. Create the deployment package, which can include the following:
● The complete application, including the binary installation files and any
automation files.
● Client configuration and support files.
● Windows domain user accounts configuration scripts.
● Scripts <strong>for</strong> configuring ODBC data sources, ADO, or OLE DB connection
strings.
● Scripts <strong>for</strong> configuring COM+ components <strong>for</strong> database connection.
● Acceptance test scripts and packages.
2. Create rollback scripts to remove changes introduced by the deployment. Rollback
scripts provide an alternate option if an uncorrectable issue arises during the
server, database, or application deployments.
3. Add the deployment package to the configuration management database (CMDB).
Maintain change control of the release. Where a CMDB does not exist, a simplified
one should be
created <strong>for</strong> release-tracking.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 319
4. When the database and application migration are completed successfully, deploy
the client application. In addition to the database and application deployment
strategy, a horizontal phase-out strategy may be employed <strong>for</strong> client applications.
5. If a fallback is required, then the application should be rolled back to the previous
one and the original configuration that points all clients back to the original
application should be restored. If the fallback is due to an application issue, then a
horizontal phase-out strategy reduces the rollback ef<strong>for</strong>t.
Technology
When deploying the client application, additional tools may be required to efficiently
manage the deployment. Some common tools used <strong>for</strong> packaging applications and
utilizing distribution channels include:
● MSI (or Windows Installer) is a Microsoft solution <strong>for</strong> application packages. This
installer provides additional functionality and integration with the Windows
environment, including elevated privileges <strong>for</strong> installation and deployment across
an Active Directory. To download Windows Installer or learn more about it, refer to
http://www.microsoft.com/downloads/details.aspx?FamilyID=5fbc5470-b259-4733-
a914-a956122e08e8&DisplayLang=en.
● Visual Studio Installer creates setups based on the Microsoft Windows Installer
technology in the Visual Studio IDE. For detailed step-by-step instructions <strong>for</strong>
Visual Studio Installer, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vsinstal/html/vehowvisualstudioinstallerquickstart.asp.
● WinINSTALL LE creates packages by recording a snapshot of a systems
environment be<strong>for</strong>e and after an application is installed, then records all of the
changes between snapshots to generate the installation package. For more
in<strong>for</strong>mation about WinINSTALL LE, refer to
http://www.ondemandsoftware.com/FREELE2003 /.
● Wise Package Studio is a tool used <strong>for</strong> packaging/repackaging applications using
Wise script or an MSI file. Scripts, checks, and conditions can be embedded into
the package, which also helps in deploying or distributing the package. For more
in<strong>for</strong>mation on Wise Package Studio, refer to
http://www.wise.com/wps.asp?bhcp=1.
● InstallShield AdminStudio can also create a scripted package file or an MSI
package. The repackaging methodology is same as that of Wise Package Studio.
For more in<strong>for</strong>mation about InstallShield, refer to
http://www.installshield.com/downloads/isas/evalguide/AdminStudio5_Evaluator_<strong>Guide</strong>.pdf.
● IntelliMirror uses a Windows Installer server to provide distributions to client
computers. When an application is launched, IntelliMirror checks to ensure that the
application is loaded and up to date. If not, the needed files are downloaded and
installed on the system. Because IntelliMirror checks <strong>for</strong> updated versioning every
time the application is launched, this software can be used to manage all future
releases of the client application. For more details on IntelliMirror, refer to
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/p
roddocs/enus/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddoc
s/en-us/sag_imirror_top_node.asp.
● Windows Installer automatically reads an MSI file and deploys the application
packaged as an MSI file. The MSI file can be customized <strong>for</strong> the features,
installation location, and so <strong>for</strong>th. Windows Installer can also per<strong>for</strong>m a silent install
of the MSI file when provided with that option. For an overview of Windows

320 Deploying Phase
●
●
Installer, refer to
http://www.microsoft.com/windows2000/en/advanced/help/default.asp?url=/window
s2000/en/advanced/help/sag_WinInstall_Technology.htm?id=3991.
Active Directory is a core feature in the Windows server operating system which
not only handles security and privileges of the domain, but also has the capability
to distribute MSI files. Group Policy policy settings can be set in Active Directory to
distribute the required MSI file. Active Directory can be used efficiently to distribute
the files at off hours or weekends to avoid blocking network congestion. For further
in<strong>for</strong>mation about Active Directory, refer to
http://www.microsoft.com/windowsserver2003/technologies/directory/activedirector
y/default.mspx.
Systems Management Server (SMS) is a tool from Microsoft <strong>for</strong> distributing
software packages. SMS has various features, such as packaging, distributing,
deploying applications, and monitoring. For step-by-step procedures <strong>for</strong> distributing
a package using SMS, refer to
http://www.microsoft.com/downloads/details.aspx?FamilyID=32f2bb4c-42f8-4b8d-
844f-2553fd78049f&DisplayLang=en
Not
e The tools listed previously have not been tested in a lab environment as part of
this solution.
Change Management
Change management is the process <strong>for</strong> controlling changes to a protected environment.
In the Stabilizing Phase, changes are made to the test environment related to bug fixes
and promoting the builds. Changes made to the solution in the production environment
are handled more strictly because they can affect the end users of the application as well
as other users of the production environment. Any proposed changes must go through
the change approval process to ensure that the changes will not adversely affect the
production environment.
For detailed in<strong>for</strong>mation on Change Management, refer to
http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx.
Stabilizing the Deployment
After the server-side application components, database, and client-side application
components are deployed, every aspect of the deployment must be validated to ensure
that the migration has been per<strong>for</strong>med successfully. Common items to check are
included in the deployment checklist discussed in the following sections.
Deployment Checklist
The product manager and the operations team should ensure that the solution meets the
business requirements and standards determined during the Envisioning Phase. The
checklist developed during the Planning Phase should contain the acceptance criteria
that evaluate the per<strong>for</strong>mance of the solution. It should also provide a baseline <strong>for</strong> the
customer to approve the solution. The following categories should be included in the
checklist to test the solution be<strong>for</strong>e signoff:
● Server
● Database
● Application (client and server side)

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 321
●
Additional considerations
These categories are discussed under the following headings.
Server
The following are some server-related items that should be considered <strong>for</strong> the checklist:
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Have all relevant service packs been loaded to the production servers? Are the OS
and installed service pack level well known and documented? You will need this
in<strong>for</strong>mation if the systems fail and manufacturer support is required.
Have the settings from the per<strong>for</strong>mance tuning in the test environment during the
Stabilizing Phase been transferred correctly? At the same time, ensure that any
configurations unique to the testing environment have not been transferred to the
production environment.
Have backup power systems been fully tested to ensure proper operation?
Are an appropriate number of replacement hard disks on hand in case of failure in
an array?
Are the default client connection network library settings established on the server?
Are all database and application server installation settings documented (such as
sort orders and default language)?
Has communication between servers been checked to assure that proper DNS
resolution and routing is functioning as expected?
Are alerts defined <strong>for</strong> key problems and conditions? Who monitors the e-mail
address to which these are sent? Are pagers used? Has the alert system been
tested?
Has the team removed guest accounts from the system and checked to ensure
that this does not affect the application?
Is the appropriate level of directory security set?
Has security logging been implemented?
Have all non-essential services and open ports on the server been identified and
closed?
Has the team tested production integration with third-party systems?
Have any and all event log messages been identified and investigated?
Does the OS have sufficient client access licenses <strong>for</strong> the expected peak traffic
loads?
Are sufficient client access licenses and connections installed <strong>for</strong> the OS? Is this
being monitored to assure that it does not reach its limit?
Are system configurations <strong>for</strong> all tiers backed up? Were scripts created to reset
configurations in an emergency or to bring up a new server? Are they in a wellknown
location?
Have server backups been tested? Are procedures in place <strong>for</strong> proper storage and
retrieval?
Have clustering software configuration and failover operations been tested?

322 Deploying Phase
Database
The following are some database-related items that should be considered <strong>for</strong> the
checklist:
● Have all database creation scripts been executed properly and without errors?
● Were the database statistics updated be<strong>for</strong>e launch?
● Have the database backups been tested to ensure that backup mechanisms are
operating properly? Have restoration procedures been tested on the solution
server and on different hardware to test failover procedures? Are off-site backup
procedures in place?
● Has database security been addressed and appropriate logon accounts created?
Is the system administrator's (SA) account password blank? Are applications using
the SA account or other account(s)?
● Did the team define, test, schedule, and sign-off on maintenance plans?
● Has a schedule been established <strong>for</strong> the transaction log dumping that will be
sufficient to recover activity to the satisfaction of the business? Has it been tested?
● Are sufficient client access licenses installed <strong>for</strong> the database server? Are these
being monitored to assure that they do not reach their limit?
● Has the latest build of the database from the development environment been
migrated, installed, tested, and verified within the production environment?
● The user databases should be checked to ensure that all the data from the
database is transferred from the source solution to the target solution during
deployment.
● Has the database been loaded in the production environment with clean data, and
have initial inventory levels been set? Have feeds from other systems been verified
under load to ensure that system availability is unaffected at the time they run?
● Is the database running on the default port of 1433? If so, can this be changed to
another port or ports to enhance security of the application without affecting proper
operation?
● Are non-essential SQL Server services running (MS Search, OLAP)? Stop them if
they are not required.
● Are non-essential databases installed on the server? Remove databases such as
pubs or Northwind, but be careful not to remove needed system databases such
as model, tempdb, or master.
● Is the database correctly tuned, and does it have the proper memory usage
settings applied?
● Is disk space sufficient <strong>for</strong> the expected size of the data 6-12 months ahead?
● Have clustering software configuration and failover operations been tested with the
databases?
Application (Client Side or Server Side)
The following list offers some client-side or server-side application-related items that
should be considered <strong>for</strong> the checklist:
● Are the proper security settings <strong>for</strong> the applications set and documented?
● Has application logging been enabled or disabled, as required?
● Has the golden release of the applications and other components been given a
release number, archived, then deployed? Confirm that the golden release of the
source code matches the version of the application that was released.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 323
●
●
●
●
●
●
●
Are all required environmental settings <strong>for</strong> the applications set and documented?
Are all third-party software or components that are required by the system installed
and documented (such as version numbers and vendor contact in<strong>for</strong>mation)?
Ensure that the client application properly connects to the database. Per<strong>for</strong>m
cursory testing of the application that is not intrusive and does not change the
production database. For example, running production reports is a good way to
test database functionality without changing the live data.
Has connectivity between the middle-tier system and any back-end systems been
tested under load? Has connection pooling been monitored to assure proper
operation?
Are the activation types <strong>for</strong> any COM+ applications set properly? Has the
application been tested with the consoles logged on and logged off to assure the
proper identity is used?
Has the application integration been tested with third-party systems?
Have clustering software configuration and failover operations been tested with the
applications?
Additional Considerations
Here are some additional considerations that could apply to your environment. Some of
the tasks per<strong>for</strong>med here are related to operations. Validating these tasks during
deployment ensures operations is prepared to manage the solution and SLAs can be
met.
● Are scheduler jobs defined <strong>for</strong> common tasks? Jobs such as backups and health
reporting are normally scheduled through a scheduler such as cron in UNIX.
These may have been migrated over.
● Has a disaster recovery plan (DRP) been established that includes database
procedures?
Who is the DRP team leader? Is the leader's contact in<strong>for</strong>mation well
known, and is a contingency leader appointed?
● Has the team enabled change-control procedures <strong>for</strong> the operations environment?
● Has the team finalized the operational processes and guidelines?
● Has the team developed, tested, and simulated disaster recovery procedures?
● Was an external connection used when testing the application against the
operations system? The external connection should be similar to what a customer
will use.
● Was solution training delivered?
● Is the processing speed acceptable?
● Have the business objectives and requirements been met?
● Have operation tests been per<strong>for</strong>med? Steps should be taken to make sure that
the operations team can properly track the servers and services with their
monitoring tools.
Quiet Period
The quiet period <strong>for</strong> the target environment begins after stabilizing the deployed solution
and continues until the deployment is complete. It usually exists <strong>for</strong> a period of 15 to 30
days. During this period, the operations team manages the deployed solution.
No significant changes should be made to the solution. However, a member from the
project team may aid the operations team to manage and resolve problems that can
affect the working of the deployed solution. This enables the organization to estimate the

324 Deploying Phase
maintenance costs of the solution and prepare a budget. Changes made to the solution
will be through the process of Change Management.
During the quiet period, the efficiency of the solution can be ascertained by evaluating the
following:
● <strong>Solution</strong>'s stability
● <strong>Solution</strong>'s downtime
● Maintenance required by the solution
Transferring Ownership to Operations
The final transition occurs when the project team completes its tasks and transfers the
infrastructure, documentation, and operations to the Operations team. The ownership of
the solution is also transferred to the Operations team.
The Operations team has to understand the functioning of the solution and manage it.
The solution's documentation should supply in<strong>for</strong>mation required to manage the solution.
The Operations team will require the following documents to handle the solution after
migration:
● User manual. The user manual details the procedures <strong>for</strong> working with the
solution. It also details the procedures <strong>for</strong> installation and solution maintenance.
● Hardware specifications. This document describes the hardware used in the
production environment.
● Software specifications. This document covers the different applications, such as
third-party software used by the solution itself or used to stabilize the deployment.
The software specifications also detail the different configurations and settings
applied to the solution during or after the installation and deployment of the
solution.
● Support policies and procedures. This document details the updated business
policies and procedures that need to be followed after the migration is complete.
Project Team Tasks
The project team will examine the deployment to ensure that all areas of the deployment
are successfully completed and functioning as required. A final run of the tests that
caused discrepancies can be used to check that they have been fixed. The project team
ensures that:
● All the procedures of the migration have been followed.
● Backups are per<strong>for</strong>med as required.
● All security measures (hardware and software) are in place and operate without
issues.
● All errors and bugs are fixed.
● Adequate training is provided to operations to manage the solution.
● Different user accounts have been created and checked <strong>for</strong> their functionality.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 325
Operations Team Tasks
The operations team will check the solution to ensure that it con<strong>for</strong>ms to the business
objectives. The operations team will:
●
●
●
●
●
Conduct a final run through of the solution to check its per<strong>for</strong>mance and stability.
Ensure that the project team has completed all the tasks needed to complete the
deployment.
Check that the tools to per<strong>for</strong>m routine tasks are set up.
Review the documentation.
Decide the frequency <strong>for</strong> per<strong>for</strong>ming routine tasks.
Conducting Project Review and Closure
After the deployment of the solution is complete, the team conducts a review meeting to
assess the migration project. This review covers all the phases of the migration project,
including the Envisioning, Planning, Developing, Stabilizing and Deploying Phases. By
taking the time to discuss the entire migration project, important lessons can be learned
and applied to future endeavors. This will also highlight the positive actions taken to
successfully migrate the solution, and the less positive decisions or actions that delayed
or hindered the migration. The project review can also compare the estimated outcome of
the migration project with the actual targets achieved.
The customer sign-off signifies the end of the Deploying Phase. The solution's key
stakeholders review the migrated solution and documentation and confirm that the needs
of the project have been met. After this sign-off has been received, the project team can
be disengaged. The exact terms of this sign off will depend on the migration requirements
<strong>for</strong> the project.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 327
20
Operations
Introduction and Goals
After the solution has been deployed, the operations staff inherits ownership of the
solution and is required to manage and maintain it. The operations team has been
prepared <strong>for</strong> this task by its involvement in the Deploying and Stabilizing Phases and by
reviewing the documentation prepared by the project team. Even if the Windows®
environment existed be<strong>for</strong>e the migration, this project will have a great impact on
operational tasks and responsibilities. This chapter provides additional links to guidance
on how to operate the production infrastructure containing Microsoft® SQL Server and
Windows technologies.
Operational Framework
With the penetration of technology into every aspect of modern day business, success is
based not only on the technology but also on the people and processes that control the
technology. The migration project has only contributed the technology and not the
operational aspects of the deployed solution. Microsoft Operations Framework (MOF) is a
collection of best practices, principles, and models. It provides comprehensive technical
guidance <strong>for</strong> achieving mission-critical production system reliability, availability,
supportability, and manageability <strong>for</strong> solutions and services built on Microsoft products
and technologies.
The following links provide in<strong>for</strong>mation about the operational framework:
● Microsoft <strong>Solution</strong>s <strong>for</strong> Infrastructure and Management (MSIM) provides in-depth
technical procedural guidance on the management and operation of Windowsbased
servers and computer data centers. More in<strong>for</strong>mation is available at
http://www.microsoft.com/tech net/itsolutions/cits/mo/default.mspx.
● A brief overview of the MOF process model and concepts is provided in "Appendix
A" of the UNIX Migration Project <strong>Guide</strong> (UMPG):
http://go.microsoft.com/fwlink/?LinkId=19832.
● An entire discussion of MOF, its Service Management Functions (SMFs), and all
the resources that support the framework, is available at
http://www.microsoft.com/technet/itsolutions/techguide/mof/m ofpm.mspx.

328 Operations
Windows Environment Operations
This section provides in<strong>for</strong>mation about various aspects of a Windows Server 2003
deployment in an enterprise environment.
System Administration
●
●
For common administrative tasks, refer to
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/wi
ndowsserver2003/proddocs/entserver/ctasks_topnode.asp.
For tools, refer to
http://www.microsoft.com/windows server2003/downloads/tools/default.mspx.
● The Active Directory Operations <strong>Guide</strong> is available at
http://www.microsoft.com/downloads/details.aspx?familyid=84dfe61e-fb7b-4673-
89b8-55bcc801b431&displaylang=en.
●
●
A technical overview of network load balancing is available at
http://www.microsoft.com/technet/prodtechnol/acs/reskit/acrkappb.mspx.
Security Administration
●
●
●
●
●
●
The Windows Server 2003 <strong>Guide</strong> is available at
http://www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch00.msp
x.
A source containing a wide range of security topics and technologies is available at
http://www.microsoft.com/security/guidance/default.mspx.
For best practices <strong>for</strong> implementing a Microsoft Windows Server 2003 Public Key
Infrastructure, refer to
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/se
curity/ws3pkibp.mspx.
In<strong>for</strong>mation on account passwords and policies is available at
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/se
curity/bpactlck.mspx.
In<strong>for</strong>mation on certificate templates is available at
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/se
curity/ws03crtm.mspx.
The Security Services FAQ is available at
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/p
roddocs/enus/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddoc
s/en-us/safer_howto.asp.
Security checklists <strong>for</strong> securing Windows 2003 Server are available at
http://www.microsoft.com/security/guidance/checklists/default.mspx.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 329
Monitoring
●
●
●
In<strong>for</strong>mation on the tools available <strong>for</strong> monitoring is available at
http://www.microsoft.com/resources/documentation/WindowsServ/2003/enterprise/
proddocs/enus/Default.asp?url=/resources/documentation/WindowsServ/2003/enterprise/prodd
ocs/en-us/tools_monitoring_status.asp.
For monitoring of server per<strong>for</strong>mance, refer to
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/wi
ndowsserver2003/proddocs/entserver/ctasks019.asp.
For monitoring of security-related events, refer to
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/wi
ndowsserver2003/proddocs/entserver/ctasks018.asp.
Additional Links
●
●
●
In<strong>for</strong>mation on Windows Server 2003 per<strong>for</strong>mance and scalability is available at
http://www.microsoft.com/windowsserver2003/evaluation/per<strong>for</strong>mance/perfscaling.
mspx.
In<strong>for</strong>mation on account management <strong>for</strong> Windows Server 2003 is available at
http://www.microsoft.com/business/reducecosts/efficiency/manageability/account.
mspx.
Best practices <strong>for</strong> managing Windows Server 2003 are available at
http://www.microsoft.com/technet/community/events/windows2003srv/tnt1-
106.mspx.
SQL Server Environment Operations
This section provides in<strong>for</strong>mation on various aspects of a SQL Server 2000 deployment
that can be used to ensure optimal per<strong>for</strong>mance in an enterprise environment.
Per<strong>for</strong>mance is also critical to scalability.
Administration
● For detailed in<strong>for</strong>mation on SQL Server administration, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_adminovw_7f3m.asp.
● In<strong>for</strong>mation about administration subjects is available at
http://www.microsoft.com/sql/techinfo/administration/2000/default.asp.
● For detailed discussions on topics such as indexes, statistics, automation, and
memory management, refer to SQL Server 2000 Operations <strong>Guide</strong>: System
Administration at
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlops4.mspx.
● In<strong>for</strong>mation about backup and recovery is available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_bkprst_9zcj.asp.
● A discussion on recovery models is available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsqlmag2k/html/dbRecovery.asp.

330 Operations
Security
For detailed discussion on managing security, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_security_05bt.asp.
Monitoring
For monitoring of system per<strong>for</strong>mance and activity, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_mon_perf_00mr.asp.
Additional Links
The following links provide in<strong>for</strong>mation on SQL Server 2000 environment operations:
●
●
In<strong>for</strong>mation about security patch management <strong>for</strong> SQL Server is available at
http://www.microsoft.com/business/reducecosts/efficiency/manageability/patch.ms
px.
The SQL Server 2000 Operations <strong>Guide</strong> is available at
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlops0.mspx.
Also refer to Appendix B, "Getting the Best out of SQL Server 2000 and Windows," <strong>for</strong>
links to additional in<strong>for</strong>mation about per<strong>for</strong>mance,
scalability, and high availability.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 331
APPENDICES
Appendix A: SQL Server <strong>for</strong> <strong>Oracle</strong> Professionals
One of the assumptions of this guide has been that both <strong>Oracle</strong> and
Microsoft® SQL Server database administration experience is available in the project
team. The success of the migration depends on how well the requirements of the current
environment are translated into the SQL Server environment. The knowledge and
involvement of the custodians of the current environment, the <strong>Oracle</strong> DBAs, is very
important. A separate set of <strong>Oracle</strong> and SQL Server DBAs working on the migration has
the disadvantage of possible communication problems and cost. Hence training the
Ora
cle DBAs in SQL Server will serve the purpose of per<strong>for</strong>ming the migration, retaining
DBAs with valuable knowledge of the business and the databases, and preparing them to
manage the new SQL Server environment.
The purpose of this appendix is to provide a primer <strong>for</strong> <strong>Oracle</strong> DBAs in the workings of
SQL Server and its administration. The transition from <strong>Oracle</strong> to SQL Server is eased by
the
several similarities that exist between the two RDBMSs. Some of the key
commonalities include:
● Relational engine. Both <strong>Oracle</strong> and SQL Server use an optimizer to generate an
optimal execution plan from alternative solutions using statistics and access paths.
The execution plan can be influenced by optimizer hints.
● Process architecture. Both <strong>Oracle</strong> and SQL Server have specialized processes
<strong>for</strong> user connections (shared) and dedicated database functions. SQL Server uses
threads and provides CPU affinity, features that are found in <strong>Oracle</strong> on Microsoft
Windows®.
● Memory architecture. In both <strong>Oracle</strong> and SQL Server, memory is broken up into
buffers or caches with separate memory areas <strong>for</strong> SQL, procedural SQL, data
dictionary, and session. Database buffers or caches are manipulated in terms of
pages/blocks. Both have similar buffer replacement policies (Least Recently Used
policy).
● Storage architecture. In both <strong>Oracle</strong> and SQL Server, the physical database is
structured as data files, system files, transaction logs, and control files. Logical
structures to complement the physical structures are hierarchical in nature.
● Backup options. <strong>Oracle</strong> and SQL Server provide various options <strong>for</strong> backing up
databases, such as online backups, full and partial backups, and transaction log
backups.
● Recovery model. Both <strong>Oracle</strong> and SQL Server use transaction logs (redo) and
rollback. Recovery is possible using single file backups, transaction logs, and so
on.
● Tools. Both <strong>Oracle</strong> and SQL Server employ Enterprise Manager, SQL client
Architecture
An understanding of SQL Server architecture and how it compares and contrasts with
<strong>Oracle</strong> is fundamental in shaping the migration as well as extracting the optimal
per<strong>for</strong>mance out of the SQL Server plat<strong>for</strong>m.

332 Appendices
<strong>Oracle</strong> and SQL Server are very similar in their architecture and internal workings.
However, the same terms have different meanings in the two environments. For example,
in <strong>Oracle</strong> the term instance is used <strong>for</strong> the memory and processes that support an <strong>Oracle</strong>
database. However, in SQL Server, the term instance contains the memory, processes,
and also the user databases. Irrespective of the terminologies used, SQL Server also
uses memory and process components in a manner similar to <strong>Oracle</strong>. In this discussion,
SQL Server is presented to the <strong>Oracle</strong> DBA using an <strong>Oracle</strong>-like view.
Database and Instance
A database, by definition, is the repository <strong>for</strong> data and metadata (data dictionary). This
definition is universal in nature. In <strong>Oracle</strong>, the term database is used to specifically refer
to the files that are used to store the database's data and metadata. The term instance is
used <strong>for</strong> the memory structures (System Global Area is the main component) and
processes that are required to access and per<strong>for</strong>m work against the database. In SQL
Server, the instance is used collectively <strong>for</strong> the data files, memory, and processes. Figure
A.1 illustrates the similarities between instances of <strong>Oracle</strong> and SQL Server with respect
to memory and processes. Only the important components of an instance—the SGA and
the processes — are covered in the figure. Details of the SQL Server architecture can be
found at http://msdn.microsoft.com/SQL/sqlarchitecture/default.aspx.
Figure A.1
<strong>Oracle</strong> and SQL Server 2000 – High level comparison of Instance and Database in <strong>Oracle</strong> and SQL
Server to show architectural similarities
Apart from the defined meaning of the terms instance and database in <strong>Oracle</strong> and SQL
Server, the terms are used very loosely to mean an occurrence of the database. The
phrase “multiple instances or multiple databases running on a single database server” is
a typical usage of this terminology. Database administrators should be able to infer the
meaning from the context.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 333
What can be confusing with SQL Server is the presence of several system and usercreated
“databases” inside a SQL Server database. Hence the term database system
has been coined here to mean an occurrence of <strong>Oracle</strong> or SQL Server. Multiple
Database Systems (Instances)
In <strong>Oracle</strong>, multiple database systems can be created on a single server and the creation
is independent of the software installation (using the CREATE DATABASE SQL
command). The same is not true with SQL Server. The initial database system (default or
named) is created as part of the software installation. The software distribution is also
needed to create additional database systems. For in<strong>for</strong>mation on working with named
and multiple instances of SQL Server 2000, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/instsql/in_runsetup_2xmb.asp.
The following components are shared between all of the instances running on the same
computer:
● There is only one SQL Server 2000 program group (Microsoft SQL Server) on the
computer, and only one copy of the utility represented by each icon in the program
group. There is only one copy of SQL Server Books Online.
● The versions of the utilities in the program group are from the first version of SQL
Server installed on the computer.
● There is only one copy of the MSSearchService that manages full-text searches
against all of the instances of SQL Server on the computer.
● There is only one copy each of the English Query and Microsoft SQL Server 2000
Analysis Services servers.
● The registry keys associated with the client software are not duplicated between
instances.
● There is only one copy of the SQL Server development libraries (include and .lib
files) and sample applications.
Extending out to the client tier, the <strong>Oracle</strong> clients and SQL Server clients connect to
databases in similar, albeit proprietary, protocols: Transparent Network Substrate (TNS)
<strong>for</strong> <strong>Oracle</strong> and Tabular Data Stream (TDS) <strong>for</strong> SQL Server. Figure A.2 compares the
user-instance-database interaction paths.

334 Appendices
Figure A.2
<strong>Oracle</strong> and SQL Server 2000 — User-instance database interaction compared
Unlike <strong>Oracle</strong>, SQL Server does not store client configuration in<strong>for</strong>mation in an operating
system file. SQL Server uses registry keys to store such in<strong>for</strong>mation. By default, SQL
Server is configured to listen on TCP/IP network protocol, which should suffice <strong>for</strong> most
installations migrating from <strong>Oracle</strong>. The server network utility (part of the server
installation) can be used to configure SQL Server to listen on named pipes, multiprotocol,
NWLink, IPX/SPX, Banyan VINES, and Appletalk protocols.
On the client side, the client network utility (part of the client installation) can be used to
set up alias names <strong>for</strong> SQL Servers. The alias names can be mapped to an IP address or
a named pipe address. The naming varies based on the type of installation. Clients can
connect to:
● A default instance by specifying the servername.
● A named instance by specifying the servername\instancename.
The proper instance naming will have to be used while defining Data Source Names
(DSN) in the connection string of ODBC, ADO, DBI::DBD, Enterprise Manager, Query
Analyzer, and isql utility.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 335
Database Architecture
A database has one or more physical data files that contain all the database data. This
fact has not changed from the early days of data repositories, such as Sequential Access
Methods (SAM), Indexed Sequential Access Method (ISAM), and Virtual Storage Access
Method (VSAM), to the modern day relational database management systems (RDBMS).
Though hardware throughput has improved in the past several years, the improvement in
data access rates is not purely hardware-related, but also in part to the evolution of the
database storage architectures.
Physical Storage Architecture
The physical architecture is made up of files that contain the system (or catalog) and
application data. As with <strong>Oracle</strong>, SQL Server also has support <strong>for</strong> raw devices. The
physical architecture is used to provide separation of data based on its type, such as
metadata from user data; heap data from index data; user data from DBMS data
(including transaction logs), and permanent data from temporary data.
The <strong>Oracle</strong> physical architecture is made up of data files, redo log files, and control files.
SQL Server database systems have four system databases (master, model, tempdb,
and msdb) and one or more user databases. Each of these databases has one or more
files. Each database has its own transaction log files, which are separate from the data
files.
Logical Storage Architecture
For the convenience of administration and efficiency of use, the physical storage is
broken down into smaller logical structures. By dividing each physical data file into
several logical structures, and allocating space to each database object in increments of
these smaller logical structures, access to the database objects can be insulated from the
physical file storage on the operating system. SQL Server has a storage hierarchy which
is similar to <strong>Oracle</strong>’s block-extent-segment-tablespace implementation.
This enables you to load smaller chunks of data into memory <strong>for</strong> faster data access and
also enables you to move the physical location of a data file in the file system,
transparent to the database objects or the applications that access them. Figure A.3
shows the hierarchy of storage structures available in <strong>Oracle</strong> and SQL Server.
Figure A.3
Physical and Logical storage structure hierarchies in <strong>Oracle</strong> and SQL Server

336 Appendices
In SQL Server, the term page is used instead of blocks. The data files are <strong>for</strong>matted into
blocks (pages) of the same size (8 KB). The unit of transfer <strong>for</strong> data between storage and
database memory is a block or page. The composition of the SQL Server page is similar
to the <strong>Oracle</strong> block and is made up of page header, data rows and row offset array (row
directory). Free and used space is also tracked and managed similarly. SQL Server does
not allow rows larger than 8060 bytes. This restriction, however, does not apply to rows
containing large data types such as text, image, and so on, which can be stored
separately.
Although the data is stored in blocks, the block is too small a unit <strong>for</strong> allocation to the
database objects. A bigger unit called extent, which corresponds to a specific number of
contiguous data blocks, is used <strong>for</strong> this purpose. SQL Server only supports fixed size
extents of 64 KB (8 pages).
For more details on the two types of extents and how they are used, refer to the “Pages
and Extents” article at http://msdn.microsoft.com/librar y/default.asp?url= /library/en-
us/architec/8_ar_da2_4iu r.asp.
Also refer to the “Managing Extent Alloc ations and Free Space” article at
http://msdn.mic rosoft.com/library/d efault.asp? url=/library/en-
us/architec/8_ar_
da2_4lgl. asp.
The SQL Server equivalen t of the <strong>Oracle</strong> tables pace is called the filegroup. Each SQL
Server database is created with a primary file belonging to the default primary filegroup.
Optionally, secondary datafiles can be added to the primary filegroup or additional
filegroups can be created. Files and filegroups in SQL Server are implemented along the
same lines as datafiles and table spaces in <strong>Oracle</strong>.
Instance Architecture
This section covers the two components that make up an <strong>Oracle</strong> instance: memory and
processes and its SQL Server equivalents.
Memory Architecture
The design of database m emory architecture in both <strong>Oracle</strong> and SQL Ser ver are based
on the same objective. This objective is to acquire memory from the syste m and make it
available to the RDBMS to per<strong>for</strong>m its work. Because the available memory is a very
small percentage of the database size, the configuration of memory is very important to
the per<strong>for</strong>mance of the database system. The memory per<strong>for</strong>mance has to be optimized
not only <strong>for</strong> application data, but also the data dictionary and the needs of the relational
engine. For SQL this includes procedures, execution plan, cursors, temporary objects,
and sorting.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 337
The SQL Server memory address space is illustrated in Figure A.4:
Figure A.4
SQL Server Address Space
A 32-bit process is normally limited to addressing 2 GB of memory, or 3 GB if the system
was booted using the /3G boot switch in boot.ini, even if there is more physical memory
available. However, both <strong>Oracle</strong> and SQL Server can use the MS Windows 2000
Address Windowing Extensions (AWE) API to support up to a maximum of 64 GB of
physical memory. The specific amount of memory is dependent on the hardware and
operating system versions. The AWE-enabled server configuration parameter is available
in SQL Server <strong>for</strong> the purpose. The Microsoft Knowledge Base Article 274750, "How to
configure memory <strong>for</strong> more than 2 GB in SQL Server," is available at
http://support.microsoft.com/default.aspx?scid=kb;en-us;274750. It provides in<strong>for</strong>mation
on the maximum amount of memory that various Microsoft Windows Operating System
versions can support and how to configure memory options.
An overview of the internals of memory management facilities of SQL Server 2000 is
available at http://msdn.microsoft.com/sql/default.aspx?pull=/library/enus/dnsqldev/html/sqldev_01262004.asp.
The SQL Server 2000 memory manager uses different algorithms to manage memory on
different versions of Windows. While memory allocation to the RDBMS has been rigidly
controlled in <strong>Oracle</strong> by the configuration (initialization) parameters, the sizes of the
components in SQL Server 2000 address space are auto-tuned dynamically in
cooperation between the RDBMS and the operating system. All memory areas within the
memory pool are also dynamically adjusted by the SQL Server code to optimize
per<strong>for</strong>mance and do not need any administrator input.
The Memory Pool is the SQL Server equivalent of the SGA. The composition of the
memory pool can be found at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/architec/8_ar_sa_1zu4.asp.

338 Appendices
Process/Thread Architecture
The process architecture identifies the various database related processes and their
functionality. As is true with <strong>Oracle</strong> on Windows, SQL Server also uses a thread-based
architecture. SQL Server does not differ significantly from <strong>Oracle</strong> in its use of pools of
processes (threads) <strong>for</strong> system functions and user requests. Table A.1 compares SQL
Server functionality with respect to <strong>Oracle</strong> background processes.
Table A.1: Mapping of <strong>Oracle</strong> and SQL Server Background Processes
<strong>Oracle</strong> Process
(Required Status)*
<strong>Oracle</strong>
Identifier
Min / Max
SQL Server Process
(Required Status)*
Min / Max
Process Monitor (M) PMON 1 / 1 Open Data Services (M) 1 / 1
System Monitor (M) SMON 1 / 1 Database cleanup / 1 / 1
shrinking (M)
Database Writers (M) DBWn 1 / 20 Lazywriter (M) 1 / 1
Checkpoint Process (M) CKPT 1 / 1 Database checkpoint (M) 1 / 1
Recoverer (O) RECO 0 / 1 MS DTC (O) 0 / 1
Log Writer (M) LGWR 1 / 1 Logwriter (M) 1 / 1
Archive Processes (O) ARCn 0 / 10 N/A
Job Queue Processes Jnnn 0 / 1000 SQL Agent (O) 0 / 1
(O)
Job Queue Coordinators CJQn 0 / 1 SQL Agent (O)
0 / 1
(O)
Queue Monitor
QMNn 0 / 10 SQL Agent (O) 0 / 1
Processes (O)
Parallel Query Slave Pnnn 0 / 3600 Worker threads (M) 32 / 32767
Processes (O)
Dispatcher (O) Dnnn 0 / 5 Network thread (M) 1 / 1
Shared Servers (O) Snnn 0 / OS Worker threads (M) 32 / 32767
SQL Server employs sophisticated shared server architecture. On startup, SQL Server
creates a User Mode Scheduler (UMS) o bject <strong>for</strong> each processor using the affinity mask
setting. A pool of worker threads is created by Open Data Services (ODS) to handle user
commands, and their control is distributed among the UMS schedulers. This architecture
mimics the shared server-dispatcher concept in <strong>Oracle</strong>. While in <strong>Oracle</strong> the shared server
processes are schedule d by the operating system, SQL Server uses the UMS to
schedule worker threads.
The internal workings of the User Mode Scheduler are available at:
http://msdn.microsoft.com/SQL/sqlarchitectu re /default.aspx?pull=/library/en-
us/dnsqldev/html/sqldev_02252004.asp?frame=true.
Additional references on topics related to process architecture include:
● Server Memory Options (Administrating SQL Server):
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/adminsql/ad_config_9zfy.asp.
● SQL Server Memory Usage: http://support.microsoft.com/default.aspx?scid=kb;enus;321363.
● 64-bit Overview: http://www.microsoft.com/sql/64bit/productinfo/overview.asp.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 339
●
IO Affinity: http://support.microsoft.com/default.aspx?scid=kb;[LN];298402.
● Allocating threads to a CPU:
http://msdn.microsoft.com/library/default.asp?url=/library/enus/architec/8_ar_sa_8agl.asp.
Relational Engine Architecture
The Relational Engine is the part of the RDBMS that is responsible <strong>for</strong> parsing,
optimizing, and executing the SQL statements received from end users and returning
results (also known as fetching) to the end users.
Figure A.5 illustrates the components of SQL Server relational engine.
Figure A.5
Components of SQL Server Relational Engine
Figue A.5 illustrates the main components of the relational engine portion of SQL Server.
The illustrated components can be organized into three groupings of subsystems:
Compilation, Execution, and SQL Manager. The components parser, T-SQL compiler,
normalizer, and query optimizer belong to the compilation subsystem, which processes
the SQL statements. These statements typically come in as TDS messages. The SQL
Manager, in the middle of the figure, <strong>for</strong>ms the second subsystem, which controls the
flow of everything inside the SQL Server. Remote Procedure Call (RPC) messages are
handled directly by the SQL Manager. T-SQL execution, query execution, and expression
service <strong>for</strong>m the execution subsystem. The query results come out of the expression
service and are sent back out by ODS, after <strong>for</strong>matting the results into TDS messages.
The expression services library per<strong>for</strong>ms data conversion, predicate evaluation or
filtering, and arithmetic calculations.
The catalog services component handles data definition statements (DDL). The UMS is a
scheduler internal to SQL Server that handles the threads and fibers. The system-stored
procedures are self evident.
For a more detailed discussion of the relational engine, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsql7/html/sqlquerproc.asp.
The concepts of execution plan, cost based optimization, and hints are common to
<strong>Oracle</strong> and SQL Server.
A white paper on query optimizer and statistics is available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsql2k/html/statquery.asp.

340 Appendices
Transaction Architecture
Users and applications interact with the database using transactions. Both <strong>Oracle</strong> and
SQL Server offer both optimistic and pessimistic concurrency control. Pessimistic locking
is the default <strong>for</strong> SQL Server. Microsoft SQL Server supports all four levels of isolation:
read uncommitted, read committed, repeatable read, and serialization. Read committed
is the default level of isolation <strong>for</strong> SQL Server.
Like most RDBMSs, <strong>Oracle</strong> and SQL Server achieve isolation by controlling concurrent
access to shared resources (such as schema objects) and their subcomponents (such as
data rows), and internal database structures using locks. Transactions acquire locks at
different levels of granularity. In <strong>Oracle</strong>, the granularities are row and table, while in SQL
Server the granularities are row (RID and rowid), key (row lock within an index), page,
exte nt, table, and database. A major difference between <strong>Oracle</strong> and SQL Server in their
use of locks is that <strong>Oracle</strong> does not escalate locks, while SQL Server escalates locks to
reduce the system overhead of maintaining a large number of finer-grained locks. SQL
Server automatically escalates row locks and page locks into table locks when a
transaction exceeds its escalation threshold.
Table A.2 compares the types of locking available in <strong>Oracle</strong> and SQL Server.
Table A.2: Comparison of the Modes of Locking in <strong>Oracle</strong> and SQL Server
<strong>Oracle</strong> SQL Server Purpose
Share (S) Shared (S) Used <strong>for</strong> operations that do not change
data, such as SELECT statements
Row Share (RS) Update (U) Used on resources that can be updated,
such as SELECT … FOR UPDATE in
<strong>Oracle</strong> and SELECT statements with
the UPDLOCK lock hint in SQL Server
Row Exclusive (RX) Exclusive (X) Used <strong>for</strong> data modification operations,
such as INSERT, UPDATE, DELETE
Share Row Exclusive N/A Only allows non-update S and RS locks
(SRX)
Exclusive (X) Exclusive (X) Disables all other updates
N/A Intent Shared (IS) Indicates intention to read some
resources lower in the hierarchy
N/A Intent Exclusive (IX) Indicates intention to modify some
resources lower in the hierarchy
N/A Shared with Intent
Exclusive (SIX)
Indicates intention to read all resources
at a lower level and modify some of
them using IX locks
Exclusive DDL Schema Modification For per<strong>for</strong>ming DDL
(Sch-M)
Breakable Parse Schema Stability For compiling queries
(Sch-S)
N/A
Bulk Update (BU) For bulk copying data into a table
SQL Server Books Online has very useful in<strong>for</strong>mation on lock modes, lock hints, lock
compatibility, and deadlocks. More in<strong>for</strong>mation is available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/architec/8_ar_sa2_2sit.asp.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 341
Security Architecture
The database has security mechanisms such as logins, privileges, and roles to provide
control over privileges to connect to the database, access schema objects, and
manipulate their structure and data. Both <strong>Oracle</strong> and SQL Server utilize a layered
app roach to security, from logins to roles to system (statement) and object privileges.
Logins
Both <strong>Oracle</strong> and SQL Server provide logins <strong>for</strong> authorized users to connect to the
database. In <strong>Oracle</strong>, the login is called user or username, and in SQL Server, it is called
login identifier or simply login. Any operation the user can per<strong>for</strong>m is controlled by the
privileges granted to the login.
Authentication
Both <strong>Oracle</strong> and SQL Server allow authentication by the operating system or by the
database (server). In SQL Server, the operating system mode is called Windows
Authentication Mode and the database mode is called SQL Server Authentication Mode.
SQL Server can operate in either Windows authentication mode or Windows and SQL
Server authentication mode.
Passwords
The features and functionality related to passwords, such as complexity, aging, or lock
out, that exist with <strong>Oracle</strong> logins, can only be found in Windows logins and not SQL
Server authenticated logins.
Privileges
<strong>Oracle</strong> and SQL Server have a similar model to secure schema objects and application
data and system objects and metadata from unauthorized users. This is achieved by
creating two sets of privileges: system (statement) privileges (permissions) and object
privileges (permissions). Privileges can be assigned to users and roles using the GRANT
statement and removed using the REVOKE statement. Roles are used to grant privileges
to users, but indirectly, are discussed next.
Roles
<strong>Oracle</strong> provides predefined roles, the most familiar being CONNECT, RESOURCE, DBA,
and so on. Similarly, SQL Server has several predefined roles with specific permissions.
There are two types of predefined roles: fixed server roles and fixed database roles. Both
<strong>Oracle</strong> and SQL Server offer user-defined roles.
For more in<strong>for</strong>mation on the privileges available in SQL Server and their management,
refer to http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_security_94dv.asp.
For in<strong>for</strong>mation on creating user-defined roles in SQL Server, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_security_6x5x.asp.
Microsoft SQL Server 2000 SP3 Security Features and Best Practices is available at:
http://www.microsoft.com/sql/techinfo/administration/2000/security/securityWP.asp. It
provides a detailed account of SQL Server security model and best practices.

342 Appendices
Data Dictionary
The data dictionary, referred to in SQL Server as the system catalog, is broken up into a
system-level component in the master database and individual database-level
components in each of the other databases. It has the following characteristics:
● Each of the databases contains tables to maintain its own database objects
(tables, indexes, constraints, users, privileges, replication definition) and other
system structures (filegroups, files).
● The centralized system catalog in the master database contains in<strong>for</strong>mation which
is a combination of <strong>Oracle</strong> control files and data dictionary, such as individual
database names and primary file location, server level logins, system messages,
configuration (initialization parameter) values, remote servers, linked servers,
system procedures (such as the DBMS_ <strong>Oracle</strong> stored programs), and so on.
The features of the data dictionary that an <strong>Oracle</strong> DBA is familiar with — system tables,
views, functions, and procedures — can also be found in SQL Server in the following
<strong>for</strong>ms:
● System tables
These serve the same function as <strong>Oracle</strong>’s data dictionary tables. The system
tables should be used <strong>for</strong> in<strong>for</strong>mation only.
System tables available under the master database store server-level system
in<strong>for</strong>mation. For example:
● master..syslogins — Available login accounts
● master..sysdatabases — Available databases
The following tables store database-level system in<strong>for</strong>mation <strong>for</strong> the respective
database:
● sy susers — Available user accounts with privileg es on database
● sysobjects — Available objects in database
● sysindexes — Available indexes in database
For a complete listing of system tables and their use, refer to
http:// msdn.microsoft.com/library/default.asp?url=/library/en-
us/tsqlref/ts_sys_00_690z.asp.
● In<strong>for</strong>mation schema views
SQL Server offers in<strong>for</strong>mation schema views which are equivalent to the ALL_
views found in <strong>Oracle</strong>. In<strong>for</strong>mation can be retrieved from these views by querying
the corresponding INFORMATION_SCHEMA.view_name. For example, the views
that are visible to a user can be verified by using
INFORMATION_SCHEMA.VIEWS. Below is a list of common in<strong>for</strong>mation schema
views.
● in<strong>for</strong>mation_schema.tables — Available tables in a database
● in<strong>for</strong>mation_schema.columns — Available columns in a database
● in<strong>for</strong>mation_schema.table_privileges — Available privileges on tables in a
database
The in<strong>for</strong>mation schema views topic is discussed at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_iaiz_4pbn.asp.
● System functions

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 343
●
Equivalents <strong>for</strong> built-in <strong>Oracle</strong> SQL functions can be found in SQL Server under the
System functions heading. Some commonly used functions include:
● User_name(id)
● getdate()
● system_user()
For a list of all available SQL Server system functions, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_fafz_79f7.asp.
System stored procedures
The system stored procedures aid the administrator in per<strong>for</strong>ming common
functions by supplementing the DDL. They also provide in<strong>for</strong>mation from system
tables, prepackaged to save the administrator from writing his or her own queries
and views. The system stored procedures can be considered to be the equivalent
of <strong>Oracle</strong>'s DBMS and UTL packages. These procedures are designed to be
comprehensive and remove the burden of having to remember DDL syntax and
system table names.
For a complete listing of system stored procedures, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/tsqlref/ts_sp_00_519s.asp
Administration
This section provides brief introductions to topics such as export, import, backup,
recovery, and monitoring.
Export/Import
In SQL Server, data can be imported and exported using the Data Trans<strong>for</strong>mation
Services (DTS) tool, Transact-SQL statements (INSERT INTO and BULK INSERT), and
Bulk Copy utility (bcp), which provides the same functionality as SQL*Loader.
Export
SQL Server does not have an equivalent of the <strong>Oracle</strong> export utility to move data into a
binary <strong>for</strong>mat file. Individual schema objects can be backed up to text-based flat files in
any of the several available file <strong>for</strong>mats, or they can be exported to any of the several
OLE DB destinations and restored using tools and utilities.
One of the following methods can be used to extract or spool data into flat files:
● Using the tool osql.exe is similar to SQL*Plus in the way the users can run
commands at the prompt.
● Using bcp, the bulk copy utility
● Using the D ata Trans<strong>for</strong>mation Services (DTS) tool
Import
SQL Server does have an equivalent to the <strong>Oracle</strong> import utility, but as mentioned in the
previous section, individual schema objects that have been exported to flat files with any
of the several supported file <strong>for</strong>mats or to any OLE DB destination can be imported into a
database using one of the many tools and utilities.
Three ways that data can be imported into SQL Server include:

344 Appendices
●
●
●
Using the BULK INSERT command, which acts as an interface to the bcp utility.
The structure of the BULK INSERT command is similar to the structure of the
control file used in SQL*Loader.
Using bcp, the bulk copy utility.
Using the Data Trans<strong>for</strong>mation Services (DTS) tool.
The functionality and use of bcp, BULK INSERT, and DTS <strong>for</strong> moving data from <strong>Oracle</strong>
int o SQL Server have been demonstrated in Chapter 8. DTS has also been discussed in
more detail in Appendix B: "Getting the Best out of SQL Server 2000 and Windows."
Some additional references on these utilities are:
●
●
●
the "DTS Package Development, Deployment and Per<strong>for</strong>mance" article available
at http://support.microsoft.com/default.aspx?scid=kb;en-us;242391&sd=tech.
For in<strong>for</strong>mation on different switches available with BULK INSERT, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_babz_4fec.asp.
For tips on optimizing bulk copy read, refer to
http: //www.databasejournal.com/features/mssql/article.php/3095511.
Backup
In <strong>Oracle</strong>, backup methods can be categorized at a high level as physical and logical
backups. Comparable methods <strong>for</strong> backing up the database can be found in SQL Server.
Table A.3 provides a comparison of the available methods:
Table A.3: Backup Methods in <strong>Oracle</strong> and SQL Server
Backup Method <strong>Oracle</strong> SQL Server
Logical Export bcp or DTS
Physical Cold Cold
Physical Online Full
Physical Incremental Transaction log or
Differential
Physical Archive log Transaction log
Logical Backups
The goal of a logical backup is to be able to recover at the individual schema object level.
Although <strong>Oracle</strong>'s export and import utilities are designed <strong>for</strong> moving <strong>Oracle</strong> data, they
can be used as a supplemental method of protecting data in an <strong>Oracle</strong> database. It is not
recommended to use logical backups as the sole method of data backup.
SQL Server does not support logical backups to proprietary binary <strong>for</strong>mat files. Individual
schema objects, however, can be backed up to flat files in any of the several supported
file <strong>for</strong>mats and restored using tools such as the bcp utility and DTS tools.
Physical Backups
In <strong>Oracle</strong>, a physical backup involves making copies of database files including datafiles,
control files, and, if the database is in ARCHIVELOG MODE, archived redo log files. The
same is true in SQL Server, though a backup is viewed to be at the database level.
Larger databases can utilize filegroup backups to back up sections of a database. The
physical backups available are:
● Cold (offline) backups. A cold backup or a closed backup can be described as a
backup of one or more database files taken while the database
is closed and is not

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 345
available <strong>for</strong> user access. Even though the term cold backup is not mentioned in
the documentation, the method can be applied <strong>for</strong> per<strong>for</strong>ming backups in SQL
Server.
● Online backups. A backup is termed as an online backup or a hot backup if it is
taken while the database is open and is accessible to users. SQL Server full
backup backs up a complete database and includes transaction log entries. File
and filegroup backups can be made using the BACKUP DATABASE statement or
through Enterprise Manager ->Backup Database -> File and filegroup.
Transaction logs can be backed up separately as well.
Incremental Backups
Physical incremental backups are per<strong>for</strong>med to capture only the changed blocks, thereby
reducing the time and space needed <strong>for</strong> the backups. Incremental backups are
per<strong>for</strong>med after an initial complete backup has been per<strong>for</strong>med. In SQL Server,
differential backups contain only data that has changed since a last full backup.
Differential database backups can be made using the BACKUP DATABASE statement or
through Enterprise Manager -> Backup Database -> Database — differential.
Recovery
The three recovery models offered by SQL Server—Full, Bulk-logged, and Simple—are
discussed below.
● Full recovery model. This is used when the data is critical and must be
recoverable to point of failure. All recovery options are available in this recovery
model. This is equivalent to <strong>Oracle</strong>’s ARCHIVELOG mode (when the
NOLOGGING option is not specified at any level), where all transactions are
logged and logs are archived <strong>for</strong> full recoverability.
● Bulk-logged recovery model. This is the mid-level recovery model available <strong>for</strong>
bulk operations such as bulk copy, SELECT INTO, and text processing. This
recovery model does not provide point-in-time recovery past the beginning of any
bulk operation. This is similar to setting the NOLOGGING option at the tablespace,
object level, or <strong>for</strong> individual commands to avoid logging of bulk operations.
● Simple recovery model. This is used when it is not important to completely
recover the database or the lost data can be recreated. This recovery model has
the lowest logging overhead. This is equivalent to running the database in
NOARCHIVELOG mode.
For more in<strong>for</strong>mation on the backup and recovery architecture of SQL Server, refer to
http://msdn.microsoft.com/library/en-us/architec/8_ar_aa_9iw5.asp.
A detailed account of the backup and recovery options and techniques, as well as
guidance <strong>for</strong> per<strong>for</strong>ming these administrative tasks, is available at
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlops4.mspx.
Monitoring
Monitoring should be per<strong>for</strong>med <strong>for</strong> availability, errors, and per<strong>for</strong>mance.

346 Appendices
Availability
Availability should cover the server(s), node(s), database services, and database.
●
●
●
Server. Monitoring of the server should also include the network access path from
the application or client to the server. The most common method to achieve this is
a ping test.
Database Services. A common mode of monitoring <strong>Oracle</strong> databases is to check
on the instance-specific processes such as SMON or PMON. Because SQL Server
uses thread architecture, only the main process (sqlservr.exe) can be monitored.
Database. Even when the services are running, connecting to a database may fail
due to some errors. A second level monitoring involving connecting to the
database and per<strong>for</strong>ming some simple tasks should expose such errors.
The command line utility scm (Service Control Manager) can be used to check the health
of a SQL Server instance. Scripts can also be executed using SQL Server command line
utilities such as isql or osql.
Errors
In a database environment, errors, failures, or faults can occur in a number of areas.
Erro rs have to be monitored by viewing (or mining) the error logs. The server event logs
and the database instance logs are a good source <strong>for</strong> errors and violations.
The event log, which contains entries <strong>for</strong> all database server instances and other
app lications running on the server, can be accessed through the Microsoft Windows
Eve nt Viewer utility. This can be accessed through Start -> Program -> Administrative
Tools -> Event Viewer. The events in the event log can be filtered by type, source, date
range, and so on.
SQL
Server has predefined error codes and error messages (see master..sysmessages
<strong>for</strong> a complete list) that give in<strong>for</strong>mation such as unique error number, severity level, error
state number, and error message on all errors.
The SQL Server error logs provide complete in<strong>for</strong>mation regarding all events, auditing
messages, errors, and so on, that have occurred against an instance. The error logs can
be viewed using a text editor or through Enterprise Manager. In Enterprise Manager, the
logs can be found using SQL Server Group -> Server Instance -> Management ->
SQL Server Logs.
Per<strong>for</strong>mance
Per<strong>for</strong>mance Monitor and Task Manager are two of the several tools that can be used to
monitor resource usage at the server level as well as the SQL Server instance level. The
following is a listing of the methods by which various server and database resources can
be monitored:
● CPU. Task Manager: Per<strong>for</strong>mance, Per<strong>for</strong>mance Monitor: Processor
● Memory. Task Manager: Per<strong>for</strong>mance, Per<strong>for</strong>mance Monitor: Memory
● Process. Task Manager: Processes, Per<strong>for</strong>mance Monitor: Process
● Virtual Memory. Task Manager: Per<strong>for</strong>mance, Per<strong>for</strong>mance Monitor: Paging File
● Network. Task Manager: Networking, Per<strong>for</strong>mance Monitor: Network Interface
● I/O. Task Manager: Processes, Per<strong>for</strong>mance Monitor: LogicalDisk and Pe<strong>for</strong>mance
Monitor: PhysicalDisk
● Storage.
My Computer, Windows Explorer
Some references on monitoring SQL Server per<strong>for</strong>mance are:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 347
●
●
●
●
●
●
"Job to Monitor SQL Server 2000 Per<strong>for</strong>mance Activity" is available at
http://support .microsoft.com/default.aspx?scid=kb;EN-US;283696.
"How to monitor SQL Server 2000 blocking" is available at
http://support.microsoft.com/default.aspx?scid=kb;en-us;271509&Product=sql2k.
"How to View SQL Server 2000 Activity Data" is available at
http://support.microsoft.com/default.aspx?scid=kb;en-us;283784&Product=sql2k.
"How to View SQL Server 2000 Blocking Data" is available at
http://support.microsoft.com/default.aspx?scid=kb;en-us;283725&Product=sql2k.
"How To: View SQL Server 2000 Per<strong>for</strong>mance Data" is available at
http://support.microsoft.com/default.aspx?scid=kb;en-us;283886&Product=sql2k.
Tools and functions to automate administration is available at
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlops4.mspx.

348 Appendices
The per<strong>for</strong>mance of a SQL Server installation is dependent on several factors covering
database design, application design, query design, access methods (indexing schemes
and views), hardware, and software resources. The following references cover the entire
breadth of topics that are critical to getting the best per<strong>for</strong>mance out of SQL Server.
● "The Data Tier: An Approach to Database Optimization" is available at
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/ en-
us/part10/c3361.mspx.
● "Improving SQL Server Per<strong>for</strong>mance" includes schemas, queries, indexes,
transactions, stored procedures, execution plans, and tuning topics:
http://msdn.microsoft.com/sql/default.aspx?pull=/library/enus/dnpag/html/scalenetchapt14.asp.
● "How To: Optimize SQL Queries" is available at
http://msdn.microsoft.com/sql/default.aspx?pull=/library/enus/dnpag/html/scalenethowto04.asp.
● "How To: Optimize SQL Indexes" is available at
http://msdn.microsoft.com/sql/default.aspx?pull=/library/enus/dnpag/html/scalenethowto03.asp.
● "Microsoft SQL Server 2000 Index Defragmentation Best Practices" is available at
http://www.microsoft.com/technet/prodtechnol/sql/2000/ma intain/ss2kidbp.mspx.
● "Using Views with a View on Per<strong>for</strong>mance" is available at
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/enus/part10/c3661.mspx.
● "Checklist: SQL Server Per<strong>for</strong>mance" is available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnpag/html/scalenetcheck08.asp.
● SQL Server 2000 Operations <strong>Guide</strong>: System Administration has very detailed
discussions on topics such as indexes, statistics, automation, and memory
management:
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sq lops4.mspx.
● "Microsoft Storage <strong>Solution</strong>s – The Right Storage and Productivity <strong>Solution</strong>" is
available at
http://www.microsoft.com/windowsserversystem/storage/solutions/rightsolution/righ
tsolution.mspx.
● "Windows 2003 Per<strong>for</strong>mance and Scalability" is available at
http://www.microsoft.com/windowsserver2003/evaluation/per<strong>for</strong>mance/perfscaling.
mspx.
Appendix B: Getting the Best Out of SQL Server 2000
and Windows
This appendix provides references on various aspects of a SQL Server 2000 deployment
that can be exploited to ensure optimal per<strong>for</strong>mance in an enterprise environment.
Per<strong>for</strong>mance is also critical to scalability.
Several of the links provided here have been referenced elsewhere in this guidance, but
they are repeated here <strong>for</strong> your convenience.
Per<strong>for</strong>mance

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 349
Scalability
Scalability is the capability to handle increased volume of data of Very Large Databases
(VLDBs) and activity. The size of the VLDBs may be due to a few large tables, or a large
number of smaller tables, or a combination of both. Activity scalability is measured in the
number of user connections, response time, throughput, and so on. <strong>Oracle</strong> and SQL
Server are continually working on adding features and functionality which are directed at
improving their respective products to meet these demands. While some of these
features, such as clustering, replication, and parallelism, are highlighted in specification
sheets and documentation, much of the scalability is built in at the lower levels of the
architecture, such as use of bitmaps instead of lists to represent storage, in-row versus
out-of-row data storage, and so on. The overall scalability is, however, dependent not
only on the RDBMS, but also on the hardware and the application. The following
references answer questions about scalability related to scaling out, scaling up, data
partitioning, 64-bit architecture, storage technology, operating system, and other related
topics.
● "Scaling Out on SQL Server" is available at
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/enus/part10/c3861.mspx.
● "SQL Server Scalability FAQ" is available at
http://www.microsoft.com/sql/techinfo/administration/2000/scalabilityfaq.asp.
● "Microsoft SQL Server 2000 Scalability Project — Server Consolidation" is available
at http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsql2k/html/sql_asphosting.asp.
High Availability
Availability refers to the ability to connect to and per<strong>for</strong>m actions against the database
server, the database, and the data. The features in SQL Server that contribute to
availability are discussed here.
"SQL Server 2000 High Availability Series" provides the most complete set of white
papers on planning and deploying a highly available environment containing SQL Server.
This series is available at:
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/harag01.mspx.
Also refer to Microsoft SQL Server 2000 High Availability (Microsoft Press, 2003).
Apart from covering the hardware technologies, the three SQL Server technologies
covered in this series are:
● Clustering
● Standby database or log shipping
● Replication
These topics are discussed under the following headings.
Clustering
Both <strong>Oracle</strong> and SQL Server offer high availability support through the use of clusters of
servers. The two DBMSs depend on the underlying hardware and system software to
provide cluster management to detect and manage failures. SQL Server can be run in an
Active-Passive or Active-Active configuration using the Microsoft Cluster
Services
(MSCS).

350 Appendices
In<strong>for</strong>mation on Windows clustering and SQL Server failover clustering is available at
http://www.microsoft.c om/technet/prodtechnol/sql/2000/maintain/failclus.mspx.
Standby Database or Log Shipping
Both <strong>Oracle</strong> and SQL Server offer the standby database capability where a copy
(secondary) of the entire (primary) database is maintained in a separate location to
provide recovery from server node and database failures as well as catastrophic
disasters. Changes made to the primary are captured in redo or transaction logs, shipped
to the secondary site, and applied to the standby database. The application of the logs to
the standby database can be controlled to be near-synchronous, or lag behind the
primary to suit recovery needs.
For more in<strong>for</strong>mation about SQL Server log shipping, refer to:
● The overview on log shipping available at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_1_server_8elj.asp.
● The FAQ available at http://support.microsoft.com/default.aspx?scid=kb;enus;314515&sd=tech.
● "Microsoft SQL Server 2000 How to Setup Log Shipping" available at
http://support.microsoft.com/default.aspx?scid=%2fsupport%2fsql%2fcontent%2f2
000papers%2fLogShippingFinal.asp.
Replication
Replication is a set of technologies <strong>for</strong> copying and distributing data and database
objects from one database to another and synchronizing the data between them <strong>for</strong>
consistency. Replication is based on the master-slave technique (called publishersubscriber
in SQL Server) in both <strong>Oracle</strong> and SQL Server. Replication is popularly used
to provide high availability of shared data over a WAN.
SQL Server offers the following <strong>for</strong>ms of replication:
● Snapshot Replication. This is a materialized view (indexed view in SQL Server)
containing a snapshot of data at a particular point in time.
● Transactional Replication. This is a progression from the snapshot, with changes
sent to the subscriber at the transaction level. This enables data modifications
made at the publisher to be propagated to the subscribers and also enables
subscribers to make occasional updates back to the publisher.
● Merge Replication. Merge replication is similar to the multimaster replication
technique in <strong>Oracle</strong> that allows several instances of the object available at several
SQL Server sites.
For an overview, planning, tools, implementation, and other details of replication, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/enus/replsql/replover_694n.asp.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 351
Features and Tools
A brief overview of some of the tools that are very valuable in managing a SQL Server
environment is provided under the following headings.
Per<strong>for</strong>mance Monitor
Per<strong>for</strong>mance Monitor is the most important tool in monitoring SQL Server per<strong>for</strong>mance.
When SQL Server is installed on a server, it adds a set of measuring and monitoring
counters <strong>for</strong> SQL Server instances.
In addition to visually monitoring per<strong>for</strong>mance counters, the per<strong>for</strong>mance of SQL Server
can be logged using counter logs. All counters available <strong>for</strong> monitoring are also available
<strong>for</strong> logging whose set up is separate from the monitoring.
Similar to <strong>Oracle</strong> Enterprise Manager, where events can be set up to track space,
resources, availability, per<strong>for</strong>mance, and faults, alerts can be set up to track SQL Server
activity using per<strong>for</strong>mance monitor alerts and SQL Server Agent.
The "Monitoring SQL Server Per<strong>for</strong>mance" chapter in SQL Server 2000 Administrator’s
Pocket Consultant (Stanek, 2000) is a good reference <strong>for</strong> using Per<strong>for</strong>mance Monitor. It
is available at
http://www.microsoft.com/technet/prodtechnol/sql/2000/books/c10ppcsq.mspx.
Profiler
The SQL Profiler utility can be used to monitor the per<strong>for</strong>mance of instance components,
Transact-SQL statements, stored procedures, and auditing activity. This utility provides a
robust set of functionality that allows you to optionally include a variety of events, report
in<strong>for</strong>mation (data columns), and filtering capabilities.
The article "How To: Use SQL Profiler" provides in<strong>for</strong>mation on how to track long running
queries and heavily used stored procedures. It is available at
http://msdn.microsoft.com/sql/default.aspx?pull=/library/en-
us/dnpag/html/scalenethowto15.asp.
SQL Server Health and History Tool (SQLH2)
This tool allows collection of data from a running instance of SQL Server which can then
be reviewed and reported on. For more in<strong>for</strong>mation on SQLH2, refer to
http://www.microsof
t.com/downloads/details.aspx?FamilyID=eedd10d6-75f7-4763-86de-
d2347b8b5f89&DisplayLang=en.
The tool is especially useful <strong>for</strong> measuring service uptime and per<strong>for</strong>mance trends.
DTS
Data Trans<strong>for</strong>mation Services (DTS) offer import and export of data by providing a set of
tools that let you extract, trans<strong>for</strong>m, and consolidate data from disparate sources into
single or multiple destinations supported by DTS connectivity. By using DTS tools to
graphically build DTS packages, or by programming a package with the DTS object
model, you can create custom data movement solutions tailored to the specialized data
transfer needs.
For more in<strong>for</strong>mation on DTS, refer to the "Data Trans<strong>for</strong>mation Services (DTS) in
Microsoft SQL Server" white paper available at
http://msdn.microsoft.com/SQL/sqlwarehouse/DTS/default.aspx.

352 Appendices
Query Analyzer
T he SQL Query Analyzer is a graphical tool that can be used to execute queries directly
a gainst the database. It also has the functionality to debug query per<strong>for</strong>mance problems
such as Show Execution Plan, Show Server Trace, Show Client Statistics and Index
Tuning Wizard.
An overview of Query Analyzer is available at
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/qryanlzr/qryanlzr_1
zqq.asp.
For an overview of some of the important features of query analyzer, refer to
http://www.sql-server-per<strong>for</strong>mance.com/query_analyzer_tips.asp.
Index Tuning Wizard
The Index Tuning Wizard allows you to select and create an optimal set of indexes and
statistics based on input from Query Analyzer or a SQL Profiler log <strong>for</strong> a SQL Server
database without requiring an expert understanding of the structure of the database, the
w orkload, or the internals of SQL Server.
For in<strong>for</strong>mation on the features and use of the Index Tuning Wizard, refer to "Index
Tuning Wizard <strong>for</strong> Microsoft SQL Server 2000" at
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnsql2k/html/itw<strong>for</strong>sql.asp.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 353
Appendix C: Baselining
This appendix is concerned with creating baselines, capturing statistics, and comparing
and reporting results.
Creating Baselines
B aselines are a collection of facts and figures that reflect the state of a system. Most
commonly, the term baseline is used with respect to per<strong>for</strong>mance. In the Stabilizing
Phase, this term is used to refer to a snapshot of the entire system specification.
Unlike a new development pr oject where there is no reference point, the state of the
current solution can be captured in a migration project. This can be used as a baseline
f or comparison with the migrated solution being tested.
After every successful
cycle of testing, it is recommended that all elements, such as
scripts, applications, application configuration, database configuration, and databases,
a re backed up and are baselined with appropriate tags <strong>for</strong> identification. Baselines from
each cycle of testing can be compared with each other to see the progression towards a
solution that can be packaged <strong>for</strong> production.
You should create a baseline during the Stabilizing Phase. These baseline values can be
used later while troubleshooting per<strong>for</strong>mance problems and also <strong>for</strong> proactive monitoring.
The Per<strong>for</strong>mance Monitor, also known as System Monitor tool, can be used to monitor
key system resources (CPU, memory, Disk I/O, network, as well as SQL Server
counters) while you run the Stabilizing Phase tests.
The following tables (A.4 through A.8) list some of the per<strong>for</strong>mance monitor counters that
you can use <strong>for</strong> creating a baseline. These counters can also be used <strong>for</strong> general
monitoring of the solution after deployment.
Table A.4: Memory Management
Per<strong>for</strong>mance Description
Monitor Counters
\Memory\Available Available MBytes is the amount of physical memory available
Mbytes
to processes running on the computer, in Megabytes. Lack of
memory puts pressure on the CPU and Disk I/O.
\Memory\Pages/sec Pages/sec is the rate at which pages are read from or written
to disk
to resolve hard page faults. Hard page faults occur
when
a process requires code or data that is not in its working
set or elsewhere in physical memory and must be retrieved
from disk. Note that some paging will usually be present
because of the way the operating system works, but the
optimal level <strong>for</strong> average
pages/sec should be close to 0.

354 Appendices
Table A.5: Network Analysis
Per<strong>for</strong>mance Description
Monitor Counters
\Network Interface Bytes Total/sec is the rate at which bytes are sent and
(Network card)\Bytes received over each network adapter, including framing
Total/sec
characters. Average value should be less than 50% of NIC
capacity.
\Network Segment\ % The percentage of network bandwidth in use on a network
Net Utilization
segment. Network Monitor Driver can be installed and used to
monitor the network utilization. The threshold value varies
based on the network configuration.
Table A.6: CPU Monitoring
Per<strong>for</strong>mance Monitor
Counters
\Processor% Processor
Time
\Processor\% Privileged
Time and \Processor\%
User Time
\System\Context
switches/sec
\System\Processor Queue
Length
Description
This counter is the primary indicator of processor activity,
and it displays the average percentage of busy time
observed during the sample interval. It is calculated by
monitoring the time that the service is inactive and
subtracting that value from 100%.
* Privileged Time is the percentage of elapsed time that the
process threads spent executing code in privileged mode.
Average values above 10% indicate possible CPU pressure.
* User Time is the percentage of elapsed time the processor
spends in the user mode.
* Privileged Time should be about 15% less than the total
User Time.
This counter indicates the combined rate at which all the
processors are switched from one thread to another. The
pressure on memory can cause page faults, which can
cause an increase in context switch/sec value, and a
decrease in the overall per<strong>for</strong>mance.
This counter indicates the number of threads in the
processor queue. There is a single queue <strong>for</strong> processor
time, even on computers with multiple processors. A
sustained processor queue length of less than 10 threads
per processor is normally acceptable, dependent on the
workload. In other words, there are more threads ready to
run than the current number of processors can service in an
optimal way.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 355
Table A.7: Disk I/O Monitoring
Per<strong>for</strong>mance Monitor
Counters
\PhysicalDisk\Avg. Disk
Queue Length
\PhysicalDisk\Current Disk
Queue Length
\PhysicalDisk\Avg. Disk
sec/Read
\PhysicalDisk\Avg. Disk
sec/Write
Description
* Avg. Disk Queue Length is the average number of
requests (both read and write) that were queued <strong>for</strong> the
selected disk during the sample interval.
* Current Disk Queue Length is the number of requests
outstanding on the disk at the time the per<strong>for</strong>mance data
is collected. These numbers should be less than two per
usable physical disk in the RAID array, and may be higher
on the SAN systems.
Average time in seconds to read/write data to the disk.
Table A.8: Monitoring SQL Server Monitoring
Per<strong>for</strong>mance Monitor
Counters
\SQLServer:Access
Methods\Free Space
Scans/sec
\SQLServer:Access
Methods\Full Scans/sec
\SQLServer:Latches\Total
Latch Wait Time (ms)
\SQLServer:Locks(Total)\Lock
Timeouts/sec and Lock Wait
Time (ms)
\SQLServer:Locks(Total)\Numb
er of Deadlocks/sec
\SQL
Server:Databases\Transaction
s/sec
\SQLServer:Buffer
Manager\Buffer cache hit ratio
Description
Number of scans initiated to search <strong>for</strong> free space to
insert a new record fragment. Inserts on a heap with
clustered index will impact per<strong>for</strong>mance as against a
heap with no clustered indexes.
Tables with missing indexes, or when too many rows
are requested, end up with unrestricted full scans of the
base table or indexes. This baseline counter can be an
indicator of an increase in the use of temporary tables
because they do not tend to have indexes.
SQL Server uses latches to protect the integrity of
internal structures. This counter monitors the total wait
time <strong>for</strong> latch requests that had to wait in the last
second.
Lock Timeouts counter indicates the number of lock
requests that timed out. This includes internal requests
<strong>for</strong> NOWAIT locks. Lock Wait Time (ms) indicates the
total wait time (in milliseconds) <strong>for</strong> locks in the last
second. Lock Timeouts should be low and Wait Time
should be zero.
Number of lock requests that resulted in a deadlock.
Should be zero.
Number of transactions started <strong>for</strong> the database. It is an
excellent indicator of growth related to transaction load.
Percentage of pages that were found in the buffer pool
without having to incur a read from disk. The higher the
value of the buffer cache hit ratio the better. In a
transaction processing system where a set user base is

356 Appendices
Per<strong>for</strong>mance Monitor
Counters
Description
operating against the database, this value may reach
98-99 percent. If this value is small, then adding
memory to the SQL Server may help. This should be
looked at with table scan frequency and might indicate
that indexes/partitioning would improve per<strong>for</strong>mance.
\SQLServer:SQL Recompilation adds overhead on the processor.
Statistics\SQL Re-
Compilations/sec
\SQLServer:Batch
Requests/sec and
\SQLServer:General
Statistics\User Connections
\SQLServer:Memory
Manager\Memory Grants
Pending
\SQLServer:Memory
Manager\Target Server
Memory (KB)
\SQLServer:Memory
Manager\Total Server Memory
(KB)
Consistent high values <strong>for</strong> this counter should be
investigated.
These counters, along with Transactions/sec, are a
good indicator of load on the server.
Current number of processes waiting <strong>for</strong> a workspace
memory grant. This value should remain around 0.
The total amount of dynamic memory the server is
willing to consume. On a dedicated server, this value
should remain close to the actual physical memory size.
The total amount of dynamic memory the server is
currently consuming. On a dedicated server, this value
should remain close to the actual physical memory size.
You must determine which server you will use to monitor SQL Server. If you run
Per<strong>for</strong>mance Monitor on the same machine as the SQL Server, it should not add major
overhead, except some disk I/O and disk space requirement <strong>for</strong> the per<strong>for</strong>mance log files,
depending on counters that you are monitoring and the interval. A large number of
counters with a short sampling interval might require a lot of disk space; however, larger
intervals will produce less accurate results. If you run Per<strong>for</strong>mance Monitor on a different
machine, be aware that it might congest traffic on your network.
For the purpose of creating the baseline, if you have disk space available on the SQL
Server machine, it is recommended you run the Per<strong>for</strong>mance Monitor on the same
machine, add as many counters as desired, and use the short sampling interval. Once
you have established the baseline, <strong>for</strong> proactive monitoring you can monitor just the
counters absolutely required and increase the interval.
To create the baseline chart, follow these steps:
1. Click Start, then All Programs, then Administrative Tools, and then
Per<strong>for</strong>mance.
2. Expand Per<strong>for</strong>mance Logs and Alerts node in the tree in the left pane.
3. Right-click Counter Logs and select New Log Settings.
4. Provide a name, click OK, add the counters, verify the details on the Log Files
and Schedule tab, and click OK.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 357
Capturing Statistics
Some of the points to be considered <strong>for</strong> capturing statistics are:
●
●
●
●
Types of data. The type of data being captured — qualitative or quantitative.
Characte ristic. The statistic must be relevant to the test being per<strong>for</strong>med. It must
suit the comparisons being made or analysis to be per<strong>for</strong>med. CPU usage
measurement is an example of a statistic that is relevant to testing.
Unit of measurement. The unit of measurement would be dependent on the
magnitude of the measured characteristic. An example is measuring and
comparing memory: the unit to be used is bytes or Mbytes.
Frequency. The frequency of measurement of a statistic can be a critical decision.
Too much data can be cumbersome and too little could be harmful.
Some examples of resources on which statistics can be captured are:
● Memory usage of the system
● Memory usage of the database
● CPU usage
● Disk I/O rate
● Number of user connections to the database
● Procedure cache usage
● Number of transactions executed per second
● Data cache usage
● Network bandwidth usage
Comparing and Reporting Results
Test results have only as much value as the inferences that can be drawn from them.
Test results can have either a qualitative value or a quantitative value. In a development
proj ect, the expected behavior of the solution is based solely on business requirements.
For a migration, measurements from the existing solution <strong>for</strong>m the expected result.
During the testing, the data from the migrated solution is compared with the expected
results. Deviations from expected results cannot be construed as defects. As a result,
analyzing and reporting results is a topic of serious consequence. A thorough analysis of
the results has to be made and conclusions drawn based on several measurable and
non-measurable factors (assumptions). The capabilities of the systems available <strong>for</strong>
per<strong>for</strong>ming stabilization tests may be one such factor.

358 Appendices
Appendix D: Installing Common Drivers and
Applications
This appendix contains installation in<strong>for</strong>mation <strong>for</strong> FreeTDS, unixODBC, and ActiveState
Perl:
● FreeTDS provides an implementation of the Tabular Data Stream (TDS) protocol,
emulating the different versions of TDS that are used by <strong>Oracle</strong> and SQL Server.
● unixODBC is an implementation of the ODBC protocol and API <strong>for</strong> UNIX; the
unixODBC library allows applications r unning under UNIX to communicate with
database servers, such as SQL Server, usin g ODBC. Applications developed
using unixODBC can execute under UNIX and SFU.
● ActiveState Perl is the industry-standard Perl distribution. This Perl distribution can
be used from within the Window environment.
Installing FreeTDS
A precompiled and directly installable version of FreeTDS (currently version 0.62.3) is
available at http://interopsystems.com/tools. This can be installed under SFU 3.5 using
the pkg_add command. The package ca n be downloaded from
Configuring FreeTDS
When FreeTDS is installed, you should configure it to connect to your SQL Server
databases using the following procedure:
To configure FreeTDS connectivity, follow these steps:
1. Move to the /usr/local/etc directory and edit the freetds.conf file. This file contains
in<strong>for</strong>mation about the Sybase and SQL Server database servers it can access and
the versions of T DS to use.
2. Add the following entries to the end of the file. Replace aa. aa.aa.aa with the IP
address or DNS name of the UNIX computer running SQL Server (DNS name is
recommended), and bbbb with the port that SQL Server is listening to on this
computer (SQL Server usually listens on port 1433) .
[SQLServer]
host = servername
port = bbbb
tds version = 8.0
Note The name, SQLServer, does not have to be the same as the name of the
computer running SQL Server — it is an identifier used by the FreeTDS library
functions to locate the entry in this file. It is a name that uniquely identifies this
entry in the configuration file, and is used wi th the -S option <strong>for</strong> most of the scripts.
3. Save the file.
Testing the FreeTDS Configuration
You can test the FreeTDS configuration using tsql, a tool provided with FreeTDS, by
following this procedure:

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 359
To test the installation of FreeTDS, follow these steps:
1. At a shell prompt, type the following command. Replace server with the entry in
freetds.conf that you want to test (SQLServer), and password with the sa password
<strong>for</strong> the selected server:
–U sa –P password
Windows NT Authentication, called "integrated security," is not supported by
FreeTDS.
2. At the 1> prompt, type the following commands. The result should be a list of
databases available on the selected server:
SELECT name FROM sysdatabases
4.
tsql –S server
Go
3. At the 1> prompt, type the following commands. The result should be a list of
connections currently established to the selected server:
EXEC sp_who
Go
At the 1> prompt, type the following command to leave tsql.
exit
Installing unixODBC
unixODBC is available in source <strong>for</strong>m (in the file unixODBC-2.2.6.tar.gz) from the
unixODBC Web site at http://www.unixodbc.com. This guide uses unixODBC version
2.2.6. The procedures assume you have already downloaded the file unixODBC-
2.2.6.tar.gz.
To install unixODBC in UNIX, follow these steps:
1. Log in to UNIX as the root user.
2. At a shell prompt, access the directory where the downloaded unixODBC source
code is located (default/usr/local/unixODBC), and then type the following command
to unzip the file unixODBC-2.2.6.tar.gz to the file unixODBC-2.2.6.tar.
gunzip unixODBC-2.2.6.tar.gz
3. Type the following command to unpack the file unixODBC-2.2.6.tar into the
directory unixODBC-2.2.6:
tar xvf unixODBC-2.2.6.tar
4. Move to the unixODBC-2.2.6 directory and type the following command to
generate the files needed to build unixODBC. This command will generate a
number of messages on the screen as it examines your UNIX configuration and
generates the appropriate make files.
./configure
Note The configure script uses a number of well-known tricks to ascertain which
tools and libraries are available that it can use to compile unixODBC. If the
configure script fails, it is usually because the script cannot find a particular tool,
file, or library. You can run the script supplying parameters to help it analyze your
environment. Execute ./configure -h <strong>for</strong> more details.
5. Type the following command to build unixODBC. As be<strong>for</strong>e, you will see a large
number of messages as the build process progresses:
make
6. Type the following command to install unixODBC:
make install

360 Appendices
7. Type the following command to check that unixODBC was installed successfully:
/usr/local/bin/isql
If unixODBC is installed correctly, you will see the following message:
**********************************************
* unixODBC - isql
*
**********************************************
* Syntax
*
*
*
* isql DSN [UID [PWD]] [options] *
* *
* Options *
*
* -b batch.(no prompting etc)
*
*
* -dx delimit columns with x *
* -x0xXX delimit columns with XX, where *
*
* -w
x is in hex, ie 0x09 is tab
wrap results in an HTML table
*
*
* -c column names on first row. *
* (only used when -d) *
* -mn limit column display width to n *
* -v verbose. *
* --version version *
* *
* Notes
*
* isql supports redirection and piping
*
*
*
* <strong>for</strong>
*
batch processing. *
*
* Examples *
*
*
* cat My.sql | isql WebDB MyID MyPWD -w *
* *
* Each line in My.sql must contain *
* exactly 1 SQL command except <strong>for</strong> the *
* last line which must be blank. *
* *
* Please visit; *
* *
* http://www.unixodbc.org *
* pharvey@codebydesign.com *
* nick@easysoft.com *
**********************************************
Installing ActiveState Perl
ActiveState Perl can be downloaded from the ActiveState Web site at
http://www.activestate.com. ActiveState Perl is available in prebuilt binary <strong>for</strong>m <strong>for</strong> Linux,
Solaris, and Windows, but the source code is also available and can be used to build
ActiveState Perl on other UNIX plat<strong>for</strong>ms.

<strong>Solution</strong> <strong>Guide</strong> <strong>for</strong> <strong>Migrating</strong> <strong>Oracle</strong> on UNIX to SQL Server on Windows 361
This section describes how to install ActiveState Perl using the prebuilt Microsoft Installer
(MSI) package ActivePerl-5.6.1.635-MSWin32-x86.msi.
To install ActiveState Perl under Windows, follow these steps:
1. Execute the file ActivePerl-5.6.1.635-MSWin32-x86.msi. Windows Installer starts
the installation.
2. In the ActivePerl 5.6.1 Build 635 Setup screen, click Next.
3. In the ActivePerl 5.6.1 Build 635 License Agreement screen, select I accept the
terms in the License Agreement and click Next.
4. In the Custom Setup screen, make sure all features are selected to be installed
(the default) and click Next.
5. In the New features in PPM screen, clear the checkbox <strong>for</strong> Enable PPM3 to send
profile info to ASPN and click Next.
6. In the Choose Setup Options screen, check all four options and click Next.
7. In the Ready to Install screen, click Install. The Installing ActivePerl 5.6.1 Build
635 screen will appear and indicate the progress of the installation process.
8. In the Completing the ActivePerl 5.6.1 Build 635 Setup Wizard screen, remove
the check mark from Display the release notes and click Finish.

362 Appendices
Appendix E: Reference Resources
For detailed discussion of the concepts and practices presented in this guide, you should
refer to the following resources.
● For additional in<strong>for</strong>mation on migration, refer to the UNIX Migration Project <strong>Guide</strong>
(UMPG) at
HTUhttp://www.microsoft.com/technet/itsolutions/migration/unix/umpg/default.mspxUTH.
● Details about Windows Services <strong>for</strong> UNIX (SFU) are available at
HTUhttp://www.microsoft.com/windows/sfu/productinfo/overview/default.aspUTH.
● Microsoft <strong>Solution</strong>s Framework (MSF) models and disciplines are available at
HTUhttp://www.microsoft.com/msfUTH.
● For guidance on the structure of operations, refer the Microsoft Operations
Framework (MOF) available at HTUhttp://www.microsoft.com/mofUTH.
● For additional in<strong>for</strong>mation on migrating UNIX applications to Microsoft Windows,
see the UNIX Application Migration <strong>Guide</strong> at
HTUhttp://go.microsoft.com/fwlink/?LinkId=30832UTH
●
●
●
Specific guidance on the Microsoft Operations Framework (MOF) quadrants is
available in the "Process Model <strong>for</strong> Operations" white paper at
HTUhttp://www.microsoft.com/technet/itsolutions/techguide/mof/mofpm.mspxUTH.
For specific guidance on operating the solution, download the <strong>Migrating</strong> High
Per<strong>for</strong>mance Computing (HPC) Applications from UNIX to Windows guide at
HTUhttp://go.microsoft.com/fwlink/?LinkID=23112UTH.
For monitoring the deployed solution, refer to
HTUhttp://www.microsoft.com/business/reducecosts/efficiency/manageability/default.m
spxUTH.
● For best practices regarding monitoring, refer to
HTUhttp://www.microsoft.com/business/reducecosts/efficiency/manageability/bestpracti
ces.mspxUTH.
● For planning a SQL Server 2000 installation, refer to the Microsoft Web site at
HTUhttp://www.microsoft.com/sql/techinfo/planning/default.aspUTH.
● For programming SQL Server 2000, refer the developer topics at
HTUhttp://www.microsoft.com/sql/techinfo/development/2000/default.aspUTH.
● SQL Server Books Online is available at HTUhttp://msdn.microsoft.com/library/enus/startsql/getstart_4fht.aspUTH.
● For SQL Server 2000 Resource Kit in<strong>for</strong>mation, refer the Microsoft Web site at
HTUhttp://www.microsoft.com/sql/techinfo/reskit/default.aspUTH.
● For managing and maintaining SQL Server 2000, refer the SQL Server 2000
Operations <strong>Guide</strong> at
HTUhttp://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql
/maintain/operate/opsguide/default.aspUTH.