Oracle Constraints during a RAM installation
I am working with a customer who is planning out a RAM installation on Oracle. They had the following set of constraints for an oracle installation and need some guidance on the impact of these constraints:
******************** Assets Database Is the SID required to be ramdb? "ramdb" violates our standard naming convention, and cannot accommodate separate databases for Test, QV and Production. Are the CONNECT and RESOURCE roles required by name, or just the privileges granted by the roles. We have a standard role that encompasses all the privileges in both those roles, as well as a few others. ALTER SESSION CREATE CLUSTER CREATE DATABASE LINK CREATE INDEXTYPE CREATE LIBRARY CREATE MATERIALIZED VIEW CREATE OPERATOR CREATE PROCEDURE CREATE SEQUENCE CREATE SESSION CREATE SYNONYM CREATE TABLE CREATE TRIGGER CREATE TYPE CREATE VIEW The UNLIMITED TABLESPACE privilege will not be granted. The schema will be granted unlimited quota on its tablespace instead. Is this OK? In this day and age of security and standards, why do you require a specific schema name (RAMSCHEMA)? ************** Asset Lifecycle Database Can this schema be in the same database as RAMSCHEMA? If not, is the SID required to be rtcdb? "rtcdb" violates our standard naming convention, and cannot accommodate separate databases for Test, QV and Production. Are the CONNECT and RESOURCE roles required by name, or just the privileges granted by the roles. We have a standard role that encompasses all the privileges in both those roles, as well as a few others. ALTER SESSION CREATE CLUSTER CREATE DATABASE LINK CREATE INDEXTYPE CREATE LIBRARY CREATE MATERIALIZED VIEW CREATE OPERATOR CREATE PROCEDURE CREATE SEQUENCE CREATE SESSION CREATE SYNONYM CREATE TABLE CREATE TRIGGER CREATE TYPE CREATE VIEW The ANY privileges are not required for a schema to modify its own objects. Why are they required? This violates regular Information Security policies because they allow the user to modify objects owned by SYS and SYSTEM. ALTER ANY INDEX ALTER ANY TABLE CREATE ANY INDEX DELETE ANY TABLE DROP ANY INDEX DROP ANY TABLE INSERT ANY TABLE UPDATE ANY TABLE The UNLIMITED TABLESPACE privilege will not be granted. The schema will be granted unlimited quota on its tablespace instead. Is this OK? |
Accepted answer
RAM has not been tested with anything other than the stated requirements. In RAM's case the database is actually maintained by RAM itself. It manages it and can at any create or delete tables, etc. That is why the RAM user needs to have complete control of the schema.
RAM requires everything to be in one schema so that it can manage it without interfering with other schemas and applications in the database. The schema name is hard-coded in the code. The sid can be what you want it to be. It is not required to be ramdb. It is the user you supply to the RAM application (in setup) that needs the complete privileges for the RAMSCHEMA schema. How those privileges are given to the user (either thru roles or explicitly) is up to the customer. As for the set of privileges that you listed being sufficient, we don't know. It has not been tested with anything other than owner or db admin. We can't answer for the Asset Lifecycle database. It has not been investigated as to whether it can share the same database or not. ed Neubecker selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.