Siemens Teamcenter Oracle-to-SQL

Server 2008 Migration Guide

Microsoft Corporation
Published: June 2010
Author:
Randy Dyess Solid Quality Mentors
Technical Reviewers:
Christopher Gill Teamcenter Centers of Excellence, Siemens PLM Software
Hewat Kennedy Siemens

Abstract
This white paper outlines a best practices methodology to use when migrating from a Siemens
Teamcenter Oracle installation to Siemens Teamcenter running on the Microsoft SQL Server 2008
database platform.

Copyright Information
The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of
any information presented after the date of publication. This white paper is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.
Complying with all 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 form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for
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 in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights,
or other intellectual property.
2010 Microsoft Corporation. All rights reserved.
Microsoft, SQL Server, and Windows are trademarks of the Microsoft group of companies. All other trademarks are
property of their respective owners.

Table of Contents
Siemens Teamcenter Oracle-to-SQL Server 2008 Migration Guide ....................................................... 1
About This Guide .......................................................................................................................................... 5
Overview of the Teamcenter Oracle-to-SQL Server Migration Process ..................................................... 5
Creating the Migration Plan for a Teamcenter Migration .......................................................................... 6
Installing the Teamcenter SQL Server Database ......................................................................................... 6
Installing the Oracle Client ......................................................................................................................... 10
Creating a Linked Server ............................................................................................................................ 19
Installing SQL Server Migration Assistant for Oracle V4.0 ........................................................................ 22
Determining Teamcenter Customizations ................................................................................................. 37
Migrating the Data into the Teamcenter Database .................................................................................. 47
Performing Post-Migration Tasks .............................................................................................................. 62
Validating the Migration Through Teamcenter Use Cases ....................................................................... 64
Appendix A: Basic Data Type Conversions .................................................................................................. 65
Appendix B: Sample Teamcenter Table Creation Scripts............................................................................ 68
Appendix C: Links for Further Information ................................................................................................. 73

About This Guide

The Siemens Teamcenter Oracle-to-SQL Server 2008 Migration Guide describes how to migrate
Teamcenter data from an Oracle database to a Microsoft SQL Server 2008 database. This guide is
intended for technical staff members who are experienced in application installations and familiar with
the installation hardware system. The Oracle-to-SQL Server migration process assumes an entry-level
database administration skill level for both Oracle and SQL Server databases.

Related Documentation
The following documentation may be helpful in learning more about implementing Teamcenter on SQL
Server:
Siemens PLM-Related Documents
o Installation on Windows Servers Guide
o Business Modeler IDE Guide
o Best Practices for Running Siemens Teamcenter on SQL Server

Overview of the Teamcenter Oracle-to-SQL Server Migration Process

The overall objective of the migration process is to extract the Teamcenter data from an Oracle
database to a SQL Server 2008 database. The migration of an existing Teamcenter Oracle database to
SQL Server involves multiple steps using both supplied PL/SQL and Transact-SQL (T-SQL) scripts and the
downloadable SQL Server Migration Assistant (SSMA) 2008 for Oracle V4.0. You use the supplied scripts
to determine and adjust the schema of an empty SQL Server Teamcenter database to match that of the
existing Oracle database. After the schema is adjusted, you use the SSMA tool to migrate the data.
The primary steps involved in the migration process are as follows:
1. Create a migration plan that includes a recovery strategy in case of failure and use-case
scenarios to test data correctness.
2. Install a default production installation of SQL Server that includes all components currently
installed on your Oracle instance on a new server and then create a Teamcenter SQL Server
database.
3. Back up both the production SQL Server and the Oracle databases.
4. Create an empty SQL Server database called INFODBA for data staging.
5. Create copies of the PPOM_ATTRIBUTES and PPOM_CLASS and tables in the production
database on the staging database.
6. Delete any existing data in the production SQL Server database.
7. Install the Oracle Client.
8. Create a SQL Server linked server to Oracle from the staging database.
9. Install the SQL Server Migration Assistant for Oracle and SSMA Extension Pack on your SQL
Server server
10. Migrate the schema from Oracle to the SQL Server staging database using SSMA.
11. Adjust the schema of the SQL Server staging database to allow for data movement.

12. Migrate the data from the Oracle database to the staging database using T-SQL scripts through
the linked server.
13. Create a backup of the staging database.
14. Create a database snapshot of the staging database.
15. Execute object and column rename scripts against the staging database.
16. Migrate the data from the staging database to the production database using T-SQL scripts.
17. Perform post-migration tasks using the supplied scripts and SQL Server Management Studio.
18. Validate the success of the migration with use-case scenarios.
19. Back up both the production SQL Server database.

Creating the Migration Plan for a Teamcenter Migration

A good migration plan is simple yet encompasses the appropriate steps to help ensure a successful
migration. The migration plan should list dates, times, staff, testing procedures, recovery options, and
validation procedures to be used during and after the migration of the database.
A migration plan should answer the following questions:
Who is going to build the new server and install Windows and SQL Server?
When is the due date for the new server build-out?
Who is going to install Teamcenter and create the new SQL Server Teamcenter database?
When is the due date for the database?
Who will verify the SQL Server installation and Teamcenter database against the Teamcenter
on SQL Server installation guidelines?
Does the migration process require an Oracle DBA as well as a SQL Server DBA?
Will you need to hire an outside firm to help with the migration?
What DBA and development resources do you have to test and perform the migration?
What are the migration testing optionsnew server or existing server?
When should all migration testing be finished?
What is the date for the actual migration?
Will all required staff be available on the migration date?
How much downtime will be required for the migration?
What is the plan if the new database is not available due to issues during the migration?
During the creation of your migration plan, you will also need to determine several use cases to use in
testing against your migrated database.
As you can see from these bullet points, a migration plan does not have to be overly complex. However,
you will need to answer some essential questions, document those answers, and then combine those
answers with the steps contained in this document.

Installing the Teamcenter SQL Server Database

There are no special requirements for installing SQL Server on your new server or creating the SQL
Server database for the migration. However, you should follow all guidelines for installing and using
6

Teamcenter with a SQL Server database as described in the Siemens Teamcenter 8 Installation on
Windows Server Guide. Any additional requirements are listed in the following sections of this white
paper.
If you know the customizations you have made to your Oracle database and can recreate those
customizations in your SQL Server database, you should do so before the migration process to speed the
process and reduce its complexity.
After installing SQL Server and creating the database for the migration, you need to change the recovery
model of the SQL Server Teamcenter database to Simple for the migration process. After the migration
process, you will need to set the recovery model back to Full.
1. To change the recovery model, open SQL Server Management Studio (SSMS) by going to Start,
All Programs, Microsoft SQL Server 2008, SQL Server Management Studio.
2. Connect to your instance.

3. In the Object Explorer, expand the instance and then expand the Databases folder.

4. Right-click your database and choose Properties.

5. Change to the Options Page on the right, and use the Recovery model drop-down box to
change the recovery model to Simple.

After changing the database to the Simple recovery model, right-click the database again and select
Tasks. Select Back Up and create a backup of your database. You should also Export your Oracle
database at this time.
Next, you should create a SQL Server staging database called INFODBA, which will allow you to make any
needed schema changes and test those changes before migrating the changed schema and data to your
actual database:
CREATE DATABASE INFODBA

Note: The above CREATE DATABASE script uses the model database to create a simple database. You
will need to adjust the script to create a database on different directories than the model for your own
installations. Or you can use SSMS to create the database.
You also need to set the recovery model of the staging database to the Simple recovery model:

After you create your SQL Server staging database, you need to capture the PPOM_CLASS and
PPOM_ATTRIBUTES tables from your production database into your staging database in order to
rename tables and columns later in the migration process. Simply execute the following script against
your SQL Server database to save a copy of these tables in your staging database:
USE INFODBA -- Change to your staging database
GO
SELECT * INTO PPOM_CLASS_saved
FROM tc..PPOM_CLASS
SELECT * INTO PPOM_ATTRIBUTE_saved
FROM tc..PPOM_ATTRIBUTE

