{"id":47082,"date":"2026-09-28T08:12:00","date_gmt":"2026-09-28T06:12:00","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=47082"},"modified":"2026-09-24T07:27:46","modified_gmt":"2026-09-24T05:27:46","slug":"goldengate-instantiation-csn-explained","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/","title":{"rendered":"GoldenGate Instantiation CSN Explained"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">For more than ten years (GoldenGate 12.2, released in 2015), GoldenGate has provided a way of performing initial load of tables with a <strong>per-table instantiation CSN<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But when migrating a database or just performing the initial load of a single table to prepare a GoldenGate replication, the known procedure is very often still the old one: start an extract, note down an SCN, run <code>expdp<\/code> with <code>FLASHBACK_SCN=&lt;that SCN&gt;<\/code>, import the data on the target, and finally start a replicat with the <code>AFTERCSN<\/code> clause.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">It takes a long time to get used to new habits, so let\u2019s refresh your memory, explaining how instantiation CSN work in GoldenGate.<\/p>\n\n\n\n<h2 id=\"historic-flashback_scn--aftercsn-initial-load\" class=\"wp-block-heading\">Historic <code>FLASHBACK_SCN<\/code> + <code>AFTERCSN<\/code> initial load<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Historically, precise instantiation of a table worked like this:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>START EXTRACT<\/code>. It is the first step, to ensure that no transaction is lost.<\/li>\n\n\n\n<li>Wait for long running transactions to be committed.<\/li>\n\n\n\n<li>Select an SCN, which should not be prior to the registration SCN of the extract.<\/li>\n\n\n\n<li>Export the data with <code>expdp ... FLASHBACK_SCN=&lt;scn&gt;<\/code> so the dump is consistent.<\/li>\n\n\n\n<li>Import the data with <code>impdp<\/code> on the target.<\/li>\n\n\n\n<li>Start the replicat with the <code>AFTERCSN &lt;csn&gt;<\/code> clause, so the replicat does not replicate anything committed at or before the instantiation CSN.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">While still perfectly valid, and even necessary under certain conditions, this method becomes hard to operate on complex replications or when the size of the database increases:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>UNDO<\/code> retention: very often, using the <code>FLASHBACK_SCN<\/code> clause will generate <code>ORA-01555: snapshot too old<\/code> errors.<\/li>\n\n\n\n<li>Splitting the initial load is not possible, since the <code>AFTERCSN<\/code> clause will apply on the whole replicat.<\/li>\n<\/ul>\n\n\n\n<h2 id=\"instantiation-csn-in-practice\" class=\"wp-block-heading\">Instantiation CSN in practice<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">GoldenGate instantiation CSN provides a simple solution: a <strong>per table instantiation CSN, on the target database<\/strong>, instead of a single one applied on the replicat.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This instantiation CSN is stored on the target database in the <code>DBA_APPLY_INSTANTIATED_OBJECTS<\/code> table, with one row per source object.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>SET PAGES 100 LINES 200\nCOL source_object_owner FORMAT A20\nCOL source_object_name FORMAT A30\nCOL instantiation_scn FORMAT 999999999999999\nSELECT source_object_owner, source_object_name, instantiation_scn\nFROM dba_apply_instantiated_objects\nORDER BY 1, 2;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">This table is <strong>populated by Data Pump<\/strong>, and is then <strong>read by GoldenGate<\/strong>. When applying changes, a replicat will compare the commit CSN of a record to the table\u2019s instantiation CSN. If the commit CSN is higher, the transaction will be discarded.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Because the comparison is done for every table, there is no need for them to share one instantiation CSN using <code>FLASHBACK_SCN<\/code>.<\/p>\n\n\n\n<h2 id=\"why-flashback_scn-is-no-longer-required\" class=\"wp-block-heading\">Why <code>FLASHBACK_SCN<\/code> is no longer required<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The instantiation CSN is the <strong>read-consistent SCN<\/strong> as of which Data Pump reads the table during export. It is stored in the dump and imported on the target when using <code>impdp<\/code>. It does <strong>not<\/strong> come from when the source table is prepared with <code>PREPARECSN<\/code>. <code>PREPARECSN<\/code> is what makes the table <em>eligible<\/em> for instantiation CSN.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Let\u2019s see the difference with three different scenarios:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standard initial load without <code>FLASHBACK_SCN<\/code><\/li>\n\n\n\n<li>Historic method with <code>FLASHBACK_SCN<\/code><\/li>\n\n\n\n<li>Instantiation with <code>PREPARECSN NONE<\/code><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">I will use the same two tables, <code>HR.EMPLOYEES<\/code> and <code>HR.DEPARTMENTS<\/code>.<\/p>\n\n\n\n<h2 id=\"enable_instantiation_filtering-vs-atcsnaftercsn\" class=\"wp-block-heading\"><code>ENABLE_INSTANTIATION_FILTERING<\/code> vs <code>ATCSN<\/code>\/<code>AFTERCSN<\/code><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before running the three scenarios, here is what the instantiation filtering replaces:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><\/th><th><code>ATCSN<\/code>\/<code>AFTERCSN<\/code><\/th><th><code>DBOPTIONS ENABLE_INSTANTIATION_FILTERING<\/code><\/th><\/tr><\/thead><tbody><tr><td>Boundary granularity<\/td><td>One CSN for the whole replicat<\/td><td>One CSN per table<\/td><\/tr><tr><td>Where the boundary is set<\/td><td>On the <code>START REPLICAT<\/code> command<\/td><td>Read from <code>dba_apply_instantiated_objects<\/code> on the target<\/td><\/tr><tr><td>Who sets the boundary<\/td><td>The operator, by hand<\/td><td>Data Pump automatically (or <code>SET INSTANTIATION CSN<\/code> manually)<\/td><\/tr><tr><td>Fits a load split across several <code>expdp<\/code>\/<code>impdp<\/code> jobs at different SCNs<\/td><td>No (every mapped table must share the one CSN)<\/td><td>Yes<\/td><\/tr><tr><td>Extra source-side step<\/td><td>None<\/td><td><code>ADD TRANDATA<\/code>\/<code>ADD SCHEMATRANDATA ... PREPARECSN<\/code> before export<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 id=\"1-prepare-the-tables-on-the-source\" class=\"wp-block-heading\">1. Prepare the tables on the source<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Using <a href=\"https:\/\/docs.oracle.com\/en\/database\/goldengate\/core\/26\/gclir\/add-schematrandata.html\" target=\"_blank\" rel=\"noopener noreferrer\"><code>ADD SCHEMATRANDATA<\/code><\/a>, we will start by preparing the table on the source. The full clause is <code>ADD SCHEMATRANDATA &lt;schema_name&gt; PREPARECSN {WAIT | LOCK | NOWAIT | NONE}<\/code>, and <code>NOWAIT<\/code> is the <strong>default<\/strong>. In other words, <code>ADD SCHEMATRANDATA<\/code> prepares tables for instantiation whether you include <code>PREPARECSN<\/code> or not.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>OGG&gt; DBLOGIN USERIDALIAS gg_source DOMAIN OracleGoldenGate\nOGG&gt; ADD SCHEMATRANDATA HR\n2026-07-26 09:41:07  INFO    OGG-01788  SCHEMATRANDATA has been added on schema HR.\n2026-07-26 09:41:07  INFO    OGG-10154  Schema level PREPARECSN set to mode NOWAIT on schema HR.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If you do not want instantiation CSN filtering for a schema, you can opt out explicitly with <code>ADD SCHEMATRANDATA HR PREPARECSN NONE<\/code>. It is the only way to get a table with zero rows in <code>dba_apply_instantiated_objects<\/code> after a load. Everything else on this page happens by default.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The full clause, <code>PREPARECSN {WAIT | LOCK | NOWAIT | NONE}<\/code>, controls how invasive the preparation is on a live table:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Mode<\/th><th>Behavior<\/th><\/tr><\/thead><tbody><tr><td><code>NOWAIT<\/code><\/td><td>Prepares immediately without waiting on in-flight transactions; the default.<\/td><\/tr><tr><td><code>WAIT<\/code><\/td><td>Waits for currently open transactions on the table to complete before marking it prepared.<\/td><\/tr><tr><td><code>LOCK<\/code><\/td><td>Takes a lock on the table to guarantee a clean preparation point; the most disruptive, reserved for tables where <code>WAIT<\/code> cannot be tolerated.<\/td><\/tr><tr><td><code>NONE<\/code><\/td><td>Disables CSN instantiation.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">For an OLTP table with a lot of concurrent DML, <code>WAIT<\/code> or <code>LOCK<\/code> can stall application sessions while GoldenGate waits for or takes the lock. <code>NOWAIT<\/code> is almost always the correct option.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Confirm both tables are prepared:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>OGG&gt; INFO SCHEMATRANDATA HR\nSchema HR has 2 prepared tables for instantiation.<\/code><\/pre>\n\n\n\n<h3 id=\"2-start-the-extract\" class=\"wp-block-heading\">2. Start the extract<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Capture has to be running before the export, so that any change committed during and after the dump is safely in the trail:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>OGG&gt; START EXTRACT EXTA<\/code><\/pre>\n\n\n\n<h3 id=\"3-wait-for-long-running-transactions-to-finish\" class=\"wp-block-heading\">3. Wait for long running transactions to finish<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A transaction that began before the extract could be missed, so wait for every long running transaction to finish before exporting. See <a href=\"https:\/\/www.dbi-services.com\/blog\/checking-long-running-transactions-in-goldengate\/\" target=\"_blank\" rel=\"noopener noreferrer\">Checking Long Running Transactions in GoldenGate<\/a> for how to list them with the <code>adminclient<\/code> and the REST API.<\/p>\n\n\n\n<h3 id=\"4-export-without-flashback_scn\" class=\"wp-block-heading\">4. Export without <code>FLASHBACK_SCN<\/code><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>expdp hr\/*** dumpfile=hr.dmp schemas=HR<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Without the <code>FLASHBACK_SCN<\/code> clause, each table\u2019s boundary will be the SCN as of which Data Pump reads it during the export, recorded automatically because the table was prepared with <code>PREPARECSN<\/code>.<\/p>\n\n\n\n<h3 id=\"5-import-on-the-target\" class=\"wp-block-heading\">5. Import on the target<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>impdp gg_target\/*** dumpfile=hr.dmp full=y<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">As part of this import, Data Pump populates <code>dba_apply_instantiated_objects<\/code> for every prepared table it loads. No extra option is needed.<\/p>\n\n\n\n<h3 id=\"6-retrieve-the-instantiation-csn-for-each-table\" class=\"wp-block-heading\">6. Retrieve the instantiation CSN for each table<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Let\u2019s query the table that replaces the SCN you used to write down by hand:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>SELECT source_object_owner, source_object_name, instantiation_scn\nFROM dba_apply_instantiated_objects\nWHERE source_object_owner = 'HR'\nORDER BY 1, 2;<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>SOURCE_OBJECT_OWNER  SOURCE_OBJECT_NAME  INSTANTIATION_SCN\n-------------------- ------------------- -----------------\nHR                   DEPARTMENTS                  17662585\nHR                   EMPLOYEES                    17662582<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The two tables come from the same export, but with <strong>two different <code>INSTANTIATION_SCN<\/code><\/strong>. Without <code>FLASHBACK_SCN<\/code> on the export, each table was read (and stamped) at its own point as the dump progressed. That per-table granularity is the entire point, and it is exactly what a single <code>AFTERCSN<\/code> could never express.<\/p>\n\n\n\n<h3 id=\"7-configure-the-replicat-and-start-it-without-aftercsn\" class=\"wp-block-heading\">7. Configure the replicat and start it, without <code>AFTERCSN<\/code><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>REPLICAT REPA\nDBOPTIONS ENABLE_INSTANTIATION_FILTERING\nUSERIDALIAS gg_target DOMAIN OracleGoldenGate\nMAP HR.*, TARGET HR.*;<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>OGG&gt; START REPLICAT REPA<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>DBOPTIONS ENABLE_INSTANTIATION_FILTERING<\/code> tells the replicat to look each table\u2019s boundary in <code>dba_apply_instantiated_objects<\/code> instead of expecting an <code>AFTERCSN<\/code> on the start command. The replicat discards trail records committed at or before its own boundary and applies everything after it. Both tables are in sync with the source, with no flashback SCN ever chosen.<\/p>\n\n\n\n<h2 id=\"same-initial-load-with-flashback_scn\" class=\"wp-block-heading\">Same initial load with <code>FLASHBACK_SCN<\/code><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let\u2019s run the same initial load again for a second schema, but add <code>FLASHBACK_SCN<\/code> to the export and watch what changes in the instantiation table. Pick an SCN and pass it to <code>expdp<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>expdp system\/*** schemas=HR2 flashback_scn=17663448 dumpfile=hr2.dmp\nimpdp system\/*** dumpfile=hr2.dmp full=y<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then the same step 6 query against the target:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>SELECT source_object_owner, source_object_name, instantiation_scn\nFROM dba_apply_instantiated_objects\nWHERE source_object_owner = 'HR2'\nORDER BY 1, 2;<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>SOURCE_OBJECT_OWNER  SOURCE_OBJECT_NAME  INSTANTIATION_SCN\n-------------------- ------------------- -----------------\nHR2                  DEPARTMENTS                  17663448\nHR2                  EMPLOYEES                    17663448<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">This time, both tables carry the <strong>same instantiation CSN<\/strong>, and it is <strong>exactly the <code>FLASHBACK_SCN<\/code><\/strong> (<code>17663448<\/code>). <code>FLASHBACK_SCN<\/code> pins the whole export to one consistent point in time, so Data Pump stamps every table in the dump with that single SCN. Please note that <code>FLASHBACK_SCN<\/code> is still not <em>required<\/em> for the instantiation mechanism to work. It only gives a consistent export.<\/p>\n\n\n\n<h2 id=\"same-initial-load-with-preparecsn-none\" class=\"wp-block-heading\">Same initial load with <code>PREPARECSN NONE<\/code><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let\u2019s see what happens when we disable instantiation, by preparing a third schema with <code>PREPARECSN NONE<\/code> and run the same export and import:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>OGG&gt; ADD SCHEMATRANDATA HR3 ALLCOLS, PREPARECSN NONE\nINFO OGG-10154  Schema level PREPARECSN set to mode NONE on schema \"HR3\"\nOGG&gt; INFO SCHEMATRANDATA HR3\nSchema \"HR3\" has 0 prepared tables for instantiation<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>expdp system\/*** schemas=HR3 dumpfile=hr3.dmp\nimpdp system\/*** dumpfile=hr3.dmp full=y<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The import succeeds and the rows land on the target as normal, but the instantiation table stays empty for this schema:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>SELECT source_object_owner, source_object_name, instantiation_scn\nFROM dba_apply_instantiated_objects\nWHERE source_object_owner = 'HR3';\n\nno rows selected<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">In that case, a replicat running with <code>DBOPTIONS ENABLE_INSTANTIATION_FILTERING<\/code> would find no boundary for these tables and therefore would not filter them. It would apply every trail record it sees, including changes the dump already contains.<\/p>\n\n\n\n<h3 id=\"the-boundary-outlives-the-schema\" class=\"wp-block-heading\">The boundary outlives the schema<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>dba_apply_instantiated_objects<\/code> is independent from the schema it describes. Dropping the target schema with <code>DROP USER ... CASCADE<\/code> and recreating it does <strong>not<\/strong> clear its row:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>SQL&gt; DROP USER hr4 CASCADE;\n\nUser dropped.\n\nSQL&gt; CREATE USER hr4 IDENTIFIED BY Welcome1;\n\nUser created.\n\nSQL&gt; SELECT source_object_owner, source_object_name, instantiation_scn\n     FROM dba_apply_instantiated_objects WHERE source_object_owner='HR4';\n\nSOURCE_OBJECT_OWNER  SOURCE_OBJECT_NAME  INSTANTIATION_SCN\n-------------------- ------------------- -----------------\nHR4                  EMPLOYEES                    52356545<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">A stale boundary from a previous initial load can silently attach itself to the next import of an object with the same name. The same table, re-imported a second time from a dump whose source was never prepared with <code>PREPARECSN<\/code>, does not delete the row from the first prepared initial load.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A replicat with <code>ENABLE_INSTANTIATION_FILTERING<\/code> reading this table afterward would filter every record against a boundary that has no relationship to what the last import actually put on the target.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A command exists in the <code>adminclient<\/code> to clear the instantiation table:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>OGG&gt; DBLOGIN USERIDALIAS gg_target DOMAIN OracleGoldenGate\nOGG&gt; CLEAR INSTANTIATION CSN FOR hr.employees FROM PDB_SOURCE\nINFO OGG-10464  Instantiation CSN has been cleared successfully.<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>SQL&gt; SELECT source_object_owner, source_object_name, instantiation_scn\n     FROM dba_apply_instantiated_objects WHERE source_object_owner='HR';\nno rows selected<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Remember to check the <code>dba_apply_instantiated_objects<\/code> view before reusing a target schema name for an initial load.<\/p>\n\n\n\n<h2 id=\"when-should-i-still-set-instantiation-scn-by-hand-\" class=\"wp-block-heading\">When should I still set instantiation SCN by hand ?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">There are multiple scenarios where automatic instantiation filtering does not work.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If your initial load is not done by Data Pump. GoldenGate initial extract, a manual <code>INSERT ... SELECT<\/code> over a database link, transportable tablespaces, do not alter the <code>dba_apply_instantiated_objects<\/code> view.<\/li>\n\n\n\n<li>If the workload during the initial load is not just DML. Instantiation filtering does not work on DDL, for instance.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">In that case, you can either go back to the <code>FLASHBACK_SCN<\/code> method, or set the instantiation CSN by hand in the <code>adminclient<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>OGG&gt; DBLOGIN USERIDALIAS gg_target DOMAIN OracleGoldenGate\nOGG&gt; SET INSTANTIATION CSN FOR hr.legacy_orders CSN 12345678 FROM PDB_SOURCE<\/code><\/pre>\n\n\n\n<h2 id=\"common-questions\" class=\"wp-block-heading\">Common questions<\/h2>\n\n\n\n<h3 id=\"a-table-added-after-preparecsn-never-gets-a-boundary\" class=\"wp-block-heading\">A table added after <code>PREPARECSN<\/code> never gets a boundary<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If a table is created on the source after you ran <code>ADD SCHEMATRANDATA HR<\/code>, it is not part of that preparation. Exporting it later with <code>expdp<\/code> means Data Pump has no CSN bookkeeping to carry into the dump, and <code>dba_apply_instantiated_objects<\/code> is not populated during import. The fix is to run <code>ADD TRANDATA ...<\/code> before exporting it.<\/p>\n\n\n\n<h3 id=\"removing-the-parameter-once-instantiation-is-complete\" class=\"wp-block-heading\">Removing the parameter once instantiation is complete<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>DBOPTIONS ENABLE_INSTANTIATION_FILTERING<\/code> can be removed from the replicat parameter file once it has processed every transaction past the instantiation CSN of every table it maps (there is no harm in leaving it in indefinitely).<\/p>\n\n\n\n<h2 id=\"summary\" class=\"wp-block-heading\">Summary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The instantiation CSN is a per-table replication boundary, stored in <code>dba_apply_instantiated_objects<\/code> on the target, compared against each record\u2019s commit CSN.<\/li>\n\n\n\n<li>Data Pump stamps it automatically on <code>impdp<\/code>, because <code>ADD SCHEMATRANDATA<\/code>\/<code>ADD TRANDATA<\/code> prepare tables for instantiation by default (<code>PREPARECSN NOWAIT<\/code>). Use <code>PREPARECSN NONE<\/code> to not use instantiation SCN.<\/li>\n\n\n\n<li>Because that boundary is per table and set by Data Pump, <code>FLASHBACK_SCN<\/code> and <code>AFTERCSN<\/code> are no longer needed just to define where the dump ends and replication begins. Retrieve the boundary with a query instead of tracking an SCN by hand.<\/li>\n\n\n\n<li><code>FLASHBACK_SCN<\/code> still has a use (making one large export internally consistent), but it is no longer needed just to drive the replication boundary. Data Pump records that boundary either way.<\/li>\n\n\n\n<li>The boundary outlives the schema it describes. Dropping and recreating a target schema does not clear its row in <code>dba_apply_instantiated_objects<\/code>. Check the view, and use <code>CLEAR INSTANTIATION CSN<\/code> if you see stale rows.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>For more than ten years (GoldenGate 12.2, released in 2015), GoldenGate has provided a way of performing initial load of tables with a per-table instantiation CSN. But when migrating a database or just performing the initial load of a single table to prepare a GoldenGate replication, the known procedure is very often still the old [&hellip;]<\/p>\n","protected":false},"author":152,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[1],"tags":[3827,3804,4239,4237,4232,734,1837,3781,4238,328,1403,2522,4236,3730,4233,96,4235,3976,4240,4234],"type_dbi":[],"class_list":["post-47082","post","type-post","status-publish","format-standard","hentry","category-non-classifiee","tag-3827","tag-26ai","tag-aftercsn","tag-atcsn","tag-csn","tag-datapump","tag-expdp","tag-extract","tag-flashback_scn","tag-goldengate","tag-impdp","tag-initial-load","tag-instantiation","tag-ogg","tag-ora-01555","tag-oracle","tag-preparecsn","tag-replicat","tag-scn","tag-snapshot-too-old"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v28.5 (Yoast SEO v28.5) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>GoldenGate Instantiation CSN Explained - dbi Blog<\/title>\n<meta name=\"description\" content=\"Why GoldenGate stamps a per-table instantiation CSN during Data Pump import, removing the need for FLASHBACK_SCN and AFTERCSN.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"GoldenGate Instantiation CSN Explained\" \/>\n<meta property=\"og:description\" content=\"Why GoldenGate stamps a per-table instantiation CSN during Data Pump import, removing the need for FLASHBACK_SCN and AFTERCSN.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-28T06:12:00+00:00\" \/>\n<meta name=\"author\" content=\"Julien Delattre\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Julien Delattre\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/\"},\"author\":{\"name\":\"Julien Delattre\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/764ab019cc9dec42655b4c6b9b8e474e\"},\"headline\":\"GoldenGate Instantiation CSN Explained\",\"datePublished\":\"2026-09-28T06:12:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/\"},\"wordCount\":1565,\"commentCount\":0,\"keywords\":[\"26\",\"26ai\",\"aftercsn\",\"atcsn\",\"csn\",\"DataPump\",\"expdp\",\"extract\",\"flashback_scn\",\"GoldenGate\",\"impdp\",\"Initial load\",\"instantiation\",\"ogg\",\"ORA-01555\",\"Oracle\",\"preparecsn\",\"replicat\",\"scn\",\"snapshot too old\"],\"articleSection\":[\"Non classifi\u00e9(e)\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/\",\"name\":\"GoldenGate Instantiation CSN Explained - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2026-09-28T06:12:00+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/764ab019cc9dec42655b4c6b9b8e474e\"},\"description\":\"Why GoldenGate stamps a per-table instantiation CSN during Data Pump import, removing the need for FLASHBACK_SCN and AFTERCSN.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-instantiation-csn-explained\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"GoldenGate Instantiation CSN Explained\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/764ab019cc9dec42655b4c6b9b8e474e\",\"name\":\"Julien Delattre\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g\",\"caption\":\"Julien Delattre\"},\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/juliendelattre\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"GoldenGate Instantiation CSN Explained - dbi Blog","description":"Why GoldenGate stamps a per-table instantiation CSN during Data Pump import, removing the need for FLASHBACK_SCN and AFTERCSN.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/","og_locale":"en_US","og_type":"article","og_title":"GoldenGate Instantiation CSN Explained","og_description":"Why GoldenGate stamps a per-table instantiation CSN during Data Pump import, removing the need for FLASHBACK_SCN and AFTERCSN.","og_url":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/","og_site_name":"dbi Blog","article_published_time":"2026-09-28T06:12:00+00:00","author":"Julien Delattre","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Julien Delattre","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/"},"author":{"name":"Julien Delattre","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/764ab019cc9dec42655b4c6b9b8e474e"},"headline":"GoldenGate Instantiation CSN Explained","datePublished":"2026-09-28T06:12:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/"},"wordCount":1565,"commentCount":0,"keywords":["26","26ai","aftercsn","atcsn","csn","DataPump","expdp","extract","flashback_scn","GoldenGate","impdp","Initial load","instantiation","ogg","ORA-01555","Oracle","preparecsn","replicat","scn","snapshot too old"],"articleSection":["Non classifi\u00e9(e)"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/","url":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/","name":"GoldenGate Instantiation CSN Explained - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2026-09-28T06:12:00+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/764ab019cc9dec42655b4c6b9b8e474e"},"description":"Why GoldenGate stamps a per-table instantiation CSN during Data Pump import, removing the need for FLASHBACK_SCN and AFTERCSN.","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-instantiation-csn-explained\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"GoldenGate Instantiation CSN Explained"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/764ab019cc9dec42655b4c6b9b8e474e","name":"Julien Delattre","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g","caption":"Julien Delattre"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/juliendelattre\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/47082","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/152"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=47082"}],"version-history":[{"count":3,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/47082\/revisions"}],"predecessor-version":[{"id":47088,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/47082\/revisions\/47088"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=47082"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=47082"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=47082"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=47082"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}