Oracle 게시자에 대한 디자인 고려 사항 및 제한 사항Design Considerations and Limitations for Oracle Publishers

Oracle 데이터베이스에서의 게시 작업은 MicrosoftMicrosoft SQL ServerSQL Server 데이터베이스에서의 게시 작업과 거의 동일합니다.Publishing from an Oracle database is designed to work nearly identically to publishing from a MicrosoftMicrosoft SQL ServerSQL Server database. 그러나 Oracle 데이터베이스에서의 게시 작업에 대한 다음과 같은 제한 사항 및 문제점을 알고 있어야 합니다.However, you should be aware of the following limitations and issues:

  • Oracle Gateway 옵션은 Oracle Complete 옵션을 사용할 때보다 더 나은 성능을 제공하지만 여러 트랜잭션 게시에서 동일한 테이블을 게시할 때는 사용할 수 없습니다.The Oracle Gateway option provides improved performance over the Oracle Complete option; however, this option cannot be used to publish the same table in multiple transactional publications. 트랜잭션 게시의 경우 특정 테이블이 한 번만 나타날 수 있지만 스냅숏 게시의 경우에는 이러한 제한이 없습니다.A table can appear in at most one transactional publication and any number of snapshot publications. 여러 트랜잭션 게시에서 동일한 테이블을 게시해야 할 경우에는 Oracle Complete 옵션을 선택하십시오.If you need to publish the same table in multiple transactional publications, choose the Oracle Complete option.

  • 복제에서 테이블, 인덱스 및 구체화된 뷰를 게시할 수 있습니다.Replication supports publishing tables, indexes, and materialized views. 다른 개체는 복제되지 않습니다.Other objects are not replicated.

  • Oracle 데이터베이스와 SQL ServerSQL Server 데이터베이스 간의 일부 데이터 저장 및 처리 방법 차이로 인해 복제가 영향을 받습니다.There are some small differences between the storage and processing of data in Oracle and SQL ServerSQL Server databases that affect replication.

  • Oracle 게시자 사용 시 트랜잭션 복제 기능이 지원되는 방식이 매우 다릅니다.There are a number of differences in how transactional replication features are supported when using an Oracle Publisher.

Oracle 개체 게시 지원Support for Publishing Objects from Oracle

다음은 복제에서 지원하는 Oracle 데이터베이스 개체입니다.Replication supports replicating the following objects from Oracle databases:

  • 테이블Tables

  • 인덱스로 구성된 테이블Index-organized tables

  • 인덱스Indexes

  • 구체화된 뷰(구체화된 뷰는 테이블로 복제됨)Materialized views (they are replicated as tables)

    다음 개체는 게시된 테이블에 표시할 수는 있지만 복제할 수는 없습니다.The following can be present on published tables but are not replicated:

  • 도메인 기반 인덱스Domain-based indexes

  • 함수 기반 인덱스Function-based indexes

  • 기본값Defaults

  • CHECK 제약 조건Check constraints

  • 외래 키Foreign keys

  • 저장소 옵션(예: 테이블스페이스, 클러스터 등)Storage options (tablespaces, clusters, etc.)

    다음 개체는 복제할 수 없습니다.The following objects cannot be replicated:

  • 중첩 테이블Nested tables

  • Views

  • 패키지, 패키지 본문, 프로시저 및 트리거Packages, package bodies, procedures, and triggers

  • Queues

  • 시퀀스Sequences

  • 동의어Synonyms

    지원되는 데이터 형식에 대한 자세한 내용은 Data Type Mapping for Oracle Publishers을 참조하세요.For information about supported data types, see Data Type Mapping for Oracle Publishers.