After the two needed tables, you need to empty any pre-populated tables in the production SQL Server
database. You can accomplish by truncating all tables that contain data. Simply execute the following
script against your SQL Server database to build the table truncate statements and then execute the
results of the scripts:
USE tc -- Change to your production database
GO
DECLARE @loop INT
DECLARE @command NVARCHAR(4000)
BEGIN TRY
DROP TABLE #commands
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #commands
(
colid INT IDENTITY(1,1)
,command NVARCHAR(4000)

)
INSERT INTO #commands (command)
SELECT 'TRUNCATE TABLE dbo.' + so.name
FROM sys.partitions sp
INNER JOIN sys.objects so
ON sp.object_id = so.object_id
WHERE sp.rows > 0
AND so.is_ms_shipped = 0
AND so.type = 'u'
AND sp.index_id IN (0,1)
ORDER BY so.name
SET @loop = @@ROWCOUNT
WHILE @loop > 0
BEGIN
SELECT @command = command FROM #commands WHERE colid = @loop
exec dbo.sp_executesql @command
SET @loop -= 1
END

(Note: DO NOT delete any data in your existing Oracle production database.)

Installing the Oracle Client

To migrate the data between Oracle and SQL Server 2008, you need to install the latest Oracle Client
software on your SQL Server 2008 server, as follows.
1. Obtain the latest Oracle Client (the version found at the at the download site is an example and
may be different from the one you will need to obtain and install):
Then accept the License Agreement.

2. Make sure you download the correct version of the client.

Note: This whitepaper refers to the x64 10g release; your version may be different.

10

11

3. Unzip the saved file and execute Setup.exe to start the installation.

12

4. Choose to install the InstantClient.

13

5. Enter the Home Destination details, which specify the name for the installation and the path
where you want the client installed, and click Next.

14

6. Correct any issues that the Installer finds.

15

7. Click Install to install the client.

16

17

8. When the installation process is complete, simply exit the Installer.

18

Creating a Linked Server

One of the easiest methods to compare two different databases is through the use of a linked server.
Using a SQL Server linked server allows you to directly compare the objects in your Oracle database to
the objects in your SQL Server database. This will enable you to capture all missing objects and recreate
them in SQL Server.
Here are the steps for creating a linked server:
1. Open SSMS by going to Start, All Programs, Microsoft SQL Server 2008, SQL Server
Management Studio.
2. Open the Server Objects folder in the object tree.
3. Right-click Linked Servers New Linked Server.
4. Create a new linked server by providing a name and data source details (note your connection
may be different from this example).

19

5. Click the Security Tab and input the login and password you will use to connect to the Oracle
database. (This example recreates the infodba login on SQL Server to use for the linked server:
infodba with password of infodba. This login should be made a member of the dbo_owners
group.)

6. Click OK, and then Test your new linked server by expanding the tables of the linked server.

20

21

Installing SQL Server Migration Assistant for Oracle V4.0

SQL Server Migration Assistant (SSMA) 2008 for Oracle is a suite of tools that reduces the effort, cost,
and risk of migrating from Oracle to SQL Server 2008. Follow these instructions for installing SSMA:
1. Download SSMA V4.0 and the Extension pack to your SQL Server server here.
2. Unzip the downloaded file and double-click the SSMA installer, SSMA 2008 for
Oracle.4.0.Install.exe, and at the Welcome screen click Next.

22

3. Accept the License Agreement and click Next.

4. Determine if you want to send a Usage Report to Microsoft and then click Next.

23

5. Choose the Typical installation.

6. Click Install.

24

7. When the installation is complete, click Finish.

8. Youre not ready to install the Extension Pack by unzipping the downloaded file and doubleclicking the SSMA installer called SSMA 2008 for Oracle Extension Pack.4.0.Install.exe.

25

9. At the Welcome screen, click Next.

10. Accept the License Agreement and click Next.

26

11. Again, choose the Typical installation option.

27

12. Click Install to begin the installation.

28

13. When the first step of the installation is complete, click Next to install SQL scripts on the
instances you specify.

29

14. Choose the SQL Server database instance (your instance name will be different from the
example) and click Next.

30

15. Enter the connection information required to connect to your SQL Server database instance and
click Next.

31

16. At the screen that asks whether you would like to install the Extension Pack Utilities Database
on your instance, leave at the default settings to install them and click Next.

17. The installation will run and execute several scripts.

32

18. After the installation is finished, click No; you do not want to install the Utilities Database on
another instance.

33

Configuring SQL Server to Use SQLCLR

After installing SSMA and the SSMA extension pack, you need to configure the SQL Server instance to
utilize the SQL Server Common Language Runtime (SQLCLR).
1. Open a new query window using SSMS and execute the following script to enable CLR in the SQL
Server instance:
EXEC sp_configure 'clr enabled',1
GO
reconfigure
GO

Installing the SSMA License Key

You are now ready to install the SSMA license key.
1. Start SSMA from the Start menu.

34

2. Obtain the License Key by using the provided license registration page link.
Note: You will need to register with Microsoft to obtain the license key. This registration is used to
help provide support for SSMA and notify you of SSMA updates and fixes.

3.

Save the license file.

35

4. Change the directory to the location where you placed the downloaded license key and refresh
the license.

36

Determining Teamcenter Customizations

Teamcenter allows for the addition of features and functionalities beyond the base installation. These
new features and functionalities often create new database objects in the Teamcenter database. To
maintain your existing data in the migration, you need to add these new components to your SQL Server
installation of Teamcenter after the base installation of Teamcenter is complete. Your SQL Server
database schema will then be as close to your Oracle database as possible.
If you have objects in your Oracle database that have not been created in the SQL Server installation, it
is important to capture these new objects and recreate them in the destination SQL Server database.
Capturing the new objects created through customizations is achieved by reading the Oracle metadata
tables and comparing the existing Oracle tables, constraints, and indexes with those found in the SQL
Server database. After the comparisons are made, you need to script out the objects and create them in
your SQL Server 2008 production database.
To ease the migration effort, SSMA is used to create the schema in a staging database for the initial
migration to SQL Server. This converted schema will then be used to compare to the production
database to identify missing objects.
Note: Teamcenter provides the functionality to automatically create needed indexes on
Teamcenter database objects. If you have custom objects not created through the Teamcenter
application, you need to manually recreate those objects in your Teamcenter SQL Server
database. For objects created through Teamcenter, Teamcenter offers functionality that will
recreate the indexes on those objects.

Migrating the Teamcenter Schema to the Staging Database

1. Start SSMA by going to Start, All Programs, Microsoft SQL Server Migration Assistant for
Oracle, Microsoft SQL Server Migration Assistant for Oracle.
2. Start a new project in SSMA by clicking New Project and then giving the project a name and

location.

37

38

3. Connect to the Oracle database.

5. Expand the INFODBA schema and select Tables.

6. Choose the Type Mapping tab to edit the default mappings.

39

7. Edit the following mappings as noted by highlighting the data type and clicking Edit.
Source Type
Float
Number
Numeric
Real

Target Type
Float
Float
Float
Float

40

8. Click OK and repeat for each data type in the above table.
9. Now connect to the SQL Server database.

10. Expand the SQL Server database.

41

11. Highlight the Oracle schema to be converted.

12. Click the Convert Schema tab.

13. Reconnect to the Oracle database.

14. The SSMA will analyze the metadata and create the conversion files.

15. When the analysis is finished, you will see that the output shows both errors and warnings. The
23 errors are for function-based indexes, and the warnings are for loss of precision. The indexes
42

have been accounted for in the production schema, and we are not using SSMA to migrate the
data. You can ignore these errors and warnings.
Note: Your exact output may be different depending on the amount of customizations you have
to your Oracle Teamcenter installation.

16. Once the conversion is finished, you need to synchronize the SQL Server database with the
Oracle database by right-clicking the SQL Server database and selecting Synchronize with
Database.

17. Click OK.

43

