I want a kind of scripting in my app allowing a user to execute arbitrary SQL on my Oracle RBO DB. Not just a select/update but something complicated with loops. But not a stored procedure also (there is no any reason to store such code persistently).
Is there such a thing in Oracle - "non-stored procedure" - and how is it called?
Yes, that's possible.
It's called an "anonymous PL/SQL block".
http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/overview.htm#i8859
Related
As far as I know there is very little difference between the two except syntax. You have to use:
CALL METHOD for AMDP
CALL DATABASE PROCEDURE for HANA Procedure
Is the AMDP performance affected by the fact it is run at ABAP Application Server?
Can this architectural downside be overcome by the SQL optimizations when comparing to HANA proc? What is the best entity to use (AMDP or HANA proc) when dealing with complex queries with multiple WITH and JOIN?
AMDP is the abbreviation of ABAP Managed Database Procedure
As the name implies, these are still database procedures, but more easy to create, maintain and transport, as they are stored in the Dictionary.
If you look into the definition of one, you will immediately see that the body is written in sqlscript1, the language that SAP uses for HANA DB procedures. It will run on the database.
There is no performance difference. If you can write efficient DB procedures, you can write efficient AMDP.
How to make them faster
Create a PlanViz file, check where the time is spent. Most often the JOIN conditions can be improved, sometimes a field is missing, or it is performed on calculated fields.
or L, or R, but never in ABAP
When I say parameterized stored procedures, I would like to specifically exclude any stored procedure that is based off of passing in parameters, building a string, and passing the string into sp_execute_sql. My application will not do that.
I have three questions I'm hoping someone might be able to help me with.
Will parameterized stored procedures prevent all SQL injection attacks other than latent SQL injection attacks?
If, on top of this, I sanitize all semi-colons from any stored procedure that writes to the database, will I be completely safe from all SQL injection attacks, including latent ones?
If the answer to either of the previous two questions is not yes, what other characters should I sanitize out before passing in parameter values.
Parameterized stored procedures (or even individual queries that are not stored procedures) will completely prevent sql injection attacks... at least on that statement. What this technique lacks is a good mechanism to enforce good practice throughout an application. I'm concerned that you're looking at this from the wrong direction. You don't prevent this just by fixing something within the database. You also need to make sure the code that calls to the database is written correctly. Even a correctly written stored procedure is vulnerable if someone uses an unsafe technique to make the call to the procedure.
No, you can still execute multiple statements in one call to the database.
There is no single character or set of character you can eliminate/sanitize that will prevent this. As I said in my comment, if you're thinking "sanitize", you're doing it wrong. Instead, you should be thinking "quarantine". That's what correct parameterization does: it quarantines the data in a separate place from the code. But this has to be checked at the client, not the server.
If you never, ever, ever use EXECUTE() or sp_execute_sql (and if you are certain no function or procedure your SP uses does, either), SQL injection won't occur, regardless of what parameter values are passed to your SP.
The only way SQL keywords within a parameter string can end up being executed as SQL is if your SP causes a run-time execution of a string.
By the way, SQL Server doesn't require statements to be terminated with the ; character, so removing them will not prevent multi-statement injection if you do happen to be executing strings as SQL at run-time.
Problem
I'm trying to understand the difference between Oracle SQL commands CALL and EXECUTE.
I've been using CALL to kick off stored procedures but in talking with another developer I found that he almost exclusively uses EXECUTE. I did some research online to see if I was doing something incorrectly but I'm not seeing the clear distinction between the two commands and people seem to use them interchangeably.
Based on the documentation, they seem remarkably similar (at least in terms of interacting with stored procedures).
http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4008.htm
http://docs.oracle.com/cd/B19306_01/server.102/b14357/ch12022.htm
http://docs.oracle.com/cd/B28359_01/olap.111/b28126/dml_app_dbms_aw026.htm
It does look like CALL is a universal SQL command while EXECUTE seems to be proprietary so I would be inclined to use CALL over EXECUTE but then again I don't know what that means in regards to performance.
Questions
Is one preferable over the other in terms of kicking off a stored procedure? Does it matter?
If it does matter, what is a situation where either is appropriate?
Are there any performance differences between the two? What's best practice?
Both EXEC[ute] SP() and CALL SP() could be used in SQL*Plus to execute an SP. BTW, you can also use BEGIN SP(); END;
But there are some differences.
CALL is Oracle SQL and should work everywhere. Other DB clients that can talk to Oracle may or may not support SQL*Plus EXEC. Many do (for example, Oracle SQL Developer, SQLWorkbench/J), but some don't (Liquibase).
The data types of the parameters passed by the CALL statement must be SQL data types. They cannot be PL/SQL-only data types such as BOOLEAN.
EXEC could be used to execute not only an SP, but an arbitrary statement.
If an SP does not have parameters, you can use EXEC SP; syntax, but CALL requires empty parentheses: CALL SP();
If you are calling a proc that returns a sys_refcursor using Toad, there is a difference between CALL and EXEC.
create procedure foo(i in number,o out sys_refcursor)
as
begin
open o for
select i from dual;
end;
exec foo(1,:r); -- outputs 1 row
call foo(1,:r); -- outputs 0 rows
-- Note: when you prefix a parameter with a colon, Toad will prompt you for the type (which in this case is a cursor).
Someone here mentioned that We should avoid naming stored procedures in MS SQL server like sp_XXX
Because that taking addition time to SQL server while check does exist system sotred procedure named like that. Because all system stored procs are starting with sp_.
Now I wondering is that a case with Functions in MSSQL, Does naming functions like fn_ take additional time to SQL while looking for system functions ?
No, I don't think so.
Found the following thread:
http://bytes.com/topic/sql-server/answers/78872-udf-starting-fn_
No. To call a system-supplied [User Defined Function], you
need to use ::, so that is what SQL
Server looks for. All system-supplied
UDFs are table functions, as scalar
system functions are not UDFs at all.
Hope this helps
For functions it does not matter, however it is recommended to NOT use a prefix of sp_ for stored procedures as it defines a system stored procedure and may cause an extra lookup in the MASTER database.
As sp_ prefix is reserved for system
stored procedure and any stored
procedure which has sp_ prefix will
cause an extra lookup in MASTER
database. There is another point to
note that if a stored procedure uses
same name, in user database as system
stored procedure in master database,
the stored procedure in user database
will never get executed as SQL Server
will always look first in master
database and will execute that one
rather one in user database.
http://furrukhbaig.wordpress.com/2007/08/22/stored-procedures-factssheet/
http://msdn.microsoft.com/en-us/library/dd172115.aspx
I am using SQL Server 2008 Enterprise on Windows Server 2008 Enterprise. In a stored procedure, we can execute a SELECT statement directly. And it could also be executed in this new way, I am wondering which method is better, and why?
New method,
declare #teststatement varchar(500)
set #teststatement = 'SELECT * from sometable'
print #teststatement
exec (#teststatement)
Traditional method,
SELECT * from sometable
regards,
George
FYI: it’s not a new method, it is known as Dynamic SQL.
Dynamic SQL are preferred when we need to set or concatenate certain values into sql statements.
Traditional or normal way sql statements are recommended, because stored procedures are complied. Complied on first run "Stored Procedure are Compiled on First Run"
, execution plan of statements are being created at the time of compilation.
Dynamic sqls are ignored while creating execution plans, because it is taken as string (VARCHAR or NVARCHAR as declared).
Refer following articles for more details about dynamic query and stored procs
Introduction to Dynamic SQL Part 1
Introduction to Dynamic SQL Part 2
Everything you wanted to know about Stored Procedures
The traditional method is safer, because the query is parsed when you save it. The query in the 'exec' method is not parsed and can contain errors.
The "new" way, as mentioned, has nothing to do with SQL 2008. EXEC has been available for quite some time. It's also - in most cases - a Very Bad Idea.
You lose parameterization - meaning you are now vulnerable to SQL Injection. It's ugly and error-prone. It's less efficient. And it creates a new execution scope - meaning it can't share variables, temp tables, etc. - from it's calling stored proc.
sp_executesql is another (and preferred) method of executing dynamic SQL. It's what your client apps use, and it supports parameters - which fixes the most glaring problem of EXEC. However, it too has very limited use cases within a stored proc. About the only redeeming use is when you need a dynamic table or column name. T-SQL does not support a variable for that - so you need to use sp_executesql. The number of times you need or should be doing that are very low.
Bottom line - you'd be best off forgetting you ever heard of it.