Oracle SQL Bind Variables missing after Migration from Managed to SaaS (DPS Licensing)

[MikeB]

Hi everyone,

We recently completed a migration from Dynatrace Managed to Dynatrace SaaS (currently using DPS licensing), and we’ve encountered a discrepancy regarding SQL bind variables in Oracle databases.

The Issue:

While bind variables are captured and visible for our MySQL databases, they are completely missing from the traces of our Oracle databases.

The strange part is that when we were on the Managed environment, bind variables for these exact same Oracle databases were captured and displayed correctly without any issues.

Environment & Technologies:

• Database: Oracle Database (multiple versions).

• Deployment: Dynatrace SaaS.

• Licensing: DPS (Dynatrace Platform Subscription).

• Monitoring: One Agent (latest versions).

Troubleshooting Performed:

1. Global Settings: Verified that Capture SQL bind values is enabled under Settings > Server-side service monitoring > Deep monitoring > Database.

2. Toggle Test: We have tried toggling the global setting Off and On again to force a configuration refresh.

3. Service-Specific Check: Confirmed that there are no service-level overrides disabling the capture.

4. Comparison: As mentioned, MySQL traces in the same environment do show bind variables, suggesting the global configuration is active.

Questions:

• Are there any known differences in how One Agent handles Oracle bind variables in a SaaS/DPS environment compared to Managed?

• Could this be related to specific JDBC driver versions or Oracle-specific deep monitoring flags that might have defaulted differently during the migration?

• Is there a specific security/privacy setting in the SaaS UI that might be masking Oracle data specifically?

Would appreciate any insights or if anyone has encountered similar behavior after a Managed-to-SaaS move.

Thanks!

[michiel_otten]

Hi there,

The technology support table looks the same for managed an SaaS. As long aas your JDBC driver is 4+ it should work.
Other masking of data would imo be captured and displayed as <masked>, but this is also something you do not see.
You can check it here I would suggest creating a support ticket for this. 

The only thing I can think of is that you're getting throttled. From the docs:

Additionally, this feature can capture a lot of data in the absolute sense. Heavy usage of this feature means that you will run out of the included trace volume for your Full-Stack monitored applications faster. In other words, heavy usage can lower your trace capture rate. To mitigate this, you should either use this feature for troubleshooting only or you can opt into Extended trace ingest to accommodate the increased data volume.

You can use the MDA to investigate whether your'e trace capture rate is very low..

KR.
Michiel