18. Because the INFODBA database is a staging database, the indexes are not needed. To speed the
data migration process, you should drop all indexes in the staging database. Execute the
following script in SSMS to create your index drop statements, and then execute the results of
the script to drop the indexes:
USE INFODBA
GO
DECLARE @commandtable TABLE(colid INT IDENTITY(1,1),commandstr
VARCHAR(2000))
DECLARE @command NVARCHAR(2000)
DECLARE @loop_count INT
INSERT INTO @commandtable (commandstr)
SELECT 'DROP INDEX ' + si.name + ' ON ' + so.name
FROM sys.indexes si
INNER JOIN sys.objects so
ON si.object_id = so.object_id
WHERE so.is_ms_shipped = 0
AND si.index_id > 0
SET @loop_count = @@ROWCOUNT
WHILE @loop_count > 0
BEGIN
SELECT @command = commandstr FROM @commandtable WHERE colid =
@loop_count

44

BEGIN TRY
EXEC dbo.sp_executesql @command
END TRY
BEGIN CATCH
END CATCH
SET @loop_count -= 1
END

Determining Table Object Differences

To determine schema object differences, use the following script to compare the schema created by
SSMA in the INFODBA database with the schema from the production SQL Server database:
USE INFODBA
GO
SELECT TABLE_NAME
FROM ORACLETC..SYS.USER_TABLES
WHERE TABLE_NAME NOT IN (SELECT name COLLATE Latin1_General_BIN
FROM sys.objects
WHERE type = 'u'
AND is_ms_shipped = 0)
AND TABLE_NAME <> 'PLAN_TABLE'
ORDER BY TABLE_NAME

Execute the results of the above script to identify tables that you will need to create.
Once you have a list of tables that are missing from the SQL Server database, you need to connect to
Oracle to describe the tables so that you can recreate them in SQL Server. Do not use the schema
created by SSMA to recreate the missing tables; use the Oracle schema.
In Oracle
For each table in the output from the above script, describe the table and create a T-SQL table creation
script for the table. For example, lets say that the PCOUNTER_TAGS_1 table was not found in SQL
Server. To get the description, execute the following:
desc PCOUNTER_TAGS_1;

The output is as follows:

Name
Null?
Type
NOT
PUID
NULL
VARCHAR2(15)
NOT
PSEQ
NULL
NUMBER(38)
PVALU_0
VARCHAR2(15)
PVALC_0
NUMBER(38)
This output of the table description will translate into the SQL Server CREATE TABLE statement below
(using lower case for column names):
45

Note: Use the SQL Server-to-Oracle data type conversion table in Appendix A to correctly map the data
types from Oracle to SQL Server.
BEGIN TRY
DROP TABLE PCOUNTER_TAGS_1
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PCOUNTER_TAGS_1
(
puid
NVARCHAR(15) NOT NULL
,pseq
FLOAT
NOT NULL
,pvalu_0
NVARCHAR(15)
,pvalc_0
FLOAT
)
GO

Note: You can find sample CREATE TABLE scripts in Appendix B for creating tables missing from base
installations.
In SQL Server
Execute the CREATE TABLE statements you created for each missing Oracle table in your production
database.

Determining Index Object Differences

After identifying and creating missing table objects, you need to create any indexes for those missing
table objects.
You can use the Teamcenter index tool (index_verifier) to recreate any missing indexes in your
production database. You do not need to create indexes in your staging database.

Determining Constraint Object Differences

After determining and creating missing table objects, you need to create any constraints for those
missing table objects.
--This script will determine difference in constraints
SELECT * FROM ORACLETC..SYS.USER_CONSTRAINTS
WHERE TABLE_NAME IN ('PCOUNTER_TAGS_1'
,'SYS_IMPORT_SCHEMA_01'
,'PFIXED_COST_TAGLIST_0'
,'POM_UID_SCRATCH'
,'PREFAUNIQUEEXPRID2'
,'PVISSTRUCTURERECEIPE'
,'PVISMANAGEDDOCUMENT'
,'PPATTERN_0'
,'POCCURRENCE_LIST'
,'PVISSTRUCTURECONTEXT'
,'PJTCONTENTFORMSTORAGE'
,'EIM_UID_GENERATOR_ROOT')

46

ORDER BY TABLE_NAME;

Now you can create those missing constraints on your tables in your production SQL Server production
database:
-- Change to your production database
USE tc
GO
CREATE UNIQUE NONCLUSTERED INDEX SYS_C009756 ON
SYS_IMPORT_SCHEMA_01(PROCESS_ORDER,DUPLICATE)

Note: You do not need to recreate NOT NULL constraints

Migrating the Data into the Teamcenter Database

After you have recreated all missing tables, indexes, and constraints, you are ready to migrate the data
from the Oracle database into your staging database (INFODBA) in SQL Server. To migrate the data, you
need to create a series of INSERT INTO statements to read the data from the Oracle tables into the SQL
Server staging tables. Once you have moved the data into the staging tables, you will then move the
data into the production SQL Server tables.
Note: Appendix B provides some common table creation scripts.
1. Execute the following script to move the data into the staging database:
USE INFODBA
GO
SET NOCOUNT ON
DECLARE
DECLARE
DECLARE
DECLARE

@table_count BIGINT
@table_name VARCHAR(255)
@strsql nvarchar(4000)
@strsql2 VARCHAR(4000)

BEGIN TRY
DROP TABLE #tables
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #tables
(
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
)
BEGIN TRY
DROP TABLE #columns
END TRY
BEGIN CATCH

47

