I have created a stored procedure without having synonym , because i don't know the importance of synonym. In my project we use two databases for development and another just to create synonyms.I had created stored proc with three input parameters and two output parameters in development database and also I executed my stored proc, it compiled successfully and got output. My question is can I create in this fashion? what happens if there isn't synonym created for a stored procedure. If it is a must then how did I get the output?. can we create synonym for a stored procedure which has input and output parameters. can any one help me out from this. Thanks in advance. :)
Generally speaking, you do not need to create synonyms for stored procedures.
However there might be cases when synonym is needed.
A synonym is an alternative name for objects such as tables, views,
sequences, stored procedures, and other database objects.
You generally use synonyms when you are granting access to an object
from another schema and you don't want the users to have to worry
about knowing which schema owns the object.
So just read on oracle synonyms and decide whether you need to use them or not.
(synonyms, create synonym)
Related
I'm surprised I haven't been able to find this question on the site already. Apologies if it turns out to be a duplicate!
In Oracle (10 upwards) is it possible for USER_A to deploy objects in USER_B's schema?
For example, assuming I am logged in as USER_B:
CREATE OR REPLACE PACKAGE user_a.my_example_pkg IS
PROCEDURE Make_Log;
PROCEDURE Init;
END user_a.my_example_pkg;
I get an ORA-1031: insufficient privileges response when I deploy.
I know that it is possible to log in as USER_A to deploy the package, and yes I can do that. But the point is that on my database, someone appears to have modified a package "across the schema" in this way. And I need to figure out how they did it!!
I'm fairly sure that the privilege exists, but I can't find what it is. Moreover, if there are many privileges which allow this to be done, it would be a bonus to get an exhaustive list of what those privileges are.
You'd want to look for the ANY privileges
CREATE PROCEDURE lets you create procedures in your schema. CREATE ANY PROCEDURE lets you create procedures in any schema.
CREATE TABLE lets you create tables in your schema. CREATE ANY TABLE lets you create tables in any schema.
CREATE VIEW lets you create views in your schema. CREATE ANY VIEW lets you create views in any schema.
For any of the CREATE privileges, there is a corresponding CREATE ANY privilege. Those ANY privileges are extremely powerful and really shouldn't be given to anyone other than a DBA since it would allow you to do things like create procedures owned by highly privileged users that can do anything a DBA could do.
We want to grant a user execute on a stored procedure which will access certain tables, but prevent that same user from performing a direct query on the same tables.
Here is our current model. User foo is the owner of the stored procedures. It has direct select, insert, update, and delete privileges on all the necessary tables. The stored procedures have been created with AUTHID CURRENT_USER. Foo grants execute on its stored procedures to user bar.
User bar calls the stored procedures via the grants above. By design, it has no ability to change the source code of any stored procedures. It has access via a role to the necessary tables.
So far, that works fine. Now we have a new requirement. A new user must be created that can execute the stored procedures, but cannot directly query against the tables (via SQLPlus, JDBC, ODBC, etc.)
I can't see any obvious way to implement this. All suggestions are welcomed.
If the procedures that foo owns were defined as authid definer, the default, then callers would not need privileges on the underlying tables in order to execute the stored procedures. Normally, that is how privileges are managed in Oracle. It is somewhat uncommon to use authid current_user stored procedures because that forces the caller to have privileges on the stored procedure in addition to privileges on the underlying table.
You'll either need to modify your existing procedures so that they are definer's rights stored procedures or you'll need to create a separate set of definer's rights stored procedures that you give the new user access to.
This is hopefully a quick one, i'm new to oracle so need to check something before it bites me on the posterior
Ok i have a function that modifies a table
if i give the user permission to execute the function do they also need permission to update and insert in the table or is the fact they are approved to use the function enough?
the reason i ask is that the users need to edit these tables but only via approved functions which perform complex validation that can't be done easily via constraints
It depends on how you define your procedure, specifically the AUTHID property:
The AUTHID property of a stored PL/SQL unit affects the name resolution and privilege checking of SQL statements that the unit issues at run time.
By default the procedures are created with a AUTHID value of DEFINER (definer's right) ,the functions are executed as if the caller were temporarily given the rights of the definer.
With a value of CURRENT_USER, the AUTHID property will make the procedures check the privileges of the caller at run-time.
In your case, the scenario you describe would fit with the property value of DEFINER (the default): the users will only be able to call the procedures and functions without direct access to the underlying tables. A similar scenario is described in the documentation:
Scenario: Suppose that you must create an API whose procedures have unrestricted access to its tables, but you want to prevent ordinary users from selecting table data directly, and from changing it with INSERT, UPDATE, and DELETE statements.
Solution: In a special schema, create the tables and the procedures that comprise the API. By default, each procedure is a DR unit, so you need not specify AUTHID DEFINER when you create it. To other users, grant the EXECUTE privilege, but do not grant any privileges that allow data access.
I was given an oracle dump file for an existing system. The dump file contained the table PARTS but when I look on the queries being done by the code. It uses mostly M_PARTS and just on one occasion, it uses PARTS. Does oracle allow multiple name on a table?
Note that I am not talking about the alias feature. ie.
Select M_PARTS.*
from PARTS M_PARTS
I want to know if there is a setting to make permanent alias in oracle. Where I just create a table PARTS and I can refer to it as either PARTS or M_PARTS in my query.
Kind of, as you can create synonyms:
CREATE SYNONYM PARTS FOR THE_SCHEMA.M_PARTS;
It is weird however, that the dump file would be inconsistent that way. Are you sure it is the same table? How was the file created?
Yes using synonyms.
Although a synonym was a solution, I found the actual script to build the database and it uses a materialized view instead of a synonym.
create materialized view M_Parts
tablespace USERS
refresh fast
as select * from Parts
Firstly
I am an oracle newbie, and I don't have a local oracle guru to help me.
Here is my problem / question
I have some SQL scripts which have to be released to a number of Oracle instances.
The scripts create stored procedures.
The schema in which the stored procedures are created is different from the schema which contains the tables from which the stored procedures are reading.
On the different instances, the schema containing the tables has different names.
Obviously, I do not want to have to edit the scripts to make them bespoke for different instances.
It has been suggested to me that the solution may be to set up synonyms.
Is it possible to define a synonym for the table schema on each instance, and use the synonym in my scripts?
Are there any other ways to make this work without editing the scripts every time?
Thank you for any help.
Yes, you can create synonym for a schema.
select ksppinm, ksppstvl from x$ksppi a, x$ksppsv b where a.indx=b.indx and ksppinm like '%schema%synonym%'
ALTER SYSTEM SET "_enable_schema_synonyms" = true SCOPE=SPFILE;
STARTUP FORCE
show parameter synonym
Assuming you already have a schema named ORA...
CREATE SCHEMA SYNONYM ORASYN for ORA; -- create synonym for schema
CREATE TABLE ORASYN.TAB1(id number(10)); -- create table in schema
More information here: https://dbaclass.com/article/how-to-create-synonym-for-a-schema/
It'd help to know what version of Oracle, but as of 10g--No, you can't make a synonym for a schema.
You can create synonyms for the tables, which would allow you not to specify the schema in the scripts. But it means that the synonyms have to be identical on every instance to be of any use...
The other option would be to replace the schema references with variables, so when the script runs the user is prompted for the schema names. I prefer this approach, because it's less work. Here's an example that would work in SQLPlus:
CREATE OR REPLACE &schema1..vw_my_view AS
SELECT *
FROM &&schema2..some_other_table
The beauty of this is that the person who runs the script would only be prompted once for each variable, not every time the variable is encountered. So be careful about typos :)
Yes, there is a hidden way to create a schema synonym.
There is a hidden parameter _enable_schema_synonyms. It's false by default , but you can set it to true and create a synonym.