Download Change Data Capture (SSIS) | Microsoft Docs

Document related concepts

Concurrency control wikipedia , lookup

Microsoft Access wikipedia , lookup

Entity–attribute–value model wikipedia , lookup

Database wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

Clusterpoint wikipedia , lookup

Relational model wikipedia , lookup

Open Database Connectivity wikipedia , lookup

Database model wikipedia , lookup

SQL wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Oracle Database wikipedia , lookup

PL/SQL wikipedia , lookup

Transcript
Table of Contents
Overview
Specify an Interval of Change Data
Determine Whether the Change Data Is Ready
Prepare to Query for the Change Data
Create the Function to Retrieve the Change Data
Retrieve and Understand the Change Data
Process Inserts, Updates, and Deletes
Apply the Changes to the Destination
Perform an Incremental Load of Multiple Tables
Change Data Capture for Oracle by Attunity
Change Data Capture Designer for Oracle by Attunity
The CDC Designer Console Introduction
Oracle CDC Instance Data Types
Error Handling
The Oracle CDC Instance
The Oracle CDC Databases
Change Data Capture Designer for Oracle by Attunity F1 Help Reference
Access the CDC Designer Console
Manage a CDC Service
Manage a CDC Instance
Use the New Instance Wizard
Edit Instance Properties
Change Data Capture Designer for Oracle by Attunity How to Guide
How to Manage a CDC Service from the CDC Designer Console
How to Create the SQL Server Change Database Instance
How to Manage a CDC Instance
How to Edit the CDC Instance Properties
How to View the CDC Instance Properties
SQL Server Connection for Instance Creation
Advanced Connection Properties
Oracle Credentials for Running Script
Oracle Supplemental Logging Script
CDC Instance Deployment Script
SQL Server Connection Required Permissions for the CDC Designer
Change Data Capture Service for Oracle by Attunity
Change Data Capture Service for Oracle by Attunity System Architecture
The Oracle CDC Service
High Availability Support
SQL Server Connection Required Permissions for the CDC Service
User Roles
Working with the Oracle CDC Service
Change Data Capture Service for Oracle by Attunity F1 Help
Connection to SQL Server
Connection to SQL Server for Delete
Create and Edit an Oracle CDC Service
Manage an Oracle CDC Service
Prepare SQL Server for CDC
Prepare SQL Server for Oracle CDC-View Script
Work with CDC Services
Change Data Capture Service for Oracle by Attunity How to Guide
How to Create and Edit a CDC Service
How to Manage a Local CDC Service
How to Prepare SQL Server for CDC
How to Use the CDC Service Command-Line Interface
How to Work with CDC Services
Change Data Capture (SSIS)
3/24/2017 • 5 min to read • Edit Online
In SQL Server, change data capture offers an effective solution to the challenge of efficiently performing
incremental loads from source tables to data marts and data warehouses.
What is Change Data Capture?
Source tables change over time. A data mart or data warehouse that is based on those tables needs to reflect these
changes. However, a process that periodically copies a snapshot of the entire source consumes too much time and
resources. Alternate approaches that include timestamp columns, triggers, or complex queries often hurt
performance and increase complexity. What is needed is a reliable stream of change data that is structured so that
it can easily be applied by consumers to target representations of the data. Change data capture in SQL Server
provides this solution.
The change data capture feature of the Database Engine captures insert, update, and delete activity applied to SQL
Server tables, and makes the details of the changes available in an easily-consumed, relational format. The change
tables used by change data capture contain columns that mirror the column structure of the tracked source tables,
along with the metadata needed to understand the changes that have occurred on a row by row basis.
NOTE
Change data capture is not available in every edition of Microsoft SQL Server. For a list of features that are supported by the
editions of SQL Server, see Features Supported by the Editions of SQL Server 2016.
How Change Data Capture Works in Integration Services
An Integration Services package can easily harvest the change data in the SQL Server databases to perform
efficient incremental loads to a data warehouse. However, before you can use Integration Services to load change
data, an administrator must enable change data capture on the database and the tables from which you want to
capture changes. For more information on how to configure change data capture on a database, see Enable and
Disable Change Data Capture (SQL Server).
Once an administrator has enabled change data capture on the database, you can create a package that performs
an incremental load of the change data. The following diagram shows the steps for creating such a package that
performs an incremental load from a single table:
As shown in the previous diagram, creating a package that performs an incremental load of changed data involves
the following steps:
Step 1: Designing the Control Flow
In the control flow in the package, the following tasks need to be defined:
Calculate the starting and ending datetime values for the interval of changes to the source data that you
want to retrieve.
To calculate these values, use an Execute SQL task or Integration Services expressions with datetime
functions. You then store these endpoints in package variables for use later in the package.
For more information: Specify an Interval of Change Data
Determine whether the change data for the selected interval is ready. This step is necessary because the
asynchronous capture process might not yet have reached the selected endpoint.
To determine whether the data is ready, start with a For Loop container to delay execution, if necessary,
until the change data for the selected interval is ready. Inside the loop container, use an Execute SQL task to
query the time mapping tables maintained by change data capture. Then, use a Script task that calls the
Thread.Sleep method, or another Execute SQL task with a WAITFOR statement, to delay the execution of
the package temporarily, if necessary. Optionally, use another Script task to log an error condition or a
timeout.
For more information: Determine Whether the Change Data Is Ready
Prepare the query string that will be used to query for the change data.
Use a Script task or an Execute SQL task to assemble the SQL statement that will be used to query for
changes.
For more information: Prepare to Query for the Change Data
Step 2: Setting Up the Query for Change Data
Create the table-valued function that will query for the data.
Use SQL Server Management Studio to develop and save the query.
For more information: Retrieve and Understand the Change Data
Step 3: Designing the Data Flow
In the data flow of the package, the following tasks need to be defined:
Retrieve the change data from the change tables.
To retrieve the data, use a source component to query the change tables for the changes that fall within the
selected interval. The source calls a Transact-SQL table-valued function that you must have previously
created.
For more information: Retrieve and Understand the Change Data
Split the changes into inserts, updates, and deletes for processing.
To split the changes, use a Conditional Split transformation to direct inserts, updates, and deletes to
different outputs for appropriate processing.
For more information: Process Inserts, Updates, and Deletes
Apply the inserts, deletes, and updates to the destination.
To apply the changes to the destination, use a destination component to apply the inserts to the destination.
Also, use OLE DB Command transformations with parameterized UPDATE and DELETE statements to apply
updates and deletes to the destination. You can also apply updates and deletes by using destination
components to save the rows to temporary tables. Then, use Execute SQL tasks to perform bulk update and
bulk delete operations against the destination from the temporary tables.
For more information: Apply the Changes to the Destination
Change Data from Multiple Tables
The process outlined in the previous diagram and steps involves an incremental load from a single table. When
having to perform an incremental load from multiple tables, the overall process is the same. However, the design
of the package needs to be changed to accommodate the processing of multiple tables. For more information on
how to create a package that performs an incremental load from multiples tables, see Perform an Incremental
Load of Multiple Tables.
Samples of Change Data Capture Packages
Integration Services provides two samples that demonstrate how to use change data capture in packages. For
more information, see the following topics:
Readme_Change Data Capture for Specified Interval Package Sample
Readme_Change Data Capture since Last Request Package Sample
Related Tasks
Specify an Interval of Change Data
Determine Whether the Change Data Is Ready
Prepare to Query for the Change Data
Create the Function to Retrieve the Change Data
Retrieve and Understand the Change Data
Process Inserts, Updates, and Deletes
Apply the Changes to the Destination
Perform an Incremental Load of Multiple Tables
Related Content
Blog entry, SSIS Design Pattern – Incremental Load, on sqlblog.com
Specify an Interval of Change Data
4/19/2017 • 4 min to read • Edit Online
In the control flow of an Integration Services package that performs an incremental load of change data, the first
task is to calculate the endpoints of the change interval. These endpoints are datetime values and will be stored in
package variables for use later in the package.
NOTE
For a description of the overall process of designing the control flow, see Change Data Capture (SSIS).
Set Up Package Variables for the Endpoints
Before configuring the Execute SQL task to calculate the endpoints, the package variables that will store the
endpoints have to be defined.
To set up package variables
1. In SQL Server Data Tools (SSDT), open a new Integration Services project.
2. In the Variables window, create the following variables:
a. Create a variable with the datetime data type to hold the starting point for the interval.
This example uses the variable name, ExtractStartTime.
b. Create another variable with the datetime data type to hold the ending point for the interval.
This example uses the variable name, ExtractEndTime.
If you calculate the endpoints in a master package that executes multiple child packages, you can use Parent
Package Variable configurations to pass the values of these variables to each child package. For more
information, see Execute Package Task and Use the Values of Variables and Parameters in a Child Package.
Calculate a Starting Point and an Ending Point for Change Data
After you set up the package variables for the interval endpoints, you can calculate the actual values for those
endpoints and map those values to the corresponding package variables. Because those endpoints are datetime
values, you will have to use functions that can calculate or work with datetime values. Both the Integration
Services expression language and Transact-SQL have functions that work with datetime values:
Functions in the Integration Services expression language that work with datetime values
DATEADD (SSIS Expression)
DATEDIFF (SSIS Expression)
DATEPART (SSIS Expression)
DAY (SSIS Expression)
GETDATE (SSIS Expression)
GETUTCDATE (SSIS Expression)
MONTH (SSIS Expression)
YEAR (SSIS Expression)
Functions in Transact-SQL that work with datetime values
Date and Time Data Types and Functions (Transact-SQL).
Before you use any one of these datetime functions to calculate the endpoints, you have to determine
whether the interval is fixed and occurs on a regular schedule. Typically, you want to apply changes that
have occurred in source tables to destination tables on a regular schedule. For example, you might want to
apply those changes on an hourly, daily, or weekly basis.
After you understand whether your change interval is fixed or is more random, you can calculate the
endpoints:
Calculating the starting date and time. You use the ending date and time from the previous load as the
current starting date and time. If you use a fixed interval for incremental loads, you can calculate this value
by using the datetime functions of Transact-SQL or of the Integration Services expression language.
Otherwise, you might have to persist the endpoints between executions, and use an Execute SQL task or a
Script task to load the previous endpoint.
Calculating the ending date and time. If you use a fixed interval for incremental loads, calculate the
current ending date and time as an offset from the starting date and time. Again, you can calculate this
value by using the datetime functions of Transact-SQL or of the Integration Services expression language.
In the following procedure, the change interval uses a fixed interval and assumes that the incremental load
package is run daily without exception. Otherwise, change data for missed intervals would be lost. The
starting point for the interval is midnight the day before yesterday, that is, between 24 and 48 hours ago.
The ending point for the interval is midnight yesterday, that is, the previous night, between 0 and 24 hours
ago.
To calculate the starting point and ending point for the capture interval
1. On the Control Flow tab of SSIS Designer, add an Execute SQL Task to the package.
2. Open the Execute SQL Task Editor, and on the General page of the editor, select the following options:
a. For ResultSet, select Single row.
b. Configure a valid connection to the source database.
c. For SQLSourceType, select Direct input.
d. For SQLStatement, enter the following SQL statement:
SELECT DATEADD(dd,0, DATEDIFF(dd,0,GETDATE()-1)) AS ExtractStartTime,
DATEADD(dd,0, DATEDIFF(dd,0,GETDATE())) AS ExtractEndTime
3. On the Result Set page of the Execute SQL Task Editor, map the ExtractStartTime result to the
ExtractStartTime package variable, and map the ExtractEndTime result to the ExtractEndTime package
variable.
NOTE
When you use an expression to set the value of an Integration Services variable, the expression is evaluated every
time that that the value of the variable is accessed.
Next Step
After you calculate the starting point and ending point for a range of changes, the next step is to determine
whether the change data is ready.
Next topic: Determine Whether the Change Data Is Ready
See Also
Use Variables in Packages
Integration Services (SSIS) Expressions
Execute SQL Task
Script Task
Determine Whether the Change Data Is Ready
4/19/2017 • 10 min to read • Edit Online
In the control flow of an Integration Services package that performs an incremental load of change data, the
second task is to ensure that the change data for the selected interval is ready. This step is necessary because the
asynchronous capture process might not yet have processed all the changes up to the selected endpoint.
NOTE
The first task for the control flow is to calculate the endpoints of the change interval. For more information about this task,
see Specify an Interval of Change Data. For a description of the overall process of designing the control flow, see Change
Data Capture (SSIS).
Understanding the Components of the Solution
The solution described in this topic uses 4 Integration Services components:
A For Loop container that repeatedly evaluates the output of an Execute SQL Task.
An Execute SQL task that queries special tables that the change data capture process maintains and then
uses this information to determine whether data is ready.
A component that implements a delay in processing when the data is not ready. This can be either a Script
task or an Execute SQL task.
Optionally, a component that reports an error or a timeout when the Execute SQL task returns a value that
indicates an error or a timeout condition.
These components set or read the values of several package variables to control the flow of execution
inside the loop and later in the package.
To set up package variables
1. In SQL Server Data Tools (SSDT), in the Variables window, create the following variables:
a. Create a variable with an integer data type to hold the status value returned by the Execute SQL task.
This example uses the variable name, DataReady, with an initial value of 0.
b. Create a variable to hold the period of time to delay when data is not ready. If you plan to use a
Script task to implement the delay, the variable should have an integer data type integer. If you plan
to use an Execute SQL task with a WAITFOR statement, the variable should have a string data type to
accept values such as "00:00:10".
This example uses the variable name, DelaySeconds, with an initial value of 10.
c. Create a variable with an integer data type to hold the current iteration of the loop.
This example uses the variable name, TimeoutCount, with an initial value of 0.
d. Create a variable with an integer data type to specify the number of times that the loop should test
for data before reporting a timeout condition.
This example uses the variable name, TimeoutCeiling, with an initial value of 20.
e. (Optional) Create a variable with an integer data type that you can use to indicate the first load of
change data.
This example uses the variable name, IntervalID, and checks only for a value of 0 to indicate the
initial load.
Configuring a For Loop Container
With the variables set, the For Loop container is the first component to be added.
To configure a For Loop container to wait until change data is ready
1. On the Control Flow tab of the SSIS Designer, add a For Loop container to the control flow.
2. Connect the Execute SQL Task that calculates the endpoints of the interval to the For Loop container.
3. In the For Loop Editor, select the following options:
a. For InitExpression, enter
@DataReady = 0
.
This expression sets the initial value of the loop variable.
b. For EvalExpressionm, enter
@DataReady == 0
.
When this expression evaluates to False, execution passes out of the loop and the incremental load
starts.
Configuring the Execute SQL Task That Queries for Change Data
Inside the For Loop container, you add an Execute SQL task. This task queries the tables that the change data
capture process maintains in the database. The result of this query is a status value that indicates whether the
change data is ready.
In the following table, the first column shows the values returned from the Execute SQL task by the sample
Transact-SQL query. The second column shows how the other components respond to these values.
RETURN VALUE
MEANING
RESPONSE
0
Indicates that the change data is not
ready.
Execution continues with the
component that implements a delay.
Then control returns to the For Loop
container, which continues to check the
Execute SQL task as long as the value
returned is 0.
There are no change data capture
records later than the ending point of
the selected interval.
1
Might indicate that the change data
has not been captured for the complete
interval, or that it has been deleted.
This is treated as an error condition.
Execution continues with the optional
component that logs the error.
There are no change data capture
records earlier than the starting point
of the selected interval
2
Indicates that data is ready.
There are change data capture records
that are both earlier than the starting
point and later than the ending point
of the selected interval.
Execution passes out of the For Loop
container and the incremental load
starts.
RETURN VALUE
MEANING
RESPONSE
3
Indicates the initial load of all available
change data.
Execution passes out of the For Loop
container and the incremental load
starts.
The conditional logic obtains this value
from a special package variable that is
used only for this purpose.
5
Indicates that the TimeoutCeiling has
been reached.
Execution continues with the optional
component that logs the timeout.
The loop has tested for data the
specified number of times, and data is
still not available. Without this test or a
similar test, the package might run
indefinitely.
To configure an Execute SQL task to query whether change data is ready
1. Inside the For Loop container, add an Execute SQL task.
2. In the Execute SQL Task Editor, on the General page, select the following options:
a. For ResultSet, select Single row.
b. Configure a valid connection to the source database.
c. For SQLSourceType, select Direct input.
d. For SQLStatement, enter the following SQL statement:
declare @DataReady int, @TimeoutCount int
if not exists (select tran_end_time from cdc.lsn_time_mapping
where tran_end_time > ? )
select @DataReady = 0
else
if ? = 0
select @DataReady = 3
else
if not exists (select tran_end_time from cdc.lsn_time_mapping
where tran_end_time <= ? )
select @DataReady = 1
else
select @DataReady = 2
select @TimeoutCount = ?
if (@DataReady = 0)
select @TimeoutCount = @TimeoutCount + 1
else
select @TimeoutCount = 0
if (@TimeoutCount > ?)
select @DataReady = 5
select @DataReady as DataReady, @TimeoutCount as TimeoutCount
3. On the Parameter Mapping page of the Execute SQL Task Editor, make the following mappings:
a. Map the ExtractEndTime variable to parameter 0.
b. Map the IntervalID variable to parameter 1.
c. Map the ExtractStartTime variable to parameter 2.
d. Map the TimeoutCount variable to parameter 3.
e. Map the TimeoutCeiling variable to parameter 4.
4. On the Result Set page of the Execute SQL Task Editor, map the DataReady result to the DataReady
variable, and the TimeoutCount result to the TimeoutCount variable.
Waiting Until the Change Data Is Ready
You can use one of several methods to implement a delay when the change data is not ready. The following two
procedures illustrate how to use a Script task or an Execute SQL task to implement the delay.
NOTE
A precompiled script incurs less overhead than an Execute SQL task.
To implement a delay by using a Script task
1. Inside the For Loop container, add a Script task.
2. Connect the Execute SQL task that queries to determine whether the change data is ready to the new Script
task.
3. For the precedence constraint that connects the Execute SQL task to the Script task, open the Precedence
Constraint Editor and select the following options:
a. For Evaluation operation, select Expression and Constraint.
b. For Value, select Success.
The constraint value of Success refers to the success of the previous task. In this case, the success of
the Execute SQL task.
c. For Expression, enter
@DataReady == 0 && @TimeoutCount <= @TimeoutCeiling
.
d. Select Logical AND. All constraints must evaluate to True, if not already selected.
4. In the Script Task Editor, on the Script page, for ReadOnlyVariables, select the User::DelaySeconds
integer variable from the list.
5. In the Script Task Editor, on the Script page, click Edit Script to open the script development
environment.
6. In the Main procedure, enter one of the following lines of code:
If you are programming in C#, enter the following line of code:
System.Threading.Thread.Sleep((int)Dts.Variables["DelaySeconds"].Value * 1000);
- or If you are programming in Visual Basic, enter the following line of code:
System.Threading.Thread.Sleep(Ctype(Dts.Variables("DelaySeconds").Value, Integer) * 1000)
NOTE
The Thread.Sleep method expects an argument that is specified in milliseconds.
7. Leave the default line of code which returns DtsExecResult.Success from the execution of the script.
8. Close the script development environment and the Script Task Editor.
To implement a delay by using an Execute SQL task
1. Inside the For Loop container, add an Execute SQL task.
2. Connect the Execute SQL task that queries to determine whether the change data is ready to the new
Execute SQL task.
3. For the precedence constraint that connects the two Execute SQL tasks, open the Precedence Constraint
Editor and select the following options:
a. For Evaluation operation, select Expression and Constraint.
b. For Value, select Success.
The constraint value of Success refers to the success of the previous Execute SQL task.
c. For Expression, enter
@DataReady == 0
.
d. Select Logical AND. All constraints must evaluate to True, if not already selected.
This selection requires that both conditions, the constraint and the expression, must be true.
4. In the Execute SQL Task Editor, on the General page, select the following options:
a. For ResultSet, select Single row.
b. Configure a valid connection to the source database.
c. For SQLSourceType, select Direct input.
d. For SQLStatement, enter the following SQL statement:
WAITFOR DELAY ?
5. On the Parameter Mapping page of the editor, map the DelaySeconds string variable to parameter 0.
Handling an Error Condition
You can optionally configure an additional component inside the loop to log an error or a timeout condition:
This component can log an error condition when the value of the DataReady variable = 1. This value
indicates that there is no available change data before the start of the selected interval.
This component can also log a timeout condition when the value of the TimeoutCeiling variable is reached.
This value indicates the loop has tested for data the specified number of times, and data is still not available.
Without this test or a similar test, the package might run indefinitely.
To configure an optional Script task to log an error condition
1. If you want to report the error or timeout by writing a message to the log, configure logging for the
package. For more information, see Enable Package Logging in SQL Server Data Tools.
2. Inside the For Loop container, add a Script task.
3. Connect the Execute SQL task that queries to determine whether the change data is ready to the new Script
task.
4. For the precedence constraint that connects the Execute SQL task to the Script task, open the Precedence
Constraint Editor and select the following options:
a. For Evaluation operation, select Expression and Constraint.
b. For Value, select Success.
The constraint value of Success refers to the success of the previous task. In this case, the success of
the Execute SQL task.
c. For Expression, enter
@DataReady == 1 || @DataReady == 5
.
d. Select Logical AND. All constraints must evaluate to True, if not already selected.
This selection requires that both conditions, the constraint and the expression, must be true.
5. In the Script Task Editor, on the Script page of the editor, for ReadOnlyVariables, select
User::DataReady and User::ExtractStartTime from the list to make their values available to the script.
If you want to include information from certain system variables (for example, System::PackageName) in
the information that you write to the log, select those variables also.
6. In the Script Task Editor, on the Script page, click Edit Script to open the script development
environment.
7. In the Main procedure, enter code to log an error by calling the Dts.Log method, or to raise an event by
calling one of the methods of the Dts.Events interface. Inform the package of the error by returning
Dts.TaskResult = Dts.Results.Failure .
The following sample shows how to write a message to the log. For more information, see Logging in the
Script Task, Raising Events in the Script Task, and Returning Results from the Script Task.
' User variables.
Dim dataReady As Integer = _
CType(Dts.Variables("DataReady").Value, Integer)
Dim extractStartTime As Date = _
CType(Dts.Variables("ExtractStartTime").Value, DateTime)
' System variables.
Dim packageName As String = _
Dts.Variables("PackageName").Value.ToString()
Dim executionStartTime As Date = _
CType(Dts.Variables("StartTime").Value, DateTime)
Dim eventMessage As New System.Text.StringBuilder()
If dataReady = 1 OrElse dataReady = 5 Then
If dataReady = 1 Then
eventMessage.AppendLine("Start Time Error")
Else
eventMessage.AppendLine("Timeout Error")
End If
With eventMessage
.Append("The package ")
.Append(packageName)
.Append(" started at ")
.Append(executionStartTime.ToString())
.Append(" and ended at ")
.AppendLine(DateTime.Now().ToString())
If dataReady = 1 Then
.Append("The specified ExtractStartTime was ")
.AppendLine(extractStartTime.ToString())
End If
End With
System.Windows.Forms.MessageBox.Show(eventMessage.ToString())
Dts.Log(eventMessage.ToString(), 0, Nothing)
Dts.TaskResult = Dts.Results.Failure
Else
Dts.TaskResult = Dts.Results.Success
End If
8. Close the script development environment and the Script Task Editor.
Next Step
After you determine that change data is ready, the next step is to prepare to query for the change data.
Next topic: Prepare to Query for the Change Data
Prepare to Query for the Change Data
3/24/2017 • 6 min to read • Edit Online
In the control flow of an Integration Services package that performs an incremental load of change data, the third
and final task is to prepare to query for the change data and add a Data Flow task.
NOTE
The second task for the control flow is to ensure that the change data for the selected interval is ready. For more
information about this task, see Determine Whether the Change Data Is Ready. For a description of the overall process of
designing the control flow, see Change Data Capture (SSIS).
Design Considerations
To retrieve the change data, you will call a Transact-SQL table-valued function that accepts the endpoints of the
interval as input parameters and returns change data for the specified interval. A source component in the data
flow calls this function. For information about this source component, see Retrieve and Understand the Change
Data.
The most frequently used Integration Services source components, including the OLE DB source, the ADO source,
and the ADO NET source, cannot derive parameter information for a table-valued function. Therefore, most
sources cannot call a parameterized function directly.
You have two design options for passing the input parameters to the function:
Assemble the parameterized query as a string. You can use a Script task or an Execute SQL task to
assemble a dynamic SQL string with parameter values hard-coded into the string. Then, you can store this
string in a package variable and use it to set the SqlCommand property of a source component. This
approach succeeds because the source component no longer requires parameter information.
NOTE
A precompiled script incurs less overhead than an Execute SQL task.
Use a parameterized wrapper. Alternatively, you can create a parameterized stored procedure as a
wrapper that calls the parameterized table-valued function. This approach succeeds because a source
component can successfully derive parameter information for a stored procedure.
This topic uses the first design option and assembles a parameterized query as a string.
Preparing the Query
Before you can concatenate the values of the input parameters into a single query string, you have to set up the
package variables that the query needs.
To set up package variables
In SQL Server Data Tools (SSDT), in the Variables window, create a variable with a string data type to hold
the query string returned by the Execute SQL Task.
This example uses the variable name, SqlDataQuery.
With the package variable created, you can use either a Script task or Execute SQL task to concatenate the
values of the input parameters. The following two procedures describe how to configure these components.
To use a Script task to concatenate the query string
1. On the Control Flow tab, add a Script task to the package after the For Loop container and connect the For
Loop container to the task.
NOTE
This procedure assumes that the package performs an incremental load from a single table. If the package loads
from multiple tables and has a parent package with multiple child packages, this task would be added as the first
component to each child package. For more information, see Perform an Incremental Load of Multiple Tables.
2. In the Script Task Editor, on the Script page, select the following options:
a. For ReadOnlyVariables, select User::DataReady, User::ExtractStartTime, and
User::ExtractEndTime from the.
b. For ReadWriteVariables, select User::SqlDataQuery from the list.
3. In the Script Task Editor, on the Script page, click Edit Script to open the script development
environment.
4. In the Main procedure, enter one of the following code segments:
If you are programming in C#, enter the following lines of code:
int dataReady;
System.DateTime extractStartTime;
System.DateTime extractEndTime;
string sqlDataQuery;
dataReady = (int)Dts.Variables["DataReady"].Value;
extractStartTime = (System.DateTime)Dts.Variables["ExtractStartTime"].Value;
extractEndTime = (System.DateTime)Dts.Variables["ExtractEndTime"].Value;
if (dataReady == 2)
{
sqlDataQuery = "SELECT * FROM CDCSample.uf_Customer('" + string.Format("{0:yyyy-MM-dd
hh:mm:ss}", extractStartTime) + "', '" + string.Format("{0:yyyy-MM-dd hh:mm:ss}",
extractEndTime) + "')";
}
else
{
sqlDataQuery = "SELECT * FROM CDCSample.uf_Customer(null" + ", '" + string.Format("{0:yyyy-MMdd hh:mm:ss}", extractEndTime) + "')";
}
Dts.Variables["SqlDataQuery"].Value = sqlDataQuery;
- or If you are programming in Visual Basic, enter the following lines of code:
Dim
Dim
Dim
Dim
dataReady As Integer
extractStartTime As Date
extractEndTime As Date
sqlDataQuery As String
dataReady = CType(Dts.Variables("DataReady").Value, Integer)
extractStartTime = CType(Dts.Variables("ExtractStartTime").Value, Date)
extractEndTime = CType(Dts.Variables("ExtractEndTime").Value, Date)
If dataReady = 2 Then
sqlDataQuery = "SELECT * FROM CDCSample.uf_Customer('" & _
String.Format("{0:yyyy-MM-dd hh:mm:ss}", extractStartTime) & _
"', '" & _
String.Format("{0:yyyy-MM-dd hh:mm:ss}", extractEndTime) & _
"')"
Else
sqlDataQuery = "SELECT * FROM CDCSample.uf_Customer(null" & _
", '" & _
String.Format("{0:yyyy-MM-dd hh:mm:ss}", extractEndTime) & _
"')"
End If
Dts.Variables("SqlDataQuery").Value = sqlDataQuery
5. Leave the default line of code which returns DtsExecResult.Success from the execution of the script.
6. Close the script development environment and the Script Task Editor.
To use an Execute SQL task to concatenate the query string
1. On the Control Flow tab, add an Execute SQL task to the package after the For Loop container and connect
the For Loop container to this task.
NOTE
This procedure assumes that the package performs an incremental load from a single table. If the package loads
from multiple tables and has a parent package with multiple child packages, this task would be added as the first
component to each child package. For more information, see Perform an Incremental Load of Multiple Tables.
2. In the Execute SQL Task Editor, on the General page, select the following options:
a. For ResultSet, select Single row.
b. Configure a valid connection to the source database.
c. For SQLSourceType, select Direct input.
d. For SQLStatement, enter the following SQL statement:
declare @ExtractStartTime datetime,
@ExtractEndTime datetime,
@DataReady int
select @DataReady = ?,
@ExtractStartTime = ?,
@ExtractEndTime = ?
if @DataReady = 2
select N'select * from CDCSample.uf_Customer'
+ N'('''+ convert(nvarchar(30),@ExtractStartTime,120)
+ ''', '''
+ convert(nvarchar(30),@ExtractEndTime,120) + ''') '
as SqlDataQuery
else
select N'select * from CDCSample.uf_Customer'
+ N'(null, '''
+ convert(nvarchar(30),@ExtractEndTime,120)
+ ''') '
as SqlDataQuery
NOTE
The else clause in this sample generates a query for the initial load of change data by passing a null value for
the starting date and time. This sample does not address the scenario in which changes that were made
before change data capture was enabled also have to be uploaded to the data warehouse.
3. On the Parameter Mapping page of the Execute SQL Task Editor, do the following mapping:
a. Map the DataReady variable to parameter 0.
b. Map the ExtractStartTime variable to parameter 1.
c. Map the ExtractEndTime variable to parameter 2.
4. On the Result Set page of the Execute SQL Task Editor, map the Result Name to the SqlDataQuery
variable.
The Result Name is the name of the single column that is returned, SqlDataQuery.
The previous procedures configure a task that prepares a query string with hard-coded string values for the
input parameters. The following code is an example of such a query string:
select * from CDCSample. uf_Customer('2007-06-11 14:21:58', '2007-06-12 14:21:58')
Adding a Data Flow Task
The last step in designing the control flow for the package is to add a Data Flow task.
To add a Data Flow task and complete the control flow
On the Control Flow tab, add a Data Flow task and connect the task that concatenated the query string.
Next Step
After you prepare the query string and configure the Data Flow task, the next step is create the table-valued
function that will retrieve the change data from the database.
Next topic: Create the Function to Retrieve the Change Data
Create the Function to Retrieve the Change Data
3/24/2017 • 9 min to read • Edit Online
After completing the control flow for an Integration Services package that performs an incremental load of change
data, the next task is to create a table-valued function that retrieves the change data. You only have to create this
function one time before the first incremental load.
NOTE
The creation of a function to retrieve the change data is the second step in the process of creating a package that performs
an incremental load of change data. For a description of the overall process for creating this package, see Change Data
Capture (SSIS).
Design Considerations for Change Data Capture Functions
To retrieve change data, a source component in the data flow of the package calls one of the following change
data capture query functions:
cdc.fn_cdc_get_net_changes_ For this query, the single row returned for each update contains the final
state of each changed row. In most cases, you only need the data returned by a query for net changes. For
more information, see cdc.fn_cdc_get_net_changes_<capture_instance> (Transact-SQL).
cdc.fn_cdc_get_all_changes_ This query returns all the changes that have occurred in each row during
the capture interval. For more information, see cdc.fn_cdc_get_all_changes_<capture_instance> (TransactSQL).
The source component then takes the results returned by the function and passes them to downstream
transformations and destinations, which apply the change data to the final destination.
However, an Integration Services source component cannot call these change data capture functions
directly. An Integration Services source component requires metadata about the columns that the query
returns. The change data capture functions do not define the columns of their output table. Thus, these
functions do not return sufficient metadata for an Integration Services source component.
Instead, you use a table-valued wrapper function because this kind of function explicitly defines the
columns of its output table in its RETURNS clause. This explicit definition of columns provides the metadata
that an Integration Services source component needs. You have to create this function for each table for
which you want to retrieve change data.
You have two options for creating the table-valued wrapper function that calls the change data capture
query function:
You can call the sys.sp_cdc_generate_wrapper_function system stored procedure to create the tablevalued functions for you.
You can write your own table-valued function by using the guidelines and the example in this topic.
Calling a Stored Procedure to Create the Table-valued Function
The quickest and easiest way to create the table-valued functions that you need is to call the
sys.sp_cdc_generate_wrapper_function system stored procedure. This stored procedure generates scripts to
create wrapper functions that are designed specifically to meet the needs of an Integration Services source
component.
IMPORTANT
The sys.sp_cdc_generate_wrapper_function system stored procedure does not directly create the wrapper functions.
Instead, the stored procedure generates the CREATE scripts for the wrapper functions. The developer must run the CREATE
scripts that the stored procedure generates before an incremental load package can call the wrapper functions.
To understand how to use this system stored procedure, you should understand what the procedure does, what
scripts the procedure generates, and what wrapper functions the scripts create.
Understanding and Using the Stored Procedure
The sys.sp_cdc_generate_wrapper_function system stored procedure generates scripts to create wrapper
functions for use by Integration Services packages.
Here are the first few lines of the definition of the stored procedure:
CREATE PROCEDURE sys.sp_cdc_generate_wrapper_function
(
@capture_instance sysname = null
@closed_high_end_point bit = 1,
@column_list = null,
@update_flag_list = null
)
All the parameters for the stored procedure are optional. If you call the stored procedure without supplying values
for any of the parameters, the stored procedure creates wrapper functions for all the capture instances to which
you have access.
NOTE
For more information about the syntax of this stored procedure and its parameters, see
sys.sp_cdc_generate_wrapper_function (Transact-SQL).
The stored procedure always generates a wrapper function to return all changes from each capture instance. If the
@supports_net_changes parameter was set when the capture instance was created, the stored procedure also
generates a wrapper function to return net changes from each applicable capture instance.
The stored procedure returns a result set with two columns:
The name of the wrapper function that the stored procedure has generated. This stored procedure derives
the function name from the name of the capture instance name. (The function name is 'fn_all_changes_'
followed by the capture instance name. The prefix used for the net changes function, if it is created, is
'fn_net_changes_'.)
The CREATE statement for the wrapper function.
Understanding and Using the Scripts Created by the Stored Procedure
Typically, a developer would use an INSERT...EXEC statement to call the sys.sp_cdc_generate_wrapper_function
stored procedure and save the scripts that the stored procedure creates to a temporary table. Each script could
then be individually selected and run to create the corresponding wrapper function. However, a developer could
also use one set of SQL commands to run all the CREATE scripts, as shown in the following sample code:
create table #wrapper_functions
(function_name sysname, create_stmt nvarchar(max))
insert into #wrapper_functions
exec sys.sp_cdc_generate_wrapper_function
declare @stmt nvarchar(max)
declare #hfunctions cursor local fast_forward for
select create_stmt from #wrapper_functions
open #hfunctions
fetch #hfunctions into @stmt
while (@@fetch_status <> -1)
begin
exec sp_executesql @stmt
fetch #hfunctions into @stmt
end
close #hfunctions
deallocate #hfunctions
Understanding and Using the Functions Created by the Stored Procedure
To systematically walk the timeline of captured change data, the generated wrapper functions expect that the
@end_time parameter for one interval will be the @start_time parameter for the subsequent interval. When this
convention is followed, the generated wrapper functions can do the following tasks:
Map the date/time values to the LSN values that are used internally.
Ensure that no data is lost or repeated.
To make querying for all rows of a change table simpler, the generated wrapper functions also support the
following conventions:
If the @start_time parameter is null, the wrapper functions use the lowest LSN value in the capture instance
as the lower bound of the query.
If the @end_time parameter is null, the wrapper functions use the highest LSN value in the capture instance
as the upper bound of the query.
Most users should be able to use the wrapper functions that the sys.sp_cdc_generate_wrapper_function
system stored procedure creates without modification. However, to customize the wrapper functions, you
have to customize the CREATE scripts before you run the scripts.
When your package calls the wrapper functions, the package must supply values for three parameters.
These three parameters are like the three parameters that the change data capture functions use. These
three parameters are as follows:
The starting date/time value and the ending date/time value for the interval. While the wrapper functions
use date/time values as the end points for the query interval, the change data capture functions use two
LSN values as the end points.
The row filter. For both the wrapper functions and the change data capture functions, the
@row_filter_option parameter is the same. For more information, see
cdc.fn_cdc_get_all_changes_<capture_instance> (Transact-SQL) and
cdc.fn_cdc_get_net_changes_<capture_instance> (Transact-SQL).
The result set returned by the wrapper functions includesthe following data:
All of the requested columns of change data.
A column named __CDC_OPERATION that uses a one- or two-character field to identify the operation that is
associated with the row. The valid values for this field are as follows: ‘I’ for insert, ‘D’ for delete, ‘UO’ for
update old values, and ‘UN’ for update new values.
Update flags, when you request them, that appear as bit columns after the operation code and in the order
that is specified in the @update_flag_list parameter. These columns are named by appending ‘_uflag’ to the
associated column name.
If your package calls a wrapper function that queries for all changes, the wrapper function also returns the
columns, __CDC_STARTLSN and __CDC_SEQVAL. These two columns become the first and second columns,
respectively, of the result set. The wrapper function also sorts the result set based on these two columns.
Writing Your Own Table-Value Function
You can also use SQL Server Management Studio to write your own table-valued wrapper function that calls the
change data capture query function, and store the table-valued wrapper function in SQL Server. For more
information about how to create a Transact-SQL function, see CREATE FUNCTION (Transact-SQL).
The following example defines a table-valued function that retrieves changes from a Customer table for the
specified change interval. This function uses change data capture functions to map the datetime values to the
binary log sequence number (LSN) values that the change tables use internally. This function also handles several
special conditions:
When a null value is passed for the starting time, this function uses the earliest available value.
When a null value is passed for the ending time, this function uses the latest available value.
When the starting LSN is equal to the ending LSN, which usually indicates that there are no records for the
selected interval, this function exits.
Example of a Table -Value Function that Queries for Change Data
CREATE function CDCSample.uf_Customer (
@start_time datetime
,@end_time datetime
)
returns @Customer table (
CustomerID int
,TerritoryID int
,CustomerType nchar(1)
,rowguid uniqueidentifier
,ModifiedDate datetime
,CDC_OPERATION varchar(1)
) as
begin
declare @from_lsn binary(10), @to_lsn binary(10)
if (@start_time is null)
select @from_lsn = sys.fn_cdc_get_min_lsn('Customer')
else
select @from_lsn = sys.fn_cdc_increment_lsn(sys.fn_cdc_map_time_to_lsn('largest less than or
equal',@start_time))
if (@end_time is null)
select @to_lsn = sys.fn_cdc_get_max_lsn()
else
select @to_lsn = sys.fn_cdc_map_time_to_lsn('largest less than or equal',@end_time)
if (@from_lsn = sys.fn_cdc_increment_lsn(@to_lsn))
return
-- Query for change data
insert into @Customer
select
CustomerID,
TerritoryID,
CustomerType,
rowguid,
ModifiedDate,
case __$operation
when 1 then 'D'
when 2 then 'I'
when 4 then 'U'
else null
end as CDC_OPERATION
from
cdc.fn_cdc_get_net_changes_Customer(@from_lsn, @to_lsn, 'all')
return
end
go
Retrieving Additional Metadata with the Change Data
Although the user-created table-valued function shown earlier uses only the __$operation column, the
cdc.fn_cdc_get_net_changes_ function returns four columns of metadata for each change row. If you want to
use these values in your data flow, you can return them as additional columns from the table-valued wrapper
function.
COLUMN NAME
DATA TYPE
DESCRIPTION
COLUMN NAME
DATA TYPE
DESCRIPTION
__$start_lsn
binary(10)
LSN associated with the commit
transaction for the change.
All changes committed in the same
transaction share the same commit
LSN. For example, if an update
operation on the source table modifies
two different rows, the change table will
contain four rows (two with the old
values and two with the new values),
each with the same __$start_lsn value.
__$seqval
binary(10)
Sequence value that is used to order
the row changes in a transaction.
__$operation
int
The data manipulation language (DML)
operation associated with the change.
Can be one of the following:
1 = delete
2 = insert
3 = update (Values before the update
operation.)
4 = update (Values after the update
operation.)
__$update_mask
varbinary(128)
A bitmask that is based on the column
ordinals of the change table identifying
those columns that changed. You could
examine this value if you had to
determine which columns have
changed.
<captured source table columns>
varies
The remaining columns returned by the
function are the columns from the
source table that were identified as
captured columns when the capture
instance was created. If no columns
were originally specified in the captured
column list, all columns in the source
table are returned.
For more information, see cdc.fn_cdc_get_net_changes_<capture_instance> (Transact-SQL).
Next Step
After you have created the table-valued function that queries for change data, the next step is to start designing
the data flow in the package.
Next topic: Retrieve and Understand the Change Data
Retrieve and Understand the Change Data
3/24/2017 • 2 min to read • Edit Online
In the data flow of an Integration Services package that performs an incremental load of change data, the first
task is to run the query that retrieves the change data. You execute this query inside a source component in a
Data Flow task. You can then use downstream transformations and destinations to apply the change data to your
destination.
NOTE
The creation of a query that contains a table-valued function is the third step in the process of creating a package that
performs an incremental load of change data. For more information about this query, see, Create the Function to Retrieve
the Change Data. For a description of the overall process for creating a package that performs an incremental load of
change data, see Change Data Capture (SSIS).
Adding the Data Flow Task
In the data flow of the package, you retrieve the change data, separate the rows based on the type of change that
occurred, and then apply the changes to the destination.
To add a Data Flow task to the package
1. In SQL Server Data Tools (SSDT), on the Control Flow tab, add a Data Flow task.
2. Connect the preceding task that prepared the query string to the Data Flow task.
Configuring the Source Component to Query for Changes
The source component uses the query string that was prepared and stored in a variable to calls the table-valued
function that retrieves the changed data.
NOTE
For more information about the query string that was prepared and stored in a variable, see Prepare to Query for the
Change Data. For more information about the table-valued function that retrieves the change data, see Create the
Function to Retrieve the Change Data.
To configure an OLE DB source to retrieve the change data
1. In SQL Server Data Tools (SSDT), on the Data Flow tab, add an OLE DB source.
2. In the OLE DB Source Editor, on the Connection Manager page, select the following options:
a. Configure a valid connection to the source database.
b. For Data access mode, select SQL command from variable.
c. For Variable name, select User::SqlDataQuery.
3. In the OLE DB Source Editor, on the Columns page, make sure that all the columns that you want are
mapped to output columns.
Next Step
After you have configured an OLE DB source to retrieve the change data, the next step is to start designing the
data flow in the package.
Next topic: Process Inserts, Updates, and Deletes
Process Inserts, Updates, and Deletes
3/24/2017 • 2 min to read • Edit Online
In the data flow of an Integration Services package that performs an incremental load of change data, the second
task is to separate inserts, updates, and deletes. Then, you can use appropriate commands to apply them to the
destination.
NOTE
The first task in designing the data flow of a package that performs an incremental load of change data is to configure the
source component that runs the query that retrieves the change data. For more information about this component, see
Retrieve and Understand the Change Data. For a description of the overall process for creating a package that performs an
incremental load of change data, see Change Data Capture (SSIS).
Associating Friendly Values to Separate Inserts, Updates, and Deletes
In the example query that retrieves change data, the cdc.fn_cdc_get_net_changes_ function returns only the
column of metadata named __$operation. This metadata column contains an ordinal value that indicates which
operation caused the change.
NOTE
For more information about the query that uses calls the cdc.fn_cdc_get_net_changes_ function, see Create the Function
to Retrieve the Change Data.
Matching an ordinal value to its corresponding operation is not as easy as using a mnemonic of the operation. For
example, 'D' can easily represent a delete operation and 'I' represent an insert operation. The example query that
was created in the topic, Creating the Function to Retrieve the Change Data, makes this conversion from an
ordinal value to a friendly string value that is returned in a new column. The following segment of code shows this
conversion:
select
...
case __$operation
when 1 then 'D'
when 2 then 'I'
when 4 then 'U'
else null
end as CDC_OPERATION
Configuring a Conditional Split Transformation to Direct Inserts,
Updates, and Deletes
To direct rows of change data to one of three outputs, the Conditional Split transformation is ideal. The
transformation just checks the value of the CDC_OPERATION column in each row and determines whether that
change was an insert, update, or delete.
NOTE
The CDC_OPERATION column contains a friendly string value derived from the numeric value in the __$operation column.
To split inserts, updates, and deletes for processing by using a Conditional Split transformation
1. On the Data Flow tab, add a Conditional Split transformation.
2. Connect the output of the OLE DB source to the Conditional Split transformation.
3. In the Conditional Split Transformation Editor, in the lower pane of the editor, enter the following three
lines to designate the three outputs
a. Enter a line with the condition
CDC_OPERATION == "I"
to direct inserted rows to the output for inserts.
b. Enter a line with the condition
updates.
CDC_OPERATION == "U"
to direct updated rows to the output for
c. Enter a line with the condition
CDC_OPERATION == "D"
to direct deleted rows to the output for deletes.
Next Step
After you split the rows for processing, the next step is to apply the changes to the destination.
Next topic: Apply the Changes to the Destination
See Also
Conditional Split Transformation
Split a Dataset by Using the Conditional Split Transformation
Apply the Changes to the Destination
3/24/2017 • 4 min to read • Edit Online
In the data flow of an Integration Services package that performs an incremental load of change data, the third and
final task is to apply the changes to your destination. You will need one component to apply inserts, one to apply
updates, and one to apply deletes.
NOTE
The second task in designing the data flow of a package that performs an incremental load of change data is to separate
inserts, updates, and deletes. For more information about this component, see Process Inserts, Updates, and Deletes. For a
description of the overall process for creating a package that performs an incremental load of change data, see Change Data
Capture (SSIS).
Applying Inserts
To apply inserts, you use an OLE DB destination because the new rows do not require any special handling.
To process inserts by using an OLE DB Destination
1. On the Data flow tab, add an OLE DB destination.
2. Connect the output that contains inserts from the Conditional Split transformation to the OLE DB
destination.
3. In the OLE DB Destination Editor, on the Connection Manager page, select the following options:
a. Select or create an OLE DB Connection Manager for the destination database.
b. Select a Data access mode option, and then select the destination table or enter a SQL statement
that contains the destination columns.
4. On the Mappings page of the editor, map the appropriate columns from the change data to the destination
table.
Applying Updates
To apply updates, you use an OLE DB Command transformation. You use this transformation because you have to
use a parameterized UPDATE statement to update one row at a time with the new column values.
NOTE
You can also use destination components to apply updates. When using this approach, you use the destination components
to save the rows to temporary tables that you create for this purpose. Then, you use Execute SQL tasks to perform bulk
update and bulk delete operations against the destination from the temporary tables.
To process updates by using an OLE DB Command transformation
1. On the Data flow tab, add an OLE DB Command transformation.
2. Connect the output that contains updates from the Conditional Split transformation to the OLE DB
Command transformation.
3. In the Advanced Editor for OLE DB Command, on the Connection Manager tab, select or create an OLE
DB Connection Manager for the destination database.
4. In the Advanced Editor for OLE DB Command, on the Component Properties tab, for SqlCommand,
enter a parameterized UPDATE statement.
For example, an UPDATE statement for a Customer table might have the following syntax:
update CDCSample.Customer
set TerritoryID = ?,
CustomerType = ?,
rowguid = ?,
ModifiedDate = ?
where CustomerID = ?
5. On the Column Mappings tab of the editor, map the appropriate columns from the change data to the
parameters in the UPDATE statement.
Applying Deletes
To apply deletes, you use an OLE DB Command transformation. You use this transformation because you have to
use a parameterized DELETE statement that deletes a single row at a time based on the column value that uniquely
identifies the row.
NOTE
You can also use destination components to apply deletes. When using this approach, you use the destination components
to save the rows to temporary tables that you create for this purpose. Then, you use Execute SQL tasks to perform bulk
update and bulk delete operations against the destination from the temporary tables.
To process deletes by using an OLE DB Command transformation
1. On the Data flow tab, add an OLE DB Command transformation to the data flow.
2. Connect the output that contains deletes from the Conditional Split transformation to the OLE DB
Command transformation.
3. Open the Advanced Editor to configure the transformation.
4. In the Advanced Editor for OLE DB Command, on the Connection Manager tab, select or create an OLE
DB Connection Manager for the destination database.
5. In the Advanced Editor for OLE DB Command, on the Component Properties tab of the editor, for
SqlCommand, enter a parameterized DELETE statement.
For example, a DELETE statement for a Customer table might have the following syntax:
delete from Customer where CustomerID = ?
6. On the Column Mappings tab of the editor, map the appropriate column from the change data to the
parameter in the DELETE statement.
Optimizing Inserts and Updates by Using MERGE Functionality
You can optimize the processing of inserts and updates by combining certain change data capture options with
the use of the Transact-SQL MERGE keyword. For more information about the MERGE keyword, see MERGE
(Transact-SQL).
In the Transact-SQL statement that retrieves the change data, you can specify all with merge as the value of the
row_filter_option parameter when you call the cdc.fn_cdc_get_net_changes_ function. This change data capture
function operates more efficiently when it does not have to perform the extra processing that is required to
distinguish inserts from updates. When you specify the all with merge parameter value, the __$operation value of
the change data is 1 for deletes or 5 for changes that were caused by inserts or updates. For more information
about the Transact-SQL function that is used to retrieve the change data, see Retrieve and Understand the Change
Data.After retrieving changes with the all with merge parameter value, you can apply deletes, and output the
remaining rows to a temporary table or a staging table. Then, in a downstream Execute SQL Task, you can use a
single MERGE statement to apply all the inserts or updates from the staging table to the destination.
Perform an Incremental Load of Multiple Tables
4/19/2017 • 4 min to read • Edit Online
In the topic, Improving Incremental Loads with Change Data Capture, the diagram illustrates a basic package that
performs an incremental load on just one table. However, loading one table is not as common as having to
perform an incremental load of multiple tables.
When you perform an incremental load of multiple tables, some steps have to be performed once for all the
tables, and other steps have to be repeated for each source table. You have more than one option for
implementing these steps in Integration Services:
Use a parent package and child packages.
Use multiple Data Flow tasks in a single package.
Loading Multiple Tables by Using a Parent Package and Multiple Child
Packages
You can use a parent package to perform those steps that only have to be done once. The child packages will
perform those steps that have to be done for each source table.
To create a parent package that performs those steps that only have to be done once
1. Create a parent package.
2. In the control flow, use an Execute SQL task or Integration Services expressions to calculate the endpoints.
For an example of how to calculate endpoints, see Specify an Interval of Change Data.
3. If needed, use a For Loop container to delay execution until change data for the selected period is ready.
For an example of such a For Loop container, see Determine Whether the Change Data Is Ready.
4. Use multiple Execute Package tasks to execute child packages for each table to be loaded. Pass the
endpoints calculated in the parent package to each child package by using Parent Package Variable
configurations.
For more information, see Execute Package Task and Use the Values of Variables and Parameters in a Child
Package.
To create child packages to perform those steps that have to be done for each source table
1. For each source table, create a child package.
2. In the control flow, use a Script task or an Execute SQL task to assemble the SQL statement that will be used
to query for changes.
For an example of how to assemble the query, see Prepare to Query for the Change Data.
3. Use a single Data Flow task in each child package to load the change data and apply it to the destination.
Configure the Data Flow as described in the following steps:
a. In the data flow, use a source component to query the change tables for the changes that fall within
the selected endpoints.
For an example of how to query the change tables, see Retrieve and Understand the Change Data.
b. Use a Conditional Split transformation to direct inserts, updates, and deletes to different outputs for
appropriate processing.
For an example of how to configure this transformation to direct output, see Process Inserts,
Updates, and Deletes.
c. Use a destination component to apply the inserts to the destination. Use OLE DB Command
transformations with parameterized UPDATE and DELETE statements to apply updates and deletes to
the destination.
For an example of how to use this transformation to apply updates and deletes, see Apply the
Changes to the Destination.
Loading Multiple Tables by Using Multiple Data Flow Tasks in a Single
Package
Alternatively, you can use a single package that contains a separate Data Flow task for each source table to be
loaded.
To load multiple tables by using multiple Data Flow tasks in a single package
1. Create a single package.
2. In the control flow, use an Execute SQL Task or Integration Services expressions to calculate the endpoints.
For an example of how to calculate endpoints, see Specify an Interval of Change Data.
3. If needed, use a For Loop container to delay execution until the change data for the selected interval is
ready.
For an example of such a For Loop container, see Determine Whether the Change Data Is Ready.
4. Use a Script task or an Execute SQL task to assemble the SQL statement that will be used to query for
changes.
For an example of how to assemble the query, see Prepare to Query for the Change Data.
5. Use multiple Data Flow tasks to load the change data from each source table and apply it to the destination.
Configure each Data Flow task as described in the following steps.
a. In each data flow, use a source component to query the change tables for the changes that fall within
the selected endpoints.
For an example of how to query the change tables, see Retrieve and Understand the Change Data.
b. Use a Conditional Split transformation to direct inserts, updates, and deletes to different outputs for
appropriate processing.
For an example of how to configure this transformation to direct output, see Process Inserts,
Updates, and Deletes.
c. Use a destination component to apply the inserts to the destination. Use OLE DB Command
transformations with parameterized UPDATE and DELETE statements to apply updates and deletes to
the destination.
For an example of how to use this transformation to apply updates and deletes, see Apply the
Changes to the Destination.
Change Data Capture for Oracle by Attunity
3/24/2017 • 1 min to read • Edit Online
The Change Data Capture for Oracle by Attunity download includes the following 2 components.
Change Data Capture Designer for Oracle by Attunity
Change Data Capture Service for Oracle by Attunity
Get the Change Data Capture for Oracle by Attunity download
The Microsoft® Change Data Capture Designer and Service for Oracle by Attunity for Microsoft SQL Server® 2016
are part of the SQL Server 2016 Feature Pack. Download components of the Feature Pack from the SQL Server
2016 Feature Pack web page.
Change Data Capture Designer for Oracle by
Attunity
3/24/2017 • 1 min to read • Edit Online
The CDC Designer Console is used to develop and maintain Oracle CDC Instances. The CDC Designer Console is a
Microsoft Management Console snap-in that contains the following elements:
New Instance Wizard: This wizard creates a new Oracle CDC Instance. For information on using the New
Instance Wizard, see Use the New Instance Wizard.
CDC Instance Properties Viewer: This is a docked view showing the status and configuration of the selected
CDC instance. For information about the properties viewer, see How to Manage a CDC Instance.
CDC Instance Properties Editor: This dialog box is used to edit any existing Oracle CDC Service instance. For
information about editing the CDC instance properties, see Edit Instance Properties.
The Microsoft® Change Data Capture Designer and Service for Oracle by Attunity for Microsoft SQL
Server® 2016 are part of the SQL Server 2016 Feature Pack. Download components of the Feature Pack
from the SQL Server 2016 Feature Pack web page.
In This Documentation
The CDC Designer Console Introduction
Oracle CDC Instance Data Types
Error Handling
The Oracle CDC Instance
The Oracle CDC Databases
Change Data Capture Designer for Oracle by Attunity F1 Help Reference
Change Data Capture Designer for Oracle by Attunity How to Guide
SQL Server Connection for Instance Creation
Advanced Connection Properties
Oracle Credentials for Running Script
Oracle Supplemental Logging Script
CDC Instance Deployment Script
SQL Server Connection Required Permissions for the CDC Designer
The CDC Designer Console Introduction
4/29/2017 • 1 min to read • Edit Online
The section describes the installation procedures for the Change Data Capture Designer for Oracle by Attunity.
Installation
The section describes the installation procedures for the Change Data Capture Designer for Oracle by Attunity.
The Microsoft® Change Data Capture Designer and Service for Oracle by Attunity for Microsoft SQL Server® 2016
are part of the SQL Server 2016 Feature Pack. Download components of the Feature Pack from the SQL Server
2016 Feature Pack web page.
Supported Windows Environments
The CDC Designer Console can run in the following Windows environments:
Windows Vista with Service Pack 2
Windows 7
Windows 8 and 8.1
Windows 10
Windows Server 2008 R2
Windows Server 2008 with Service Pack 2
Windows Server 2012
Database Prerequisites
To work with the Change Data Capture Designer for Oracle by Attunity, you work with an Oracle database. The
Change Data Capture Designer for Oracle by Attunity supports the following versions:
Oracle Database
Oracle Database 10g Release 2: 10.2.0.1-10.2.0.5 (patchset as of April 2010)
Oracle Database 11g Release 1: 11.1.0.6-11.1.0.7 (patchset as of September 2008)
Oracle Database 11g Release 2: 11.2.0.1-11.2.0.3 (patchset as of September 2011)
Oracle Database 12c in classic installation. (Multitenant installation is not supported.)
SQL Server Database
SQL Server 2016 edition with support for SQL Server CDC
Software Prerequisites
You have to use the 32-bit or 64-bit version of the Oracle client software according to the version of the Oracle
CDC Designer console installed.
The Oracle CDC Designer Console uses the Oracle ODBC provider to communicate with the source Oracle
database.
Running the Installation Program
This section describes how to install the CDC Designer Console.
To install the CDC Designer Console
Double-click the CDC Designer Console installation kit and follow the directions in the installation wizard.
Uninstalling the CDC Designer Console
Uninstall the CDC Designer Console by using Control Panel, Programs and Features.
Oracle CDC Instance Data Types
3/24/2017 • 1 min to read • Edit Online
The Oracle CDC Instance supports most Oracle data types. The following sections describe the supported data
types and the non-supported data types.
Supported Data Types
The following table describes the Oracle data types that can be captured and their default mapping to SQL Server
data types in the change tables. When adding a capture instance for a source Oracle table, you can override some
of these mappings.
ORACLE DATABASE DATA TYPE
SQL SERVER DATA TYPE
BINARY_FLOAT
REAL
BINARY_DOUBLE
FLOAT
CHAR
NVARCHAR
DATE
DATETIME
FLOAT
FLOAT
INT
NUMERIC (38)
INTERVAL
DATETIME
NCHAR
NVARCHAR
NUMBER
FLOAT
NAVARCHAR2
NVARCHAR
RAW
VARBINARY
REAL
FLOAT
TIMESTAMP
DATETIME2
TIMESTAMP WITH TIME ZONE
VARCHAR (37)
TIMESTAMP WITH LOCAL TIME ZONE
VARCHAR (37)
VARCHAR2
VARCHAR
XMLTYPE
NVARCHAR (MAX)
Non-Supported Data Types
Source Oracle tables with columns of the following Oracle data types cannot be captured. Captured columns with
these data types will show as null; however, a change in their value is indicated in the change mask of the captured
tables.
LONG
XMLTYPE
BLOB
CLOB
Source Oracle tables with columns of the following Oracle data types cannot be captured.
BFILE
ROWID
REF
UROWID
Nested Table
If the following data types are present in a table they will prevent the LogMinder from getting any data for
any column of the table:
User-defined data types
VARRAY
See Also
Change Data Capture Designer for Oracle by Attunity
The Oracle CDC Instance
Error Handling
3/24/2017 • 7 min to read • Edit Online
An Oracle CDC Instance mines changes from a single Oracle source database (an Oracle RAC cluster is considered
a single database) and writes the committed changes to change tables in a CDC database in the target SQL Server
instance.
A CDC Instance maintains its state in a system table called cdc.xdbcdc_state. This table can be queried any time to
find the state of the CDC Instance. For more information about the cdc.xdbcdc_state table, see cdc.xdbcdc_state.
The table below describes the CDC Instance states in the xdbcdc_state table.
For each state, the following two indications are shown for the corresponding columns in the cdc.xdbcdc_state
table:
Instance is not active (there is no Windows process currently handling it). If the active column value is 1, a
subprocess of the Oracle CDC Service handling this specific Oracle CDC Instance is running.
If the error column value is 0, the Oracle CDC Instance is not in an error condition. If the error column value
is 1, there is an error that prevents the Oracle CDC Instance from processing changes.
If the error column has a value of 1 and the active column value is also 1, then a recoverable error is
occurring for the Oracle CDC Instance, which can be resolved automatically. If the error column has a value
of 1 and the active column has a value of 0, then in most cases a manual workaround may be needed to
resolve the problem before processing can be resumed.
The following table describes the various status codes that the Oracle CDC Instance may report in its state
table.
STATUS
ACTIVE STATUS CODE
ERROR STATUS CODE
DESCRIPTION
SUBSTATUS
ABORTED
0
1
The Oracle CDC
Instance is not
running. The
ABORTED substatus
indicates that the
Oracle CDC Instance
was ACTIVE and then
has stopped
unexpectedly.
The ABORTED
substatus is
established by the
Oracle CDC Service
main instance when it
detects that the
Oracle CDC Instance
is not running while
its status is ACTIVE.
STATUS
ACTIVE STATUS CODE
ERROR STATUS CODE
DESCRIPTION
SUBSTATUS
ERROR
0
1
The Oracle CDC
Instance is not
running. The ERROR
status indicates that
the CDC instance was
ACTIVE but then
encountered an error
that is not
recoverable and
disabled itself.
MISCONFIGURED: An
unrecoverable
configuration error
was detected.
The CDC instance is
running and is
processing change
records.
IDLE: All change
records were
processed and stored
into the target control
(_CT) tables. There is
no active transaction
with the control
tables.
RUNNING
1
0
PASSWORDREQUIRED: There is
no password set for
the Change Data
Capture Designer for
Oracle by Attunity or
the configured
password is not valid.
This can be because
of a change to the
service asymmetric
key password.
PROCESSING: There
are change records
being processed that
are not yet written to
the control (_CT)
tables.
STOPPED
0
0
The CDC instance is
not running.
The STOP substatus
indicates that the
CDC instance was
ACTIVE and then was
stopped correctly.
STATUS
ACTIVE STATUS CODE
ERROR STATUS CODE
DESCRIPTION
SUBSTATUS
SUSPENDED
1
1
The CDC instance is
running but
processing is
suspended due to a
recoverable error.
DISCONNECTED: The
connection with the
source Oracle
database cannot be
established.
Processing will
resume once
connection is
restored.
STORAGE: The
storage is full.
Processing will
resume when storage
becomes available. In
some cases, this
status may not
appear because the
status table cannot be
updated.
LOGGER: The logger
is connected to Oracle
but it cannot read the
Oracle transaction
logs because of a
temporary problem.
DATAERROR
x
x
This status code is
only used for the
xdbcdc_trace table.
It does not appear in
the xdbcdc_state
table. Trace records
with this status
indicate a problem
with an Oracle log
record. The bad log
record is stored in the
data column as a
BLOB.
BADRECORD: The
attached log record
could not be parsed.
CONVERT-ERROR:
The data in some
columns could not be
converted to the
target columns in the
capture table. This
status may appear
only if the
configuration specifies
that conversion errors
should produce trace
records.
Because the Oracle CDC Service state is stored in SQL Server, there may be cases where the state value in the
database might not reflect the actual state of the service. The most common scenario is when the service loses its
connection to SQL Server and cannot resume it (for any reason). In that case, the state stored in cdc.xdbcdc_state
becomes stale. If the last update timestamp (UTC) is more than a minute old, the state is probably stale. In this case,
use the Windows Event Viewer to find additional information about the status of the service.
Error Handling
This section describes how the Oracle CDC Service handles errors.
Logging
The Oracle CDC Service creates error information in one of the following places.
The Windows event log, which is used with logging errors and to indicate Oracle CDC Service life cycle
events (starting, stopping, (re)connection to the target SQL Server instance).
The MSXDBCDC.dbo.xdbcdc_trace table, which is used for general logging and tracing by the Oracle CDC
Service main process.
The <cdc-database>.cdc.xdbcdc_trace table, which is used for general logging and tracing by Oracle CDC
Instances. This means that errors related to a specific Oracle CDC Instance are logged to that instance’s trace
table.
Information is logged by the Oracle CDC service when the service:
Is started or stopped by the service control manager.
Cannot connect to the associated SQL Server instance and when it successfully establishes a connection
following a failure.
Encounters an error starting Oracle CDC Service instances.
Detects that an Oracle CDC Instance has aborted.
Encounters an unexpected error.
Information is logged by the CDC instance when the instance:
Is enabled or disabled.
Encounters an error.
Recovers from a recoverable error.
The trace table is also used for recording detailed trace information for troubleshooting.
Handling Source Oracle Connection Errors
The Oracle CDC Service needs a persistent connection with the source Oracle database. Many connection errors
that are unrelated to the service configuration (such as networking errors) are considered transient. Therefore, if
the Oracle CDC Service cannot establish connection with the Oracle database (either on start or during work
following a disconnection), the service changes its state to SUSPENDED/DISCONNECTED and enters a retry loop
where the connection is retried at regular intervals. When the connection is re-established, processing continues.
Other types of connection errors are not transient (for example, bad credentials, insufficient privileges, and bad
database address). When these errors occur, the Oracle CDC Service state is set to ERROR/MISCONFIGURED or to
ERROR/PASSWORD-REQUIRED and the service is disabled. When the user fixes the underlying error, the Oracle
CDC Instance should be manually re-enabled for processing to resume.
When it is not clear whether the error is transient, it is best to assume it is transient.
Handling Target SQL Server Connection Errors
The Oracle CDC Service needs a persistent connection to the target SQL Server instance. This connection is used to:
Ensure that there are no other services by the same name currently working with this SQL Server instance.
Check which Oracle CDC Instance is enabled or disabled and start (or stop) its subprocess.
When the service establishes a connection with the target SQL Server instance and verifies that it is the only
Oracle CDC service by this name that is working, it can check which Oracle CDC instances are enabled and
start their handling processes (afterward the service stops these processes when they are disabled). The
Oracle CDC instances use their SQL Server connections to work with the CDC database of the Oracle CDC
instance.
How errors are handled when the connection to the target SQL Server fails depends on whether the errors
are transient.
For known non-transient errors (such as bad credentials, insufficient privileges, bad connection
information), the service logs an error to the Windows event log and stops (it cannot write to the trace table
because it cannot connect to SQL Server). In this case, the user must resolve the error and restart the Oracle
CDC Windows service.
For transient errors and unexpected errors, the operation is retried several times and if the failure persists
for a significant time period, the CDC Service stops its CDC Instance subprocesses and goes back to its initial
connection attempt (by this time, an Oracle CDC Service on another machine may have already taken
control of the named CDC service).
Handling Target SQL Server Storage Full Errors
When the Oracle CDC Service detects that it cannot insert new change data into the target SQL Server CDC
database, it writes a warning to the event log and tries to insert a trace record (although that may fail for the same
reason). It then retries the operation in a specific interval until it is successful.
Handling Oracle CDC Errors
The Oracle CDC Instance reads the Oracle transaction log and processes it. If the CDC processing encounters an
error, it is reported in the cdc.xdbcdc_state table and the user needs to manually intervene based on the reported
error.
For example, the Oracle CDC Instance may not be active for an extended duration and the required Oracle
transaction log files are no longer available. In this case, the Oracle DBA must restore the required logs for the
Oracle CDC Instance to resume processing.
Handling Unexpected Oracle CDC Instance Failures
The Oracle CDC Service monitors its CDC Instance subprocesses. When a CDC Instance subprocess aborts, the CDC
Service disables it in the MSXDBCDC.dbo.xdbcdc_databases table and updates its cdc.xdbcdc_state status to
ABORTED. In this case, the standard Windows Error Reporting dialog box is used to report this error for further
analysis.
See Also
Change Data Capture Designer for Oracle by Attunity
The Oracle CDC Instance
The Oracle CDC Instance
3/24/2017 • 2 min to read • Edit Online
The Oracle CDC Instance is a process created by the Oracle CDC Service to process changes captured from a single
Oracle source database. The Oracle CDC Instance retrieves its configuration from the cdc.xdbcdc_config table
and maintains its state in the cdc.xdbcdc_state table. These tables are part of the CDC database, which defines
the Oracle CDC Instance. For more information about the xdbcdc database and tables see The CDC Databases.
The following describes the tasks carried out by the Oracle CDC instance:
Handling service startup verification: When started, the CDC instance loads its configuration from the
xdbcdc_config table and performs a series of status verifications that ensure that the CDC instance
persisted state is consistent and that it can start processing changes.
Preparing for change capture: When the verification passes successfully, the Oracle CDC Instance scans
all of the capture instances currently defined and prepares the Oracle LogMiner queries and other support
structures required for change capture. In addition, the Oracle instance re-loads the internal capture state
that was saved the last time the Oracle CDC Instance run.
Capturing changes from Oracle: The Oracle CDC Instance pools changes from Oracle by means of the
Oracle LogMiner facility, orders them in according to transaction commit, and then changes the time in a
transaction and writes them to the SQL Server change tables in the CDC database.
Handling service shutdown: The life cycle of the Oracle CDC Instance is managed by the Oracle CDC
Service. When the Oracle CDC Instance is requested to shut down, it performs the following tasks:
Stops reading from the Oracle transaction log.
Stops writing completed Oracle transactions to the CDC database.
Waits for up to 30 seconds (if necessary) until the current transaction finishes writing to the CDC
database. If more than 30 seconds pass, the writing is cancelled and transaction is rolled back (to be
retried when the CDC instance is restarted).
In a separate thread, writes as many memory-cached records as possible to the staged transactions
table for up to 30 seconds (from the oldest transaction to the newest), then updates the
xdbcdc_state table and commits all the changes.
Handling configuration changes: The Oracle CDC Instance is notified about configuration changes either
from the CDC Service or by detecting a new version in the cdc.xdbcdc_config table. Most changes do not
require the restart of the Oracle CDC Instance (for example, adding or removing capture instances).
However, some changes, such as changing the Oracle connection string or access credentials do require the
restart of the CDC Instance.
Handling recovery: When an Oracle CDC Instance starts its internal state is restored from the
xdbcdc_state and the xdbcdc_staged_transactions tables. Once the state is restored, the CDC instance
proceeds as usual.
See Also
Error Handling
The Oracle CDC Databases
3/24/2017 • 12 min to read • Edit Online
An Oracle CDC Instance is associated with a SQL Server database by the same name on the target SQL Server
instance. This database is called the Oracle CDC database (or the CDC database).
The CDC database is created and configured using the Oracle CDC Designer Console and it contains the following
elements:
A
cdc
schema created by enabling the database for SQL Server CDC.
A set of cdc.xdbcdc_xxxx tables used by the Oracle CDC Instance.
A set of empty mirror tables with the definitions of the captured tables in tuphe Source Oracle database.
A set of change tables and change access functions that are generated by the SQL Server CDC mechanism
and are identical to those used in the regular, non-Oracle, SQL Server CDC.
The cdc schema is initially accessible only to the members of the dbowner fixed database role. Access to
the change tables and change functions is determined by the same security model as the SQL Server CDC.
For more information about the security model, see Security Model.
Creating the CDC Database
In most cases, the CDC database is created using the CDC Designer Console, but it can also be created with a CDC
deployment script that is generated using the CDC Designer Console. The SQL Server system administrator can
change the database settings if necessary (for items such as for storage, security, or availability).
For more information about using the CDC Designer Console to create the database tables and the necessary
scripts, see Use the New Instance Wizard.
CDC Database User Roles
When a CDC Database is created and enabled for CDC, a database user called cdc_service is created in the CDC
database and is associated with the SQL Server login that the Oracle CDC Service was configured with. This user is
made a member of the db_datareader, db_datawriter, and db_ddladmin database roles. If the SQL Server login
is also the associated with the dbo user then the cdc_service is not created.
This role assignment allows the Oracle CDC Service to update the tables under the
and with control information.
cdc
schema with captured data
When a CDC database is created and CDC source Oracle tables are set up, the CDC database owner can grant
SELECT permission of mirror tables and define SQL Server CDC gating roles to control who accesses the change
data.
Mirror Tables
For each captured table, <schema-name>.<table-name>, in the Oracle source database, a similar empty table is
created in the CDC Database, with the same schema and table name. Oracle source tables with the schema name
cdc (not case sensitive) cannot be captured because the cdc schema in SQL Server is reserved for the SQL Server
CDC.
The mirror tables are empty; no data is stored in them. They are used to enable the standard SQL Server CDC
infrastructure that is used by the Oracle CDC Instance. To prevent data from being inserted or updated into the
mirror tables, all UPDATE, DELETE, and INSERT operations are denied for PUBLIC. This ensures that they cannot be
modified.
Access to Change Data
Because of the SQL Server security model used to gain access to the change data that is associated with a capture
instance, the user must be granted select access to all the captured columns of the associated mirror table
(access permissions to the original Oracle tables do not provide access to the change tables in SQL Server). For
information on the SQL Server security model, see Security Model.
In addition, if a gating role is specified when the capture instance is created, the caller must also be a member of
the specified gating role. Other general change data capture functions for accessing metadata are accessible to all
database users through the PUBLIC role, although access to the returned metadata is usually gated by using select
access to the underlying source tables, and by membership in any defined gating roles.
Change data may be read by calling special table-based functions generated by the SQL Server CDC component
when a capture instance is created. For more information about this function, see Change Data Capture Functions
(Transact-SQL).
Accessing CDC data through the Integration Services CDC Source component is subject to the same rules.
The CDC Database Tables
This section describes the following tables in the CDC database.
Change Tables (_CT)
cdc.lsn_time_mapping
cdc.xdbcdc_config
cdc.xdbcdc_state
cdc.xdbcdc_trace
cdc.xdbcdc_staged_transactions
Change Tables (_CT )
The change tables are created from the mirror tables. They contain the change data that is captured from the
Oracle database. The tables are named according to the following convention:
[cdc].[<capture-instance>_CT]
When capture is initially enabled for table <schema-name>.<table-name> , the default capture instance name is
<schema-name>_<table-name> . For example, the default capture instance name for the Oracle HR.EMPLOYEES table is
HR_EMPLOYEES and the associated change table is [cdc]. [HR_EMPLOYEES_CT].
The capture tables are written to by the Oracle CDC Instance. They are read using special table-valued functions
generated by SQL Server when the capture instance is created. For example, fn_cdc_get_all_changes_HR_EMPLOYEES .
For more information about these CDC functions see Change Data Capture Functions (Transact-SQL).
cdc.lsn_time_mapping
The [cdc].[lsn_time_mapping] table is generated by the SQL Server CDC component. Its use in the case of Oracle
CDC is different than its normal use.
For the Oracle CDC, the LSN values stored in this table are based on the Oracle System Change Number (SCN)
value associated with the change. The first 6 bytes of the LSN value is the original Oracle SCN number.
Also when using the Oracle CDC, the time columns ( tran_begin_time and tran_end_time ) store the UTC time of
the change rather than the local time as it does with the regular SQL Server CDC. This ensures that daylight savings
time changes do not impact the data stored in the lsn_time_mapping.
cdc.xdbcdc_config
This table contains the configuration data for the Oracle CDC Instance. It is updated using the CDC Designer
Console. This table has only one row.
The following table describes the cdc.xdbcdc_config table columns.
ITEM
DESCRIPTION
version
This keeps track of the version of the CDC instance
configuration. It is updated each time that the table is
updated and each time a new capture instance is added or an
existing capture instance is removed.
connect_string
An Oracle connection string. A basic example is:
<server>:<port>/<instance>
erp.contoso.com:1521/orcl
(for example,
).
The connection string can also specify an Oracle Net connect
descriptor, for example,
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=erp.contoso.com) (PORT=1521)) (CONNECT_DATA=
(SERVICE_NAME=orcl)))
.
If using a directory server or tnsnames, the connect string can
be the name of the connection.
For more information about Oracle connection strings, see
http://go.microsoft.com/fwlink/?LinkId=231153 for detailed
information on Oracle database connection strings for the
Oracle Instant Client that is used by the Oracle CDC Service.
use_windows_authentication
A Boolean value that can be:
0: An Oracle user name and password are provided for
authentication (the default)
1: Windows authentication is used to connect to the Oracle
database. You can use this option only if the Oracle database
is configured to work with Windows authentication.
username
The name of the log-mining Oracle database user. This is
mandatory only if use_windows_authentication = 0.
password
The password for the log-mining Oracle database user. This is
mandatory only if use_windows_authentication = 0.
transaction_staging_timeout
The time, in seconds, that an uncommitted Oracle transaction
is kept in memory before being written to the
cdc.xdbcdc_staged_transactions table. The default is 120
seconds.
ITEM
DESCRIPTION
memory_limit
The limit on the amount of memory, in Mb, that can be used
for caching data in memory. A lower setting causes more
transaction to be written to the
cdc.xdbcdc_staged_transactions table. The default is 50
Mb.
options
A list of options in the form of name[=value][; ] - it is used for
specifying secondary options (for example, tracing, tuning).
See the table below for a description of the available options.
The following table describes the available options.
NAME
DEFAULT
MIN
MAX
STATIC
DESCRIPTION
trace
False
-
-
False
The available
values are:
True
False
on
off
cdc_update_state
_interval
10
1
120
False
The size (in
Kbytes) of
memory chunks
allocated for a
transaction (a
transaction can
allocate more
than one chunk).
See the
memory_limit
column in
cdc.xdbcdc_config
table.
target_max_batch
ed_transactions
100
1
1000
True
The maximum
number of Oracle
transactions that
can be processed
as one
transaction in
SQL Server CT
tables update.
target_idle_lsn_u
pdate_interval
10
0
1
False
The interval (in
seconds) for
updating the
lsn_time_mappi
ng table when
the captured
tables have no
activity.
NAME
DEFAULT
MIN
MAX
STATIC
DESCRIPTION
trace_retention_p
eriod
24
1
24*31
False
The amount of
time (in hours to
keep messages in
the trace table).
sql_reconnect_int
erval
2
2
3600
False
The amount of
time (in seconds)
to wait before
reconnecting to
SQL Server. This
interval is used in
addition to SQL
Server client’s
connect timeout.
sql_reconnect_lim
it
-1
-1
-1
False
The maximum
number of SQL
Server
reconnections.
The default -1
means that the
process tries to
reconnect until it
stops.
cdc_restart_limit
6
-1
3600
False
In most cases,
the CDC service
restarts an
abnormally
ended CDC
instance
automatically.
This property
defines after how
many failures per
hour the service
stops to restart
the instance. The
value -1 means
that the instance
should be always
restarted.
The Service
returns to restart
the instance after
any update of the
configuration
table.
cdc_memory_rep
ort
0
0
1000
False
If the value of the
parameter was
changed, the
CDC Instance
prints its memory
report on the
trace table.
NAME
DEFAULT
MIN
MAX
STATIC
DESCRIPTION
target_command
_timeout
600
1
3600
False
Command
timeout working
with SQL Server.
source_character_
set
-
-
-
True
Can be set to a
specific Oracle
encoding to be
used instead of
the Oracle
database
codepage. This
may be of use
when the actual
encoding the
character data is
using is different
than the one
expressed by the
Oracle database
codepage.
source_error_retr
y_interval
30
1
3600
False
Used before retry
on several errors
such as a
connection error
or temporary lack
of
synchronization
between system
tables.
source_prefetch_s
ize
100
1
10000
True
Size of the
prefetch batch.
source_max_table
s_in_query
100
1
10000
True
Maximum
number of tables
in WHERE clause
before switching
to reading the
Oracle log
without table
filtering.
source_read_retry
_interval
2
1
3600
False
The amount of
time the source
waits before
trying to read the
Oracle
transaction logs
on EOF again.
source_reconnect
_interval
30
1
3600
False
How long (in
seconds) to wait
before trying to
re-connect to the
source database.
NAME
DEFAULT
MIN
source_reconnect
_limit
-1
-1
source_command
_timeout
30
1
source_connectio
n_timeout
30
trace_data_errors
CDC_stop_on_br
eaking_schema_c
hanges
MAX
STATIC
DESCRIPTION
False
The maximum
number of the
source database
reconnections.
The default -1
means that the
process tries to
reconnect until it
is stopped.
3600
False
Connection
timeout working
with Oracle.
1
3600
False
Connection
timeout working
with SQL Server.
True
-
-
False
Boolean. True
indicates to log
data conversion
and truncation
errors.
False
-
-
False
Boolean. True
indicates to stop
when breaking
schema change is
detected.
False indicates to
drop the mirror
table and capture
instance.
source_oracle_ho
me
-
-
False
Can be set to a
specific Oracle
Home path or an
Oracle Home
Name that the
CDC instance will
use to connect to
Oracle.
cdc.xdbcdc_state
This table contains information about the persisted state of the Oracle CDC Instance. The capture state is used in
recovery and fail-over scenarios and for health monitoring.
The following table describes the cdc.xdbcdc_state table columns.
ITEM
DESCRIPTION
status
The current status code for the current Oracle CDC Instance.
The status describes the current state for the CDC.
sub_status
A second level status that provides additional information
about the current status.
ITEM
DESCRIPTION
active
A Boolean value that can be:
0: The Oracle CDC Instance process is not active.
1: The Oracle CDC Instance process is active.
error
A Boolean value that can be:
0: The Oracle CDC Instance process is not in an error state.
1: The Oracle CDC Instance is in an error state.
status_message
A string that provides a description of the error or status.
timestamp
The timestamp with the time (UTC) that the capture state was
last updated.
active_capture_node
The name of the host (the host can be a node on a cluster)
that is currently running the Oracle CDC Service and the
Oracle CDC Instance (which is processing the Oracle
transaction logs).
last_transaction_timestamp
A timestamp with the time (UTC) when the last transaction
that was written to the change tables.
last_change_timestamp
A timestamp with the time (UTC) when the most recent
change record was read from the source Oracle transaction
log. This timestamp helps to identify the current latency of the
CDC process.
transaction_log_head_cn
The most recent change number (CN) read from the Oracle
transaction log.
transaction_log_tail_cn
The change number (CN) on the Oracle transaction log where
the Oracle CDC Instance repositions to in case of a restart or
recovery.
current_cn
The most recent change number (CN) known to be in the
source database.
software_version
The internal version of the Oracle CDC Service.
completed_transactions
The number of transactions processed since the CDC was last
reset.
written_changes
The number of change records written to the SQL Server
change tables.
read_changes
The number of change records read from the source Oracle
transaction log.
staged_transactions
The number of currently active transactions that are staged in
the cdc.xdbcdc_staged_transactions table.
cdc.xdbcdc_trace
This table contains information about the operation of the CDC instance. Information stored in this table includes
error records, notable status changes, and trace records. Error information is also written to the Windows event log
to ensure that the information is available if the cdc.xcbcdc_trace table is unavailable.
The following table describes the cdc.xdbcdc_trace table columns.
ITEM
DESCRIPTION
timestamp
The exact UTC timestamp when the trace record was written.
type
Contains one of the following values.
ERROR
INFO
TRACE
node
The name of the node on which the record was written.
status
The status code that is used by the state table.
sub_status
The sub-status code that is used by the state table.
status_message
The status message that is used by the state table.
data
Additional data for cases when the error or trace record
contains a payload (for example, a corrupted log record).
cdc.xdbcdc_staged_transactions
This table stores change records for large or long-running transactions until the transaction commit or rollback
event is captured. The Oracle CDC Service orders captured log records by transaction commit time and then by
chronological order for each transaction. Log records for the same transaction are stored in memory until the
transaction ends and then are written to the target change table or discarded (in case of a rollback). Because there
is a limited amount of memory available, large transactions are written into the cdc.xdbcdc_staged_transactions
table until the transaction is complete. Transactions are also written to the staging table when they run for a long
time. Therefore, when the Oracle CDC Instance is restarted, the old changes do not need to be re-read from the
Oracle transaction logs.
The following table describes the cdc.xdbcdc_staged_transactions table columns.
ITEM
DESCRIPTION
transaction_id
The unique transaction identifier of the transaction being
staged.
seq_num
The number of xcbcdc_staged_transactions row for the
current transaction (starting with 0).
data_start_cn
The change number (CN) for the first change in the data in
this row.
data_end_cn
The change number (CN) for the last change in the data in this
row.
ITEM
DESCRIPTION
data
The staged changes for the transaction in the form of a BLOB.
See Also
Change Data Capture Designer for Oracle by Attunity
Change Data Capture Designer for Oracle by
Attunity F1 Help Reference
3/24/2017 • 1 min to read • Edit Online
The Change Data Capture Designer for Oracle by Attunity is used to create and manage Oracle CDC Instance. The
topics in this section explain how to carry out the available tasks in the CDC Designer Console.
What do you want to do?
Access the CDC Designer Console
Manage a CDC Service
Manage a CDC Instance
Use the New Instance Wizard (Or go directly to one of the following tasks)
Create the SQL Server Change Database
Connect to an Oracle Source Database
Connect to Oracle
Select Oracle Tables and Columns
Select Oracle Tables for Capturing Changes
Make Changes to the Tables Selected for Capturing Changes
Generate and Run the Supplemental Logging Script
Generate Mirror Tables and CDC Capture Instances
Finish
Edit Instance Properties(Or go directly to one of the following tasks)
Edit the Oracle Database Properties
Edit Tables
Add Tables to a CDC Instance
Edit the Table Properties
Review and Generate Supplemental Logging Scripts
Edit the Advanced Properties
Access the CDC Designer Console
3/24/2017 • 1 min to read • Edit Online
You can access the CDC Designer Console from the computer where you installed the console. For more
information about installation, see Installation.
When you open the CDC Designer Console, the Connect to SQL Server dialog box opens.
The SQL Server login that accesses the CDC Designer must have UPDATE permissions on the MSXDBCDC
database. In addition, the login must also have the dbcreator fixed-server role to create new Oracle CDC Instances.
It is recommended that the login also have SELECT access to the CDC databases being used or the user will not be
able to view the state of those databases.
Enter the following information in the Connect to SQL Server dialog box.
Server Name
Type the name of the server where the SQL Server is located.
Authentication
Select one of the following:
Windows Authentication
SQL Server Authentication: If you select this option, you must type the Login and Password for the user
in the SQL Server you are connecting to.
The login must have a database role that allows access to the MSXCDCDB database. It is recommended that
the login also have access to any additional databases being used or the user will not be able to view the
data in those databases.
Options
Click the arrow to view available options to be configured. You can choose to leave these options with their default
value. The available options are:
Connection Timeout
Type the time (in seconds) that the CDC Service for Oracle waits for a connection to the SQL Server before timing
out. The default value is 15.
Execution Timeout
Type the time (in seconds) that the Oracle CDC Windows Service waits for a command to execute before timing
out. The default value is 30.
Encrypt Connection
Select Encrypt Connection for communication between the Oracle CDC Service and the target SQL Server
instance using an encrypted connection.Advanced: Click Advanced and type any additional connection properties
into the Advanced Connection Properties dialog box, if necessary.
Advanced
Click Advanced and type any additional connection properties into the Advanced Connection Properties dialog
box, if necessary.
For information about the Advanced Connection Properties dialog box, see Advanced Connection Properties.
See Also
SQL Server Connection Required Permissions for the CDC Designer
Manage a CDC Service
3/24/2017 • 1 min to read • Edit Online
You can use the CDC Designer Console to view the services you created with the CDC Service Configuration
Console and manage all of the instances in the Oracle CDC Service.
Click the name of the service in the left pane to display information about the service and to manage it.
NOTE
You must first create a service using the CDC Service Configuration Console to add services to this list. For information on
how to create a service, see the online help provided with the CDC Service Configuration Console.
What you can do when you display the CDC service information
You can do the following when you display information about a service:
Create a new CDC instance for the selected service
Click New Oracle CDC Instance in the right pane to create a new instance for that service. The New Instance
wizard opens to create the instance. For more information about the New Instance wizard, see Use the New
Instance Wizard.
Start all CDC instances in the service
Click Start All Instances in the right pane to begin capturing data from all the defined instances in the service.
Stop all CDC instances in the service
Click Stop All Instances to stop the change data capture for all instances in the service.
See Also
How to Create the SQL Server Change Database Instance
How to Manage a CDC Service from the CDC Designer Console
Use the New Instance Wizard
Manage a CDC Instance
3/24/2017 • 5 min to read • Edit Online
You can use the CDC Designer Console to view information about the instances that you create and to manage the
operation of the instances.
Click on the name of an instance in the left pane to view the information about the instance.
NOTE
If you select a service in the left pane, the list of available instances is also displayed in the center of the CDC Designer
Console. If you select one of the instances in this section, you can carry out the tasks in the right pane; however, you will not
be able to view the information in the property tabs.
What you can do when you display the CDC Instance information
The following actions are carried out from the right pane:
Start
Click Start to start the capturing changes for the selected CDC instance.
Stop
Click Stop to stop capturing changes for the selected CDC instance. When you stop the CDC instance, the changes
that were captured to that point are not lost and are delivered when the CDC instance is resumed.
Reset
Click Reset to reset the CDC instance to its initial (empty) state. This option is available when the CDC instance is
stopped. All changes in the change tables and the CDC instance internal state are deleted. When the CDC instance
is started later, the change capture starts from that point in time and only includes transactions that started after
the CDC instance started.
Click OK in the confirmation dialog box to confirm that you want to reset the CDC instance and delete the changes
written to the change tables.
Delete
Click Delete to delete the CDC instance permanently. This option is available only when the CDC instance is
stopped.
Click OK in the confirmation dialog box to confirm that you want to delete the CDC instance.
Oracle Logging Script
Click this link to display the Oracle Logging script dialog box with the Oracle supplemental-logging script. For
information on what you can do in this dialog box, see Oracle Supplemental Logging Script.
NOTE
When you run the supplemental logging scripts, the Oracle Credentials for Running Script dialog box opens where you
provide a valid Oracle user name and password. For information on how to provide the proper Oracle credentials, see Oracle
Credentials for Running Script.
CDC Instance Deployment Script
Click this link to display the CDC Instance Deployment Script dialog box that displays the CDC instance
deployment script. For information about this dialog box, see CDC Instance Deployment Script.
Properties
Click this link to open the property editor. You edit the CDC instance configuration using the property editor. For
more information about editing the properties for a CDC instance, see Edit Instance Properties.
Viewer Tabs
The following Viewer tabs are available when you view information for the CDC instance. The information in these
tabs is read only.
Status
This tab provides information and statistics about the CDC instance current status. It contains the following
information.
Status: An icon that indicates the current status for the CDC instance. The following describes the statuses.
Error. The Oracle CDC Instance is not running because a
non-retryable error occurred. The following sub-statuses
are available:
Misconfigured: A configuration error occurred that
requires manual intervention.
Password Required: No password was set for the Oracle
CDC Instance or the password is not valid.
Unexpected. All other non-recoverable errors.
Running: The CDC Instance is running and is processing
change records. The following sub-statuses are available:
Idle: All change records have been processed and stored
in the target change tables. There are no more active
transactions.
Processing: There are change records being process that
are not yet written to the change tables.
Stopped: The CDC instance is not running. The stopped
status indicates that the CDC instance was stopped in a
normal manner.
Paused: The CDC instance is running but processing is
suspended because of a retryable error. The following
sub-statuses are available:
Disconnected: The connection to the source Oracle
database cannot be established. Processing resumes when
the connection is restored.
Storage: The storage is full. Processing resumes when
additional storage becomes available.
Logger: The logger is connected to Oracle but cannot
read the Oracle transaction logs due to a temporary
problem, for example, a required transaction log is not
available.
Detailed Status: The current substatus.
Status Message: More information about the current status.
Timestamp: The UTC time for when the CDC state was last read from the state table.
Currently Processing: You monitor the following information in this section.
Last transaction timestamp: The local time of the last transaction written to the change tables.
Last change timestamp: The local time of the most recent change seen by the Oracle CDC Instance
in the source Oracle database transaction logs. This provides information about the current latency of
the CDC instance in reading the Oracle transaction log.
Transaction log head CN: The most recent change number (CN) that was read from the Oracle
transaction log.
Transaction log tail CN: The change number for recovery or restarting the CDC instance. The
Oracle CDC instance will reposition to this location in the event of a re-start or any other type of
failure (including cluster failover).
Current CN: The last change number (SCN) seen in the source Oracle database (not the transaction
log).
Active transactions: The current number of source Oracle transactions that are being processed by
the Oracle CDC Instance and are not yet decided (commit/rollback).
Staged transactions: The current number source Oracle transactions that are staged to the
cdc.xdbcdc_staged_transactions table.
Counters: You monitor the following information in this section.
Completed transactions: The number of transactions completed since the CDC instance was last
reset. This does not include transactions that do not contain tables of interest.
Written changes: The number of changes written to the SQL Server change tables.
Oracle
Displays information about the CDC instance and its connection to the Oracle database. This tab is read
only. To edit these properties, right-click the instance in the left pane and select Properties or click
Properties in the right pane to open the <instance> Properties dialog box.
For information about these properties and how to edit them, see Edit the Oracle Database Properties.
Tables
Displays information about the tables included in the CDC instance. Column information is also available
here. This tab is read only. To edit these properties, right-click the instance in the left pane and select
Properties or click Properties in the right pane to open the <instance> Properties dialog box.
For information about these properties and how to edit them, see Edit Tables.
Advanced
Displays the advanced properties for the CDC instance and the property values. This tab is read only. To edit
these properties, right-click the instance in the left pane and select Properties or click Properties in the
right pane to open the <instance> Properties dialog box.
For information about these properties and how to edit them, see Edit the Advanced Properties.
See Also
How to Create the SQL Server Change Database Instance
How to View the CDC Instance Properties
How to Edit the CDC Instance Properties
Use the New Instance Wizard
Use the New Instance Wizard
3/24/2017 • 1 min to read • Edit Online
The New Instance wizard is used to create a new instance for a CDC service. You open the Create an Oracle CDC
Instance wizard from the CDC Designer Console. You can do the following in the New Instance wizard.
Create the SQL Server Change Database
Connect to an Oracle Source Database
Connect to Oracle
Select Oracle Tables and Columns
Select Oracle Tables for Capturing Changes
Make Changes to the Tables Selected for Capturing Changes
Generate and Run the Supplemental Logging Script
Generate Mirror Tables and CDC Capture Instances
Finish
See Also
How to Create the SQL Server Change Database Instance
Create the SQL Server Change Database
3/24/2017 • 1 min to read • Edit Online
When you start the New Instance wizard, the Create CDC Database page opens. Use the Create CDC Database page
to provide information about the new CDC instance and create a new Change database.
When you create a new CDC database it is enabled for SQL Server CDC and this enablement requires a login that is
a member of the sysadmin fixed-server role.
When a user that starts the Create an Oracle CDC Instance wizard is not a member of the sysadmin fixed-server
role, the Connect to SQL Server dialog box opens and requests the credentials for a member of the sysadmin role
to carry out the Enable the database for SQL Server CDC task. When the CDC database is created, the sysadmin
login is discarded and work resumes with the original SQL Server login used when the Oracle Designer Console
was entered.
IMPORTANT
For tasks other than Enable the database for SQL Server CDC of, the SQL Server login used for running the New Instance
Wizard must have the dbcreator fixed-server role and UPDATE permissions on the MSXDBCDC database.
For information on entering the data in the Connect to SQL Server dialog box, see SQL Server Connection for
Instance Creation.
Options
Oracle CDC Instance
Type the following information about the CDC instance you are creating.
Name: Type a name for the new service. This will also be the name of the new Change database.
Description: Type a description for the new instance to help you identify it. This is optional.
SQL Server Change Database
This section is used to create the database.
1. Change Database: The name of the new Change database. The name of the database is the same as the
name that you gave to the instance. This read-only field displays the full path to the database.
2. Create Database: Click Create Database to create the database.
To create the database, the login must have the
information.
sysasmin
server role. See the security note above for more
After you create the database, you can click Next to Connect to an Oracle Source Database.
See Also
How to Create the SQL Server Change Database Instance
The Oracle CDC Service
Connect to an Oracle Source Database
3/24/2017 • 1 min to read • Edit Online
Use the Oracle Source page to provide the information necessary to connect to the Oracle source database. The
CDC instance will read the redo logs of the Oracle database you are connected to.
Oracle Connect String
Enter the Oracle connect string to the computer with the Oracle database you are using. The connect string is
written in one of the following ways:
host[:port][/service name]
The connection string can also specify an Oracle Net connect descriptor, for example,
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=erp.contoso.com) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=orcl)))
If using a directory server or tnsnames, the connect string can be the name of the connection.
Oracle Log Mining Authentication
To enter the credentials for the Oracle database user that is authorized for log mining, select one of the following:
Windows Authentication: Select this to use the current Windows domain credentials. You can use this
option only if the Oracle database is configured to work with Windows authentication.
Oracle Authentication: If you select this option, you must type the User Name and Password for the user
in the Oracle database you are connecting to.
NOTE
A user must have the following privileges granted in the Oracle database to be a log-mining user.
SELECT on <any-captured-table>
SELECT ANY TRANSACTION
EXECUTE on DBMS LOGMNR
SELECT on V$LOGMNR CONTENTS
SELECT on V$ARCHIVED LOG
SELECT on V$LOG
SELECT on V$LOGFILE
SELECT on V$DATABASE
SELECT on V$THREAD
SELECT on ALL INDEXES
SELECT on ALL OBJECTS
SELECT on DBA OBJECTS
SELECT on ALL TABLES
If any of these privileges cannot be granted to a V$xxx, then grant them to the V_S$xxx.
Test Connection
Click Test Connection to determine whether you established a connection with the remote computer that has the
Oracle database. A dialog box opens to inform you whether the connection was successful.
IMPORTANT
Due to a known issue connection to the Oracle source database may fail if the CDC Designer is not run as an administrator.
If connection fails, close and restart the CDC Designer using the Run as administrator option.
After you finish entering information on this page, click Next to Select Oracle Tables and Columns.
See Also
How to Create the SQL Server Change Database Instance
Edit Instance Properties
Connect to Oracle
3/24/2017 • 1 min to read • Edit Online
When you add or edit the tables used in the CDC instance for the first time, you may be asked to connect to the
Oracle database. You should enter the credentials of an Oracle user who can access the schema of the tables to be
captured. Enter the following in this dialog box:
Authentication
Select one of the following:
Windows Authentication: Select this to use the current Windows domain credentials. You can use this
option only if the Oracle database is configured to work with Windows authentication.
Oracle Authentication: If you select this option, you must type the User Name and Password for the user
in the Oracle database you are connecting to.
See Also
Add Tables to a CDC Instance
Select Oracle Tables and Columns
3/24/2017 • 1 min to read • Edit Online
Use the Select Oracle Tables and Columns page to select the tables from the Oracle source database where
changes are captured. This page has the following elements:
Options
Table list
The table list has three columns:
Oracle Table Name: The name of the table, including the table schema.
Capture Instance: The name of the capture instance used to name instance-specific change data capture
objects. The capture instance cannot be NULL.
If not specified, the name is derived from the source schema name plus the source table name in the format
<schema-name>_<table-name> . The capture instance name cannot exceed 100 characters and must be unique
within the database.
You can click in any cell in this column to manually edit the capture_instance.
Security Role: The name of the database gating role used to control access to change data.
You can click in any cell in this column to manually edit the security_role.
Add Tables
Click Add Tables to open the Table Selection dialog box where you can Select Oracle Tables for Capturing
Changes.
Edit
Select a table from the list and select Edit to open the Properties dialog box for that table where you can
Make Changes to the Tables Selected for Capturing Changes.
Remove
Select a table from the list and click Remove to remove the table from the CDC instance.
After you Select Oracle Tables for Capturing Changes and/or Make Changes to the Tables Selected for
Capturing Changes using the correct dialog boxes, click Next to Generate and Run the Supplemental
Logging Script.
See Also
How to Create the SQL Server Change Database Instance
Edit Tables
Add Tables to a CDC Instance
Edit the Table Properties
Select Oracle Tables for Capturing Changes
3/24/2017 • 1 min to read • Edit Online
Use this dialog box to select the tables that are included in the CDC instance. The tables selected are added to the
list in the Select Tables and Columns page of the New Instance wizard. You can do the following in this dialog
box.
By default, no tables are included in the list of tables in this dialog box. You can select the check box at the top of
the check box column to select all of the tables or search for specific tables.
To search for specific tables
Enter search criteria as follows, and then click Search:
Schema: Select a database schema from the list. Only tables that have that schema will be included in the
list.
Table Name Pattern: Enter any string of characters. Only tables that include the character string entered
are displayed.
NOTE
You can enter criteria in one or both of these fields.
Display first 1000 matching tables: By default this check box is selected. It limits the display to the first
1000 matching tables. If you clear the check box, all tables that match the criteria are displayed. If there are
a large number of tables, it may take a long time to display the list.
To select tables to include in the CDC instance
Click the check box next to any of the tables you want to include, and then click Add. The tables are added
to the list in the New Instance Wizard Select Tables and Columns page.
Click Close to close the dialog box without adding any additional tables.
NOTE
If you select a table that includes a non-supported data type, you will see an error message and the table will not be
included.
See Also
How to Create the SQL Server Change Database Instance
Select Oracle Tables and Columns
Make Changes to the Tables Selected for Capturing
Changes
3/24/2017 • 1 min to read • Edit Online
In this dialog box, you can select specific columns from the selected table to capture changes from. You can also
edit the Security Role and Capture Instance information.
You can make the following changes to the tables you selected for capturing changes in this dialog box.
Make changes to which columns are included in the CDC instance:
Do one or both of the following:
Select the check box next to any additional column you want to include.
Clear the check box next to any column that you no longer want to include.
Change the data type for a specific column:
You can select a different data type for a specific column. You can only change the data type to a data type
that is compatible with the original data type.
To change the data type, click in the Data Type column and select a different data type. Only data types that
are compatible with the original data type are available.
NOTE
If no additional data types can be selected, the drop-down list is not available.
Change the Security Role
Type a new name or edit the name of the security gating role in the Security Role field.
Change or add a capture instance
In the Capture Instance field enter a name for the capture instance.
See Also
How to Create the SQL Server Change Database Instance
Select Oracle Tables and Columns
Generate and Run the Supplemental Logging Script
3/24/2017 • 1 min to read • Edit Online
Use the Set up Tables for Capturing Changes page to run a script on the Oracle source database that will set up
supplemental logging.
To run the supplemental logging scripts
Click Run Script to run the supplemental logging script on the tables defined for the CDC instance. This script
instructs the Oracle database to write all columns of interest to its transaction logs when logging UPDATE
operations to captured tables. This script is normally examined and executed by an Oracle system administrator.
You can also run the scripts manually using SQL * Plus.
To run the scripts manually
Click Copy to paste the script to the clipboard. Open SQL* Plus and go to the directory with your Oracle source
database. Paste the script into SQL*Plus to run it.
To save the supplemental logging script in a text file, click Save as and browse to the location where you want to
save the file. Give the file a name and click Save to save the file.
Click Next to Generate Mirror Tables and CDC Capture Instances.
See Also
How to Create the SQL Server Change Database Instance
Review and Generate Supplemental Logging Scripts
Generate Mirror Tables and CDC Capture Instances
3/24/2017 • 1 min to read • Edit Online
Use the Generate Mirror Tables page to generate the mirror tables for the tables you included in the CDC instance
Click Run to create the mirror tables. The progress for the creation of each table is displayed and a message is
displayed to let you know whether each mirror table is completed successfully or with errors. If any errors occur,
click Details to see a dialog box with an explanation of the error.
If any of the tables fail to be created, you can choose to continue or delete any tables that failed before continuing.
After you finish running the wizard, you can decide whether to fix the table in the Oracle source database or not
use it in the CDC instance. If you fix the table, you can add it when you Edit Tables.
Click Next to open the Finish page.
See Also
How to Create the SQL Server Change Database Instance
Finish
3/24/2017 • 1 min to read • Edit Online
The Finish page summarizes the wizard process. Click Finish to close the wizard and generate all of the tables you
defined in the Create CDC Instance wizard.
See Also
How to Create the SQL Server Change Database Instance
Use the New Instance Wizard
Edit Instance Properties
3/24/2017 • 1 min to read • Edit Online
Use the Properties editor to make changes to the CDC instance after you create the initial configurations. You can
do the following in the Properties editor.
Edit the Oracle Database Properties
Edit Tables
Add Tables to a CDC Instance
Edit the Table Properties
Review and Generate Supplemental Logging Scripts
Edit the Advanced Properties
To open the Properties editor
1. From the left pane in the CDC Designer Console, expand the service you are working with.
2. Select the CDC instance where you want to edit the properties.
3. From the Actions pane on the right of the CDC Designer Console, click Properties.
You can also right-click the service in the left pane and select Properties.
OR
1. From the left pane in the CDC Designer Console, select the Service you are working with.
2. From the list in the center of the CDC Designer Console, select the CDC instance where you want to edit the
properties.
3. From the Actions pane on the right of the CDC Designer Console, click Properties.
You can also right-click the service from the list in the center of the CDC Designer Console and select
Properties.
Edit the Oracle Database Properties
3/24/2017 • 1 min to read • Edit Online
Use the Oracle tab in the Properties editor to make changes to the description you provided in the Create CDC
database page in the New Instance wizard and to make changes to the Oracle Log Mining database connection
information.
The following describes the information in the Oracle tab.
Name
The name of the CDC Instance that you entered in the Create CDC Database page in the New Instance wizard. This
field is read only and you cannot edit this information.
Description
You can edit the description of the new instance or add one if you did not do so when creating the CDC Instance.
Oracle Connect String
The Oracle connect string to the computer with the Oracle database you are using. This field is read only and you
cannot edit this information. This is because some changes to the connect string may point the Oracle CDC
Instance to another Oracle database entirely, corrupting the CDC Instance state as stored in the
cdc.xdbcdc_config table. If minor changes are needed, you can change the connect string directly in the
configuration table using SQL Server Management Studio.
Oracle Log Mining Authentication
To enter the authentication credentials for the Oracle database that contains the log miner, select one of the
following under Authentication:
Windows Authentication: Select this to use the current Windows domain credentials. You can use this
option only if the Oracle database is configured to work with Windows authentication.
Oracle Authentication: If you select this option, you must type the User Name and Password for the
user in the Oracle database you are connecting to.
You can view the Oracle database properties in the viewer. When using the viewer the information is read
only. The viewer also includes a list of the captured columns in the table. For information on how to access
the viewer, see How to Manage a CDC Instance.
See Also
How to Manage a CDC Service from the CDC Designer Console
Connect to an Oracle Source Database
Connect to Oracle
Edit Tables
3/24/2017 • 1 min to read • Edit Online
Use the Tables tab to make changes to the tables and columns that you selected from the Oracle source database.
This tab has the following elements:
Table list
The table list has three columns:
Oracle Table Name: The name of the table, including the table schema.
Capture Instance: The name of the capture instance used to name instance-specific change data capture
objects. The capture instance cannot be NULL. If not specified, the name is derived from the source schema
name plus the source table name in the format <schema-name>_<table-name>. The capture instance name
cannot exceed 100 characters and must be unique within the database. You can click in any cell in this
column to manually edit the capture_instance.
Security Role: The name of the database role used to gain access to change data. You can click in any cell
in this column to manually edit the security_role.
Add Tables
Click Add Tables to open the Table Selection dialog box where you can Add Tables to a CDC Instance. The
first time this session that you access the Oracle database, you must Connect to Oracle.
Edit
Select a table from the list and select Edit to open the Properties dialog box for that table where you can
Edit the Table Properties.
NOTE
You cannot edit type mapping for tables that already have mirror tables. You can do this for new tables only.
Remove
Select a table from the list and click Remove to remove the table from the CDC instance.
See Also
How to Edit the CDC Instance Properties
Select Oracle Tables and Columns
Add Tables to a CDC Instance
3/24/2017 • 1 min to read • Edit Online
Use the Table Selection dialog box to add additional tables from the Oracle source to the CDC instance. The tables
selected are added to the list in the Tables tab of the Properties editor.
By default, no tables are included in the list of tables in this dialog box. You can select the (Select All) check box or
search for specific tables.
To search for specific tables
Enter search criteria as follows, and then click Search:
Schema: Select a database schema from the list. Only tables that have that schema will be included in the
list.
Table Name Pattern: Enter any string of characters. Only tables that include the character string entered
are displayed.
NOTE
You can enter criteria in one or both of these fields.
Display first 1000 matching tables: By default this check box is selected. It limits the display to the first
1000 matching tables. If you clear the check box, all tables that match the criteria are displayed. If there are
a large number of tables, it may take a long time to display the list.
To select tables to include in the CDC instance
Click the check box next to any of the tables you want to include, and then click Add. The tables are added
to the list in the New Instance Wizard Select Tables and Columns page.
Click Close to close the dialog box without adding any tables.
NOTE
If you select a table that includes a non-supported data type, you will see an error message and the table will not be
included.
NOTE
You can view the list of tables in the viewer. When using the viewer the information is read only. The viewer also includes a
list of the captured columns in the table. For information on how to access the viewer, see How to Manage a CDC Instance.
See Also
How to Edit the CDC Instance Properties
How to Manage a CDC Instance
Select Oracle Tables for Capturing Changes
Edit the Table Properties
3/24/2017 • 1 min to read • Edit Online
Use this dialog box to edit the specific columns from the selected table where changes are being captured. You can
also edit the Security Role and Capture Instance information.
To edit the columns to include in the CDC instance
1. Do one or both of the following:
Select the check box next to any additional column you want to include.
Clear the check box next to any column that you no longer want to include.
To edit the Security Role
1. Type a new name or edit the name of the security role in the Security Role field.
To create a new capture instance
1. In the Security Role section, Name field enter a name for the capture instance. By default, the name
entered in the field is the name of the current capture instance with _NEW added to the end of the name
(for example, old_instance_NEW).
2. Save the capture instance as one of the following:
New Capture Instance: In this case a new capture instance is saved and the old capture instance is
not deleted.
Note: You can have no more than two capture instances per table. If there are already two capture
instances, this option is not available.
Replace Existing: In this case the current capture instance is deleted and replaced by the capture
instance you created. If there are two capture instances defined for this table, you must select one to
replace.
Note: You can remove a capture instance from the list of tables in the Table tab.
After you finish entering the information in this dialog box, click OK to accept the changes.
See Also
How to Edit the CDC Instance Properties
Make Changes to the Tables Selected for Capturing Changes
Review and Generate Supplemental Logging Scripts
3/24/2017 • 1 min to read • Edit Online
Use the Scripts tab to run or re-run a script on the Oracle source database that sets up supplemental logging.
Before you run the scripts select one of the following:
Include changes in this session
Select this to run the script on any new table that was added to the CDC instance or on tables that were changed in
any way using the Properties editor.
NOTE
If no changes were made to the tables in the CDC instance, the Oracle supplemental logging script area will be empty.
Include all tables/capture instances
Select this to run the script on all of the tables and capture instances in the CDC instance.
After you select one of these options, run the supplemental logging script.
To run the supplemental logging scripts
1. Click Run Script to run the supplemental logging script on the tables defined for the CDC instance. This
script instructs the Oracle database to write all columns of interest to its transaction logs when logging
UPDATE operations to captured tables. This script is normally examined and executed by an Oracle system
administrator.
2. When you run the supplemental logging scripts, the Oracle Credentials for Running Script dialog box opens
where you provide a valid Oracle user name and password. For information on how to provide the proper
Oracle credentials, see Oracle Credentials for Running Script.
You can also run the scripts manually using SQL * Plus, if necessary.
To run the scripts manually
1. Click Copy to paste the script to the clipboard. Open SQL* Plus and go to the directory with your Oracle source
database. Paste the script into SQL*Plus to run it.
To save the supplemental logging script in a text file
1. Click Save as and browse to the location where you want to save the file.
2. Give the file a name and click Save to save the file.
See Also
How to Edit the CDC Instance Properties
Oracle Credentials for Running Script
Edit the Advanced Properties
3/24/2017 • 1 min to read • Edit Online
Use the Advanced tab to add special properties to the CDC instance.
To add advanced properties to the CDC instance
1. Type the name of the property in the Name column.
2. Type a valid value for the property in the Value column.
NOTE
You can view the Advanced Properties in the viewer. When using the viewer the information is read only. The viewer
also includes a list of the captured columns in the table.
For a description of the properties you can enter, see the available options table in cdc.xdbcdc_config.
See Also
How to Manage a CDC Instance
How to Edit the CDC Instance Properties
Change Data Capture Designer for Oracle by
Attunity How to Guide
3/24/2017 • 1 min to read • Edit Online
This section describes how to carry out tasks in the Change Data Capture Designer for Oracle by Attunity.
Learn how to use the Oracle CDC Designer Console
How to Manage a CDC Service from the CDC Designer Console
How to Create the SQL Server Change Database Instance
How to Manage a CDC Instance
How to Edit the CDC Instance Properties
How to View the CDC Instance Properties
How to Manage a CDC Service from the CDC
Designer Console
3/24/2017 • 1 min to read • Edit Online
This procedure describes how to use the CDC Designer Console to manage a CDC service.
To manage a CDC service from the CDC Designer Console
1. From the Start menu, select the CDC Designer Console.
2. In the left pane, expand Change Data Capture.
3. Select the service you want to manage.
Note: If there are no services listed in the CDC Designer Console, you must create new instances using the
CDC Service Configuration Console. For information about creating a new service, see the online help
included with the service configuration console.
4. You can carry out the following tasks for a CDC service:
Create a New CDC Instance
Start All Instances (that are included in the selected CDC service)
Stop All Instances (that are included in the selected CDC service)
For information about these tasks, see Manage a CDC Service.
Other CDC service tasks are carried out using the CDC Service Configuration Console. For information
about the tasks you can carry out in the service configuration console, see the online help included with the
service configuration console.
How to Create the SQL Server Change Database
Instance
3/24/2017 • 1 min to read • Edit Online
This procedure describes how to use the CDC Designer Console to create CDC instances.
To create CDC instances
1. From the Start menu, select the CDC Designer Console.
2. In the left pane, expand Change Data Capture.
3. Select the service where you want to create the new CDC instance.
4. From the Actions pane on the right side of the CDC Designer Console, select New Oracle CDC
Instance.
You can also right-click the service where you want to create the new CDC instance and select New
Oracle CDC Instance.
5. Enter the required information in the New Instance wizard to create the new instance. For information
about the information required for this wizard, see Use the New Instance Wizard.
How to Manage a CDC Instance
3/24/2017 • 1 min to read • Edit Online
This procedure describes how to use the CDC Designer Console to manage CDC instance operations at runtime.
To manage CDC instance operations
1. From the Start menu, select the CDC Designer Console.
2. In the left pane, expand Change Data Capture then expand the service that contains the instance you
want to view.
3. Select the name of an instance you want to work with.
4. From the Actions pane on the right side of the CDC Designer Console, click on the operation you want to
carry out.
You can also right-click the name of the instance in the left pane and select the operation you want to carry
out.
You can carry out the following tasks:
Start: To start capturing changes.
Stop: To stop capturing changes
Reset: Click Reset to reset the CDC instance to its initial (empty) state. This option is available when
the CDC instance is stopped. All changes in the change tables and the CDC instance internal state
are deleted. When the CDC instance is started later on, change capture will start from that point in
time and only includes transactions that started after the CDC instance started.
Delete: To delete the CDC instance.
Oracle Logging Script: Click Oracle Logging Script to display the Oracle Logging script dialog
box with the Oracle supplemental-logging script. For information on what you can do in this dialog
box, see Oracle Supplemental Logging Script.
Note: When you run the supplemental logging scripts, the Oracle Credentials for Running Script
dialog box opens where you provide a valid Oracle user name and password. For information on
how to provide the proper Oracle credentials, see Oracle Credentials for Running Script.
CDC Instance Deployment: To generate a deployment script for the CDC Instance. For
information about this dialog box, see CDC Instance Deployment Script.
For more information about these tasks, see Manage a CDC Instance.
You can also select Properties to edit the CDC instance configuration properties. For more information
about editing the CDC instance properties, see Edit Instance Properties.
How to Edit the CDC Instance Properties
3/24/2017 • 1 min to read • Edit Online
This procedure describes how to use the CDC Designer Console to edit the configuration properties for a CDC
instance.
To edit the CDC instance configuration properties
1. From the Start menu, select the CDC Designer Console.
2. In the left pane, expand Change Data Capture then expand the service that contains the instance with the
properties that you want to edit.
3. Select the name of the instance where you want to edit the properties.
4. From the Actions pane on the right side of the CDC Designer Console, click Properties.
You can also right-click the instance where you want to edit the properties and click Properties.
5. In the Properties editor, edit the properties in the following tabs:
Oracle: Use the Oracle tab in the Properties editor to make changes to the description you
provided in the Create CDC database page in the New Instance wizard and to make changes to the
Oracle Log Mining database connection information.
For information about what you can edit in this tab, see Edit the Oracle Database Properties.
Tables: Use the Tables tab to make changes to the tables and columns that you selected from the
Oracle source database.
For information about what you can edit in this tab, see Edit Edit Tables
Scripts: Use the Scripts tab to run or re-run a script on the Oracle source database that will set up
supplemental logging.
For information about what you can do in this tab, see Review and Generate Supplemental Logging
Scripts.
Advanced: Use the Advanced tab to add special properties to the CDC instance.
For information about what you can do in this tab, see Edit the Advanced Properties.
How to View the CDC Instance Properties
3/24/2017 • 1 min to read • Edit Online
This procedure describes how to use the CDC Designer Console to view information about the instances that you
create to help manage the operation of the instances.
To view information about a specific instance
1. From the Start menu, select the CDC Designer Console.
2. In the left pane, expand Change Data Capture then expand the service that contains the instance you want
to view.
3. Select the name of an instance you want to work with.
The information about the instance is displayed in the center part of the CDC Designer Console. It is divided
into four tabs. All of the tabs are read only.
Status
This tab displays the information about the current status of the change data capture for the instance. For
information about what is displayed in this tab, see the Viewer Tabs section in Manage a CDC Instance.
Oracle
This tab displays general information about the CDC instance and the Oracle source database. For
information about what is displayed in this tab, see Edit the Oracle Database Properties.
Tables
This tab displays information about the tables included in the change data capture. It also lists the columns
that are captured. For information about what is displayed in this tab, see Edit Tables.
Advanced
This tab displays a list of advanced properties that you define in the properties editor. For information about
what is displayed in this tab, see Edit the Advanced Properties.
SQL Server Connection for Instance Creation
3/24/2017 • 1 min to read • Edit Online
One of the first steps when creating an Oracle CDC Instance is the creation of a CDC database on the target SQL
Server instance. This CDC database is enabled for SQL Server CDC and this enablement requires a login that is a
member of the sysadmin fixed-server role.
When a user that starts the Create an Oracle CDC Instance wizard is not a member of the sysadmin fixed-server
role, the Connect to SQL Server dialog box opens and requests the credentials for a member of the sysadmin
role to carry out the Enable the database for SQL Server CDC task. When the CDC database is created, the
sysadmin login is discarded and work resumes with the original SQL Server login used when the Oracle Designer
Console was entered.
Task List
Enter the following information in the Connect to SQL Server dialog box.
Server Name
Type the name of the server where the SQL Server is located.
Authentication
Select one of the following:
Windows Authentication
SQL Server Authentication: If you select this option, you must type the Login and Password for the user
in the SQL Server you are connecting to.
The login must have a database role that allows access to the MSXCDCDB database. It is recommended that
the login also have access to any additional databases being used or the user will not be able to view the
data in those databases.
Options
Click the arrow to view available options to be configured. You can choose to leave these options with their
default value. The available options are:
Connection Timeout: Type the time (in seconds) that the CDC Service for Oracle waits for a connection to
the SQL Server before timing out. The default value is 15.
Execution Timeout: Type the time (in seconds) that the Oracle CDC Windows Service waits for a
command to execute before timing out. The default value is 30.
Encrypt Connection: Select Encrypt Connection for communication between the Oracle CDC Service
and the target SQL Server instance using an encrypted connection.
Advanced: Click Advanced and type any additional connection properties into the Advanced Connection
Properties dialog box, if necessary.
For information about the Advanced Connection Properties dialog box, see Advanced Connection
Properties.
See Also
Create the SQL Server Change Database
SQL Server Connection Required Permissions for the CDC Designer
Advanced Connection Properties
3/24/2017 • 1 min to read • Edit Online
Use the Advanced Connection Properties dialog box to add more connection parameters to the connection
string.
The additional connection parameters can be any ODBC connection parameter that is supported by the SQL Server
database instance you are using.
The parameters added using the Advanced Connection Properties dialog box are added to the parameters
selected in the Connect to SQL Server dialog box.
The last instance of each parameter provided overrides any previous instances of the parameter. Parameters
added using the Advanced Connection Parameters dialog box follow and replace the parameters provided in
the SQL Server Connection dialog box. For example, if the SQL Server Connection dialog box specifies
SERVER1 as the Server name, and the Additional Connection Parameters page contains ;SERVER=SERVER2,
the connection will be made to SERVER2.
Parameters added using the Advanced Connection Properties dialog box are passed as plain text.
IMPORTANT
Do not include login credentials in the Advanced Connection Properties dialog box. They will not be encrypted when they
are passed across the network.
See Also
Access the CDC Designer Console
SQL Server Connection for Instance Creation
Oracle Credentials for Running Script
3/24/2017 • 1 min to read • Edit Online
To run the Oracle supplemental logging script from the Oracle CDC Designer console, the program prompts you
for the credentials of the Oracle user who is running the script. To run this script, the Oracle user must have ALTER
TABLE permission for all the tables to be captured and SELECT permission on the DBA_LOG_GROUPS view.
Task List
Enter the following in this dialog box:
Authentication
Select one of the following:
Windows Authentication: Select this to use the current Windows domain credentials. You can use this
option only if the Oracle database is configured to work with Windows authentication.
Oracle Authentication: If you select this option, you must type the User Name and Password for the
user in the Source Oracle database you are connecting to.
See Also
How to Manage a CDC Instance
Review and Generate Supplemental Logging Scripts
Oracle Supplemental Logging Script
3/24/2017 • 1 min to read • Edit Online
This dialog box shows the script the Oracle supplemental logging script.
When you prepare a CDC Instance for use, the CDC Designer creates an Oracle SQL script that sets up
supplemental logging for the tables to be captured. The supplemental logging script tells Oracle that when a
specific table is updated, the change records it writes to the transaction log should contain the data of all columns
of interest, not just the columns that changed.
Depending on the Oracle DBA policies in your organization, running the supplemental logging script may require
a review and approval by an Oracle DBA.
Options
The following are the available options for how to execute the script.
Run Script
Runs the supplemental logging script on the tables defined for the CDC instance. To run this script, the Oracle user
must have ALTER TABLE permission for all the tables to be captured and SELECT permission on the
DBA_LOG_GROUPS view. In addition, the Oracle user must have the credentials for an Oracle database use with
the required permissions. You can let the program prompt you for the Oracle credentials and then have it run the
script.
Save As
Saves the script to a text file. This is used if an Oracle database administrator (DBA) needs to examine and execute
the supplemental logging script, the program lets you save the script to a text file that you can later send to the
Oracle DBA by email or by other means to be execute later (by using the SQL*Plus Oracle utility or other tool for
running scripts on an Oracle database).
Copy
Copies the script to the clipboard. When ready you can paste the script in any location you need in case an Oracle
database administrator (DBA) needs to examine and execute the supplemental logging script.
See Also
How to Manage a CDC Instance
Manage a CDC Instance
CDC Instance Deployment Script
3/24/2017 • 1 min to read • Edit Online
The CDC Instance Deployment Script dialog box that displays the CDC instance deployment script. This script can
be used to re-create the CDC database with all of its artifacts on a different SQL Server instance.
At the completion of the deployment script, you should make sure of the following:
The deployment script assumes that the target SQL Server instance was prepared for Oracle CDC, by using
the Oracle CDC Service Configuration Console or by using prepare script that program creates.
The part of the script that is used to enable the database for CDC needs to be run by a
sysadmin
.
The script does not preserve the Oracle log-mining password. This needs to be set manually after the script
is run and the Oracle CDC Service is started.
Select the following options in the CDC Instance Deployment Script dialog box.
Save As
Saves the script in a text file that you can save in any location you want. You can copy the file with the script
to any other server to run it there.
Copy
Copies the script to the clipboard. You can then paste the script into the SQL Server Management Studio or
any text editor to run the scripts later.
See Also
Prepare SQL Server for CDC
SQL Server Connection Required Permissions for the
CDC Designer
3/24/2017 • 1 min to read • Edit Online
The CDC Designer Console requires connection information to SQL Server to perform its tasks. This topic
describes the information that can be provided in the Connect to SQL Server dialog box for setting up the
connection to SQL Server.
The Connect to SQL Server dialog box opens when necessary, such as when the SQL Server connection
information is not available or when the information exists but the connection does not have the required
permissions.
The following table describes the various tasks where a connection to SQL Server is required and the required
permissions from the SQL Server login/user.
TASK
MINIMUM PERMISSIONS
View the list of CDC Services and Instances using the
associated SQL Server instance.
db_datareader
role on MSXDBCDC
Start/Stop CDC Instance(s)
db_datareader
and
View the CDC Instance status.
db_owner
Create a new Oracle CDC Instance database.
dbcreator
Create a new Oracle CDC Instance.
db_datareader
db_owner
Get deployment scripts.
Change configuration and add/remove capture instances.
See Also
Access the CDC Designer Console
SQL Server Connection for Instance Creation
fixed-server role
role on MSXDBCDC
role on the CDC database that was created.
and
db_datawriter
roles on MSXDBCDC
role on the relatedCDC database
db_datareader
db_owner
roles on MSXDBCDC
role on the CDC Instance database
db_datareader
db_owner
db_datawriter
and
db_datawriter
roles on MSXDBCDC
role on the related CDC database
Change Data Capture Service for Oracle by Attunity
4/29/2017 • 3 min to read • Edit Online
The CDC Service for Oracle is a Windows service that scans Oracle transaction logs and captures changes to Oracle
tables of interest into SQL Server change tables. The SQL change tables where the changes captured from Oracle
are stored are the same type of change tables used in the native SQL Server Change Data Capture feature. This
makes consuming these changes as easy as consuming changes made to SQL Server databases.
Installation
The Microsoft® Change Data Capture Designer and Service for Oracle by Attunity for Microsoft SQL Server® 2016
are part of the SQL Server 2016 Feature Pack. Download components of the Feature Pack from the SQL Server
2016 Feature Pack web page.
The CDC Service for Oracle can be installed on any supported Windows computer with access to the source Oracle
database(s) being captured and the target SQL Server instance where the target CDC database resides. The CDC
Service does not need a local installation of the Oracle database or the SQL Server database, only their supported
clients. For information about where to install the required database components, see Database Prerequisites in
this topic.
The installation of the SQL Server CDC Service for Oracle places the service configuration UI and the service
program in the selected location. The CDC Service for Oracle is configured separately using the Oracle CDC Service
Configuration Console. For more information on configuring the Oracle CDC Service, see Change Data Capture
Service for Oracle by Attunity F1 Help.
The CDC Service for Oracle can be installed on any supported Windows computer where the SQL Server 2016
Native Client is installed; it does not need to be installed on the same computer where the target SQL Server is
installed.
Supported Windows Environments
The Change Data Capture Service for Oracle by Attunity can run in the following Windows environments:
Windows Vista with Service Pack 2
Windows 7
Windows 8 and 8.1
Windows 10
Windows Server 2008 R2
Windows Server 2008 with Service Pack 2
Windows Server 2012
Database Prerequisites
To work with the CDC Service for Oracle you must install the SQL Server 2016 Native Client Oracle software. This
is a prerequisite that should be obtained from Oracle and installed before installing the Oracle CDC Service.
Additionally, you need to install the SQL Server ODBC Client using SQL Server Setup.
The CDC Service for Oracle supports the following versions:
Source Oracle Database
Oracle Database 11x, any version
Oracle Database 10x, any version
Oracle Database 10g Release 2: 10.2.0.1-10.2.0.5 (patchset as of April 2010)
Oracle Database 11g Release 1: 11.1.0.6-11.1.0.7 (patchset as of September 2008)
Oracle Database 11g Release 2: 11.2.0.1-11.2.0.3 (patchset as of September 2011)
Oracle Database 12c in classic installation. (Multitenant installation is not supported.)
Target SQL Server Database
For a list of features that are supported by the editions of SQL Server, see Features Supported by the Editions of
SQL Server 2016.
Running the Installation Program
To install the CDC Service for Oracle, open the installation wizard for the Windows platform you are using (32/64bit) and follow the directions on the screen.
Uninstalling Change Data Capture Service for Oracle by Attunity
You uninstall the CDC Service for Oracle using Control Panel, Programs and Features.
Uninstalling the CDC Service does not delete the SQL Server databases created. For complete removal of the tool,
you must remove the MSXDBCDC database and the specific CDC databases that were created in the target SQL
Server instance you worked with.
If you uninstall the CDC Service software from one machine and install it on another computer, you only need to
provide the following definitions:
Service account
SQL Server connect string and credentials
The master password
All the other definitions are stored in SQL Server and are available from the previous installation on another
computer.
In This Documentation
Change Data Capture Service for Oracle by Attunity System Architecture
The Oracle CDC Service
Change Data Capture Service for Oracle by Attunity F1 Help
Change Data Capture Service for Oracle by Attunity How to Guide
See Also
Working with the Oracle CDC Service
Change Data Capture Service for Oracle by Attunity
System Architecture
3/24/2017 • 4 min to read • Edit Online
The CDC Service for Oracle captures changes made to selected tables in one or more source Oracle databases into
SQL Server CDC databases located on a SQL Server instance. The following diagram shows the components that
make up the CDC Service for Oracle.
This figure illustrates four platforms that are used. In many cases, these platforms can overlap, however this
diagram represents a standard use case. For example, it makes sense that the Oracle and SQL Server databases
each run on a separate computer and are not shared with the Oracle CDC Service platform or the platform from
which the CDC Service is designed. The platforms illustrated in this figure are:
The Oracle CDC Service: This can be any supported Windows computer where the Oracle CDC Service is
installed and run. This platform may also represent a cluster node in a Microsoft failover cluster (high
availability configurations are discussed later in this document).
The Oracle Database: This can be any computer where a supported version of the Oracle database runs. This
includes any computer running Windows, Linux, or any other operating system supported by the version of
the Oracle database installed. Note that the diagram shows this platform in plural because a single Oracle
CDC Service can capture changes from multiple source Oracle databases.
The SQL Server: This can be any computer where the target SQL Server database (a supported SKU of SQL
Server 2016) runs. An Oracle CDC Service supports one SQL Server target where it stores change tables and
service configuration. The SQL Server Platform may also represent a clustered instance of SQL Server 2016
or a mirrored instance of SQL Server 2016 using the Always On feature.
The Oracle CDC Designer: This can be any supported Windows computer that can access the source Oracle
database and the target SQL Server database.
The following table describes the components that run on the four platforms described above.
COMPONENT/DESCRIPTION
COMPONENT CONSISTS OF:
Oracle CDC Service: This is a Windows service where the
change data capture activity takes place.
Oracle CDC Instance: A sub-process of the Oracle CDC Service
that handles change data capture activity for a single source
Oracle database (there is one Oracle CDC instance per source
Oracle database).
Oracle Log Reader: Reads Oracle transaction logs using the
Oracle Client.
Oracle Client: The Oracle Instant Client used for
communication with Oracle. This is a prerequisite that should
be obtained from Oracle and installed before installing the
Oracle CDC Service.
SQL Server Change Writer: This writes committed changes
made to the captured Oracle table to SQL Serverchange
tables. This component also maintains that capture state
within the target SQL Server database.
SQL ServerODBC Client: The Microsoft Native Client for SQL
Server 2016. This is a prerequisite component that should be
obtained from Microsoft and installed before installing the
Oracle CDC Service.
Oracle CDC Service Configuration: This is a Microsoft
Management Console snap-in that creates the Windows
service and sets up its configuration.
SQL Server Client: The SQL ADO.NET client that ships with
version 4 of the .NET framework.
Oracle Database: A source Oracle database from which
changes to select tables are captured.
Log Miner: An Oracle component through which the Oracle
transaction logs are read.
Transaction Logs: The online and archived Oracle Redo Logs
that are used by Oracle to ensure that the database can roll
back transactions and recover from failures (in this case, the
Oracle database must operate in archive-log mode).
SQL Server Instance: A SQL Server instance where the CDC
databases are hosted. This may be a clustered SQL Server
Instance (failover cluster) or a mirrored database (Always On).
The MSXDBCDC Database: A database where information
about the CDC Services working with this SQL Server Instance
is kept. It also keeps information on the Oracle CDC Instances
handled by each CDC Service. This database is created as part
of the CDC Service creation process.
The CDC Databases: SQL Server databases that store changes
made to one of the source Oracle databases. The CDC
Databases are enabled for SQL Server CDC so they have the
SQL Server CDC tables and functions, making it easy to
consume changes originating from Oracle.
COMPONENT/DESCRIPTION
COMPONENT CONSISTS OF:
Oracle CDC Designer: A Microsoft Management Console
snap-in that helps create Oracle CDC Instances. Use this to
select the tables and columns to be captured, provide Oracle
connection information and manage the life cycle of CDC
Instances.
SQL Server Client: The SQL ADO.NET client that ships with
version 4 of the .NET framework.
Oracle Client: The Oracle Instant Client used for
communication with Oracle. This is a prerequisite component
that should be obtained from Oracle and installed before
installing the Oracle CDC Service.
The Oracle CDC Service and its child Oracle CDC Instances can communicate only with the source Oracle
database(s) and the target SQL Server instance as clients. They do not actively listen on any network and other
protocols. The Oracle CDC Service monitors the CDC databases for configuration changes and updates its
operation based on the updated configuration.
The Oracle CDC Service
3/24/2017 • 6 min to read • Edit Online
The Oracle CDC Service is a Windows service running the program xdbcdcsvc.exe. The Oracle CDC Service can be
configured to run multiple Windows services on the same computer, each one with a different Windows service
name. Creating multiple Oracle CDC Windows services on a single computer is often done to achieve a better
separation between them, or when each needs to work with a different SQL Server instance.
An Oracle CDC Service is created using the Oracle CDC Service Configuration console or is defined through the
command-line interface built into the xdbcdcsvc.exe program. In both cases, each Oracle CDC Service created is
associated with a single SQL Server instance (which may be clustered or mirrored with Always On setup) and the
connection information (connect string and access credentials) are part of the service configuration.
When an Oracle CDC Service is started, it tries to connect to the SQL Server instance it is associated with, get the
list of Oracle CDC instances it needs to handle, and performs an initial environment validation. Errors during the
service startup and any start/stop information are always written to the Windows application event log. When a
connection to SQL Server is established, all errors and information messages are written to the dbo.xdbcdc_trace
table in the MSXDBCDC database of the SQL Server instance. One of the checks made during startup is verification
that no other Oracle CDC Service with the same name is currently working. If a service with the same name is
currently connected from a different computer, the Oracle CDC Service enters a wait loop, waiting for the other
service to disconnect before proceeding to handle the Oracle CDC work.
When the Oracle CDC Service passes all the startup verifications, it checks the dbo.xdbcdc_databases table in the
MSXDBCDC database for any enabled Oracle CDC Instances. For every enabled Oracle CDC Instance, the service
starts a sub-process to handle that Oracle CDC Instance.
When an Oracle CDC Instance starts, it accesses the SQL Server CDC database with the same name as the CDC
Instance and retrieves its state from the previous run. It also verifies that everything is running properly. It then
resumes processing changes; Reading the Oracle transaction logs and writing changes to the CDC database.
The Oracle CDC Service periodically monitors the dbo.xdbcdc_tables table in the MSXDBCDC database to
determine if there were any configuration changes to any of the Oracle CDC Instance configurations. If a change is
found, the Oracle CDC Service notifies the Oracle CDC Instance that it should check its configuration for changes.
Most configuration changes, such as adding and removing capture instances can be applied while the Oracle CDC
instance is enabled, others require the Oracle CDC Instance to be restarted.
When using the Oracle CDC Designer console, changes are automatically detected. When updating the Oracle CDC
configuration directly using SQL, the following procedure should be called for the Oracle CDC Service to notice the
configuration change:
DECLARE @dbname nvarchar(128) = 'HRcdc'
EXECUTE [MSXDBCDC].[dbo].[xdbcdc_update_config_version] @dbname
GO
The Oracle CDC Instance process updates its status in the system table cdc.xdbcdc_state and writes error
information to the cdc.xdbcdc_trace table. The xdbcdc_state table is useful for monitoring the state of the
Oracle CDC Instance. It provides up-to-date status, various counters (such as number of changes read from Oracle,
number of changes written to SQL Server, number of committed transaction written and the current number of inflight transactions) and latency indication.
The Oracle CDC Instance configuration is saved in the cdc.xdbcdc_config table, which is the table that the Oracle
CDC Designer console works with. Because the entire configuration of an Oracle CDC Instance is found in the
target SQL Server instance and CDC databases, it is possible to create SQL Server deployment scripts for an Oracle
CDC Instance. This is done using the Oracle CDC Service Configuration and Oracle CDC Designer consoles.
Security Considerations
The following describes the security requirements necessary to work with the CDC Service for Oracle.
Protection of Source Oracle Data
The Oracle CDC service does not require access to Oracle source data and is protected by ensuring that the logmining credentials do not give SELECT permission on customer Oracle tables.
Protection of Source Oracle Change Data
The Oracle CDC service is provided with log-mining credentials that let the service capture changes made to any
table in the Oracle database. Change data does not have the granular access permissions regular tables have,
therefore accessing change data bypasses the built-in Oracle data access controls.
Captured source Oracle tables have empty mirror tables with the same schema and table name in CDC database.
The captured data is stored in SQL Server capture instances and offer the same protection as is provided for
changes captured from SQL Server database. To gain access to the change data that is associated with a capture
instance, the user must be granted select access to all the captured columns of the associated mirror table. In
addition, if a gating role is specified when the capture instance is created, the caller must also be a member of the
specified gating role. Other general change data capture functions for accessing metadata is accessible to all
database users through the public role, although access to the returned metadata is usually also gated by using
select access to the underlying source tables, and by membership in any defined gating roles.
This means that users with the sysadmin fixed server role or the db_owner fixed database role have (by default)
full access to the captured data, and further access can be granted either through gating roles or by granting select
access to the captured columns.
Protection of Source Oracle Log Mining Credentials
The Oracle CDC service configuration, stored in the CDC database (in the cdc.xdbcdc_config table) includes the log
mining user name and its associated password.
The log mining password is stored encrypted by means of an asymmetric key with the fixed name
xdbcdc_asym_key that is automatically created with the following command:
USE [<cdc-database-name>]
CREATE ASYMMETRIC KEY xdbcdc_asym_key
WITH ALGORITHM = RSA_1024
ENCRYPTION BY PASSWORD = '<cdc-database-name><asym-key-password>'
If a different algorithm is used, this key can be dropped and a new one by the same name and encrypted by the
same password can be created.
The asymmetric key password is the master password that is saved in the registry under the path
HKLM\Software\Microsoft\XDBCDCSVC\. That key is accessible only to local administrators and to the Oracle
CDC Windows service account. The key contains an encrypted binary value AsymmetricKeyPassword that stored
the asymmetric key password. Access to this registry key is required to be able to access to the Oracle log mining
credentials.
To use the ENCRYPTION BY PASSWORD clause, the password must meet the Windows password policy
requirements for the computer running the SQL Server instance. This is done by selecting the asymmetric key
password according to that policy.
If the asymmetric key password is lost, the log mining credentials for each of the Oracle CDC instances must be
specified again in the Oracle CDC Service Designer.
The asymmetric key is automatically created in the CDC database when the CDC service detects an Oracle instance
CDC database that does not have this asymmetric key or when the key exists but the password does not match.
Oracle CDC Service Windows Service Account
The service account used with the Oracle CDC Windows service does not require any additional privileges. This
account must be able to use both the Oracle Native Client API and the SQL Server Native Client ODBC API. It also
needs to be able to access the service configuration key in the registry (this CDC Service Configuration console sets
up the ACL for that).
In This Section
High Availability Support
SQL Server Connection Required Permissions for the CDC Service
User Roles
Working with the Oracle CDC Service
See Also
How to Manage a Local CDC Service
Manage an Oracle CDC Service
High Availability Support
3/24/2017 • 1 min to read • Edit Online
The CDC Service for Oracle is designed for high availability. The following features provide part of the high
availability support:
The CDC Service for Oracle does not use any file resource (local or otherwise). Its entire state is stored in the
target SQL Server instance. This makes it easy to start the service on a different computer that uses the same
SQL Server instance if the computer the service runs on fails. To reduce recovery time, long or long-running
Oracle transactions are kept in a staging table in the target SQL Server, preventing the need to re-scan many
Oracle transaction logs following a failure (or service restart).
The CDC Service for Oracle can use clustered SQL Server instances so it can recover after the SQL Server
instance fails over to another cluster node. The Oracle CDC Service Computer Administrator only needs to
specify the connection information to the clustered SQL Server instance when creating an Oracle CDC
Service.
The CDC Service for Oracle can use the SQL Server 2016Always On database mirroring feature. This
support requires that the MSXDBCDC and all the CDC databases are in the same availability group. It also
requires the Oracle CDC Service Computer Administrator to specify the appropriate Always On connection
information to the SQL Server availability group (for example, the connection properties
Failover_Partner and Network=dbmssocn ). This allows the CDC service to automatically resume processing on
a secondary replication of the databases following a failover.
The CDC Service for Oracle can be configured as a generic service resource on a Windows failover cluster
(along with, or separate from SQL Server), making it simple to fail over and fall back CDC processing with
the cluster. To configure the CDC Service for Oracle as a resource in a failover cluster, the system
administrator must set the CDC Service for Oracle as a Generic Service Resource on each node on the
failover cluster.
The CDC Service for Oracle supports Oracle RAC, which allows it to communicate with the Oracle database
and process logs even when one of the Oracle RAC nodes is down.
SQL Server Connection Required Permissions for the
CDC Service
3/24/2017 • 1 min to read • Edit Online
The CDC Service Configuration Console requires connection information to SQL Server to perform their tasks. This
topic describes the information that can be provided in the Connect to SQL Server dialog box for setting up the
connection to SQL Server.
The Connect to SQL Server dialog box opens when necessary, such as when the SQL Server connection
information is not available or when the information exists but the connection does not have the required
permissions.
The following table describes the various tasks where a connection to SQL Server is required and the required
permissions from the SQL Server login/user.
TASK
MINIMUM PERMISSIONS
Prepare SQL Server Instance.
dbcreator
Create an Oracle CDC Service-SQL Server login for use by the
Oracle CDC service.
public
Create an Oracle CDC Service-login to use for registering the
new service in MSXDBCDC.
db_datareader
and
db_datawriter
roles on MSXDBCDC
Edit an Oracle CDC Service-login to use for updating the
registration of the service in MSXDBCDC.
db_datareader
and
db_datawriter
roles on MSXDBCDC
Delete an Oracle CDC Service-login to use for updating the
registration of the service in MSXDBCDC.
db_datareader
and
db_datawriter
roles on MSXDBCDC
See Also
Connection to SQL Server
Connection to SQL Server for Delete
fixed-server role
fixed-server role
User Roles
3/24/2017 • 7 min to read • Edit Online
This section describes the user roles for the Change Data Capture Service for Oracle by Attunity. The roles
described are SQL Server database roles, Windows roles, or Oracle database roles.
Windows User Roles
The following describes the Windows user roles used by the Oracle CDC Service.
Computer Administrator: Oracle CDC Service
The computer administrator is a Windows user responsible for creating and maintaining the CDC Service on the
computer. This user must belong to the group of local machine administrators.
The tasks performed by the Oracle CDC Service Computer Administrator include:
Installing the CDC Service for Oracle software
Creating an Oracle CDC Windows service
Setting up the CDC Service connection to the target SQL Server instance (connection string and credentials)
Ensuring that the CDC Service Master Password with which Oracle log mining credentials are protected
Deleting a CDC Service Windows service
Uninstalling the CDC Service for Oracle software
Maintaining the CDC Service for Oracle software (for example, installing updates)
Starting and stopping a CDC Service Windows service
When working with high-availability configurations, such as Microsoft failover clusters, the computer
administrator must have additional responsibilities and permissions such as:
Installation and maintenance of the CDC Service for Oracle software on all cluster nodes.
Defining generic cluster service resources for the CDC Service' Windows service on the various cluster
nodes.
Acting as the computer administrator authorized as an administrator on the computer where the CDC
Service for Oracle is installed. This person installs the CDC Service for Oracle and uses the CDC Service
Configuration Console to configure a CDC Service for Oracle on a local computer.
Service Account: Oracle CDC Service
This is Oracle CDC Service Windows Service Account is a Windows account used for running the Oracle CDC
Service (the Service Account).
The only required privilege necessary for the service account is to be able to use the Oracle client and the SQL
Server native client ODBC provider. This account does not need to access files unless required by specific providers
(for example, if the Oracle client connection string references Oracle database instances in a tnsnames.ora file,
then that file must be read-accessible to the service account).
When creating an Oracle CDC Service on Windows Vista or Windows Server 2008, the default service account is
the NETWORK SERVICE account.
On Windows 7, Windows Server 2008 R2 and later, the default service account is NT Service\.
When SQL Server runs on another machine or is a clustered SQL Server instance and there the service needs to
connect to the target SQL Server using Windows authentication, then the service account should be a domain
account.
SQL Server User Roles
The following describes the SQL Server user roles used by the Oracle CDC Service.
Oracle CDC Service Administrator
The CDC Service Administrator is a SQL Server user with full control over the Oracle CDC Service artifacts in the
target SQL Server instance. The CDC Service Administrator uses the Oracle CDC Designer Console to design Oracle
CDC Instances.
The CDC Service Administrator should be granted the SQL Server fixed server roles public and dbcreator.
The tasks performed by the CDC Service Administrator include:
Preparing a SQL Server instance to host Oracle CDC Instances (which are SQL Server databases). In this task,
a special database called MSXDBCDC is created in the SQL Server instance.
Creating an Oracle CDC Instance SQL Server database. Task includes enabling the newly created SQL Server
database for CDC, which requires a SQL Server system administrator (sysadmin).
Designing an Oracle CDC Instance. This task includes providing information about the source Oracle
database and captured tables, which requires an Oracle database administrator.
Maintaining the Oracle CDC Instance over time, which includes adding/removing capture instances and
updating configuration.
Enabling or disabling an Oracle CDC Instance.
Monitoring the state of an Oracle CDC Instance.
Troubleshooting issues that affect the Oracle CDC Instance.
The CDC Service Administrator is, at least initially, in the db_owner fixed database role for the SQL Server
CDC database associated with the Oracle CDC Instance. This gives the CDC Service Administrator access to
the change data stored in the CDC database. Once created, the db_owner role of the CDC database can be
assigned to a different user who can carry out all of the tasks listed above except for preparing a SQL Server
instance and creating another Oracle CDC Instance).
The CDC Service Administrator does not need to know the master password specified with the creation of
the Oracle CDC Windows service.
System Administrator
The SQL Server system administrator is a SQL Server user and should be granted the fixed server sysadmin role
on the SQL Server instance associated with the Oracle CDC Service(s).
There is only one Oracle CDC specific task that carried out with the SQL Server System Administrator and that is to
enable the SQL Server database for an Oracle CDC Instance for SQL Server CDC. This task is performed using the
Oracle CDC Designer console when creating a new Oracle CDC Instance.
Oracle CDC Service User
The SQL Server Oracle CDC Service user is a SQL Server login which is used by the Oracle CDC Service to perform
its work against the MSXDBCDC and all of the Oracle CDC Instances (CDC databases) handled by this service.
The SQL Server Oracle CDC Service user should be granted the following:
Member of the fixed database roles db_dlladmin, db_datareader, and db_datawriter for all CDC
databases handled by the server.
Member of the fixed database roles db_datareader and db_datawriter for the MSXDBCDC database.
Because the Oracle CDC Service uses a single SQL Server login to work with all CDC databases and the
MSXDBCDC database, this login should be mapped in all of these databases.
Oracle CDC Change Consumer
The Oracle CDC Change Consumer is a SQL Server user that consumes changes stored in the CDC tables in the
SQL Server Oracle CDC Instance database.
This user determines the user role that is required for accessing each of the CDC tables through the CDC functions
generated by the SQL Server CDC infrastructure. If no user role is specified when a capture instance is specified,
access to the changes is limited to the member of the db_owner fixed database role of the CDC database.
Oracle User Roles
The following describes the Oracle user roles used by the Oracle CDC Service.
Database Administrator (DBA )
The Oracle database administrator (DBA) is an Oracle database user. The tasks performed by the Oracle DBA
include:
Setting the source Oracle database to work in ARCHIVELOG mode.
Setting up a log mining user with the required permissions.
Setting supplemental logging for captured tables.
Helping to restore archived transaction log files no longer available so they can be processed.
The Oracle database administrator can get Oracle SQL scripts that need to run so they can be evaluated
before running them. The Oracle database administrator can also directly run Oracle SQL scripts from the
Oracle CDC Designer console.
If the Oracle database administrator chooses to use the Oracle CDC Designer console, administrator’s
credentials are not kept except for the context (dialog) in which they were used.
The Oracle database administrator works in coordination with the Oracle CDC Service administrator on the
configuration of the SQL Server Oracle CDC Instances.
Log Mining User
The Oracle Log Miner user is a special Oracle database user that is granted the required privileges for accessing
and processing the Oracle transaction logs.
The credentials for this user are stored in the SQL Server Oracle CDC Instance database using asymmetric key
encryption. They are accessible only to the Oracle CDC Service but not to the SQL Server Oracle CDC Instance
database owner.
The following list describes the required privileges of the log mining user should be granted:
SELECT on <any-captured-table>
SELECT ANY TRANSACTION
EXECUTE on DBMS_LOGMNR
SELECT on V$LOGMNR_CONTENTS
SELECT on V$ARCHIVED_LOG
SELECT on V$LOG
SELECT on V$LOGFILE
SELECT on V$DATABASE
SELECT on V$THREAD
SELECT on ALL_INDEXES
SELECT on ALL_OBJECTS
SELECT on DBA_OBJECTS
SELECT on ALL_TABLES
If any of these privileges cannot be granted to a V$xxx, then they should be granted to the V $xxx.
Schema User
The Oracle Schema User is an Oracle user with read access to the schema of the Oracle tables to be captured. This
user is necessary when working with the Oracle CDC Designer console to retrieve the list of Oracle schema, tables
to be captured and their columns, indexes and keys.
The credentials for this user are never stored. They are requested by the CDC Designer console each time they are
needed and they are kept for the rest of the UI sessions.
Working with the Oracle CDC Service
3/24/2017 • 12 min to read • Edit Online
This section describes some important concepts of the Oracle CDC Service. The concepts included in this section
are:
The MSXDBCDC Database
This section describes the tables that are included in this database and how it is important to CDC.
The CDC Databases
This section provides a brief description of the CDC databases. These databases are created using the Oracle
CDC Designer Console. See the documentation included with your installation of the CDC Designer Console
for more information about the CDC databases.
Using the Command Line to Configure the CDC Service
This section describes the command-line commands that can be used to configure the Oracle CDC Service.
The MSXDBCDC Database
The MSXDBCDC (Microsoft External-Database CDC) database is a special database that is required when using the
CDC Service for Oracle with a SQL Server instance.
The name of this database cannot be changed. If a database called MSXDBCDC exists on the host SQL Server
instance and contains tables other than those defined by the CDC Service for Oracle, the host SQL Server instance
cannot be used.
The main uses for this database are to:
Serve as a registry of Oracle CDC Services associated with a SQL Server instance. This information is used
for the service configuration and design components and to support coordination of multiple CDC services
by the same name on different nodes over which one is the active one.
Serve as a registry of the Oracle CDC instances contained in a SQL Server instance, the CDC service that
handles each instance, and the configuration version each uses. This information is equivalent to the
is_cdc_enabled column in the sys.databases table of the master database. The CDC service periodically
scans the dbo.xdbcdc_databases table to identify changes made to the CDC configuration or to the list of
captured instances.
Hold sysadmin-owned stored procedures that help create and maintain CDC instances. These are similar to
the system procedures that are used for the implementation of the SQL Server CDC feature.
Creating the MSXDBCDC Database
An MSXDBCDC database must be created before the Oracle CDC Service can be defined. You can create only one
MSXDBCDC database on a SQL Server instance. The MSXDBCDC database is created when you prepare a SQL
Server database for Oracle CDC. This can be done by using the Oracle CDC Service Configuration Console or by
running a creation script that is generated by the CDC Service Configuration Console.
The owner of this database is the Oracle CDC Service Administrator, who can control all of the Oracle CDC
instances hosted under the SQL Server instance.
See also:
How to Prepare SQL Server for CDC
The MSXDBCDC Database Tables
This section describes the following tables in the MSXDBCDC database.
dbo.xdbcdc_trace
dbo.xdbcdc_databases
dbo.xdbcdc_services
dbo.xdbcdc_trace
This table stores tracing information for the Oracle CDC Service. The information stored in this table includes
notable status changes and trace records.
The Oracle CDC Service writes error records and some of the information records to both the Windows event log
and the trace table. In some cases the trace table may not be accessible, in which case the error information is
accessible from the event log.
The following describes the items that are included in the dbo.xdbcdc_trace table.
ITEM
DESCRIPTION
timestamp
The exact UTC timestamp when the trace record was written.
type
Contains one of the following values.
ERROR
INFO
TRACE
node
The name of the node on which the record was written.
status
The status code that is used by the state table.
sub_status
The substatus code that is used by the state table.
status_message
The status message that is used by the state table.
source
The name of the Oracle CDC component that produced the
trace record.
text_data
Additional text data for cases when the error or trace record
contains a textual payload.
binary_data
Additional binary data for cases when the error or trace record
contains a binary payload.
The Oracle CDC instance will delete old trace table rows according to the change tables retention policy.
dbo.xdbcdc_databases
This table contains the names of CDC Service for Oracle CDC databases in the current SQL Server instance. Each
database corresponds to an Oracle CDC instance. The Oracle CDC Service uses this table to determine which
instances to start or stop and which instances to reconfigure.
The following table describes the items that are included in the dbo.xdbcdc_databases table.
ITEM
DESCRIPTION
name
The name of the Oracle database in the SQL Server instance.
config_version
The timestamp (UTC) for the last change in the corresponding
CDC database xdbcdc_config table or the timestamp (UTC)
for the current row in this table.
The UPDATE trigger enforces a value of GETUTCDATE() for
this item. config_version lets the CDC service identify the
CDC instance that needs to be checked for configuration
change or for enabling/disabling.
cdc_service_name
This item determines which Oracle CDC Service handles the
selected Oracle database.
enabled
Indicates whether the Oracle CDC instance is active (1) or
disabled (0). When the Oracle CDC Service starts only the
instances marked enable (1) are started.
Note: An Oracle CDC instance can become disabled due to an
error that is not retryable. In this case, the instance must be
restarted manually after the error is resolved.
dbo.xdbcdc_services
This table lists the CDC services associated with the host SQL Server instance. This table is used by the CDC
Designer Console to determine the list of CDC services that are configured for the local SQL Server instance. It is
also used by the CDC service to ensure that only one running Windows service handles a given Oracle CDC Service
name.
The following describes the capture state items that are included in the dbo.xdbcdc_databases table.
ITEM
DESCRIPTION
cdc_service_name
The name of the Oracle CDC Service (the Windows service
name).
cdc_service_sql_login
The name of the SQL Server login used by the Oracle CDC
Service to connect to the SQL Server instance. A new SQL
User named cdc_service is created and associated with this
login name and is then added as a member of the
db_ddladmin, db_datareader and db_datawriter fixed database
roles for each CDC database handled by the service.
ref_count
This item counts the number of machines where the same
Oracle CDC Service is installed. It gets incremented with each
addition of same-named Oracle CDC service, and it is
decremented when such a service is removed. When the
counter reaches zero, this row is deleted.
active_service_node
The name of the Windows node that currently handles the
CDC service. When the service is stopped correctly, this
column is set to null, indicating that there is no longer an
active service.
ITEM
DESCRIPTION
active_service_heartbeat
This item tracks the current CDC service to determine if it still
active.
This item is updated with the current database UTC
timestamp for the active CDC service at regular intervals. The
default interval is 30 seconds, however the interval is
configurable.
When a pending CDC service detects that the heartbeat was
not updated after the configured interval has passed, the
pending service attempts to take over the active CDC service
role.
options
This item specifies the secondary options, such as tracing or
tuning. It is written in the form of name[=value][; ]. The
options string uses the same semantics as the ODBC
connection string. If the option is Boolean (with a value of
yes/no), the value can include the name only.
trace has the following possible values.
true
on
false
off
<class name>[,class name>]
The default value is false.
service_heartbeat_interval is the time interval (in seconds)
for the service to update the active_service_heartbeat column.
The default value is 30. The maximum value is 3600.
service_config_polling_interval is the polling interval (in
seconds) for the CDC service to check for configuration
changes. The default value is 30. The maximum value is 3600.
sql_command_timeout is the command timeout that works
with the SQL Server. The default value is 1. The maximum
value is 3600.
The MSXDBCDC Database Stored Procedures
This section describes the following stored procedures in the MSXDBCDC database.
dbo.xcbcdc_reset_db(Database Name)
dbo.xdbcdc_disable_db(dbname)
dbo.xcbcdc_add_service(svcname,sqlusr)
dbo.xdbcdc_start(dbname)
dbo.xdbcdc_stop(dbname)
dbo.xcbcdc_reset_db(Database Name )
This procedure clears the data of an Oracle CDC instance. It is used:
To restart data capturing while disregarding previous data, for example following source database recovery
or following inactivity where some of the Oracle transaction logs are not available.
When there is a corruption in the CDC state (specifically in the any cdc.*tables data).
The dbo.xcbcdc_reset_db procedure performs the following tasks:
Stops the CDC instance (if active).
Truncates the change tables, the cdc_lsn_mapping table, and the cdc_ddl_history table.
Clears the cdc_xdbcdc_state table.
Clears the start_lsn column for each row of the cdc_change_table.
To use the dbo.xcbcdc_reset_db procedure, the user must be a member of the db_owner database role
for the CDC Instance database being named or else member of the sysadmin or serveradmin fixed server
role.
For more information about the CDC tables, see The CDC Databases in the help system in the CDC Designer
Console.
dbo.xdbcdc_disable_db(dbname )
The dbo.xcbcdc_disable_db procedure performs the following task:
Removes the entry for the selected CDC database in the MSXDBCDC.xdbcdc_databases table.
To use the dbo.xcbcdc_disable_db procedure, the user must be a member of the db_owner database role
for the CDC instance being named or a member of the sysadmin or serveradmin fixed server role.
For more information about the CDC tables, see The CDC Databases in the help system in the CDC Designer
Console.
dbo.xcbcdc_add_service (svcname,sqlusr)
The dbo.xcbcdc_add_service procedure adds an entry to the MSXDBCDC.xdbcdc_services table and adds an
increment of one to the ref_count column for the service name in the MSXDBCDC.xdbcdc_services table. When
the ref_count is 0, it deletes the row.
To use the dbo.xcbcdc_add_service<service name, username> procedure, the user must be a member of the
db_owner database role for the CDC instance database being named or a member of the sysadmin or
serveradmin fixed server role.
dbo.xdbcdc_start(dbname )
The dbo.xdbcdc_start procedure sends a start request to the CDC service that handles the selected CDC instance
to start the change processing.
To use the dbo.xcdcdc_start procedure, the user must be a member of the db_owner database role for the CDC
database or be a member of either the sysadmin or serveradmin roles for the SQL Server instance.
dbo.xdbcdc_stop(dbname )
The dbo.xdbcdc_stop procedure sends a stop request to the CDC service that handles the selected CDC instance
to stop the change processing.
To use the dbo.xcdcdc_stop procedure, the user must be a member of the db_owner database role for the CDC
database or be a member of either the sysadmin or serveradmin roles for the SQL Server instance.
The CDC Databases
Each Oracle CDC instance used in a CDC service is associated with a specific SQL Server database called the CDC
Database. This SQL Server database is hosted in the SQL Server instance associated with the Oracle CDC Service.
The CDC Database contains a special cdc schema. The Oracle CDC Service uses this schema with table names with
the prefix xdbcdc_. This schema is used for security and consistency purposes.
Both the Oracle CDC instance and the CDC databases are created using the Oracle CDC Designer Console. For
more information about the CDC databases, see the documentation included with your installation of the Oracle
CDC Designer Console.
Using the Command Line to Configure the CDC Service
You can operate the Oracle CDC Service program (xdbcdcsvc.exe) from the command line. The CDC service
program is a native 32-bit/64-bit Windows executable file.
See also
How to Use the CDC Service Command-Line Interface
Service Program Commands
The section describes the following commands that are used to configure the CDC service.
Config
Create
Delete
Config
Use Config to update an Oracle CDC Service configuration from a script. The command can be used to update
only specific parts of the CDC service configuration (for example, only the connection string without knowing the
asymmetric key password). The command must be run by a computer administrator. The following is an example
of the Config command.
"<path>xdbcdcsvc.exe" config
<cdc-service-name>
[connect= <sql-server-connection-string>]
[key= <asym-key-password>]
[svcacct= <windows-account> <windows-password>]
[sqlacct= <sql-username> <sql-password>]
Where:
cdc-service-name is the name of the CDC service to be updated. This is a required parameter.
sql-server-connection-string is the connect string to be updated. If the connect string contains spaces or quotes
then it must be wrapped in double-quotation marks ("). Embedded quotes are escaped by doubling the quotation
marks.
asym-key-password is the password to be updated.
windows-account, windows-password are the Windows account credentials for the service that is being
updated.
sql-username, sql-password are the SQL Server authentication credentials being updated. If sqlacct has both an
empty username and empty password, then the Oracle CDC Service connects to SQL Server using Windows
authentication.
Note: Any parameter that contains spaces or double quotes must be wrapped with double quotes ("). Embedded
double quotation marks must be doubled (for example to use "A#B" D as a password enter ""A#B"" D").
Create
Use Create to create an Oracle CDC Service from a script. The command must be run by a computer
administrator. The following is an example of the Create command:
"<path>xdbcdcsvc.exe" create
<cdc-service-name>
[connect= "<sql-server-connection-string>"]
[key= <asym-key-password>]
[svcacct <windows-account> <windows-password>]
[sqlacct <sql-username> <sql-password>]
Where:
cdc-service-name is the name of the newly created service. If there is already a service with this name, the
program returns an error. You should not use long names or names with spaces. The characters "/" and "\" are not
valid characters in a service name. This is a required parameter.
sql-server-connection-string is the connect string to use to connect to the SQL Server instance that is associated
with the new Oracle CDC Service.
asym-key-password is the password that protects the asymmetric key used for storing the source database logmining credentials.
windows-account, windows-password are the account name and password associated with the Oracle CDC
Service being created.
sql-username, sql-password are the SQL Server account name and password used to connect to the SQL Server
instance. If both of these parameters are empty, then CDC Service for Oracle connects to SQL Server using
Windows authentication.
Note: Any parameter that contains spaces or double quotes must be wrapped with double quotes ("). Embedded
double quotation marks must be doubled (for example to use "A#B" D as a password enter ""A#B"" D".
Delete
Use Delete to cleanly delete the Oracle CDC Service from a script. This command must be run by a computer
administrator. The following is an example of the Delete command.
"<path>xdbcdcsvc.exe" delete
<cdc-service-name>
Where:
cdc-service-name is the name of the CDC service to be deleted.
Note: Any parameter that contains spaces or double quotes must be wrapped with double quotes ("). Embedded
double quotation marks must be doubled (for example to use "A#B" D as a password enter ""A#B"" D").
See Also
How to Use the CDC Service Command-Line Interface
How to Prepare SQL Server for CDC
Change Data Capture Service for Oracle by Attunity
F1 Help
3/24/2017 • 1 min to read • Edit Online
You use the CDC Service Configuration Console to define a local Oracle CDC Service, update it, and delete it.
The topics in this section help provide information about the information you need to provide when using the CDC
Service Configuration Console.
In This Section
Connection to SQL Server
Connection to SQL Server for Delete
Create and Edit an Oracle CDC Service
Manage an Oracle CDC Service
Prepare SQL Server for CDC
Prepare SQL Server for Oracle CDC-View Script
Work with CDC Services
Connection to SQL Server
3/24/2017 • 1 min to read • Edit Online
When a login without a database role that includes write permission (for example the db_owner role) to the
MSXDBCDC database attempts to create an Oracle CDC instanced, the Connect to SQL Server dialog box is
displayed.
In this dialog box you must enter the credentials for a login that has write permission to the MSXDBCDC database,
such the db_owner database role to create the new Oracle CDC instance.
Enter the following information in the Connect to SQL Server dialog box.
Server Name
Type the name of the server where the SQL Server is located.
Authentication
Select one of the following:
Windows Authentication
SQL Server Authentication: If you select this option, you must type the Login and Password for the user
in the SQL Server you are connecting to.
Options
Click the arrow to view available options to be configured. You can choose to leave these options with their default
value. The available options are:
Connection Timeout: Type the time (in seconds) the program waits for the SQL Server connection to be
established before producing a timeout error. The default value is 15.
Execution Timeout: Type the time (in seconds) that the program waits for SQL command execution to
finish before producing a timeout error. The default value is 30.
Encrypt Connection: Select Encrypt Connection to ensure that the SQL Server connection that being
established is encrypted to guarantee privacy.
Advanced: Click Advanced and type any additional connection properties into the Advanced Connection
Properties dialog box, if necessary.
See Also
SQL Server Connection Required Permissions for the CDC Service
Connection to SQL Server for Delete
3/24/2017 • 1 min to read • Edit Online
When a login without a database role that includes write permission (for example the db_owner role) to the
MSXDBCDC database attempts to delete an Oracle CDC instance, the Connect to SQL Server dialog box is
displayed.
In this dialog box you must enter the credentials for a login that has write permission to the MSXDBCDC database,
such the db_owner database role to delete the Oracle CDC instance.
Enter the following information in the Connect to SQL Server dialog box.
Server Name
Type the name of the server where the SQL Server is located.
Authentication
Select one of the following:
Windows Authentication
SQL Server Authentication: If you select this option, you must type the Login and Password for the user
in the SQL Server you are connecting to.
Options
Click the arrow to view available options to be configured. You can choose to leave these options with their
default value. The available options are:
Connection Timeout: Type the time (in seconds) the program waits for the SQL Server connection to be
established before producing a timeout error. The default value is 15.
Execution Timeout: Type the time (in seconds) that the program waits for SQL command execution to
finish before producing a timeout error. The default value is 30.
Encrypt Connection: Select Encrypt Connection to ensure that the SQL Server connection that being
established is encrypted to guarantee privacy.
Advanced: Click Advanced and type any additional connection properties into the Advanced Connection
Properties dialog box, if necessary.
See Also
SQL Server Connection Required Permissions for the CDC Service
Create and Edit an Oracle CDC Service
3/24/2017 • 3 min to read • Edit Online
You create and edit a new Oracle CDC Windows Service from the CDC Service Configuration Console.
To create a new Oracle CDC Windows service, select Local CDC Services from the left pane, then click New
Service from the Actions pane. You can also right-click Local CDC Services and select New Service. The New
Oracle CDC Windows Service dialog box opens.
OR
To edit the CDC service properties, select the service that you want to edit the properties for and click Properties
from the Actions pane. You can also right-click the service you are working with and select Properties. The CDC
Service Properties dialog box opens.
Enter the following information in the New Oracle CDC Windows Service dialog box or the CDC Service Properties
dialog box.
** Service Name**
Type the name of the new Oracle CDC Windows Service. You should not use long names, if possible. The
characters / and \ cannot be used in the service name.
NOTE
This option is not available when editing the service. You cannot change the name of a Windows service that already exists.
Description
Type a description of the service to help identify it.
Service Account
Select one of the following to determine under which account to run the service:
Local System Account
This is not recommended because it gives too many permissions to the service.
This Account
On Windows Vista or Windows Server 2008, the default service account is the NETWORK SERVICE account.
On Windows 7, Windows Server 2008 R2 and later, the default service account is NT Service\.
Using these accounts lets you work without using passwords because a password is not necessary for these
accounts. In addition these accounts provide only the necessary permissions required for the Oracle CDC
Service to run.
You can use a local or domain Windows account for the service account. In this case, you must enter the
Password for that account. This account can be for the local host or a domain account. Be sure to update
the password when it is changed using Local Services in the Windows Control Panel.
Server name: Select the target SQL Server instance to connect to (for example, \\\). The server instance last
connected to is displayed by default.
Authentication
Select one of the following:
Windows Authentication: If you select this option, the Oracle CDC service connects to the target SQL
Server instance using the service account identity. If the SQL Server instance is running on a different
computer, Windows Authentication must be used with domain accounts.
SQL Server Authentication: If you select this option, you must type the User Name and Password for the
SQL Server login you want to use. The Oracle CDC service uses these credentials when connecting to the
target SQL Server instance.
The SQL Server login used by the Oracle CDC Service only needs to be a member of the public fixed-server
role, no other privileges are needed. Once new Oracle CDC Instances are added, that login will gain
db_owner access to the associated SQL Server CDC databases.
To create the Oracle CDC Windows Service definition, the program needs update access to the MSXDBCDC
database in the associated SQL Server instance. When you click OK, a dialog box prompts the user to enter
a SQL Server login with an update access to the MSXDBCDC database.
For information about the data you must type into the Connect to SQL Server dialog box, see Connection to
SQL Server.
Options
Click the arrow to view available options to be configured. You can choose to leave these options with their
default value. The available options are:
Connection Timeout: Type the time (in seconds) that the CDC Service for Oracle waits for a connection to
the SQL Server before timing out. The default value is 15.
Execution Timeout: Type the time (in seconds) that the Oracle CDC Windows Service waits for a
command to execute before timing out. The default value is 30.
Encrypt Connection: Select Encrypt Connection for communication between the Oracle CDC Service
and the target SQL Server instance using an encrypted connection.
Advanced: Type any additional connection properties, if necessary.
Master Password
Enter a password to be used by the Oracle CDC Windows Service to protect the Oracle log-mining
credentials.
The same master password must also be used when other instances of the same service are configured on
other nodes on a cluster in high-availability configuration. If you lose or modify the master password, all
log mining passwords stored in Oracle CDC Instance databases must be re-entered using the CDC Designer
console.
See Also
How to Create and Edit a CDC Service
Manage an Oracle CDC Service
3/24/2017 • 1 min to read • Edit Online
You can use the CDC Service Configuration Console to manage a specific CDC Service.
To select the CDC service you want to work with
1. From the left pane in the CDC Service Configuration Console, expand Local CDC Services.
2. Select the CDC service you want to work with.
You can also right-click the CDC service you want to work with and select the desired action. See What can
you do with a CDC Service.
OR
3. Select Local CDC Services from the left pane in the CDC Service Configuration Console.
4. From the middle section of the CDC Service Configuration Console, select the service you want to work
with.
You can also right-click the CDC service you want to work with and select the desired action. See What can
you do with a CDC Service.
What can you do with a CDC Service
You can carry out the following actions when working with a CDC service.
Delete the service
From the Actions pane on the right side of the CDC Service Configuration Console, click Delete to delete the
service.
You can also right-click the CDC service you want to delete and select Delete.
Note: If the service is running when deleting the service, the service is stopped before being deleted.
To delete the Oracle CDC Windows Service definition, the program needs update access to the MSXDBCDC
database in the associated SQL Server instance. When you click OK to delete the service, the program attempts to
delete the Oracle CDC Service registration in the MSXDBCDC database. If the program cannot delete the Oracle
CDC Service registration because it does not have the proper permissions, it prompts the user to enter a SQL
Server login with update permissions to the MSXDBCDC database.
For information about the data you must enter in the Connect to SQL Server dialog box, see Connection to SQL
Server for Delete.
Edit the CDC Service Properties
From the Actions pane on the right side of the CDC Service Configuration Console, click Properties.
You can also right-click the CDC service where you want to edit the properties and select Properties.
See Also
How to Manage a Local CDC Service
Prepare SQL Server for CDC
3/24/2017 • 1 min to read • Edit Online
The Oracle CDC service requires all target SQL Server instances to contain the MSXDBCDC database. You create
this database using the Prepare SQL Server action in the CDC Service Configuration Console. This creates a special
script that is run to create the required tables, stored procedures, and other required artifacts for this database.
This task is done one time only for each target SQL Server instance.
For more information about the MSXDBCDC database, see The MSXDBCDC Database.
In the CDC Service Configuration Console, click Prepare SQL Server. If this option is not available, make sure that
Local CDC Services is selected in the left pane of the console.
Options
Server Name
Type the name of the server where the SQL Server is located.
Authentication
Select one of the following:
Windows Authentication
SQL Server Authentication: If you select this option, you must type the User Name and Password for
the user in the SQL Server you are connecting to.
To prepare the SQL Server instance for Oracle CDC, the login must have write permission to the
MSXDBCDC database. Enter the credentials for a login that has write permission to the MSXDBCDC
database, such as a member of the sysasmin role.
Options
Click the arrow to view available options to be configured. You can choose to leave these options with their default
value. The available options are:
Connection Timeout: Type the time (in seconds) that the CDC Service for Oracle waits for a connection to
the SQL Server before timing out. The default value is 15.
Execution Timeout: Type the time (in seconds) that the Oracle CDC Windows Service waits for a
command to execute before timing out. The default value is 30.
Encrypt Connection: Select Encrypt Connection for communication between the Oracle CDC Service
and the target SQL Server instance using an encrypted connection.
Advanced: Type any additional connection properties, if necessary.
View Script
Click View Script to view a read-only version of the setup script. A SQL Server system administrator can copy this
script into the SQL Server Management Console to edit it, if necessary. For more information about the Prepare
SQL Server Script, see Prepare SQL Server for Oracle CDC-View Script.
See Also
How to Work with CDC Services
How to Prepare SQL Server for CDC
Prepare SQL Server for Oracle CDC-View Script
3/24/2017 • 1 min to read • Edit Online
This dialog box shows the Prepare SQL script that creates the MSXDBCDC database. This database is must be on a
SQL Server instance for it to be used with Oracle CDC for SQL Server.
Do the following in the Prepare SQL Server Script dialog box.
Save As
Saves the script in a text file that you can save in any location you want. You can then run the scripts at a later time
by pasting the script into the SQL Server Management Studio.
Copy
Copies the script to the clipboard. You can then paste the script into the SQL Server Management Studio to run
them and create the MSXDBCDC database.
See Also
Prepare SQL Server for CDC
Work with CDC Services
3/24/2017 • 1 min to read • Edit Online
You can use the CDC Service Configuration Console to create a new CDC service and to prepare a SQL Server
database for CDC.
Options
Prepare SQL Server
Select this option from the Actions pane on the right side of the CDC Service Configuration Console.
You can also right-click Local CDC Services and select Prepare SQL Server.
The Preparing SQL Server Instance for Oracle CDC dialog box opens.
For information on how to use this dialog box, see Prepare SQL Server for CDC. For information on how to enable
a SQL Server instance for CDC, see How to Prepare SQL Server for CDC.
Create a new CDC service
Click New Service from the Actions pane on the right side of the CDC Service Configuration Console.
You can also right-click Local CDC Services and select New Service.
The New Oracle CDC Service dialog box opens.
See Also
How to Work with CDC Services
Create and Edit an Oracle CDC Service
Change Data Capture Service for Oracle by Attunity
How to Guide
3/24/2017 • 1 min to read • Edit Online
This section describes how to carry out tasks in the CDC Service Configuration Console.
Learn how to use the CDC Service for Oracle Service Configuration UI
How to Create and Edit a CDC Service
How to Manage a Local CDC Service
How to Prepare SQL Server for CDC
How to Use the CDC Service Command-Line Interface
How to Work with CDC Services
How to Create and Edit a CDC Service
3/24/2017 • 2 min to read • Edit Online
These procedures describe how to create and edit a new Oracle CDC Service from the CDC Service Configuration
Console.
This procedure requires a Windows user with administrator privileges on the computer where the Oracle CDC
service is configured.
To create a new CDC service
1. From the Start menu, select CDC Service Configuration for Oracle.
2. From the left pane, right click Local CDC Services and select New Service
You can also click New Service from the Actions pane.
3. Type or enter the required information in the New Oracle CDC Service dialog box. See Create and Edit an
Oracle CDC Service for information on how to enter information in the New Oracle CDC Service dialog box.
The SQL Server login provided in the New Oracle CDC Service dialog box is used by the Oracle CDC Service
when the service runs. This login only needs to be a member of the public fixed-server role, no other
privileges are needed. Once new Oracle CDC Instances are added, that login receives db_owner access to
the associated SQL Server CDC databases.
4. When you finish entering the required information, click OK.
To create the Oracle CDC Windows Service definition, the program needs update access to the MSXDBCDC
database in the associated SQL Server instance. When you click OK, a dialog box prompts the user to enter
a SQL Server login with an update access to the MSXDBCDC database.
For information about the data you must type into the Connect to SQL Server dialog box, see Connection to
SQL Server.
5. Click OK to close the New Oracle CDC Service dialog box.
To edit a CDC service
1. From the Start menu, select CDC Service Configuration for Oracle.
2. From the left pane, select Local CDC Services then right-click the local service you want to edit and select
Properties.
You can also select the service you are working with in the middle and then from the Actions pane, click
Properties.
3. Type or enter the required information in the CDC Service Properties dialog box. See Create and Edit an
Oracle CDC Service for information on how to enter information in the CDC Service Properties dialog box.
4. When you finish entering the required information, Click OK, the Connect to SQL Server dialog box opens.
When a login without write permission to the MSXDBDCDC database attempts to create a new Oracle CDC
instance an error message is displayed. Click OK in that dialog box to display the Connect to SQL Server
dialog box. In this dialog box you must enter the credentials for a login that has write permission to the
MSXDBCDC database, such the db_owner database role.
For information about the data you must type into the Connect to SQL Server dialog box, see Connection to
SQL Server.
5. Click OK in the Connect to Oracle dialog box. Both dialog boxes close and the service is updated and
registered.
See Also
Change Data Capture Designer for Oracle by Attunity
Create and Edit an Oracle CDC Service
How to Manage a Local CDC Service
3/24/2017 • 1 min to read • Edit Online
This procedure describes how to use the CDC Service Configuration Console to manage specific CDC services.
To manage a specific CDC Service
1. From the Start menu, select the CDC Service Configuration for Oracle.
2. From the left pane in the CDC Service Configuration Console, expand Local CDC Services.
3. Select the CDC service you want to work with.
You can also right-click the CDC service you want to work with and select the desired action.
OR
Select Local CDC Services from the left pane in the CDC Service Configuration Console then select the
service you want to work with from the middle section of the CDC Service Configuration Console.
You can also right-click the CDC service you want to work with and select the desired action.
4. You can carry out the following tasks when working with a CDC service.
Delete the service
From the Actions pane on the right side of the CDC Service Configuration Console, click Delete to
delete the service.
You can also right-click the CDC service you want to delete and select Delete.
Note: If the service is running when deleting the service, the service is stopped before being deleted.
To delete an Oracle CDC Windows Service definition, the program needs update access to the
MSXDBCDC database in the associated SQL Server instance. When you click OK to delete the service,
the program attempts to delete the Oracle CDC Service registration in the MSXDBCDC database. If it
fails due to lack of permissions, a dialog box is displayed to prompt the user to enter a SQL Server
login with an update access to the MSXDBCDC database.
For information about the data you must enter in the Connect to SQL Server dialog box, see Manage
an Oracle CDC Service and Connection to SQL Server for Delete.
Edit the CDC Service Properties
From the Actions pane on the right side of the CDC Service Configuration Console, click Properties.
You can also right-click the CDC service where you want to edit the properties and select Properties.
See Also
Manage an Oracle CDC Service
How to Prepare SQL Server for CDC
3/24/2017 • 1 min to read • Edit Online
The Oracle CDC service requires all target SQL Server instances to contain the MSXDBCDC database. You create
this database using the Prepare SQL Server action in the CDC Service Configuration Console.This task is done one
time only for each target SQL Server instance.
The following describes how to prepare a SQL Server database for Oracle Change Data Capture using the CDC
Service Configuration Console. This process creates the MSXDBCDC database and defines the required tables,
stored procedures, and other required artifacts.
Preparing the SQL Server for Oracle CDC is done by the Oracle CDC Service Administrator. For more information
about the CDC Service Administrator role, see User Roles.
To enable SQL Server for CDC
1. From the Start menu, select the CDC Service Configuration for Oracle.
2. From the left pane, select Local CDC Services then from the Actions pane, click Prepare SQL Server.
You can also right-click Local CDC Services and select Prepare SQL Server.
3. Enter the required information in the Preparing SQL Server Instance for Oracle CDC dialog box. For
information on how to enter the required information into this dialog box, see Prepare SQL Server for CDC.
To Prepare the SQL Server instance for Oracle CDC, the login must have write permission to the
MSXDBCDC database. Enter the credentials for a login that has write permission to the MSXDBCDC
database, such as a member of the sysasmin role.
Note: You can click View Script to view a read-only version of the setup script. A SQL Server system
administrator can copy this script into the SQL Server Management Console to edit and execute it, if
necessary.
See Also
Prepare SQL Server for CDC
How to Use the CDC Service Command-Line
Interface
3/24/2017 • 1 min to read • Edit Online
The Oracle CDC service program, xdbcdcsvc.exe, normally runs the Oracle CDC Windows service but it can be
invoked directly from the command line to create, or delete an Oracle CDC Windows service.
To use the command line
1. From the Start menu, open the command-line console. Type cmd in the run or search box to open the
console.
2. At the command prompt, type cd and the full path to the folder where the CDC Service for Oracle is
installed.
3. Type the command that you need to carry out one of the possible tasks.
How to Work with CDC Services
3/24/2017 • 2 min to read • Edit Online
This procedure describes how to use the CDC Service Configuration Console to prepare a SQL Server instance to
work with Oracle CDC Services and to create a new CDC service.
To work with CDC services
1. From the Start menu, select the CDC Service Configuration for Oracle.
2. From the left pane, select Local CDC Services (the root level).
3. You carry out the one or both of the following tasks:
Prepare SQL Server
Select this option from the Actions pane on the right side of the CDC Service Configuration Console.
You can also right-click Local CDC Services and select Prepare SQL Server.
The Preparing SQL Server Instance for Oracle CDC dialog box opens.
To prepare the SQL Server instance for Oracle CDC services, the login must have a SQL Server login
with the dbcreator fixed server role. This login is used to create the MSXDBCDC database that is
required for adding Oracle CDC Services and, later on, Oracle CDC Instances.
For information on how to use this dialog box, see Prepare SQL Server for CDC. For information on
how to enable a SQL Server instance for CDC, see How to Prepare SQL Server for CDC.
Create a new CDC service
Click New Service from the Actions pane on the right side of the CDC Service Configuration
Console.
You can also right-Click Local CDC Services and select New Service.
The New Oracle CDC Service dialog box opens.
For information on how to use this dialog box, see Create and Edit an Oracle CDC Service. For
information on how to create or edit a CDC service, see How to Create and Edit a CDC Service.
The SQL Server login used by the Oracle CDC Service only needs to be a member of the public
fixed-server role, no other privileges are needed. However, to create the Oracle CDC Service, the
login must have write permission to the MSXDBCDC database, for example the db_owner database
role must be assigned to the login. When a login without write permission to the MSXDBDCDC
database attempts to create a new Oracle CDC instance an error message is displayed. Click OK in
that dialog box to display the Connect to SQL Server dialog box.
For information on how to enter the credentials for a login that has write permission to the
MSXDBCDC database, such the db_owner database role, see Create and Edit an Oracle CDC Service
and Connection to SQL Server.
See Also
Work with CDC Services