The difference is that --
and /* */
can be used in a PL/SQL block, while REM[ARK]
cannot. The following will work in SQL*Plus:
REM comment
-- comment
/* comment */
begin
DBMS_OUTPUT.PUT_LINE('Test'); --comment
DBMS_OUTPUT.PUT_LINE('Test'); /* comment */
end;
/
These will not:
begin
DBMS_OUTPUT.PUT_LINE('Test'); REM comment
end;
/
begin
REM comment
DBMS_OUTPUT.PUT_LINE('Test');
end;
/
The 11.2 documentation on all comment types has more comment information. The basics are...
You can enter comments in a script in
three ways:
using the SQL*Plus REMARK command for single line comments.
using the SQL comment delimiters /*... */ for single or multi-line
comments.
using ANSI/ISO (American National Standards Institute/International
Standards Organization) comments - -
for single line comments.
The documentation also includes notes on four places that comments should not be used, but these do not include any further differences.
Chained and Migrated Rows are explained in the Logical Storage Structures of the Concepts Guide.
A migrated row would be a row who's column data was completely transferred from one block to another due to an update. The original block would essentially only have a "forwarding address" stored for that row.
A chained row would have parts of its column data in multiple blocks. The original block would contain both actual column data and a forwarding address for the rest of it. (You can get rows chained to more than two blocks.)
Both are implemented the same way deep down, so they're really two aspects of the same thing.
Also note that for tables with more than 255 columns, all rows are technically chained - one "row piece" can only contain 255 column values. The chaining can happen in the same block, or with other blocks depending on space availability (and isn't particularly "bad" if all the data ends up in the same block).
The only way, as far as I know, to get accurate data on row chaining is to use:
ANALYZE TABLE your_table [partition (your_part)] LIST CHAINED ROWS
See Listing Chained Rows of Tables and Clusters.
This is potentially expensive, the whole table needs to be scanned. Statistics gathering doesn't fill the CHAIN_CNT
column of the dba_tables
view. (I think it might have at some point, but it doesn't in 11.2 at least.)
You can monitor the table fetch continued row
1 statistic (v$sysstat
) to see if a query is affected by chained or migrated rows, but I don't believe you can have that metric per-session so either you need a quiet system to measure, or the reading will be "noisy".
The Secrets of Oracle Row Chaining and Migration has interesting information about chained and migrated rows, how you measure them, and potential ways of fixing them.
As always, don't go about rebuilding tables or changing storage parameters "just because" you see chained or migrated rows. Do so only if you measure that it's actually causing you performance problems.
1 From Statistics Descriptions:
Number of times a chained or migrated row is encountered during a fetch
Retrieving rows that span more than one block increases the logical I/O by a factor that corresponds to the number of blocks than need to be accessed. Exporting and re-importing may eliminate this problem. Evaluate the settings for the storage parameters PCTFREE and PCTUSED. This problem cannot be fixed if rows are larger than database blocks (for example, if the LONG datatype is used and the rows are extremely large).
See also Table Fetch by Continued Row.
Best Answer
Its an interesting question, to be sure. Most people who are familiar with Oracle development wouldn't give it a thought but when you come down to it, its sometimes confusing to define the demarcation between SQL and PL/SQL.
By looking at the definition of the acronyms, you start to get an idea of what areas of functionality each covers:
SQL - Structured Query Language
PL/SQL - Procedural Language / Structured Query Language
The observant reader might notice how SQL shows up twice 8) That's because SQL is often embedded within PL/SQL - PL/SQL is a language that was made to provide a proprietary 4th generation language (4GL) that plays very well with database objects in Oracle.
Wikipedia has some pretty good material on both SQL and PL/SQL
The confusing part is where PL/SQL and SQL overlap a bit. SQL's purview includes data insert, query, update and delete, the so-called DML, or data manipulation language operations, but it also includes create, alter, rename, drop which are DDL or data definition language operations. Its here where some might get confused. The operation to create a stored procedure, something written using PL/SQL, is actually SQL - you use SQL to create the database object that represents a block of PL/SQL.
Likewise, you can embed SQL code inside your PL/SQL. A FOR loop in PL/SQL can be based upon a SQL query, for example. Blows your mind a little, eh? You create a procedure using SQL that actually internally uses SQL to perform some action on records from the database.
Cool stuff if you ask me.