END CATCH
CREATE TABLE #columns
(
colid INT IDENTITY(1,1)
,column_name VARCHAR(255)
,system_type_id INT
)
INSERT INTO #tables (table_name)
SELECT TABLE_NAME FROM ORACLETC..SYS.USER_TABLES
WHERE TABLE_NAME <> 'PLAN_TABLE'
SET @table_count = @@ROWCOUNT
WHILE @table_count > 0
BEGIN
TRUNCATE TABLE #columns
SELECT @table_name = table_name FROM #tables WHERE colid =
@table_count
SET @strsql = 'INSERT INTO #columns (column_name,system_type_id)
SELECT name, system_type_id FROM sys.columns WHERE object_id =
OBJECT_ID('''
+ @table_name + ''')'
EXEC dbo.sp_executesql @strsql
UPDATE #columns
SET column_name = 'CAST(' + column_name + ' AS VARCHAR(1000))'
WHERE system_type_id IN (108)
SET @strsql2 = ''
SELECT @strsql2 = @strsql2 + column_name + ','
FROM #columns
SET @strsql2 = @strsql2 + '|' --take care of trailing comma
SET @strsql2 = REPLACE (@strsql2,',|',' ')
SET @strsql = 'INSERT INTO ' + @table_name
+ ' SELECT * FROM OPENQUERY(ORACLETC,''SELECT ' + @strsql2 + '
FROM INFODBA.'
+ @table_name + ''') AS ROWSET_1'
BEGIN TRY
EXEC dbo.sp_executesql @strsql
END TRY
BEGIN CATCH
SELECT @strSQL
END CATCH
SET @table_count -= 1
END

2. Verify that the rows in the Oracle database and the SQL Server staging database are consistent:
48

USE INFODBA
GO
SET NOCOUNT ON
BEGIN TRY
DROP TABLE #ora_tables
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #ora_tables (
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
,row_count BIGINT
)
BEGIN TRY
DROP TABLE #sql_tables
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #sql_tables (
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
,row_count BIGINT
)
DECLARE
DECLARE
DECLARE
DECLARE

@ora_table_count INT
@sql_table_count INT
@table_name VARCHAR(255)
@strSQL NVARCHAR(4000)

INSERT INTO #sql_tables(table_name)

SELECT name FROM sys.objects
WHERE is_ms_shipped = 0
AND type = 'U'
SET @sql_table_count = @@ROWCOUNT
WHILE @sql_table_count > 0
BEGIN
SELECT @table_name = table_name FROM #sql_tables WHERE colid =
@sql_table_count
SET @strSQL = 'UPDATE #sql_tables SET row_count = (SELECT
COUNT(*) FROM dbo.' + @table_name + ' WITH (NOLOCK))
WHERE colid = ' + CAST(@sql_table_count AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @sql_table_count -= 1
END
INSERT INTO #ora_tables(table_name)
SELECT TABLE_NAME
FROM ORACLETC..SYS.USER_TABLES
SET @ora_table_count = @@ROWCOUNT

49

WHILE @ora_table_count > 0

BEGIN
SELECT @table_name = table_name FROM #ora_tables WHERE colid =
@ora_table_count
SET @strSQL = 'UPDATE #ora_tables SET row_count = (SELECT
COUNT(*) FROM dbo.' + @table_name + ' WITH (NOLOCK))
WHERE colid = ' + CAST(@ora_table_count AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @ora_table_count -= 1
END
--Tables showing up have different row counts
SELECT sc.table_name AS 'Staging Table'
,sc.row_count AS 'Staging row count'
,oc.table_name AS 'Oracle Table'
,oc.row_count AS 'Oracle row count'
FROM #sql_tables sc
INNER JOIN #ora_tables oc
ON sc.table_name = oc.table_name
AND sc.row_count <> oc.row_count

3. Verify that the data precision is the same:

USE INFODBA
GO
SET NOCOUNT ON
BEGIN TRY
DROP TABLE #ora_tables
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #ora_tables (
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
,column_name VARCHAR(255)
,ora_data_length INT
,sql_data_length INT
)
DECLARE
DECLARE
DECLARE
DECLARE
DECLARE

@ora_table_count INT
@loop INT
@table_name VARCHAR(255)
@column_name VARCHAR(255)
@strSQL NVARCHAR(4000)

SET @loop = 1
INSERT INTO #ora_tables(table_name,column_name)
SELECT TABLE_NAME, COLUMN_NAME
FROM ORACLETC..SYS.USER_TAB_COLUMNS
WHERE DATA_TYPE = 'FLOAT'
AND DATA_PRECISION = 126
SET @ora_table_count = @@ROWCOUNT

50

SET @loop = @ora_table_count

WHILE @loop > 0
BEGIN
SELECT @table_name = table_name, @column_name = column_name
FROM #ora_tables WHERE colid = @loop
SET @strSQL = 'UPDATE #ora_tables SET ora_data_length = (SELECT
ISNULL(MAX(LEN(' + @column_name + ')),0) FROM ORACLETC..INFODBA.'
+ @table_name + ' WITH (NOLOCK))
WHERE colid = ' + CAST(@loop AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @loop -= 1
END
SET @loop = @ora_table_count
WHILE @loop > 0
BEGIN
SELECT @table_name = table_name, @column_name = column_name
FROM #ora_tables WHERE colid = @loop
SET @strSQL = 'UPDATE #ora_tables SET sql_data_length = (SELECT
ISNULL(MAX(LEN(' + @column_name + ')),O) FROM dbo.' + @table_name
+ ' WITH (NOLOCK))
WHERE colid = ' + CAST(@loop AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @loop -= 1
END
--Should be no result set
SELECT *
FROM #ora_tables
WHERE ora_data_length <> sql_data_length

Note: You may have to manually correct any data precision issues by changing the data types of
the production SQL Server database.
4. After migrating the data from the Oracle database into your staging database, create a backup
of the staging database.
5. After the backup completes, you will need to create a snapshot database of the database for
easier rollback to the migrated staging database in case of errors or issues during the migration
to the production database.
USE master
GO
--Determine file names
SELECT name, physical_name FROM sys.master_files
WHERE database_id = DB_ID('INFODBA')
CREATE DATABASE INFODBA_snapshot
ON
--You will need to change the path to your SQL Server directory.

51

( NAME = INFODBA
, FILENAME =
'C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Data\INFODBA.ss' )
AS SNAPSHOT OF INFODBA;
GO

6. After creating a snapshot of the staging database for rollback purposes, you will now need to
rename several tables in the staging database schema to match the production database
schema.
--Rename tables in staging to match production
USE INFODBA
GO
SET NOCOUNT ON
DECLARE @loop INT
DECLARE @loop_1 INT
DECLARE @rowcount INT
DECLARE @command_1 NVARCHAR(4000)
DECLARE @command_2 NVARCHAR(4000)
--There will be one set of commands for temporary names
--There will be another set of commands for final names
SET @loop_1 = 2
--Table to hold rename commands
BEGIN TRY
DROP TABLE #PLOVP
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #PLOVP
(
colid INT IDENTITY(1,1)
,command_1 NVARCHAR(4000)
,command_2 NVARCHAR(4000)
)

COLLATE Latin1_General_BIN
COLLATE Latin1_General_BIN

--Determine the difference between SQL Server version and Oracle

version
--Rename to SQL Server version
--Need to set tables to temp names to avoid renaming conflicts
INSERT INTO #PLOVP (command_1, command_2)
SELECT 'exec sp_rename ''' + infodba.pdbname
COLLATE
Latin1_General_BIN + ''',''' + tc.pdbname + '_new'''
,'exec sp_rename '''+ tc.pdbname + '_new'''+ ',''' + tc.pdbname + ''''
FROM
(SELECT a.pdbname
,c.pname AS pname_class
,a.pname AS pname_attribute
FROM INFODBA..PPOM_CLASS_saved c
INNER JOIN INFODBA..PPOM_ATTRIBUTE_saved a
ON a.rdefining_classu = c.puid
AND a.plength = -1

52

WHERE a.pdbname LIKE 'PLOV_VALUES%') tc

INNER JOIN (SELECT a.pdbname
,c.pname AS pname_class
,a.pname AS pname_attribute
FROM INFODBA..PPOM_CLASS c
INNER JOIN INFODBA..PPOM_ATTRIBUTE a
ON a.rdefining_classu = c.puid
AND a.plength = -1
WHERE a.pdbname LIKE 'PLOV_VALUES%'
AND
c.pname LIKE 'ListOf%') infodba
ON tc.pname_class = infodba.pname_class COLLATE Latin1_General_BIN
AND tc.pname_attribute = infodba.pname_attribute COLLATE
Latin1_General_BIN
SET @rowcount = @@ROWCOUNT
WHILE @loop_1 > 0
BEGIN
SET @loop = @rowcount
--Execute rename statements
WHILE @loop > 0
BEGIN
SELECT @command_1 = command_1, @command_2 = command_2 FROM
#PLOVP WHERE colid = @loop
IF @loop_1 = 2
BEGIN
EXEC dbo.sp_executesql @command_1
END
IF @loop_1 = 1
BEGIN
EXEC dbo.sp_executesql @command_2
END
SET @loop -= 1
END
SET @loop_1 -= 1
END
GO

7. After creating a snapshot of the staging database for rollback purposes, you will now need to
rename several columns in the staging database schema to match the production database
schema.
--Rename columns in staging to match production
USE INFODBA
GO
SET NOCOUNT ON
DECLARE @rowcount INT
DECLARE @command_1 NVARCHAR(4000)
--Table to hold rename commands

53

BEGIN TRY
DROP TABLE #PLOVP
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #PLOVP
(
colid INT IDENTITY(1,1)
,command_1 NVARCHAR(4000)
)

COLLATE Latin1_General_BIN

--Determine the column naming differences between SQL Server version

and Oracle version
--Rename to SQL Server version
INSERT INTO #PLOVP (command_1)
SELECT 'EXEC dbo.sp_rename ''' + info.tabname_class + '.' + info.vla +
''',''' + tc.vla + ''',''COLUMN'''
FROM
(SELECT 'VLA_'+ CONVERT(VARCHAR, pc.pcpid) + '_' + CONVERT(VARCHAR,
pa.papid) AS vla
,pc.PNAME AS oname
,pa.PNAME AS descp
,pc.PTNAME AS tabname_class
FROM INFODBA..PPOM_CLASS pc
INNER JOIN INFODBA..PPOM_ATTRIBUTE pa
ON pa.rdefining_classu = pc.puid
AND pa.plength = -1) info
INNER JOIN
(SELECT 'VLA_'+ CONVERT(VARCHAR, pc.pcpid) + '_' + CONVERT(VARCHAR,
pa.papid) AS VLA
,pc.PNAME AS oname
,pa.PNAME AS descp
,pc.PTNAME AS tabname_class
FROM INFODBA..PPOM_CLASS_saved pc
INNER JOIN INFODBA..PPOM_ATTRIBUTE_saved pa
ON pa.rdefining_classu = pc.puid
AND pa.plength = -1) tc
ON info.oname COLLATE Latin1_General_BIN = tc.oname
AND info.descp COLLATE Latin1_General_BIN = tc.descp
AND info.tabname_class COLLATE Latin1_General_BIN = tc.tabname_class
SET @rowcount = @@ROWCOUNT
WHILE @rowcount > 0
BEGIN
SELECT @command_1 = command_1 FROM #PLOVP WHERE colid = @rowcount
BEGIN TRY
EXEC dbo.sp_executesql @command_1
END TRY
BEGIN CATCH
END CATCH
SET @rowcount -= 1
END
GO