Oracle과 SQL Server의 차이점Differences between Oracle and SQL Server

  • Oracle에서는 일부 개체에 대한 최대 크기 제한이 서로 다릅니다.Oracle has different maximum size limits for some objects. Oracle 게시 데이터베이스에서 생성된 모든 개체는 SQL ServerSQL Server에서의 해당 개체에 대한 최대 크기 제한을 따라야 합니다.Any objects created in the Oracle publication database should adhere to the maximum size limits for the corresponding objects in SQL ServerSQL Server. SQL ServerSQL Server의 제한에 대한 자세한 내용은 SQL Server의 최대 용량 사양을 참조하세요.For information about limits in SQL ServerSQL Server, see Maximum Capacity Specifications for SQL Server.

  • 기본적으로 Oracle 개체 이름은 대문자로 생성됩니다.By default Oracle object names are created in upper case. Oracle 데이터베이스에서 Oracle 개체 이름이 대문자인 경우 이 개체를 SQL ServerSQL Server 배포자를 통해 게시할 때 해당 이름을 대문자로 입력해야 합니다.Ensure that you supply the names of Oracle objects in upper case when publishing them through a SQL ServerSQL Server Distributor if they are upper case on the Oracle database. 대/소문자를 올바르게 입력하지 않으면 개체를 찾을 수 없다는 오류 메시지가 나타납니다.Failure to specify the objects in the correct case may result in an error message indicating that the object cannot be found.

  • Oracle의 SQL 언어는 SQL ServerSQL Server와 조금 다릅니다. 행 필터를 Oracle 호환 구문으로 작성해야 합니다.Oracle has a slightly different SQL dialect from SQL ServerSQL Server; row filters should be written in Oracle-compliant syntax.

큰 개체에 대한 고려 사항Considerations for Large Objects

LOB(큰 개체) 데이터는 아티클 로그 테이블에 저장되지 않으며 LOB 데이터의 업데이트 내용은 게시된 테이블에서 언제든지 검색할 수 있습니다.Large object (LOB) data is not stored in the article log table; updates to LOB data are always retrieved directly from the published table. LOB에 영향을 주는 작업이 복제된 테이블의 복제 트리거를 발생시키는 경우에만 트랜잭션 게시에 업데이트가 복제됩니다.Updates are replicated in transactional publications only if the operation affecting the LOB fires the replication trigger on the replicated table. LOB을 포함하는 행이 삽입 또는 삭제되는 경우 Oracle 트리거가 발생되지만 LOB 열이 업데이트되는 경우에는 트리거가 발생되지 않습니다.Oracle triggers fire when rows containing LOBs are inserted or deleted; however updates to LOB columns do not fire triggers. 같은 행의 비-LOB 열이 같은 Oracle 트랜잭션에서도 업데이트되는 경우에만 LOB 열 업데이트를 즉시 복제합니다.An update to a LOB column will be replicated immediately only if a non-LOB column of the same row is also updated in the same Oracle transaction. 그렇지 않으면 같은 행에 있는 비-LOB 열에서 다음 업데이트가 발생할 경우 구독자에서 LOB 열을 새로 고칩니다.If not, the LOB column will be refreshed at the Subscriber when the next update to a non-LOB column in the same row occurs. 이 동작을 응용 프로그램에 사용할 수 있는지 확인합니다.Ensure that this behavior is acceptable for your application.

트랜잭션 게시에서 LOB 열 업데이트를 복제하려면 응용 프로그램을 작성할 때 다음 전략 중 하나를 고려하십시오.To replicate updates to LOB columns in transactional publications, consider one of the following strategies when writing the application:

  • 트랜잭션 내에서 행을 업데이트하지 않고 행을 삭제 또는 다시 삽입합니다. 행을 다시 삽입할 때 새 LOB을 지정합니다.Delete and reinsert the row(s) within a transaction instead of updating the row: specify the new LOB when re-inserting the row. 삭제와 삽입 모두 트리거를 발생시키므로 행이 복제됩니다.Because delete and insert both fire triggers, the row will be replicated.

  • 행 업데이트에 LOB 열 외에 비-LOB 열을 포함시키거나 행의 비-LOB 열을 동일한 Oracle 트랜잭션의 일부로 업데이트합니다.Include a non-LOB column in the row update in addition to the LOB column, or update a non-LOB column of the row as part of the same Oracle transaction. 두 경우 모두 비-LOB 열을 업데이트하면 트리거가 발생됩니다.In both cases, the update of the non-LOB column ensures that the trigger fires.

    LOB에 대한 자세한 내용은 Data Type Mapping for Oracle Publishers을 참조하십시오.For more information about LOBs, see Data Type Mapping for Oracle Publishers.

