technical white paper Sybase Adaptive Server Enterprise Data Transfer Utility www.sybase.com
Contents 1. Executive Summary.......................................................................................................... 1 2. Feature Offerings............................................................................................................. 1 3. The Basics of DTU............................................................................................................ 1 3.1 Table Eligibility for Incremental Transfer.................................................................................. 1 3.2 Physical Changes in the Database........................................................................................ 1 3.3 Supported Output Formats.............................................................................................. 2 3.4 The transfer table Command.................................................................................... 3 4. Setting Up to Use DTU........................................................................................................ 3 5. Considerations for the Receiving Table........................................................................................ 4 6. The transfer table to Command.................................................................................. 5 6.1 Options Controlling the Overall Command...............................................................................6 6.2 Options Controlling Output for IQ........................................................................................ 7 6.3 Options Controlling Character-Coded Output............................................................................ 8 7. Interaction with Other Ongoing Work........................................................................................ 8 7.1 Interaction with Transactions............................................................................................ 8 7.2 Interaction with Other Transfers.........................................................................................9 8. Tracking Transfers............................................................................................................9 9. File Handling for Transfer.................................................................................................... 10 10. Resending a Transfer......................................................................................................... 10 11. Transfer Speed Tests..........................................................................................................11 12. DTU, bcp, and Replication Server..............................................................................................11 13. License Requirements....................................................................................................... 12 14. Security Restrictions......................................................................................................... 12
Executive Summary Sharing data between applications requires sending data, often repeatedly, from one application to the other(s). Selecting all data repeatedly from a given table and sending it to an outside receiver can potentially send huge volumes of repeated data, most of which is not necessary because it already exists at the receiving application. This slows down processing speed and requires a lot of work at the receiver. The Data Transfer Utility (DTU) helps lessen this workload within ASE by providing a fast, efficient means of determining which rows in a table have changed since table data was most recently transferred. It then sends only those rows in the current transfer. Feature Offerings The Data Transfer Utility provides a means of transferring data from a table to a file on the ASE host, selecting only the rows that have changed since a previous transfer. This is accomplished through a new T-SQL command, transfer table. Transfers are fast and lightweight, interfering only minimally with normal database operations. During normal processing, the utility keeps track of the physical location of data changes, providing a means of going directly to the changed data instead of reading every row in the table. The transfer table command is somewhat similar to the bulk copy (bcp) utility: it obtains data by scanning the table, unlike replication, which scans the transaction log. The utility can format its output data in one of several forms, suitable for a variety of receivers, primarily ASE and Sybase IQ. It provides a new internal file format suitable for exchanging data with other ASE servers. It offers a configurable history mechanism for remembering the results of previous transfers, applying previous command options as the defaults for the current transfer. A new monitoring table allows users to track the progress of ongoing transfers as they occur. Internal tests show that the utility transfers data out from tables at between four and five times the speed of the equivalent bcp out command. The Basics of DTU Table Eligibility for Incremental Transfer While any table may be transferred via DTU, only user-created tables may be marked for incremental transfer. We refer to these marked tables as eligible tables. Transferring an eligible table will send only changed or new data, and only committed data (that is, data whose updating transaction has committed at the time the transfer starts). Optionally, transfer of an eligible table can also interact with ongoing transactions to assure that only transactionally consistent data is sent. Transferring other tables will always send every row in the table, and will not interact with ongoing transactions. Tables are marked as eligible via a new option to the create table and alter table commands: transfer table on. Once made eligible, tables remain eligible until that option is specifically removed via alter table set transfer table off. While eligible, they can participate in incremental transfers and will retain a history of their transfers, as described below. Physical Changes in the Database Providing incremental transfer requires a way of knowing what data has already been sent and what hasn t been sent since data was inserted or most recently changed. To accomplish this, transfer table uses two things: a marker in the data and a transfer history. 1
Row Changes for Eligible Tables The data marker is an 8-byte timestamp in the data row. This is not a date or time, just a sequence number that tells when this data was most recently updated. Having these timestamps is what makes a table eligible for incremental transfer. Every row in an eligible table has this marker. This means that rows in eligible tables are larger than rows in otherwise identical ineligible tables, so an eligible table requires more space in the database. Tables can be made eligible when they are created. They can also be altered to have their eligibility added or removed. However, because altering the table in this way makes the row larger or smaller, doing this alteration completely reallocates the table, just as it would when altering the table byadding or removing a column. Because of these physical row changes, only user-created tables can be eligible for incremental transfer. System catalogs have a required row format that cannot be changed except as required by upgrade. New Table spt_tabletransfer Transfer history is stored in a new table, spt_tabletransfer. This table exists in each database containing eligible tables, and is owned by that database s Database Owner (DBO). It contains information about past transfers of eligible tables. The length of the retained history is configurable, with the configuration controlling the number of succeeding and of failing transfers ASE will remember for each eligible table. This aids in troubleshooting and recovery: you can tell right away which transfers succeeded, and which failed and why they failed. Also, if something happens later to damage the output data, you can use these history entries to resend data from previous transfers. Supported Output Formats The utility can create output files suitable for a variety of receivers: bcp, Sybase IQ, character-coded output, or a new ASE internal file format. Of these, only ASE s internal format is suitable for directly processing incremental data, because it is the only format that carries status information along with the data. The other formats contain only the data; and while the data itself will be only an incremental data set, there is no way to tell whether an individual row represents new data or a change to previously existing data. Features of the individual output file formats are: Data for bcp ( for bcp ) is written in bcp s binary file format. Each output file is accompanied by a format file in the same directory that bcp uses to format rows for transfer back to ASE. Data for Sybase IQ ( for iq ) is written in IQ s binary format, similar to sending the result of an IQ select statement out to a file in binary form. Where necessary, data has been converted to IQ format. This file is suitable for loading into IQ via load table. Character-coded data ( for csv ) is written with user-definable column and row separators. This file is suitable for loading into ASE or IQ via bcp, into IQ via load table, or to third-party programs. Data in ASE internal form ( for ase ) is suitable for loading via ASE s new transfer table from command. Again, this is the only file format in which individual rows are marked to show whether they are new rows or updates to older rows. This format also automatically detects when data is being loaded into a machine having a different byte order than the machine where it was produced. 2
The transfer table Command To invoke DTU, use a new command, transfer table. The basic form of this command is: transfer table table_name to destination_file Command options exist to modify this command s operation, as explained in the transfer table to command below. Without any options, the first-ever transfer of a table produces output in ASE s internal format. Subsequent transfers of an eligible table use the command options from the previous successful transfer of that table as their defaults. When table data has been transferred out in ASE internal format, a variant of the same command will transfer it in to another ASE: transfer table table_name from source_file This will import the extracted data into another table. The receiving table must be identical to the source table. (Some exceptions exist to this rule. Actually, the receiving table must be nearly identical to the source.) Setting Up to Use DTU Setup consists of four steps: Create table spt_tabletransfer. Do this once in each database that will contain tables marked for incremental transfer, using procedure sp_setup_transfer_table. This should be done by the database owner, or by a user with sa_role on behalf of the database owner. This step is not absolutely required. If you don t complete this step, ASE will create this table automatically when you mark a table for incremental transfer. However, to avoid potential problems we suggest you do it manually. Configure the transfer history length. Do this once for the entire server, using sp_configure max transfer history, N, where N is an integer in the range 1 255. The default is 10, meaning that for each eligible table ASE will remember as many as 10 successful transfers and 10 failing transfers. These history entries are useful for remembering which file transfers were written to, and for recovering from problems such as data files that were damaged before they were loaded into the receiving system. As a precaution, you might choose to configure this history longer if you were producing incremental transfers much more often than you were loading them. Or you might choose to configure it shorter if you have hundreds of tables that you transfer incrementally, and want to limit the size of the transfer history table. 3
Configure the transfer memory pool. Do this configuration once for the entire server, using sp_configure transfer utility memory size, N, where N is a number of memory pages (that is, blocks of 2048 bytes). The default is 4096 pages, or 8 megabytes. This memory is used during normal runtime to describe the table and to track information about where changed data for each table is physically located in the database. It is used during transfers to hold rows being written to or read from the file. You will probably not need to change this configuration. The default is large enough to transfer about 100 normal tables simultaneously. If you don t intend to transfer any tables incrementally, you might choose to configure this memory smaller in order to reclaim the memory for other purposes. Conversely, if you have hundreds of tables marked for incremental transfer, or if the tables you intend to transfer are extremely large (hundreds of gigabytes), you may wish to configure it larger to avoid potentially running out of memory when starting a transfer. This memory pool is dynamic, meaning it can be reconfigured larger or smaller without needing to restart ASE. Create or modify tables for transfer table. You must do this for each table that you plan to transfer incrementally. Considerations for the Receiving Table Requirements for the table that will receive the data vary. When importing data that was written in bcp format, the receiving table should have the same columns, in the same order, as the source table. When importing data that was written character-coded, the receiving table need only be capable of accepting the data that appears in the output file. When importing data that was written for Sybase IQ, IQ s load table command allows you to specify the receiving table s columns in any order necessary to match what appears in the output file, as long as the receiving columns match the size and datatype of the imported data. All of the above formats are only suitable for importing new data. They cannot handle changes to existing rows. If you know that your data includes changes to existing rows, then you should format the data for ASE, so that you can use the transfer table command to load it. The receiving table must have the same columns, in the same order, as the source table. Customers having IMDB licenses must assure that either the source table or the destination table reside in an IMDB or RDDB. The columns of the two tables need not be identical, but they must be close enough : A varying-length nullable column from the source table need not be nullable in the receiving table. A varying-length column in the receiving table must be at least as long as its equivalent in the source table, but it may be longer. An encrypted column in the source table need not be encrypted in the destination table, as long as the data was written unencrypted and the receiving column is either nullable or varying-length. (ASE stores all encrypted columns as though they were varying-length.) Columns in the destination table may be encrypted where the source columns were not, as long as the source columns were either nullable or varying-length. 4
The requirement is that for each column as it appears in the output file, there must be a column capable of receiving the data without converting the column to a different datatype. Additionally, in order to receive changes to existing data, the receiving table must have a primary index. The transfer uses this index to locate and remove existing rows so that it can store the new row (until the old row is gone it is an error to store the replacement row). The transfer table to Command As explained above, the basic command for extracting incremental data from an eligible table and writing it to a file is: transfer table table_name to destination_file Those are the only required parts of the command. Options provided to this command control its operation, describing how the data is formatted and controlling some aspects of the formatting, as well as controlling how the command behaves. Specify options controlling basic formatting via the for clause: transfer table table_name to destination_file for {ase bcp csv iq } These options are: for ase writes data in ASE s internal file format. Use the T-SQL command transfer table from to load this file. For example: transfer table table_name from /path/to/file for ase for bcp writes data in bcp s binary data format. This format produces an associated format file, placed in the same directory as the output data, named {table_name},{dbid},{object_id}.fmt. Use bcp to load this data, and provide the path to the format file using bcp s -f flag. for csv writes character-coded output. This is not a file in standard csv format. Rather, it provides userdefinable column and row separators, and writes a file suitable for loading into ASE or Sybase IQ using bcp c, or into Sybase IQ via load table format ascii. See Options Controlling Character-Coded Output below for more information about the column and row separators. for iq writes data in Sybase IQ s binary data format. Use IQ s load table format binary command to load this file. Specify options controlling command operation, and modifying the for clause, using the with clause: transfer table table_name to destination_file for format with { column_order={ id offset name name_utf8 }, column_separator=string, encryption={ true false }, fixed_length=( true false ), null_byte={ true false }, progress=nnn, resend=nnn, row_separator=string, sync={ true false }, tracking_id=nnn } 5
These options affect various things about the command as described below. Options Controlling the Overall Command Options column_order, encryption, progress, resend, sync, and tracking_id affect the overall command: column_order determines the order in which columns are written from table rows into the file. Different options serve different purposes: Order id : columns will be written in ascending order by their defined column ID in syscolumns. This order is required when doing a transfer for bcp. It is the order in which bcp naturally writes columns, so it is also suitable for transfers for csv when you want to mimic what bcp c would do. Order offset : columns will be written in the order in which they are physically stored in the data row. This order is required when doing a transfer for ase. Orders name and name_utf8 : columns will be written in ascending order, sorted by their column name. The name option sorts the names in bytewise order, whereas name_utf8 converts the names to UTF-8 characters before sorting. These options are useful when the source and destination tables have identically named columns, but you are not sure that the columns appear in the same ID or offset order in both tables. To be able to take advantage of this option, you must be able to specify the column order when importing to the destination table. This is primarily useful for Sybase IQ: its load table command allows you to specify column presentation order as needed. encryption controls whether or not the command decrypts encrypted columns. When true, the command writes encrypted column data to the output file without decrypting it. With this option, the receiving column must use exactly the same encryption method and key as the source column, or the data will not be readable. However, the user executing the command does not need permission to access the encryption key(s) used to encrypt the data. When false, the command decrypts columns before writing them to the output file. Using this option, the user must have permission to decrypt the data, and the data will be written to the output file without encryption; but it will then be readable at its destination without needing to know the details of how it was encrypted. This is the default. progress causes the command to produce a progress message every NNN seconds. This is useful when the user executing the command wants assurance that the command has not stalled. However, progress information is also available through the monitoring table montabletransfer, as described in Tracking Transfers, below. resend aids disaster recovery by instructing the command not to start with the beginning timestamp it would normally use, but with a timestamp taken from an indicated previous successful transfer. Output files can be damaged after transfer is complete but before they are loaded. When this happens, you can locate the history entry in spt_tabletransfer that contains that output file, find its sequence ID, and cause this transfer to use that transfer s base timestamp instead of the one it would otherwise select. Please note that this does not send exactly what the previous transfer sent. Rather, it uses the base timestamp to establish its low bound for sending rows. Generally, that means the transfer will send all those rows, plus rows sent by any intervening transfers, plus rows that would be sent by the current transfer without the resend option. 6
sync determines whether this transfer does or does not synchronize with current transactions. When true, transfer interacts with transactions as described in Interaction with Transactions, below. This can slow down transaction processing, but assures that the transfer includes only transactionally consistent data. When false, transfer works independently of transactions. The transfer will include only committed data, but the output file is not guaranteed to contain every row affected by a particular transaction. This is the default. tracking_id associates a user-supplied ID with the current transfer. It will be stored in the history entry for this transfer. Users can then use that ID as a way of locating a particular transfer. Note that ASE does not control this ID, nor does it care whether many different transfers use the same ID. This is purely a user convenience. The default is to use no tracking ID. Options Controlling Output for IQ Two options exist that are specific to transfers for iq : fixed_length determines whether the transfer sends non-nullable varying-length character strings as their correct length, or pads them with blanks to the column s maximum possible width. When true, columns are padded. This produces a larger output file, but can be safer. (See below.) When false, columns are sent as their correct length. This option only affects non-nullable varying-length string columns. Transfer for iq always sends all other columns padded out to their full possible width. This occurs because when loading using `format binary, the load table command only provides syntax to accept varying length input for character columns. You should use this option if your table contains a mix of nullable columns and non-nullable varying-length string columns. Otherwise, we have seen that load table can misinterpret data in the transfer file, which will cause the load to be corrupt. null_byte determines whether transfer appends a null byte to every column in the output file, or only to nullable columns. When true, every column has an appended null byte. If you use this option, it forces the transfer to use the option fixed_length=true regardless of whether you specify differently. In Sybase IQ s binary format, only fixedlength columns may include a null byte. When false, only nullable columns have the null byte. In Sybase IQ, nullable columns are followed by a single byte indicating whether the column is null or not. In this byte, zero means not null, and non-zero means null. This option is useful when the source table has different nullable columns than the destination table does. The load table syntax allows you to specify with null byte to indicate that columns in the input data have the null byte regardless whether the column they are loaded into is nullable. 7
Options Controlling Character-Coded Output Two options exist that are specific to transfers for csv : column_separator is a string written between output columns. The default for the first transfer for csv is a tab character. The default for subsequent transfers is the string used in the most recent successful transfer. row_separator is a string written at the end of each output row. The default for the first transfer for csv is a line feed (ctrl-j) on Unix or Linux, or a carriage return (ctrl-m) and line feed pair on Windows. The default for subsequent transfers is the string used in the most recent successful transfer. These strings may each be as long as 64 bytes. You can specify some special characters to be included in the string, as follows: \b inserts a backspace (ctrl-h) \t inserts a tab (ctrl-i) \n inserts a line feed (ctrl-j) \r inserts a carriage return (ctrl-m) \\ inserts a backslash ( \ ) Occurrences of the backslash character that are not part of one of the sequences above are not considered special. They simply insert the characters without interpreting them. Interaction with Other Ongoing Work Interaction with Transactions By default, DTU transfers committed data, which is not the same as transactionally consistent data. For transfer, data is committed if the transaction that modified it committed before the transfer began. On the other hand, transactionally consistent transfers require that if one row changed by a given transaction is sent, then all rows changed by that transaction are also sent in the same transfer. This section explains how command options cause DTU to send either committed or transactionally consistent data. The utility will not send data it considers to be uncommitted, because it cannot know whether a transaction will roll back, which would mean that some changes should not have been sent. However, it cannot afford to spend the time needed to check every row to see whether its transaction committed. Thus, it considers data to be committed only for transactions that committed before the transfer starts. If a transaction commits while a transfer is in progress, and before the transfer reads rows affected by that transaction, the transfer still considers those rows to be uncommitted. Transmitting committed data is the default action because we assume that this transfer will be followed by another transfer. However, this can cause DTU not to send all the rows changed by a given transaction: it can happen that an uncommitted transaction changes rows while a transfer is in progress and before the transfer inspects them, causing those rows not to be sent. If those rows were originally part of some other update, this can cause a transfer to send some of the rows from the previous update but not others. Such a transfer is thus transactionally inconsistent. If the possibility of that inconsistency is not acceptable, DTU provides an option to prevent it. The command transfer table with sync= true causes DTU to synchronize this transfer with currently ongoing transactions. Using this option: A transfer may not begin against a table until all currently open transactions that modify that table have ended. The transfer will wait until the table has no transactions open against it. While a transfer is waiting to begin, no transaction may change the affected table unless that transaction has already changed that table. After the transfer begins, transactions may change the table, but they may only change pages that the transfer has already inspected. 8
For very large, very active tables, this can cause significant delays in normal transaction processing. It can happen that transactions attempt to change data on pages that a transfer will not inspect for some time yet. Transfer reads pages in a predetermined order, and no mechanism exists to cause it to inspect a page early because a transaction wants to modify that page. Interaction with Other Transfers Only one transfer at a time may be active against one table. If you attempt to start a transfer while another transfer is in progress, the second transfer will sleep until the first transfer completes. This prevents confusion about whether a row has or has not been sent during a transfer. Transfers of separate tables may happen simultaneously. The number of simultaneous transfers you may do is limited only by the number of files your operating system permits ASE to open simultaneously. Each ongoing transfer uses one file. Please note, though, that connections to database devices also count as open files, so if your site uses many database devices, that could limit the number of simultaneous transfers you are able to complete. Tracking Transfers Statistical and historical information for each transfer is stored in table spt_tabletransfer. For each eligible table, this table keeps up to a configured number of successful and unsuccessful transfer history records. Records are written to spt_tabletransfer after the transfer completes. Transfers store information about the transfer s completion status, which is not known until it finishes. Note too that this table only stores history entries for eligible tables other tables that you may transfer do not keep history entries, since DTU will not transfer them incrementally. However, while a transfer is in progress, statistical information about that transfer is kept in memory, including the amount of data transferred so far and estimates of how much more data the transfer expects to send. That information is available in real time through monitoring table montabletransfer. This includes all transfers, whether or not the table being transferred is eligible for incremental transfer. This table also contains historical information about transfers of tables for which ASE currently stores information in memory. Thus: spt_tabletransfer stores information for completed transfers of eligible tables. This table exists in every database that contains an eligible table. Its history records are limited by configuration option max transfer table history : it stores up to the configured number of successful and of unsuccessful transfers of each eligible table. montabletransfer has information about transfers of tables for which ASE currently holds information in memory. This includes all eligible tables that have been transferred at least once since ASE was started, unless those tables memory has been scavenged. It also includes non-eligible tables while they are actively being transferred. For the eligible tables that montabletransfer can report, it also can extract and report historical information from spt_tabletransfer. But again, this is only true while the table s information is available in memory. If a table has not been transferred since ASE was most recently restarted, or if ASE has had to reclaim that table s in-memory information, montabletransfer will not report it. 9
File Handling for Transfer The transfer table command writes data to or reads data from a file on the same system where ASE is currently running. In a multi-engine server, the file will be on a file system visible to the engine that services the command. The transfer opens the file when the transfer begins and closes it when the transfer ends. Under certain circumstances, DTU will delete the file as it closes it. This occurs when: Transfer fails for any reason. Transfer opens the file, but finishes without writing any data to the file. There are two possible scenarios in which DTU might not write any data for a particular transfer. The first is that DTU can tell in advance that there is no data available to send: its tracking information shows that no data in the table has been modified since the last successful transfer. The second is that data has been modified, but all the changes are uncommitted and thus cannot be sent by this transfer. In the first case, DTU does not try to remove the file (because it never opened it); in the second case, it does. There is an exception to this rule. If the file is a special file such as a FIFO (first-in, first-out, also called a named pipe ), ASE will not try to remove that file. Please also note two additional points about transfers using a FIFO: A FIFO is not acceptable for transfers done for bcp. This is because those transfers require a second file, the format file; but ASE does not know where to write that file. When transferring to or from a FIFO, it is the customer s responsibility to see that there is something on the other end of the pipe to read or write data. ASE simply opens the FIFO and begins writing or reading. With no coordinating program, the transfer will seem to hang, and can even encounter timeslice errors if it waits too long. Resending a Transfer If something happens after transfer out to a file is complete but before the file is loaded to its intended receiver, you can instruct DTU to resend that data so as not to lose any updates you may have made. You do this by directing DTU to take its floor timestamp from a history entry in spt_tabletransfer. Please note: it is not possible to resend exactly the same data sent by a prior transfer. Subsequent updates may have changed the data, so those rows may no longer exist. What you are actually doing when you resend a transfer is starting a transfer that behaves as though that transfer and any subsequent transfers never happened (however, DTU uses the selected history entry to provide command defaults). Do this as follows: transfer table table_name to destination_file with resend=nnn The value NNN is a sequence ID as stored in spt_tabletransfer. There are two ways to specify this sequence number: as a positive, non-zero integer, or as a negative integer. Positive integers are sequence IDs from spt_ TableTransfer.sequence_id. You can obtain that sequence ID by selecting from spt_tabletransfer, for example: select sequence_id from spt_tabletransfer where pathname like %file_name% If you provide a sequence_id that does not exist, DTU assumes you want to resend all data in the table. It treats this transfer as though it were the first transfer ever done for this table. The other way to designate sequence_id is as a negative integer. Here, you are directing DTU to locate a previous successful transfer by its relative position in spt_tabletransfer: -1 is the most recent successful transfer, -2 the next most recent, and so on. 10
As with positive IDs, if you provide a negative sequence ID for which ASE has no history of a transfer, DTU assumes you want to send all rows in the table. If your history has only 5 successful transfers and you execute transfer table with resend=-6, DTU will treat this transfer as the first-ever transfer of this table. Transfer Speed Tests We ran internal tests of transfer table to to measure transfer speed. Tests were performed using a single in-memory database in ASE on a Linux (AMD 64-bit) machine. We measured throughput on five tables simultaneously, using bcp in to add data to the tables while transfer table was extracting data from them. In these tests: bcp in inserted data at 91 110 Gb per hour transfer table extracted data at 107 145 Gb per hour Total I/O throughput was 198 255 Gb per hour. We also ran tests to measure data extraction speed for transfer table for bcp versus single-threaded bcp out. In these tests: bcp out averaged about 17,000 rows per second transfer table averaged about 75,000 rows per second. DTU, bcp, and Replication Server The transfer table command, the bulk copy utility, and Replication Server are all different from one another in important ways. They can all be used together; you should determine which one is most appropriate for a given purpose. Like bcp, transfer table scans the table for data and writes its output to a file. Unlike bcp, transfer table requires that the output file be one that ASE can open directly it does not currently write output to the network. Also, where bcp is able to address a single partition of a table, transfer table inspects the entire table. Currently, transfer table and bcp cannot capture deleted rows. (This will be added to transfer table... for ase in a subsequent release.) When transfer table sends a row, it sends only the image of that row as it exists when it scans the table. It does not capture individual changes that occur to that row over time. Also, transfer table depends on the user to issue commands to send or fetch the data database changes are not captured in real time. Replication Server can do all these things, and has the notion of subscribing to the data, so it can propagate changes automatically to a collection of subscribers. Tables transferred via transfer table... for ase can be loaded into databases with a different byte order, but the command cannot change the data s character set. 11
License Requirements The DTU feature comes bundled with the ASE IMDB (In-Memory Databases) license. Please refer to the Sybase ASE documentation for further details on licensing. Note: customers with IMDB licenses who want to transfer data in ASE s internal format are subject to the restriction that either the source table or the destination table (or both) must reside in an IMDB or RDDB (Relaxed Durability Database). Security Restrictions Permission to use transfer table to transfer a given table defaults to the owner of that table and to System Administrators (that is, users having role sa_role ). Table owners may grant permission to transfer their tables to other users. The transfer table command does not encrypt data before writing it to the file. Where tables contain encrypted columns, a command option controls whether DTU will decrypt columns before transfer or if it will write the data in its encrypted form. Where DTU decrypts data, the user performing the transfer must have permission to access all necessary decryption keys, and that data will be written to the file unencrypted. Where DTU does not decrypt data, the receiving application must know the precise details of how the data was encrypted, otherwise it will not be readable after loading. Sybase, Inc. Worldwide Headquarters One Sybase Drive Dublin, CA 94568-7902 U.S.A 1 800 8 sybase www.sybase.com 12 Copyright 2010 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo and Adaptive Server are trademarks of Sybase, Inc. or its subsidiaries. All other trademarks are the property of their respective owners. indicates registration in the United States. Specifications are subject to change without notice. 04/10