54

8.

Update columns in the POM_INDEXES table.

--Determine and rename duplicate entries
USE INFODBA
GO
UPDATE TOP (1) d
SET d.dbname = d.dbname + '_' + CAST(d.youneek AS VARCHAR(11))
FROM POM_INDEXES d
INNER JOIN (
SELECT dbname,cpid,apid
FROM POM_INDEXES
GROUP BY dbname,cpid,apid
HAVING COUNT(*) > 1)db
ON db.dbname = d.dbname
AND db.cpid = d.cpid
AND db.apid = d.apid

9. Drop the temporary PPOM_CLASS_saved and PPOM_ATTRIBUTE_saved tables.

USE INFODBA
GO
DROP TABLE PPOM_CLASS_saved
DROP TABLE PPOM_ATTRIBUTE_saved
GO

10. Once you are satisfied that everything is correct and have performed all use-case testing from
your migration plan, migrate the data into the production database:
USE tc
GO
SET NOCOUNT ON
DECLARE
DECLARE
DECLARE
DECLARE

@table_count BIGINT
@table_name VARCHAR(255)
@strsql nvarchar(4000)
@strsql2 VARCHAR(4000)

BEGIN TRY
DROP TABLE #row_count
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #row_count
(
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
,row_count BIGINT
)

55

BEGIN TRY
DROP TABLE #tables
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #tables
(
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
)
BEGIN TRY
DROP TABLE #columns
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #columns
(
colid INT IDENTITY(1,1)
,column_name VARCHAR(255)
,system_type_id INT
)
DECLARE @row_count INT
INSERT INTO #row_count(table_name)
SELECT name FROM INFODBA.sys.objects
WHERE is_ms_shipped = 0
AND type = 'U'
SET @row_count = @@ROWCOUNT
WHILE @row_count > 0
BEGIN
SELECT @table_name = table_name FROM #row_count WHERE colid =
@row_count
SET @strSQL = 'UPDATE #row_count SET row_count = (SELECT COUNT(*) FROM
INFODBA.dbo.' + @table_name + ' WITH (NOLOCK))
WHERE colid = ' + CAST(@row_count AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @row_count -= 1
END
INSERT INTO #tables (table_name)
SELECT so.name
FROM tc.sys.objects so
WHERE so.is_ms_shipped = 0
AND so.type = 'U'
SET @table_count = @@ROWCOUNT
WHILE @table_count > 0
BEGIN
TRUNCATE TABLE #columns
SET @row_count = 0

56

SELECT @table_name = table_name FROM #tables WHERE colid =

@table_count
SELECT @row_count = row_count FROM #row_count WHERE table_name =
@table_name
SET @row_count = ISNULL(@row_count,0)
IF @row_count > 0
BEGIN
SET @strsql = 'INSERT INTO #columns (column_name)
SELECT name FROM tc.sys.columns WHERE object_id =
OBJECT_ID('''
+ @table_name + ''')'
EXEC dbo.sp_executesql @strsql
SET @strsql2 = ''
SELECT @strsql2 = @strsql2 + column_name + ','
FROM #columns
SET @strsql2 = @strsql2 + '|' --take care of trailing comma
SET @strsql2 = REPLACE (@strsql2,',|',' ')
SET @strsql = 'INSERT INTO ' + @table_name + '(' + @strsql2
+ ')'
+ ' SELECT ' + @strsql2 + ' FROM INFODBA.dbo.' +
@table_name
BEGIN TRY
EXEC dbo.sp_executesql @strsql
END TRY
BEGIN CATCH
SELECT @strSQL AS 'Table did not load investigate
manually'
END CATCH
END
SET @table_count -= 1
END

11. The script above will produce a listing of tables that did not have data into them due to column
differences between the staging and production databases. You may have to manually create
some table insert statements to overcome these column differences, as in these examples:
USE tc
GO
--Column names different
INSERT INTO PPOM_SITE_CONFIG(puid,LS_13_2,pindex )
SELECT puid,LS_388_1,pindex FROM INFODBA.dbo.PPOM_SITE_CONFIG
--Column names different
INSERT INTO PTC_PREFERENCES(puid,LS_330_2,robject_tagu,robject_tagc )
SELECT puid,LS_473_1,robject_tagu,robject_tagc FROM
INFODBA.dbo.PTC_PREFERENCES

57

--Column names are different

INSERT INTO PFULLTEXT(puid,LS_739_1,pbody_cleartext,pcontent_type )
SELECT puid,LS_492_1,pbody_cleartext,pcontent_type FROM
INFODBA.dbo.PFULLTEXT
--Column PIPLISTOFVALUES_1_0 not in SQL Server table
INSERT INTO
PLISTOFVALUES(puid,plov_name,plov_desc,plov_type,plov_attached_class,pl
ov_attached_attr,VLA_427_9,VLA_427_10,VLA_427_11,VLA_427_12,VLA_427_13,
VLA_427_14,VLA_427_15,VLA_427_16,VLA_427_17,VLA_427_18,VLA_427_19,VLA_4
27_20,plov_attached_type,plov_value_type,plov_usage )
SELECT
puid,plov_name,plov_desc,plov_type,plov_attached_class,plov_attached_at
tr,VLA_427_9,VLA_427_10,VLA_427_11,VLA_427_12,VLA_427_13,VLA_427_14,VLA
_427_15,VLA_427_16,VLA_427_17,VLA_427_18,VLA_427_19,VLA_427_20,plov_att
ached_type,plov_value_type,plov_usage FROM INFODBA.dbo.PLISTOFVALUES
--Column PIPIMANQUERY_1_0 not in SQL Server table
INSERT INTO
PIMANQUERY(puid,pquery_name,pquery_desc,pquery_class,VLA_184_4,pquery_u
id_name,pquery_flag,presults_type )
SELECT
puid,pquery_name,pquery_desc,pquery_class,VLA_184_4,pquery_uid_name,pqu
ery_flag,presults_type FROM INFODBA.dbo.PIMANQUERY
--Column PIPITEMREVISION_2_0 not in SQL Server table
INSERT INTO
PITEMREVISION(puid,pitem_revision_id,VLA_631_8,VLA_631_10,VLA_631_11,VL
A_631_12,rsequence_anchoru,rsequence_anchorc,rvariant_expression_blocku
,rvariant_expression_blockc,ritems_tagu,ritems_tagc,psequence_id,pseque
nce_limit,phas_variant_module)
SELECT
puid,pitem_revision_id,VLA_631_8,VLA_631_10,VLA_631_11,VLA_631_12,rsequ
ence_anchoru,rsequence_anchorc,rvariant_expression_blocku,rvariant_expr
ession_blockc,ritems_tagu,ritems_tagc,psequence_id,psequence_limit,phas
_variant_module FROM INFODBA.dbo.PITEMREVISION
--Columns PIPOM_KEY_0 and PIPOM_KEY_1 not in SQL Server table
INSERT INTO POM_KEY(puid,domain,key_value)
SELECT puid,domain,key_value FROM INFODBA.dbo.POM_KEY
--Column PIPPOM_USER_1_0 not in SQL Server table
INSERT INTO
PPOM_USER(puid,puser_id,ppassword,puser_name,pstatus,pdef_acl,pdefault_
group,puser_data_source,plicense_level,plast_login_time,puser_last_sync
_date )
SELECT
puid,puser_id,ppassword,puser_name,pstatus,pdef_acl,pdefault_group,puse
r_data_source,plicense_level,plast_login_time,puser_last_sync_date
FROM INFODBA.dbo.PPOM_USER
--Column difference
INSERT INTO
POM_ROOT(site_id,[schema],[path],site_state,cpid,[version],scan_state,s
can_name,scan_class,info,can_edit_schema )