고유 인덱스 및 제약 조건Unique Indexes and Constraints

스냅숏과 트랜잭션 복제에서 고유 인덱스 및 UNIQUE 제약 조건(PRIMARY KEY 제약 조건 포함)에 포함된 열이 특정 제한 사항을 따라야 합니다.For both snapshot and transactional replication, columns contained in unique indexes and constraints (including primary key constraints) must adhere to certain restrictions. 이러한 제한 사항을 따르지 않으면 제약 조건이나 인덱스가 복제되지 않습니다.If they do not adhere to these restrictions, the constraint or index is not replicated.

  • SQL ServerSQL Server 의 인덱스에서 허용된 최대 열 수는 16입니다.The maximum number of columns allowed in an index on SQL ServerSQL Server is 16.

  • UNIQUE 제약 조건에 포함된 모든 열에 지원되는 데이터 형식이 있어야 합니다.All columns included in unique constraints must have supported data types. 데이터 형식에 대한 자세한 내용은 Data Type Mapping for Oracle Publishers을 참조하세요.For more information about data types, see Data Type Mapping for Oracle Publishers.

  • UNIQUE 제약 조건에 포함된 모든 열이 게시되어야 합니다. 이러한 열은 필터링할 수 없습니다.All columns included in unique constraints must be published (they cannot be filtered).

  • UNIQUE 제약 조건이나 고유 인덱스에 포함된 열은 Null이 아니어야 합니다.Columns involved in unique constraints or indexes should not be null.

    또한 다음 문제를 고려해야 합니다.Also consider the following issues:

  • Oracle 및 SQL ServerSQL Server 은 NULL을 다르게 처리합니다.Oracle은 NULL을 허용하고 UNIQUE 제약 조건 또는 고유 인덱스에 포함된 열에 대해 NULL 값을 갖는 행을 여러 개 허용합니다.Oracle and SQL ServerSQL Server treat NULL differently: Oracle permits multiple rows with NULL values for columns that allow NULL and are included in unique constraints or indexes. SQL ServerSQL Server 는 동일한 열에 대해 NULL 값을 갖는 행을 하나만 허용하여 고유성을 갖도록 합니다. enforces uniqueness by only permitting a single row with a NULL value for the same column. 게시된 테이블에 인덱스 또는 제약 조건에 포함된 열에 대해 NULL 값을 갖는 행이 여러 개 포함된 경우 구독자에서 제약 조건 위반이 발생하므로 NULL을 허용하는 UNIQUE 제약 조건이나 고유 인덱스를 게시할 수 없습니다.You cannot publish a unique constraint or index that allows NULL because a constraint violation would occur on the Subscriber if the published table contains multiple rows with NULL values for any of the columns included in the index or constraint.

  • SQL ServerSQL Server 에서는 고유성을 테스트할 때 필드의 후행 공백을 무시하지만 Oracle에서는 무시하지 않습니다.When testing for uniqueness, trailing blanks in a field are ignored by SQL ServerSQL Server but not by Oracle.

    SQL ServerSQL Server 트랜잭션 복제에서처럼 Oracle 트랜잭션 게시의 테이블에는 기본 키가 필요하며 기본 키는 위에 지정된 규칙에 따라 고유해야 합니다.As in SQL ServerSQL Server transactional replication, tables in Oracle transactional publications require a primary key; the primary key must be unique based on the rules specified above. 기본 키가 위의 글머리 기호로 요약된 규칙을 따르지 않을 경우 테이블을 트랜잭션 복제용으로 게시할 수 없습니다.If the primary key does not adhere to the rules outlined in the previous bullets, the table cannot be published for transactional replication.

