The database I am using is Oracle 11g Express Edition release 2.
I created 2 schemas in the same instance xe. They all have the same tables names and sequences names and stored procedures and stored functions and views names. But the tables structures and views texts are different ( there is some modifications between them ).
The reason for the creation of these two schemas is because our project has two versions. So the first schema is used for the first version , and the second schema was created for the second version. The mechanism of our web application Spring project is that whenever a connection is made through the web application login page then a corresponding Oracle user is making a connection according to the login entered ; so there is no fixed credential connection , there are Oracle users corresponding to each web application login.
So in order for each user to work with each database objects then I created public synonyms for every objects , and granted permissions to them for each user. But the database objects are owned by the schema I mentioned at the beginning. Now my problem is this : our customer wants the two project versions to be run on a same instance ( same computer server ). So one of the project version cannot run because the public synonyms can only refer to a particular schema owner. So how to make the public synonyms work for each schema ?
In short, you can't. However, you can always use a distinct synonym name to identify the object.
Something similar to below:
create public synonym structures_v1 for schema1.structures;
create public synonym structures_v2 for schema2.structures;
Oracle provides 2 totally different technologies for this situation (which comes to my mind):
Editions (and Edition Based Redefinition)
PDBs
With Editions you can create the same Object once in each Edition - but there are limitations like tables are not editionable.
It's not a feature you just enable, you need to understand the concept and implement it properly.
PDBs enable consolidation of Databases with colliding namespace (such as your described synonyms) within the same CDB and therefore save SGA/memory. Basically they are totally separated - limited interference can be implemented when it's concept of object & data inheritance is understand.
What about creating a 3rd Schema and having Synonym and permission to query 1st and 2nd schema. Anyone tested this concept?
Related
We are a team of tens of data analysts. Our main data back-end is an Oracle database. We use personal schemas to do work where we don't need to collaborate with others and we would like to create schemas dedicated to projects where people need to collaborate.
The problem is that in Oracle, one schema is equivalent to one DB user. If we create a schema dedicated to a project, for the purpose of creating DB objects in the context of that project, there will be a single set of credentials (username + password) that needs to be shared by all team members. This has two inconveniences:
if people mistype the credentials, they can block the account for everyone;
it is no longer possible to monitor who did what for security/audit reasons, since everyone uses the same schema;
An alternative would be that only one person uses the Schema user to create objects and assigns privileges to other people in those objects, but that can become quickly cumbersome.
Another alternative is to interact with the DB through R or Python but that means the credentials will be stored in some text file, which is bad for security.
As we see it, the ideal situation is if multiple personal DB users can create objects in the same schema, and if those objects are automatically available for that set of DB users. Is this totally impossible in Oracle? Is this impossible in any major DB? Is this requirement somehow flawed and as such, there is a good reason for why it is not available?
We could compare this collaboration in a DB schema to what commonly happens with people collaborating in a folder, using R, Python or other programming language for data analytics.
Thank you for your advise!
Maybe I miss something but could you not just create a schema that will be used for all users and grant the required privileges to each individual user?
Each user authenticates with his local account and by default uses his local schema and to access the public one you just use the ALTER SESSION SET CURRENT_SCHEMA command.
I have two users on windows server
Administrator
devUser
Both can use SQL Developer to connect to Oracle 11g Server (Oracle e-Business suite) but in the same query (from synonym) they got the difference result: devUser got the correct result and Administrator got null in first three columns.
SELECT * from XXAUTO.XXFND_OU_COMPANY_V
where ou_name like 'ASL%'
Query Result from Administrator(Windows User)
Seems like the view has some form of VPD in place. Oracle supports Fine-Grained Access Control through its DBMS_RLS package, which despite the name allows us to implement security policies on columns as well as rows (since 10g). Find out more.
The common model is, when users connect to the database a LOGON trigger populates an application context with details about them. These details are used to generate as additional filters on tables and views which have security policies in place. You can confirm this by using the pertinent views: start with ALL_POLICIES and drill down depending on what you find.
It's possible the view implements a hand-rolled version of this (FGAC is an Enterprise Edition feature) but if you're using EBS that seems unlikely.
Another option is that your database is protected by Oracle Database Vault. This product is a chargeable extra to the EE license. It is a very powerful tool, and one of its uses is to prevent super users like sysadmins or DBAs abusing their privileges to look at sensitive data. It seems unlikely that an organisation would put Database Vault in place on a server that developers have access to but I offer this suggestion for completeness. Find out more.
Thank you for all.
Now I found the problem that is both user set the different Windows locale.
I have an ERP application running with Oracle forms and Oracle database. Now I am planning to migrate this application to a java based enterprise application. will it be a good idea to keep the existing oracle database as back end and developing a web application with certain level of changes/additions in the DB design.
There are two facts to know before answer your questions:
has your database schema some oracle forms special structures or is it in 3rd normal form and simply stores data using keys and enforced referential integrity?
How much stored code contains your database?
Ad 1. Oracle forms don't have specific schema reqiurements. They work best if your schema if based on 3rd normal form. If your schema is like this, use it for new Java application. We have both forms and Java EE applications on same database schemas and is works fine.
Advantage is, if you have keys (primary, unique, foreign) in your schema. Use them when generating Java app.
Probably you will have to add #Version columns for optimistic locking (see https://docs.oracle.com/javaee/6/api/javax/persistence/Version.html). But there is not reason to build new schema for it.
Ad 2. Your will have to overwrite bigger part of database stored code (triggers, procedures, functions) to Java. In most cases this does not have dramatic impact to schema structure, but deal with it.
So - if your database schema is not tailored to some UI client needs AND you want only use a new client, use your schema. If not, create a new one.
We are using a SaaS provider at my company, who also offers direct read-only access to their back end Oracle database.
Our Oracle user does not own any of the tables, therefore the tables we want to read belong to other users. So the tables must be addressed as follows: OwnerUser.table1, OwnerUser.table2, etc.
When setting up a data source in LightSwitch, no tables are visible, because the Entity Data Model is mapping to tables owned by our user (the one which we connect with).
Does anyone know if I can tweak the data source somewhere to inject the owner prefix (e.g. OwnerUser) so that the LightSwitch Designer will show the tables owned by OwnerUser?
You might find that in this case it might be easier to create a custom RIA Service layer for the datasource that passes the user information and sets up the tables.
In my project, I am using Oracle Database and SubSonic for DAL. I have a problem with SubSonic and Oracle Schema, that is:
When developing, I used a schema DEV in Oracle Database and generate DAL using SubSonic.
After that when release to customer, he used a new schema TEST in Oracle Database and changed the connection string in app.config to connect to Oracle. The error will appear, that is “Table or View does not exist”. I found this error and see that the schema of tables is still DEV.
I do not want re-generate DAL after change schema and when released to the customer. Please help me.
Firstly, your schema should not be DEV. DEV is a user or role.
Your schema name should be related to the data content (eg ACCOUNTS or SALES)
Secondly, consider whether you or the customer is going to decide the schema name. Say you have a product called FLINTSTONE. You may decide that the schema name should be FLINTSTONE. However your customer may want to run two instances of your product (eg one for local sales, the other for international) and use the same database. So they want FS_LOCAL and FS_INTER as the schema names. Is that option a feature of your product ?
Next, decide if your application should connect as the schema owner. There are good security reasons for NOT doing that. For example, the schema owner has privileges to drop tables, which is generally something the application doesn't do and thus, on the principle of least privilege, is something your application shouldn't have privileges to do.
Generally I would recommend some config parameter for the application for the schema name, and after connecting to the database, the app should do an "ALTER SESSION SET CURRENT_SCHEMA = 'whatever was it the config file'". The application database user would need the appropriate insert/update/delete/select/execute privileges on the objects in the application schema. If the application can't do that, you can have a LOGON trigger in the database.
Gary is correct in not using DEV as a schema on your own machine. In using Oracle we typically set up the schema as what the client is going to name their schema. This however does not fix your issue. What you need to do is create a global alias in Oracle that maps say DEV to CLIENTSCHEMA. You should still rename the schema on your machine but this will allow your schema to differ from your clients.