Oracle Database Vault is employed for approximately 300 different applications in a large banking system, catering to 300 different business needs, resulting in a very long list of diverse business cases. The variety is vast, and there is nothing typical when it comes to middle-sized, large, or big banks.
Oracle Database Vault is a robust, high-quality DBMS capable of providing solutions for database management for many different application systems. It can be very simple or very complex, and it serves as a general solution for different types of applications and uses, including data warehousing and beyond.
Oracle Database Vault has been used in my organization for tens of years, as Oracle is a major DBMS for most of the application systems not on IBM mainframe, with the core business running on IBM mainframe with DB2 for z/OS, while most other applications and systems in the open environment work with Oracle. I think it is more like 40 years.
The implementation of Oracle Database Vault can be simple, but if you want to provide DB services for more complex applications, it gets complex. You can start with a simple deployment, but if you aim for real volumes, response times, and work with many applications, the deployment can be quite complex. It really depends.
The time frame for deployment of Oracle Database Vault depends on various factors, and it can vary significantly for different solutions and complexities, making it impossible to give a specific number. In an environment, implementation could take as little as two weeks, and I do not think it can be more than that—the maximum, I think.
I am not really familiar with IBM DB2 on Cloud or DB2 Big SQL, as I have never worked with it.
I think the technical support for Oracle is very good.
I am not really at a professional level working with Oracle Database, as Oracle is just a team and sometimes we touch the ground, but I am not working with Oracle. I never dive deep into the professional issues with Oracle.
Oracle Database Vault is a relational database management system, which is implemented mostly on Linux, Windows, Unix, and there is a z/OS option as well, but it is very rarely used. It is similar to DB2, so more or less the histories of both RDBMSs are quite similar, and there are many similarities, but also different things. I am not really at a professional level talking about Oracle.
I mostly work with the on-premises version in the banking sector, where most solutions are used as on-premises, not cloud.
The integration of Oracle Database Vault with third-party tools typically involves providing connectivity and proper setup to connect with different application systems. I find it is very similar to other DBMSs such as MS SQL, MySQL, or Postgres. You set up the usual connectivity and proper parameters for the database, such as buffer pools and memory, and then it works fine. I would not say there is anything different from other databases.
When it comes to using Realms in Oracle Database Vault, there are two options for dealing with security inside the database and also an option to use a separate product for security issues. Organizations can decide according to their needs and priorities what to implement, but tools for security issues regarding sensitive data are built inside the database.
Command rules in Oracle Database Vault help create security features by allowing you to define user security needs, but they operate during the database's runtime. You do not have a person sitting to provide commands. Instead, you create a general set of rules using the commands, and everything operates according to those commands once set up.
In addressing insider threats, Oracle Database Vault effectively prevents insiders from seeing sensitive data. A person working in IT, for example, typically does not have authorization to even look at production data, while sensitive data in development environments is usually hashed or changed to prevent visibility of production-sensitive data.
The metrics I use to measure the success of Oracle Database Vault usually involve SLAs. For instance, 90-95% of SQL queries or transactions should be completed within one second in terms of response time and CPU usage, while a small percentage may take one to three seconds. I measure all parameters for transactions running online to check if I am meeting my SLA standards.