Oracle 게시와 표준 트랜잭션 복제의 차이점Differences between Oracle Publishing and Standard Transactional Replication

  • Oracle 게시자는 SQL ServerSQL Server 배포자 또는 동일한 배포자를 사용하는 모든 SQL ServerSQL Server 게시자 또는 게시를 받는 모든 구독자와 동일한 이름을 가질 수 없습니다.An Oracle Publisher cannot have the same name as: its SQL ServerSQL Server Distributor; any of the SQL ServerSQL Server Publishers that use the Distributor; or any Subscribers that receive the publication. 같은 배포자가 서비스하는 게시의 경우 각 게시에 고유 이름이 있어야 합니다.Publications serviced by the same Distributor must each have a unique name.

  • Oracle 게시에 게시된 테이블은 복제된 데이터를 받을 수 없습니다.A table published in an Oracle publication cannot receive replicated data. 따라서 Oracle 게시는 즉시 업데이트 구독 또는 지연 업데이트 구독을 사용하는 게시나 게시 테이블이 피어 투 피어 및 양방향 복제와 같은 구독 테이블로도 사용되는 토폴로지를 지원하지 않습니다.Therefore, Oracle publishing does not support: publications with immediate updating or queued updating subscriptions; or topologies in which publication tables also act as subscription tables, such as peer-to-peer and bidirectional replication.

  • Oracle 데이터베이스에서 기본 키와 외래 키의 관계는 구독자에 복제되지 않습니다.Primary key to foreign key relationships in the Oracle database are not replicated to Subscribers. 그러나 변경 내용이 배달될 때는 데이터에 관계가 유지됩니다.However, the relationships are maintained in the data as changes are delivered.

  • 표준 트랜잭션 게시는 최대 1000개의 열로 구성된 테이블을 지원합니다.Standard transactional publications support tables of up to 1000 columns. Oracle 트랜잭션 게시는 995개의 열을 지원하고 복제 시 게시된 각 테이블에 5개의 열이 추가됩니다.Oracle transactional publications support 995 columns (replication adds five columns to each published table).

  • COLLATE 절은 기본 키와 UNIQUE 제약 조건에 중요한 대/소문자 비교를 사용할 수 있도록 CREATE TABLE 문에 추가됩니다.Collate clauses are added to the CREATE TABLE statements to enable case sensitive comparisons, which is important for primary keys and unique constraints. 이 동작은 sp_addarticle(Transact-SQL)@schema_option 매개 변수로 지정하는 스키마 옵션 0x1000에 의해 제어됩니다.This behavior is controlled with the schema option 0x1000, which is specified with the @schema_option parameter of sp_addarticle (Transact-SQL).

  • 저장 프로시저를 사용하여 Oracle 게시자를 구성하거나 유지 관리하는 경우 프로시저를 명시적 트랜잭션 내에 두지 마십시오.If you use stored procedures to configure or maintain an Oracle Publisher, do not put the procedures inside an explicit transaction. 이 기능은 Oracle 게시자에 연결하는 데 사용된 연결된 서버에서는 지원되지 않습니다.This is not supported over the linked server used to connect to the Oracle Publisher.

  • 마법사로 Oracle 게시에 대한 끌어오기 구독을 만드는 경우 SQL Server 2005SQL Server 2005 이상 버전에서 제공하는 새 구독 마법사를 사용해야 합니다.If you create a pull subscription to an Oracle publication with a wizard, you must use the New Subscription Wizard supplied with SQL Server 2005SQL Server 2005 and later versions. 그러나 이전 버전의 SQL ServerSQL Server에서는 저장 프로시저 및 SQL-DMO 인터페이스를 사용하여 Oracle 게시에 대한 끌어오기 구독을 설정할 수 있습니다.For previous versions of SQL ServerSQL Server, you can, however, use the stored procedure and SQL-DMO interfaces to setup pull subscriptions to Oracle publications.

  • 저장 프로시저를 사용하여 변경 내용을 구독자(기본값)에게 전파할 경우 MCALL 구문은 지원되지만 Oracle 게시자의 게시에서 다르게 작동합니다.If you use stored procedures to propagate changes to Subscribers (the default), be aware that the MCALL syntax is supported, but it has different behavior when the publication is from an Oracle Publisher. 일반적으로 MCALL은 게시자에서 업데이트된 열을 보여 주는 비트맵을 제공합니다.Typically MCALL provides a bitmap that shows which columns were updated at the Publisher. Oracle 게시에서의 비트맵은 항상 모든 열이 업데이트되었음을 보여 줍니다.With an Oracle publication, the bitmap always shows that all columns were updated. 저장 프로시저 사용에 대한 자세한 내용은 트랜잭션 아티클에 대한 변경 내용을 전파하는 방법 지정을 참조하세요.For more information about using stored procedures, see Specify How Changes Are Propagated for Transactional Articles.

