Errata

This is for the Kindle e-book format:

About the Code
All of the code referenced in this book is available from [oreil.ly URL]oracle-plsql-sixth.

The link above, if followed is a Web Page that contains under Publisher Resources:

Supplemental Content: [learning O'Reilly URL]0636920024859/

The link for Supplemental Content returns:

Not Found
The requested URL /0636920024859/ was not found on this server.

It appears that a purchaser of this book is not able to locate any of the source code referenced in this book.

MAX_SQL_STRING_SIZE parameter does not exist; instead it is MAX_STRING_SIZE in Oracle 12c and higher. This error occurs again on page 202.

The text is saying:

Note the case difference on the month abbreviations of the next two examples. You
get exactly what you ask for with Oracle date formats!
TO_CHAR (SYSDATE, 'MON DDth, YYYY') --> 'FEB 05TH, 1994'
TO_CHAR (SYSDATE, 'fmMon DDth, YYYY') --> 'Feb 5TH, 1994'
The TH format is an exception to the capitalization rules. Even if you specify lowercase “th” in a format string, the database will use uppercase TH in the output.

This is not actually correct. The TH format changes according the formatting of the number which is attached to. i.e.:

TO_CHAR (SYSDATE, 'MON ddth, YYYY') --> 'MAY 23rd, 2017'
TO_CHAR (SYSDATE, 'MON dDth, YYYY') --> 'MAY 23rd, 2017'
TO_CHAR (SYSDATE, 'MON Ddth, YYYY') --> 'MAY 23rd, 2017'

In Oracle 12.2, as per my tests, if a letter of the number format to which TH applies is lowercase then the TH format will use.

The use of compose in this chapter is incorrect.

Following the example here below:

COMPOSE(‘a\0303’) will then return '\00E3', which is the Unicode code point (in hexadecimal) for the character ã.

does not return '\00E3' but 'a\0303', same as input string.

Even correcting the input, the following:
COMPOSE('a'||UNISTR('\0303'))
returns characters ã and not its Unicode code point.

In this code block:

(SELECT c1.*,COUNT(*)
FROM customer_known_good
GROUP BY c1.cust_nbr, c1.name...
MINUS
SELECT c2.*, COUNT(*)
FROM customer_test c2
GROUP BY c2.cust_nbr, c2.name...)
UNION ALL
(SELECT c3.*,COUNT(*)
FROM customer_test c3
GROUP BY c3.cust_nbr, c3.name...
MINUS
SELECT c4.*, COUNT(*)
FROM customer_known_good c4
GROUP BY c4.cust_nbr, c4.name...)

it is obvious that customer_known_good should be aliased as c1 but it is not shown as being aliased.

The table doesn't list the DBMS_DB_VERSION.VER_LE_11 constant

The query for the CURSOR does not contain a FOR UPDATE clause, even though this example is supposed to show what will happen when a CURSOR with FOR UPDATE issues a premature COMMIT.
Indeed, with my debuggable-in-SQLDeveloper-Version of it, the expected error ORA-01002: fetch out of sequence does not appear.
Only if I include the FOR UPDATE will the error occur as predicted.
Below my code:
1) Testdata:
INSERT INTO winterize VALUES(1,'fix door bell',1,'hammer, screwdriver','Y',TO_NUMBER(TO_CHAR (SYSDATE, 'YYYY')),'N','STEVEN');

2) a debuggable PROCEDURE made out of the anonymous block:

CREATE OR REPLACE PROCEDURE cursor_for_update_commit_err IS
/* All the jobs in the Fall to prepare for the Winter */
CURSOR fall_jobs_cur
IS
SELECT task, expected_hours, tools_required, do_it_yourself_flag
FROM winterize
WHERE year_of_task = TO_NUMBER (TO_CHAR (SYSDATE, 'YYYY'))
AND completed_flag = 'N'
FOR UPDATE; --you forgot that, Steven ;-)
BEGIN
/* For each job fetched by the cursor... */
FOR job_rec IN fall_jobs_cur
LOOP
IF job_rec.do_it_yourself_flag = 'Y'
THEN
/*
|| I have found my next job. Assign it to myself (like someone
|| else is going to do it!) and then commit the changes.
*/
UPDATE winterize
SET responsible = 'STEVEN'
WHERE task = job_rec.task
AND year_of_task = TO_NUMBER (TO_CHAR (SYSDATE, 'YYYY'));

COMMIT;
END IF;
END LOOP;
END;

The first example of constant declaration includes
TO_NUMBER(TO_CHAR(SYSDATE, 'YYYY'))

This is technically correct and will produce the desired result, but it is not a good practice. Better to use
EXTRACT(YEAR FROM SYSDATE)

The procedures calculate successive values for int1, eventually resulting in OVERFLOW; please test on your machine to confirm. This makes sense: the final value of int1 is
int1 + int2 * (1 + 2 + ... + iterations).
The sum is of the order of 1/2 * iterations^2, and with iterations of the order of 10^8, the result is of the order of 10^16, more than allowed for PLS_INTEGER. For my own testing, I changed to int1 = 1 + int2 * cnt, which generates the same number of additions and multiplications. I get execution times similar to yours.

An interesting aside: I got the same overflow problem with simple_test and your loop body. You may want to test to confirm. This is likely caused by cnt: the loop counter is PLS_INTEGER, and since it is mixed with int1 and int2, they are converted form SIMPLE to PLS NOT NULL (according to the Oracle documentation). This would be worth a brief note in itself. Can cnt be forced to SIMPLE_INTEGER? If it can, the speed improvement might become much greater - as it is, simple_test saves only the NULL checks, but not the overflow checks.