Skip to main content
Delphix

Virtual Database (VDB) Performance - Frequently Asked Questions

Q: What can I do proactively to ensure acceptable virtual database (VDB) performance?

Check the Performance Tuning section of the Delphix documentation for your engine and see what tuning parameters are recommended. There are a variety of recommendations we provide for the network, storage, VM environment and your target host. Check out Performance Tuning in our main documentation for more information.

Q: Why doesn't my VDB have the same performance as our physical production system?

When comparing two different environments, it's important to understand the differences between them and the implications of those differences. Production systems may be assigned a higher class of storage, have more memory, have better underlying hardware or less contention (if also a VM), etc. Aside from that, there may be differences in the configuration at the database or application levels that are impacting the perceived VDB performance. It's important to ensure that caching options are comparable, the appropriate indices are created, network connectivity to the application layer is comparable, etc.

Q: If I need Delphix's assistance with analyzing the VDB's performance, what information do I need to provide?

If you are still having difficulty with performance after implementing the recommended tuning and taking into account the environmental factors, we can certainly help. To help us identify the problem as quickly as possible, we'd recommend having the following available:

  • A clear description of the problem - "Reporting jobs take longer than expected to run on a particular VDB"
  • Target performance - "Our reporting job should complete within 2 hours"
  • Current performance - "The reporting jobs have been taking 8 hrs for the last six weeks"
  • A repeatable, representative test that can be run that exhibits the problem with performance. This could be a full job, a portion of a job, a query, etc. Whatever is selected should be something that's safe to run as needed and, if improved, will help with the core problem.
  • Is the problem consistent? If not, are there any particular workloads or times of day when the problem manifests?
  • Has the performance ever been acceptable? If so, when and have any changes been made around the time it degraded?
  • A description of the target environment: storage, network configuration, cpu/memory, etc.
  • Reports from the database or application showing it's interpretation of the performance. Oracle AWR reports, for instance. If the problem is intermittent, it is beneficial to have both a "good" and a "bad" sample.
  • A support bundle from the engine

This information will help us give you the best possible support in assisting with your performance issue. It's also important to note that assistance may be required from your Network, Systems or VM teams if there are problems suspected in any or all of those areas. It is not uncommon to have to look at something on the target that requires root access or data from a console session on the ESX host. Having someone available to assist with that, or having the permissions in advance, can help streamline the process.

Q: Are there any known performance issues? How can I be aware of them?

Generally we will have any known issues in the relevant section of the documentation. Issues for more specific configurations may have a Knowledge Base article written for them like:

How to Mitigate Multi-Block Read Performance on Oracle 10g

You can find these by searching on our support site.

If there is a widely applicable problem in a specific version of Delphix, as the result of a bug for example, we'll send out a Technical Bulletin alerting you to the fact. Also, you can check the Delphix Community forums.

  • Was this article helpful?