트랜잭션 복제 기능 지원Transactional Replication Feature Support

  • SQL Server 게시에서 지원되는 스키마 옵션 중 일부는 Oracle 게시에서 지원되지 않습니다.Oracle publications do not support all of the schema options that SQL Server publications support. 스키마 옵션에 대한 자세한 내용은 sp_addarticle(Transact-SQL)을 참조하세요.For more information on schema options, see sp_addarticle (Transact-SQL).

  • Oracle 게시의 구독자는 즉시 업데이트 구독 또는 지연 업데이트 구독을 사용할 수 없거나 피어 투 피어 또는 양방향 토폴로지의 노드입니다.Subscribers to Oracle publications cannot use immediate updating or queued updating subscriptions, or be nodes in a peer-to-peer or bidirectional topology.

  • Oracle 게시의 구독자는 백업에서 자동으로 초기화할 수 없습니다.Subscribers to Oracle publications cannot be automatically initialized from a backup.

  • SQL ServerSQL Server 에서는 이진 유효성 검사와 행 개수 유효성 검사를 지원합니다. supports two types of validation: binary and rowcount. Oracle 게시자에서는 행 개수 유효성 검사를 지원합니다.Oracle Publishers support rowcount validation. 자세한 내용은 복제된 데이터의 유효성 검사를 참조하세요.For more information, see Validate Replicated Data.

  • SQL ServerSQL Server 에서는 네이티브 bcp 모드 스냅숏과 문자 모드 스냅숏을 제공합니다. offers two snapshot formats: native bcp-mode and character-mode. Oracle 게시자에서는 문자 모드 스냅숏을 지원합니다.Oracle Publishers support character mode snapshots.

  • 게시된 Oracle 테이블의 스키마 변경은 지원되지 않습니다.Schema changes to published Oracle tables are not supported. 스키마를 변경하려면 먼저 게시를 삭제하고 스키마를 변경한 다음 게시 및 구독을 다시 만듭니다.To make schema changes, first drop the publication, make the changes, and then re-create the publication and any subscriptions.

    참고

    게시된 테이블에서 어떠한 동작도 발생하지 않을 때 스키마가 변경된 후 게시 및 구독의 삭제와 다시 생성 작업이 한 번에 수행되는 경우에는 해당 구독에 대해 'replication support only' 옵션을 지정할 수 있습니다.If the schema changes and the subsequent drop and re-creation of the publication and subscriptions are performed at a time when no activity is occurring on the published tables, you can specify the option 'replication support only' for the subscriptions. 이렇게 하면 각 구독자에 스냅숏을 복사하지 않고도 구독을 동기화할 수 있습니다.This allows them to be synchronized without having to copy a snapshot to each Subscriber. 자세한 내용은 스냅숏 없이 트랜잭션 구독 초기화를 참조하세요.For more information, see Initialize a Transactional Subscription Without a Snapshot.

복제 보안 모델Replication Security Model

Oracle 게시의 보안 모델은 표준 트랜잭션 복제의 보안 모델과 동일합니다. 단 다음과 같은 경우는 예외입니다.The security model for Oracle publishing is the same as the security model for standard transactional replication, with the following exceptions:

관련 항목:See Also

Oracle 게시자에 대한 관리 고려 사항 Administrative Considerations for Oracle Publishers
Oracle 게시자 구성 Configure an Oracle Publisher
Oracle Publishing OverviewOracle Publishing Overview