58

SELECT
site_id,[schema],[path],site_state,cpid,[version],scan_state,scan_name,
scan_class,info,can_edit_schema FROM INFODBA.dbo.POM_ROOT
--Columns PIPWORKSPACEOBJ_0_0 and PIPWORKSPACEOBJ_1_0 not in SQL Server
table
INSERT INTO
PWORKSPACEOBJECT(puid,pobject_name,pobject_desc,pobject_type,pobject_ap
plication,VLA_484_7,pip_classification,VLA_484_10,pgov_classification,V
LA_484_13,VLA_484_16,pactive_seq,prevision_number,rwso_threadu,rwso_thr
eadc,rowning_organizationu,rowning_organizationc,prevision_limit,rownin
g_projectu,rowning_projectc,pdate_released )
SELECT
puid,pobject_name,pobject_desc,pobject_type,pobject_application,VLA_484
_7,pip_classification,VLA_484_10,pgov_classification,VLA_484_13,VLA_484
_16,pactive_seq,prevision_number,rwso_threadu,rwso_threadc,rowning_orga
nizationu,rowning_organizationc,prevision_limit,rowning_projectu,rownin
g_projectc,pdate_released FROM INFODBA.dbo.PWORKSPACEOBJECT

12. Verify the row counts between the staging and production SQL Server databases:
USE INFODBA
GO
SET NOCOUNT ON
BEGIN TRY
DROP TABLE #sql_tables_staging
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #sql_tables_staging
(
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
,row_count BIGINT
)
BEGIN TRY
DROP TABLE #sql_tables_final
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #sql_tables_final
(
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
,row_count BIGINT
)
DECLARE
DECLARE
DECLARE
DECLARE

@stage_table_count INT
@final_table_count INT
@table_name VARCHAR(255)
@strSQL NVARCHAR(4000)

59

INSERT INTO #sql_tables_staging(table_name)

SELECT name FROM sys.objects
WHERE is_ms_shipped = 0
AND type = 'U'
SET @stage_table_count = @@ROWCOUNT
WHILE @stage_table_count > 0
BEGIN
SELECT @table_name = table_name FROM #sql_tables_staging
WHERE colid = @stage_table_count
SET @strSQL = 'UPDATE #sql_tables_staging SET row_count = (SELECT
COUNT(*) FROM dbo.' + @table_name + ' WITH (NOLOCK))
WHERE colid = ' + CAST(@stage_table_count AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @stage_table_count -= 1
END
INSERT INTO #sql_tables_final(table_name)
SELECT name
FROM tc.sys.objects --you will have to change to your database name
WHERE is_ms_shipped = 0
AND type = 'U'
SET @final_table_count = @@ROWCOUNT
WHILE @final_table_count > 0
BEGIN
SELECT @table_name = table_name FROM #sql_tables_final
WHERE colid = @final_table_count
SET @strSQL = 'UPDATE #sql_tables_final SET row_count = (SELECT
COUNT(*) FROM tc.dbo.' + @table_name + ' WITH (NOLOCK))
WHERE colid = ' + CAST(@final_table_count AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @final_table_count -= 1
END
--Tables showing up have different row counts
SELECT sc.table_name AS 'Staging Table'
,sc.row_count AS 'Staging Row Count'
,fc.table_name AS 'Production Table'
,fc.row_count AS 'Production Table Row Count'
FROM #sql_tables_staging sc
INNER JOIN #sql_tables_final fc
ON sc.table_name = fc.table_name
AND sc.row_count <> fc.row_count

13. Verify that the data precision is the same:

USE INFODBA
GO
SET NOCOUNT ON
BEGIN TRY

60

DROP TABLE #staging_tables

END TRY
BEGIN CATCH
END CATCH
CREATE TABLE #staging_tables (
colid INT IDENTITY(1,1)
,table_name VARCHAR(255)
,column_name VARCHAR(255)
,staging_data_length INT
,final_data_length INT
)
DECLARE
DECLARE
DECLARE
DECLARE
DECLARE

@staging_table_count INT
@loop INT
@table_name VARCHAR(255)
@column_name VARCHAR(255)
@strSQL NVARCHAR(4000)

