We now support Oracle EBS on RAC.
We have fixed a bug with very high precision NUMBER values from Oracle. Previously, we either truncated these values or did not sync them to the destination. Now, we sync these values to the destination without truncating them, but we change the column type to STRING to accomodate high precision values. Re-sync any tables where you have previously synced high precision NUMBER values to ensure data integrity.
You can now configure your Oracle, Oracle RDS, and Oracle EBS connectors using the Fivetran REST API. This feature is in BETA and available only for Standard and Enterprise accounts.
We have a new method for counting the rows in a table that is much faster than our old method. Previously, the query we used to count rows would sometimes time out after 30 minutes, causing the sync to fail. The new method’s speed makes your syncs much more reliable. If the new method fails, we will fall back to the old method.
We now support Flashback as an incremental update mechanism. To learn more, see our Oracle documentation.
We have a new way to import tables with fewer than 1 million rows. Our new method will make initial and historical syncs much faster and reduce the resource load on your Oracle database. We will roll out this change over the next few weeks.
We have fixed a bug where we mapped NUMBER column values incorrectly if the column was defined with no precision or scale in the source database. Previously, these values may have been truncated in the destination, but they are now copied to the destination exactly as they appear in the source database. We will roll out this fix over the next few weeks. Once the fix rolls out to you, re-sync any tables where you have previously synced NUMBER column values to ensure data integrity.
Oracle E-Business Suite (EBS) is an enterprise resource planning system developed by Oracle.
We have fixed a bug with FLOAT, REAL, and DOUBLE PRECISION column values. Previously, these values may have been truncated in the destination, but they are now copied to the destination exactly as they appear in the source database.
We are rolling out support for
TRUNCATE statements. When we encounter a
TRUNCATE statement for one of your selected tables, we set the
_fivetran_deleted column value to
TRUE for every row in that table that predates the
We now create a task in your Fivetran dashboard that reminds you to re-sync your data when you have a transaction that has been uncommitted for more than six hours. The re-sync ensures that we do not miss any data from our syncs.
We are rolling out support for RAW column types.
We now support the TIMESTAMP WITH LOCAL TIME ZONE column type. It will appear as TIMESTAMP in your destination.
We’ve fixed some bugs with NUMBER and FLOAT column types with high precision or scale. Previously, these values might have been rounded, but they are now copied to the destination exactly as they appear in the source database. Oracle 11g is an exception to this fix because LogMiner incorrectly rounds some values.
We no longer re-sync tables when we detect
GRANTDDL operations. We will roll out this change to all customers over the next four weeks.
The two hour limit on importing tables has been removed resulting in fewer syncs appearing as “Rescheduled” in the dashboard.
Syncs that fail due to falling behind processing archive logs during the incremental update phase will appear as “Rescheduled” in the dashboard and are attempted again immediately. Previously, there was no indication of a problem.
These changes will be rolled out over the next month.
If you have a logging service connected to your Fivetran account, the import progress of your tables in the event logs will be visible in your logs as an
import_progressevent. Table names will be in either the
IN_PROGRESSstate, depending on their sync status. Tables that are not reported in the event have not started their import.
We have reduced our minimum archive log retention period to 3 hours. We still recommend setting a retention time of more than 24 hours.
We’ve fixed a few bugs that slowed down the import process for partitioned tables. To take advantage of the new speed improvements, you must enable
SELECTaccess to the
DBA_SEGMENTSsystem views. A new warning message on the Alerts page of your Fivetran dashboard will prompt you to enable access.
- Table import progress is now available in the logs. Table names are included in one to two lists: “complete” or “inProgress”.
- We have optimized our log miner query. The query now only selects for and processes tables which have changes inside the window for which log miner is active.
- Incremental Updates should now make progress even when the connection to the server is unstable. This will reduce the number of failed syncs due to temporary network issues.
Improvement to fast import strategy
Our quick import strategy now works for tables stored in
BIGFILE tablespaces. However, this requires access to another
dba_tablespaces. You will receive a one-time warning requesting access to
dba_tablespaces in your dashboard
the next time your Oracle connector runs.
If you have previously given us permission for
dba_extents and choose not to provide access to
your connector’s initial imports will still benefit from the quicker imports but may not sync data from
tables stored in
Systems Views Permission setup test will now include information about
dba_tablespaces, in addition to
dba_extents, if you choose not to provide access to them.
Changes to connection method requirements for Oracle connectors
Going forward, all connectors for Oracle databases versions 12.1 and earlier will be required to connect via SSH tunnels. This connection method ensures that all connections to your databases are secure and encrypted. If you do not currently connect via SSH tunnel, you will be required to update your connection method to continue syncing data. To set up an SSH tunnel, please reach out to your network administrator.
We have added support for table-level supplemental logging. This will reduce overhead when syncing with Fivetran if you only want to replicate some of your tables in an Oracle database.
We can now sync changes to primary keys.
- For each table where the primary key is expected to change, you need to run the following query:
ALTER TABLE "<schema>"."<table>" ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS
- If you don’t configure the logging data correctly, you will receive a warning when Fivetran encounters a primary key change. The warning will give you customized instructions.
- This improvement will roll out to customers over the next month.
Fivetran has significantly increased the speed of initial syncs in Oracle by leveraging information from a system metadata table called
TIMESTAMP data types will now be represented as
TIMESTAMP WITHOUT TIME ZONE types in the destination. Since
DATE column types are also timezone unaware, dates that lack a time component will be interpreted as
TIMESTAMP WITHOUT TIME ZONE types as well. This update is currently only available for Snowflake warehouses.
Oracle’s DATE data type is really a TIMESTAMP WITH TIME ZONE. It is a common convention to use midnight as a way to represent dates in Oracle. We now detect this pattern and convert these values to DATE in the destination. If you currently have an Oracle connector, you will need to change the existing TIMESTAMP WITH TIME ZONE columns in your destination to DATE columns in order to take advantage of this feature.
When performing the initial sync of large tables from Oracle RAC sources, we now use smaller block ranges to avoid getting interrupted by multi-node transactions.
We receive changed data from Oracle using LogMiner, and we use the system change number (SCN) as a cursor. We now use smaller ranges of SCNs to reduce the probability of a failed request.
You now get a warning in your Fivetran dashboard when no database transactions have been committed for over an hour after the start of the transaction.