Symptom
When using the Cribl Stream Database Source to query an Oracle database, large numeric column values (typically 17–19 digit integers) arrive in Cribl with different values than those stored in the source database. The discrepancy does not appear when the same data is queried by other tools. Affected values often show trailing zeros, indicating silent rounding rather than truncation.
Environment
- Cribl Stream (all versions)
- Deployment type: Cloud (Managed AWS) or self-managed
- Component: Database Source (Oracle driver via
node-oracledb) - Source database: Oracle
Resolution
Wrap each affected large-integer Oracle column in TO_CHAR(...) within the Database Source SQL query. This instructs the Oracle driver to return the value as a string, bypassing JavaScript numeric conversion and preserving full precision.
- Navigate to the Database Source configuration in Cribl Stream.
- Open the SQL Query field for the relevant collection job.
- Modify the
SELECTstatement to cast each large numeric column to a character type usingTO_CHAR:SELECT TO_CHAR(root_process_id) AS root_process_id, TO_CHAR(parent_process_id) AS parent_process_id, -- ... other columns ... FROM <your_table> - Click Save and deploy the configuration.
- Re-run the collection job and compare the resulting field values against the source database to confirm they now match.
Note: The column value arrives in Cribl as a string type after applying TO_CHAR. If a downstream destination or pipeline function requires the value to be numeric, cast it back using parseInt() or a similar expression — however, be aware that casting back to a JavaScript number will reintroduce precision loss for values exceeding Number.MAX_SAFE_INTEGER (2^53 - 1). For destinations such as XSIAM that accept string-typed ID fields, keeping the value as a string is the correct long-term approach to preserve fidelity.
Cause
Cribl's Oracle database driver (node-oracledb) returns NUMBER columns as JavaScript Number (double-precision floating point) by default. JavaScript's Number type can only represent integers exactly up to Number.MAX_SAFE_INTEGER = 2^53 - 1 (9,007,199,254,740,991 — approximately 9 quadrillion). Oracle IDs that are 17–19 digits routinely exceed this limit.
When node-oracledb converts such a value to a JavaScript Number, the excess precision is silently rounded to the nearest representable double. This rounding is irreversible within the Cribl pipeline. The driver's internal fetchTypeHandler automatically string-casts CLOB, NCLOB, and BLOB column types, but does not apply the same treatment to NUMBER columns — they are always returned as JavaScript doubles unless the SQL query itself returns the value as a character type.
The discrepancy is not visible in tools such as Splunk that use different Oracle drivers or that natively handle Oracle NUMBER as arbitrary-precision types before serializing to string.
Last Validated
Cribl Stream 4.18.1
Additional Information
- The Oracle
TO_CHARfunction is the standard workaround for this class of problem across allnode-oracledb-based integrations. See the node-oracledb documentation on fetching numbers for driver-level details. - This issue applies to any Oracle
NUMBERcolumn whose value exceeds9,007,199,254,740,991. Common examples include process IDs, event sequence numbers, and other high-cardinality system-generated identifiers. - Related Cribl docs: Database Source
