While reading a PLSQL book I have stumbled upon this piece of code :
ALTER PROCEDURE pls_test COMPILE PLSQL_CODE_TYPE=INTERPRETED;
Could you please explain how it differs from normal compilation? I was not able to find the answer in the book.
Thank you!
Oracle supports two different compilation modes : INTERPRETED and NATIVE.
INTERPRETED is the default mode, that was introduced at the same time as stored PL/SQL (Oracle 7) :
... each PL/SQL program unit is compiled into an intermediate form, machine-readable code (MCode). The MCode is stored in the database dictionary and interpreted at run time
In the code you showed, the INTERPRETED part is redundant, as it corresponds to the default compilation mode (unless the command is executed against a server whose default was changed).
NATIVE was introduced in Oracle 9, then enhanced and simplified in the following versions :
SQL modules (packages, triggers, procedures, function, and types) .. are compiled... into native code residing in shared libraries. The procedures are translated into C code, then compiled with a C compiler and dynamically linked into the Oracle process.
This results in faster execution times, as no interpretation is needed at runtime : improvement factor was forecasted from 1.04 to 2.4 in Oracle 10g.
As a conclusion : unless you have a good reason, you want to use NATIVE over INTERPRETED...
For more details and a possible migration path, read this Oracle 10g FAQ paper and this post on Oracle blog.
Below description summarizes Native vs Interpreted Compilation. Interpreted Compilation is default compilation on Oracle DB. Natively compiled code does not need to be interpreted at runtime thus it executes faster.
Native compilation is the process by which a stored PL/SQL program is
compiled into native code (Pro *C) that does not need to be
interpreted at runtime. In comparison, code that is not natively
compiled is stored in an intermediate form that must be interpreted at
runtime.
PL/SQL native compilation provides the greatest performance gains for
computation-intensive procedural operations.
Reference : [1] [2]
Related
I am primarily a C developer. I have a sample COBOL driver that calls my C DLL in z/OS.
The COBOL driver was working fine in z/OS COBOL V4 when we used the Pre-Linker and IMPORT statements to define the API’s inside the DLL.
With COBOL V6 (and V5), the pre-linker is no longer supported (along with a myriad of other changes).
How can I get COBOL to recognize my IMPORT statements to know about the LONGMIXED API’s inside my DLL?
The COBOL call looks like:
CALL
'PBFNTerminate' USING
BY VALUE NULL-POINTER,
My COBOL program is compiled with RENT,DLL,PGMN(LM).
I tried to simply include the IMPORT statements from the DLL creation in the BINDER but they seem to be ignored. I have DYNAM(DLL),CALL as a BINDER parameter but I still get:
IEW2456E 9207 SYMBOL PBFNTerminate UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.
If I run the BINDER with DYNAM(DLL),NCAL I get
IEW2454W 9203 SYMBOL PBFNTerminate UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. NAME SPACE = 3
And then a S0C1 when I try to run.
I’m thinking there is a step or parameter I’m missing but obviously I don’t know what it is.
Side comment, the COBOL INTERLANGUAGE COMMUNICATIONS guide seems to be written pre COBOL V5 and V6: https://www.ibm.com/docs/en/cobol-zos/4.2?topic=answers-interlanguage-communication
Found the problem. At least for me, the PLKED step defaulted NOUPCASE. In the Binder I had to add CASE(MIXED) to the PARM. The the final solution was: PGM=HEWL,PARM='DYNAM(DLL),CASE(MIXED)'.
I couldn't find a similar question here.
I have a PRO*C program named pro_c.pc. How can I call and execute this in a piece of PL/SQL code?! Could someone give me a simple example?!
You can link external libraries (Windows DLL or UNIX ".so" files) to Oracle and then make them callable via PLSQL. This has been around at least since Oracle 8i.
This though requires DBA privs on the server to set this up, and is probably not a recommended approach these days .... but useful for crunching huge data.
See here for more details.
Calling a actual program directly, as opposed to a library function from PLSQL would be done indirectly via DBMS_SCHEDULER as #Justin suggested as the easiest way, creating a program with the PROGRAM_TYPE as EXECUTABLE. See here for more info.
A couple of things to note when doing this, the program will run as the (assuming UNIX) "oracle" user - bringing with it some security considerations, e.g. if the program creates a file it will be created as owned by oracle, and so might not be accessible to an "application" user. The program will run on the Oracle database server.
My knowledge of interpreter based languages is that for every time we change the code we don't need to compile it. Compilation will be done at the time of actual execution only. Then why does most of the scripting languages use interpreter's when we usually write script to automate something which we usually doesn't modify.
All the answers seems to be unrelevant of what i was expecting. So let me phrase my question in this way.
Pure interpreter based language : which compiles and executes the code line by line, everytime we execute the code(as of my knowledge).
Then why does scripting languages were developed interpreter based(NOT combination of compiler and interpreter), when we usually execute the same script file everytime(without changing the source code). It would be better if they make it compiler based(or even combination of compiler and interpreter) so that we can compile it once and execute any number of times.
Do not confuse unrelated things together. Firstly, distinguish between a language and its implememntation. A language is given by its syntax + its semantics. A "computer" language (actually, a formally defined language) can be used to express things, such as algorithms, even if there is no known implementation of the invented and described language.
But in practice, the syntax specification is usually done by writing a parser (eg. using yacc) that can be understood by a machine, and semantics specification is done by writing code to be executed upon encoutering particular keywords and other semantic signs. In this way, a typical language creator performs the language specification by writing its first implementation, which then becomes an implicit standard for the language. People do it this way because it's simple, and because if you invent a language and merely publish it as a theoretical paper in a computer science journal, it is not guaranteed that anyone will bother to write its implementation for you.
This doesn't mean that the implementation provided by the language author is the only possible. If the language is well liked, people will attempt to write other implementations including compilers for it. This was eg. the case of Ruby, which was originally written by Yukihiro Matsumoto, but was liked well enough that people wrote a compiler of Ruby for JVM -- JRuby.
In a compiled language the program, once compiled, is expressed in the instructions of the target machine.
In a interpreted language the program instructions are not directly executed by the the target machine, but instead read and executed by some other program (in java its called the JVM). This enables interpreted language to be "Write Once Execute Anywhere".
I think your question is based on a false premise. Most scripting-language interpreters of which I am aware will do some amount of "compilation" to an internal form to avoid having to re-parse the source for repeated code (function-calls or loops).
The strings that represent identifiers will usually be interned so that the internal form uses integers that index a string table. Constants will be converted to the machine format. Labels and function-names will be stored (in the internal form) as pointers.
At some point (but the line is very blurry) if the internal form is specified precisely, it can be considered a byte-code format, and the interpreter is then considered a virtual machine. But it is still an interpreter. The microprocessor is still an interpreter for its machine language.
Java is compiled into Binary code and executed by JVM.
C++ is compiled into platform dependent code.
When I read definition of Stored Procedure in SQL Server, it says
A stored procedure is a group of Transact-SQL statements compiled into a single execution plan.
http://msdn.microsoft.com/en-us/library/aa174792(v=sql.80).aspx
So what is SQL compiled into (something SQL Server can execute..?) ? Could I say stored procedure is pre-compiled and ready to execute so it is faster?
I believe "compilation" with stored procedures simply means "creation and storage of a query execution plan."
According to the blog post here, stored procs are checked for syntax when created or altered, but only compiled when they are first run. That link also gives scripts you can run to tell you if a given procedure has been compiled or not.
For more reading, see this Microsoft article on compilation in Sql Server 2005.
Since upgrading from 4.7 to ECC6 the ABAP compiler has become a lot stricter on the use of certain statements in the OO context.
For instance you're not allowed to use the statement LIKE, but in stead have to use TYPE and internal tables does not have an implicit header line, etc.
These restrictions are explained in greater detail here
MY QUESTION: To what extent does this restriction affect your existing code-base?.
We have over a thousand "Classes" written since 1998 in OO as far as it was available at the time. For the most part each class is its own include in SE38, with the class definition and implementation together in this include.
Up to now, we could successfully change and activate these classes as long as the main program was pre-existing in 4.7. Now we are trying to use one of these older classes in a new main program for regression test purposes, and we are getting the following error:
"Within classes and interfaces, you can only use "TYPE" to refer to ABAP Dictionary types (not "LIKE" or "STRUCTURE")."
This error is valid as per the current definition of the SAP language.
I would like to know wheter the SAP interpreter continues to run old code with obsolete statements intentionally, or whether a future patch may correct this "feature" and cause these classes to stop compiling.
Each development object is tagged with a version corresponding to the SAP version it was developed on. You can see this in version management or table VRSD.
As I understand it, that is there specifically so that code with statements that have been made illegal in later versions will survive an upgrade and continue to run.
This is why, when you attach an include developed in 4.5b to a class that was developed in NW700, it won't compile. The compiler knows that this is new dev, and its applying the rules accordingly.
The ABAP community has been informed for a really long time (years) that LIKEs, work areas, RANGEs etc. are obsolete.
I don't think SAP will kill any old code, but I wouldn't count on it if I were in charge.
So can they cause it to stop compiling: yes, will they: probably not.