We have application where all logic is implemented in oracle database using pl/sql.
We have different oracle databases for development and production.
When developer make changes in development database after testing we move changes from development database to production database using schema compare tool of toad. Problem here is that developer must have password of production database. We want only admin to know this password.
Can somebody advice me better way of moving changes between databases without need of having production database password, what is best practice for this ?
I posted this question on oracle OTN forums and got some advices there. Maybe it will be interesting for somebody.
Her is a link
I do not recommend to use comparison tools for generating of database migration scripts.
Development and production databases (and also test databases) must be identical except for current changes made by developers in development databases. Generally speaking this assertion is not correct, because there are many kinds of differencies between development and production databases, e.g. partitioned objects, additional objects for audit (triggers, tables), replication-based objects (snapshots), different tablespaces etc.
Every developer must know, what changes were made by him and applied to development database.
If developer was able to change schema and data in developer database, then he/she must be able to create programs for these DDL and DML changes.
To delegate the same developer an ability to run these migration programs on production database is a bad idea. But if you don't have a better way of database migration, then you can use one of following:
1. Configure Oracle authentication by OS. OS authentication allows Oracle to pass
control of user authentication to the operating system.
2. TOAD can save passwords without disclose them. DBA will insert required password
to local TOAD installation at developer PC (if developers use PC).
Related
I've been trying for days but cannot find the answer to this. I am using Oracle Application Express (APEX), someone else setup the initial connection to a "Apex" database in oracle, but I am trying to connect to our production database in oracle. I am making web forms and the web forms are connected to the "Apex" database that was setup already, but I need to connect to our production database so we can create reports from the data entered through the web forms. I need the tables to show up in the create page option from the production database, currently its coming from the apex database, please help.
Create Page View with Tables (from apex)
Thank You so much in Advance!
What is the "production database"? Is it really a different database (than the one you're currently connected to), or is it a user in the same database?
if former:
you could create a database link between those two databases and create synonyms for production users' tables in one of schemas your workspace is assigned to.
another option is to install Apex onto the production database, so that you could use current installation as "development" and then deploy the application into the "production-based" Apex
if latter, you might do the same (i.e. create synonyms, just without the database link), or simply assign the production schema to your workspace
You may be interested to read Mike's response to a question with a similar misunderstanding regarding architecture.
https://community.oracle.com/thread/4135843
Once you have your head wrapped around this, you can consider the parsing schema to your application. This schema defines the table access your application has, in the normal way Oracle handles table privileges.
Then it's up to you to define who has access to what pages, using APEX Authorisation Schemes.
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.
We are developing a large data migration from Oracle DB (12c) to another system with SSIS. The developers are using a production copy database but the problem is that, due to the complexity of the data transformation, we have to do things in stages by preprocessing data into intermediate helper tables which are then used further downstream. The problem is that all developers are using the same database and screw each other up by running things simultaneously. Does Oracle DB offer anything in terms of developer sandboxing? We could build a mechanism to handle this (e.g. have dev ID in the helper tables, then query views that map to the dev), but I'd much rather use built-in functionality. Could I use Oracle Multitenant for this?
We ended up producing a master subset database of select schemas/tables through some fairly elaborate PL/SQL, then made several copies of this master schema so each dev has his/her own sandbox (as Alex suggested). We could have used Oracle Data Masking and Subsetting but it's too expensive. Another option for creating the subset database wouldn have been to use Jailer. I should note that we didn't have a need to mask any sensitive data.
Note. I would think this a fairly common problem so if new tools and solutions arise, please post them here as answers.
My work uses Oracle 10G and is planning on installing Apex. In the meantime, I have downloaded Oracle XE and have taught myself APEX on it; however, I can only access users/tablespaces that I have made in the XE database. What I would like to do is use the XE's Apex to access the users/tablespaces in the production databases of my work.
My colleague says that this should be possible because my workstation is connected to the server, and that there should be a way to configure access from my XE's Apex to the 10g's databases, such as by setting up an appropriate DAD.
I see nothing in the Apex user interface to allow this. I've read every word of the Apex documentation but nothing registered.
XE uses the embedded PL/SQL gateway, as opposed to 10/11G which uses either an Apex Listener or an HTTP Server with the mod_plsql plugin.
Thank you,
Matthew Moisen
I have done this before where we didn't have access to the actual database hosting the data to be worked with save for the standard port 1521 listener access. Apex at the time was new enough to the organization that the DBA's also had a voodoo taboo on using their database server as a webserver gateway as well. You can use your database instance with APEX installed as a "middle tier" or app server with the following steps:
Set up an account on your 10g database that is accessible remotely via dblink.
Set up dblinks to your 10g database table on your workstation with XE installed, use the account and connection information for the 10g database as set up in (1). Note, you may have to update a TNS names file or explicitly indicate your host/networking settings within the dblink itself.
For simple sanity and simplicity in coding your apex projects, set up synonyms for all your dblinked objects (i.e., table1 for table1#dblink) so you're not referencing the dblinks directly in your apex code. Making changes later will be easier if you adhere to this.
That's it. One proviso is that you need to know that LOBs will not work with the out-of-the-box functionality of APEX driven DML operations while using dblinks. This may have changed with the newest version. One workaround you may consider is trying to use a stored procedure which passes your LOB data as a input parameter which will do your DML operation for you.
Otherwise, this approach works nicely. The place where I implemented this model has several production level apps, a test and a development tier all using servers hosting APEX separately from the actual data sources. We used Oracle Standard Edition One (for the support), but Oracle XE should work as well since APEX is the platform in common between either Oracle version.
...and how should those permissions be granted. I work in a large IT dept with 70+ applications, some in SQL server and most in oracle. Each system has a prod, QA and Dev instance. We (I'm a developer) have readonly access to prod/qa, which I'm fine with. In SQL server development instances devs are given db_owner, which works totally fine. The debate is over what permissions I should have in the DEV oracle databases.
I recognize that best case would be to have each dev run their own instance on their workstation for development, but because of the size of the databases this has not been considered an option.
I'm also interested in HOW these permissions should be applied. In oracle permissions granted via a role are not active during PL/SQL execution so roles (even the "dba" role) are not useful. That leaves using a built in account (system) or creating dozens of users accross dozens of database and directly granting dozens of permissions to each.
In my mind just letting the devs login as system is making a lot of sense, but our DBAs claim that's a bad idea.
We used to just give developers access to the application account. This works for small shops but rapidly gets out of hand as the number of developers increase.
Here's what we do now:
the Application has it's own account (aka schema).
Developers have their own accounts
Data resides in the application schema
We have an ant build script to build code into whatever schema you want.
code includes views, packages, objects etc..
the build script includes a step to run a stored procedure to grant explicit rights to developers to the application data
Developers make changes in their own schema
When happy they check that into subversion
The Application's dev schema is built from the new subversion build.
Developers can check out and rebuild their own environments.
DDL changes to table structures are done via the DBA
these can be scripted as well
This has the benefit of ensure any front end application is not broken by database developers constantly rebuilding everything.
I assume that there are a relatively small number of application accounts that own the actual objects. So one or more logical applications are comprised of tables owned by a particular Oracle user. This would not by SYSTEM or SYS, it would not be any of the accounts that Oracle the company delivers. It would be an account that your DBAs created. If you are familiar with the Oracle sample schemas, the HR user owns all the tables in the HR schema which comprise the back end for an HR application.
Starting from the principle of "the simplest thing that could possibly work," my first thought would be to see if the developers could log in directly to those application accounts. This isn't the securest possible configuration, and you are opening up the possibility that a developer accidentally or intentionally does some damage that may be difficult to track or easily resolve. But it can work reasonably well depending on the organization. Privilege management is trivial-- the application owner account already has all the privileges it needs most likely.
The next step up would be giving every developer a separate schema to develop in, presumably in conjunction with a load of public synonyms in the database and an absence of schema qualifiers in the application code, so that any object created in the developer's schema automatically overrides the shared version of that object. This provides much better isolation. Permissions are generally granted by either creating scripts that contain all the grants a developer needs or by creating a script that copies all the privileges from a "known good" account to the new account. Neither is particularly difficult to write-- you just have to make sure that all the developers end up with the same set of privileges, which is generally just another script that gets run when a new privilege is granted.
If you are developing stored PL/SQL objects, then the schema owning those objects needs, as you mentioned, explicit grants on the objects used. If you have a single 'data' schema but are developing code in your own individual schemas then you should get the ability to grant access on the data schema objects to your development schemas. Normally I'd expect username/password for the data schema.
In regards to system privileges (eg CREATE), I'd expect CREATE TABLE, TYPE, VIEW, PROCEDURE TRIGGER, SYNONYM. Others may be appropriate (eg CONTEXT) depending on what you do. The DBA may rule out CREATE DIRECTORY as that could be damaging if mis-used. Ditto for privileges with ANY in them (eg SELECT ANY TABLE, DELETE ANY TABLE)
For performance tuning / system monitoring, on a dev database SELECT_CATALOG_ROLE is good. If the DBA is risk-averse, you may have to negotiate grants on individual views. Go through the REFERENCE guide for your version and ask for any you may use.
One of the DBA's jobs is to manage user privileges. I don't think system is a good idea for a few reasons, not the least being the ability to drop an entire schema which I am sure you don't want. That being said, I think it is perfectly fine to grant all to your users and let the DBAs manage these permissions no matter how many dozens of accounts there may be. Most DBAs will have scripts they can use to manage these permissions anyway.
Listen to your DBAs, they generally know what they are talking about.
If it's just a dev instance; i'd have all users have individual accounts added to the admin role. That way you can still log activity on a per-user basis; but give the devs enough breathing room to do their thing.
My group supports about 100 apps with about 20 of them having their own Oracle schema. We have gone down the road of every developer has the password to the schema and it is convenient. However, in hindsight I would recommend that each developer use their own Oracle account to develop. The main reason is auditing.
I recognize that best case would be to
have each dev run their own instance
on their workstation for development,
but because of the size of the
databases this has not been considered
an option.
Is there a way to deal with this, maybe by reducing the amount of data in your personal copies? This seems like the ideal solution, since it would allow you to make any changes you need. Then you could submit them to the DBA when you're ready, and have him update the shared development server.