SET @loop = 1
INSERT INTO #staging_tables(table_name,column_name)
SELECT TABLE_NAME, COLUMN_NAME
FROM ORACLETC..SYS.USER_TAB_COLUMNS
WHERE DATA_TYPE = 'FLOAT'
AND DATA_PRECISION = 126
SET @staging_table_count = @@ROWCOUNT
SET @loop = @staging_table_count
WHILE @loop > 0
BEGIN
SELECT @table_name = table_name, @column_name = column_name
FROM #staging_tables WHERE colid = @loop
SET @strSQL = 'UPDATE #staging_tables SET staging_data_length =
(SELECT ISNULL(MAX(LEN(' + @column_name + ')),0) FROM
INFODBA.dbo.' + @table_name + ' WITH (NOLOCK))
WHERE colid = ' + CAST(@loop AS VARCHAR(20))
EXEC sp_executesql @strSQL
SET @loop -= 1
END
SET @loop = @staging_table_count
WHILE @loop > 0
BEGIN
SELECT @table_name = table_name, @column_name =LOWER(column_name)
FROM #staging_tables WHERE colid = @loop
--You will have to change production database name
BEGIN TRY
SET @strSQL = 'UPDATE #staging_tables SET final_data_length
= (SELECT ISNULL(MAX(LEN(' + @column_name COLLATE
Latin1_General_BIN + ')),0) FROM tc.dbo.' + @table_name +
' WITH (NOLOCK))
WHERE colid = ' + CAST(@loop AS VARCHAR(20))
EXEC sp_executesql @strSQL
END TRY
BEGIN CATCH

61

SELECT @table_name AS 'Table Name'

, @column_name AS 'Column Name'
END CATCH
SET @loop -= 1
END
--Should be no result set
SELECT *
FROM #staging_tables
WHERE staging_data_length <> final_data_length

Note; You may have to manually correct any data precision issues.
14. Drop the staging database snapshot:
USE MASTER
GO
DROP DATABASE INFODBA_snapshot
GO

Performing Post-Migration Tasks

After you have migrated and verified all your data, you need to perform the following post-migration
tasks:
1. Index maintenance
2. Database checks
3. Database backups

Monitoring Index Fragmentation and Defragmenting

SQL Server uses indexes to provide fast access to information when users or applications request it.
These indexes are maintained by the Database Engine as the table data grows and/or changes. Over
time, the indexes can become fragmented; especially in databases that handle heavy insert, update, and
delete activity. An index is fragmented when the physical ordering on disk does not match the logical
order of the data (as defined by the index key) or when data pages that contain the index are dispersed
across non-adjacent sections of the disk.
Fragmentation of an index can reduce the speed of data access and result in slower application
performance. It can also cause more disk space to be used than is actually necessary. Index
fragmentation can be corrected by reorganizing or rebuilding the index.
You can tell which indexes, if any, have fragmentation problems by using the sys.dm_db_physical_stats()
system function. This function provides a lot of detail about the physical layout of the index. However,
the most important result column for tracking fragmentation is avg_fragmentation_in_percent. This
column indicates how fragmented the index is on disk. A low number means low fragmentation (good);
a high number means high fragmentation (bad).
For example, the following query returns index physical stats for all the indexes in the current database:
62

SELECT OBJECT_NAME(object_id),
index_id,
page_count,
index_type_desc,
avg_fragmentation_in_percent,
fragment_count
FROM sys.dm_db_index_physical_stats(db_id(),NULL,NULL,NULL,'LIMITED')

To identify the indexes by name, you can join against the sys.indexes system view.
Similar information is also available in the Standard Reports in SSMS. To view this report, right-click the
Teamcenter database, select Reports, Standard Reports, and then select the Index Physical Statistics
report on the fly-out menu.
The rule-of-thumb in the following table indicates how to interpret the avg_fragmentation_in_percent
value.
Fragmentation
< 5%
5% to 30%
> 50%

Recommended Action
Do nothing
Reorganize with
ALTER INDEX REORGANIZE
Rebuild with
ALTER INDEX REBUILD WITH (ONLINE=ON)
or
CREATE INDEX with DROP_EXISTING=ON

Reorganizing an index does not block user access to the index while underway. Rebuilding or recreating
the index, however, does prevent user access to the index. The exception to this is if the ALTER INDEX
REBUILD statement is used with the ONLINE = ON option. Note that online index rebuild requires the
Enterprise Edition of SQL Server 2008.
Periodically checking index fragmentation and taking any necessary corrective action is important to
maintaining the performance of your Teamcenter deployment. The rate at which fragmentation may
occur depends on user activity, but as a general rule Siemens recommends checking index
fragmentation at least monthly.

Running the Teamcenter Index-Verifier Tool

Siemens provides an index_verifier utility, packaged with all versions of Teamcenter, to analyze your
Teamcenter database for missing indexes. If the index_verifier utility finds missing indexes, it will output
SQL statements that you can use to create the indexes.Siemens best practice is to run this utility
monthly at a minimum.
Siemens also recommends adding additional indexes you may require by using the install command-ine
utility provided with Teamcenter. Doing so will register the index as part of the Teamcenter schema, at
which point index_verifier can check for its existence. If you manually add indexes to the Teamcenter
63

database, index_verifier will have no knowledge of them and it will be your responsibility to ensure that
those indexes are carried forward and maintained.
You can find full documentation of these utilities in the Teamcenter Utilities Reference Manual available
on the Siemens Teamcenter GTAC Support Site.

Checking Database Integrity

For all the sophisticated data management techniques embedded in the SQL Server database engine,
there is still the possibility of some corruption occurring in a database, most notably as the result of a
hardware glitch. To head off the potential impact of such problems, you should regularly check the
integrity of the database. The statement for doing this in T-SQL is DBCC CHECKDB.
It is best to include database integrity checks in a scheduled job that executes DBCC CHECKDB or
through a scheduled Maintenance Plan that includes the Check Database Integrity task.
If any problems are detected, you can restore from backups (usually the best option) or use one of the
REPAIR options on DBCC CHECKDB.

Changing the Recovery Model

After verifying the health of your new SQL Server production database, you need to change the recovery
model back to Full.

Creating Database Backups

It is recommended that you create full database backups, differential database backups, and transaction
log backups in order to protect your database. You should use SSMS and create custom T-SQL backup
scripts and SQL Server Agent jobs or use a Maintenance Plan to back up your database.
You should also use a Maintenance Plan to back up your system databases on a weekly basis.

Validating the Migration Through Teamcenter Use Cases

The final step in your migration process is to test the use-case scenarios you determined at the start of
your migration planning to verify your new production database. These scenarios should include the
addition of new data and the validation of existing data between the Oracle database and the SQL
Server database.
Some common use cases affected by the migration process are customized form attributes in
Teamcenter, as well as custom items, objects, and data types. Testing their functionality is of utmost
importance.
Further testing should be done on assemblies and viewer data to ensure correctness; however issues
here should be rare or related to custom attributes.

64

Appendix A: Basic Data Type

Conversions
Numeric Data Types
Oracle

SQL Server

Number(19,0)

BigInt

Int or Number(10,0)

Int

SmallInt or Number(6,0)

SmallInt

Number(3,0)

TinyInt

Number(p,0)

Decimal(p,s)

Number(p,0)

Numeric(p,s)

Float, Double Precision, or Number(38)

Float

Number(1)

Bit

Number(19,4)

Money

Number(10,4)

SmallMoney

Character Data Types

Oracle
Data Type

SQL Server
Size in bytes

Data Type

Number of
Chars

Size in bytes

65

Char

1 to 2000

Char

1 to 8000

1 to 8000 fixed

NChar

1 to 2000 (fewer chars)

NChar

1 to 4000

2 to 8000 fixed

Varchar

1 to 4000

Varchar
Varchar(max)

1 to 8000
1 to 231-1

0 to 8000
0 to 2GB

NVarchar

1 to 4000 (fewer chars)

NVarchar
NVarchar(max)

1 to 4000
1 to 230-1

0 to 8000
0 to 2GB

Varchar2

1 to 4000

NVarchar2

1 to 4000 (fewer chars)

LONG

1 to 231

Text,
Varchar(max)

1 to 231-1

0 to 2GB

CLOB

1 to 232

Text,
Varchar(max)

1 to 231-1

0 to 2GB

NCLOB

1 to 232

Ntext,
Nvarchar(max)

1 to 230-1

0 to 2GB

Date and Time Data Types

Oracle

SQL Server

Data Type

Values

Data Type

Values

Date

Date and time to seconds

SmallDateTime

Date and time to seconds

DateTime

Date and time with fractional seconds to

1/300 or 3.33 milliseconds

Calendar

01/01/1753 AD 01/06/9999 AD(DMY)

DateTime2 (DT2)

Date and time with fractional seconds

(7 digits)

Timestamp (TS)

Date and time with

fractional seconds (9 digits)

Timestamp with
time zone (TSTZ)

Like TS with zones

66

Timestamp with
local time zone
(TSLTZ)

Like TS with relative zones

to users

DateTimeOffset

Like DT2 with time zone offsets

Calendar Julian

01/01/4712 BCE 12/31/4712 CE

Calendar
Gregorian

01/01/0001 AD 31/12/9999 AD (DMY)

Daylight Saving
Time Support

Yes

Daylight Saving
Time Support

No

DATE

Date only Gregorian

TIME

Time only with fractional seconds

(7 digits)

Binary Data Types

Oracle

SQL Server

BLOB

Image, Varbinary(max)

Raw

Image, Varbinary(max)

Long Raw

Image, Varbinary(max)

BFile

Similar to
Varbinary(max) Filestream

BLOB/Raw(n)

Binary(n)

BLOB/Raw(n)

Varbinary(n), Varbinary(max)

67

Appendix B: Sample Teamcenter Table

Creation Scripts
--Change to your production database name
USE tc
GO
BEGIN TRY
DROP TABLE PCOUNTER_TAGS_1
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PCOUNTER_TAGS_1
(
puid
VARCHAR(30) NOT NULL
,pseq
FLOAT NOT NULL
,p_valu_0
VARCHAR(30) NULL
,p_valc_0
FLOAT NULL
)
GO
BEGIN TRY
DROP TABLE SYS_IMPORT_SCHEMA_01
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE SYS_IMPORT_SCHEMA_01
(
PROCESS_ORDER
FLOAT NULL
,DUPLICATE
FLOAT NULL
,DUMP_FILEID
FLOAT NULL
,DUMP_POSITION
FLOAT NULL
,DUMP_LENGTH
FLOAT NULL
,DUMP_ALLOCATION
FLOAT NULL
,COMPLETED_ROWS
FLOAT NULL
,ERROR_COUNT
FLOAT NULL
,ELAPSED_TIME
FLOAT NULL
,OBJECT_TYPE_PATH
VARCHAR(200)
,OBJECT_PATH_SEQNO
FLOAT NULL
,OBJECT_TYPE
VARCHAR(30) NULL
,IN_PROGRESS
CHAR(1)
NULL
,OBJECT_NAME
VARCHAR(500)
,OBJECT_LONG_NAME VARCHAR(4000)
NULL
,OBJECT_SCHEMA
VARCHAR(30) NULL
,ORIGINAL_OBJECT_SCHEMA VARCHAR(30) NULL
,PARTITION_NAME
VARCHAR(30) NULL
,SUBPARTITION_NAME
VARCHAR(30) NULL
,FLAGS
FLOAT NULL
,PROPERTY
FLOAT NULL
,COMPLETION_TIME DATE NULL
,OBJECT_TABLESPACE
VARCHAR(30) NULL

NULL

NULL

68

,SIZE_ESTIMATE
FLOAT NULL
,OBJECT_ROW FLOAT NULL
,PROCESSING_STATE CHAR(1)
NULL
,PROCESSING_STATUS
CHAR(1)
,BASE_PROCESS_ORDER
FLOAT NULL
,BASE_OBJECT_TYPE VARCHAR(30) NULL
,BASE_OBJECT_NAME VARCHAR(30) NULL
,BASE_OBJECT_SCHEMA
VARCHAR(30)
,ANCESTOR_PROCESS_ORDER FLOAT NULL
,DOMAIN_PROCESS_ORDER
FLOAT NULL
,PARALLELIZATION FLOAT NULL
,UNLOAD_METHOD
FLOAT NULL
,GRANULES
FLOAT NULL
,SCN FLOAT NULL
,GRANTOR
VARCHAR(30) NULL
,XML_CLOB
VARCHAR(MAX)
NULL
,NAME VARCHAR(30) NULL
,VALUE_T
VARCHAR(4000)
NULL
,VALUE_N
FLOAT NULL
,IS_DEFAULT FLOAT NULL
,FILE_TYPE FLOAT NULL
,USER_DIRECTORY
VARCHAR(4000)
,USER_FILE_NAME
VARCHAR(4000)
,FILE_NAME VARCHAR(4000)
NULL
,EXTEND_SIZE
FLOAT NULL
,FILE_MAX_SIZE
FLOAT NULL
,PROCESS_NAME
VARCHAR(30) NULL
,LAST_UPDATE
DATE NULL
,WORK_ITEM VARCHAR(30) NULL
,OBJECT_NUMBER
FLOAT NULL
,COMPLETED_BYTES FLOAT NULL
,TOTAL_BYTES
FLOAT NULL
,METADATA_IO
FLOAT NULL
,DATA_IO
FLOAT NULL
,CUMULATIVE_TIME FLOAT NULL
,PACKET_NUMBER
FLOAT NULL
,OLD_VALUE VARCHAR(4000)
NULL
,SEED FLOAT NULL
,LAST_FILE FLOAT NULL
,USER_NAME VARCHAR(30) NULL
,OPERATION VARCHAR(30) NULL
,JOB_MODE
VARCHAR(30) NULL
,CONTROL_QUEUE
VARCHAR(30) NULL
,STATUS_QUEUE
VARCHAR(30) NULL
,REMOTE_LINK
VARCHAR(4000)
,VERSION
FLOAT NULL
,DB_VERSION VARCHAR(30) NULL
,TIMEZONE
VARCHAR(64) NULL
,STATE
VARCHAR(30) NULL
,PHASE
FLOAT NULL
,GUID VARBINARY(16)
NULL
,START_TIME DATE NULL
,BLOCK_SIZE FLOAT NULL
,METADATA_BUFFER_SIZE
FLOAT NULL
,DATA_BUFFER_SIZE FLOAT NULL
,DEGREE
FLOAT NULL
,PLATFORM
VARCHAR(101)
NULL

NULL

NULL

NULL
NULL

NULL

69

,ABORT_STEP FLOAT NULL

,INSTANCE
VARCHAR(60) NULL
)
GO
CREATE UNIQUE NONCLUSTERED INDEX SYS_C009756 ON
SYS_IMPORT_SCHEMA_01(PROCESS_ORDER,DUPLICATE)
GO
BEGIN TRY
DROP TABLE PFIXED_COST_TAGLIST_0
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PFIXED_COST_TAGLIST_0
(
puid
VARCHAR(30) NOT NULL
,pseq
FLOAT NOT NULL
,p_valu_0
VARCHAR(30) NULL
,p_valc_0
FLOAT NULL
)
GO
BEGIN TRY
DROP TABLE POM_UID_SCRATCH
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE POM_UID_SCRATCH
(
puid VARCHAR(30) NOT NULL
)
GO
BEGIN TRY
DROP TABLE PREFAUNIQUEEXPRID2
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PREFAUNIQUEEXPRID2
(
puid VARCHAR(30) NOT NULL
)
GO
BEGIN TRY
DROP TABLE PVISSTRUCTURERECEIPE
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PVISSTRUCTURERECEIPE
(
puid
VARCHAR(30) NOT NULL

70

,pvis_id
)
GO

VARCHAR(64) NULL

BEGIN TRY
DROP TABLE PVISMANAGEDDOCUMENT
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PVISMANAGEDDOCUMENT
(
puid
VARCHAR(30) NOT NULL
,pvis_id
VARCHAR(64) NULL
)
GO
BEGIN TRY
DROP TABLE PPATTERN_0
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PPATTERN_0
(
puid
,pseq
,pval_0
)
GO

VARCHAR(30) NOT NULL

FLOAT NOT NULL
VARCHAR(480) NULL

BEGIN TRY
DROP TABLE POCCURRENCE_LIST
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE POCCURRENCE_LIST
(
puid
VARCHAR(30) NOT NULL
,pseq
FLOAT NOT NULL
,pvall
FLOAT NULL
,pval
VARCHAR(MAX) NULL
)
GO
BEGIN TRY
DROP TABLE PVISSTRUCTURECONTEXT
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PVISSTRUCTURECONTEXT
(
puid
VARCHAR(30) NOT NULL
,vla_847_2
FLOAT NULL
,rstatic_structure_fileu VARCHAR(30) NULL

71

,rstatic_structure_filec FLOAT NULL

)
GO
BEGIN TRY
DROP TABLE PJTCONTENTFORMSTORAGE
END TRY
BEGIN CATCH
END CATCH
CREATE TABLE PJTCONTENTFORMSTORAGE
(
puid VARCHAR(30) NOT NULL
,pjt_id
VARCHAR(480) NOT NULL
,pgeometry FLOAT NOT NULL
,pmaterial_overrides
FLOAT NOT NULL
,pcad_attributes FLOAT NOT NULL
,ppmi FLOAT NOT NULL
)
GO
BEGIN TRY
DROP TABLE EIM_UID_GENERATOR_ROOT
END TRY
BEGIN CATCH
END CATCH
GO
CREATE TABLE EIM_UID_GENERATOR_ROOT
(
MOST_RECENT_TIME FLOAT NULL
,SITE_ID FLOAT NOT NULL
)
GO

72

Appendix C: Links for Further

Information
For general information, visit the Siemens PLM Software home page.
SQL Server information can be found in Books Online:
SQL Server 2008 Books Online
SQL Server 2005 Books Online
See the SQL Server Best Practices portal for technical white papers, the SQL Server Best Practices
Toolbox, Top 10 Lists, and other resources.
For Siemens and Microsoft news, events, and further information, see the Siemens/Microsoft Alliance
page.
Following is a list of technical white papers that were tested and validated by the SQL Server
development team. These can help you learn more about specific SQL Server topics.
Guide to Migrating from Oracle to SQL Server 2008
Practical SQL Server 2008 for Oracle Professionals
Motorola Migrates Mission Critical Oracle Database in One Day with 100 Percent Accuracy
Whitepaper: Best Practices for Running Siemens Teamcenter on SQL Server
SQL Server Oracle Migration Site
Siemens Teamcenter on SQL Server blog
SQL Server Web site
SQL Server TechCenter
SQL Server DevCenter
Storage Top 10 Best Practices (for SQL Server)
Predeployment I/O Best Practices
Tuning the Performance of Change Data Capture in SQL Server 2008
The Data Loading Performance Guide
Best Practices for Migrating Non-Unicode Data Types to Unicode
The Impact of Changing Collations and of Changing Data Types from Non-Unicode to Unicode
XML Best Practices for Microsoft SQL Server 2005
SQL Server 2005 Security Best Practices - Operational and Administrative Tasks
Partial Database Availability
Comparing Tables Organized with Clustered Indexes versus Heaps
SQL Server 2005 Deployment Guidance for Web Hosting Environments
Implementing Application Failover with Database Mirroring
TEMPDB Capacity Planning and Concurrency Considerations for Index Create and Rebuild
73

Getting Started with SQL Server 2008 Failover Clustering

SQL Server 2008 Failover Clustering
Database Mirroring Best Practices and Performance Considerations
SQL Server 2005 Waits and Queues
Troubleshooting Performance Problems in SQL Server 2005

74