ALTER sequence MY_SEQ increment BY 500;
SELECT MY_SEQ.NEXTVAL FROM dual;
ALTER sequence MY_SEQ increment BY 1;

What do you do if you don’t have the correct permissions to do this? You can always call up the dba and ask him. If you’re impatient, you can also do a little pl/sql programming to accomplish the same thing. All you want to do is just repeatedly select the next value until the sequence value is higher that the current key value.

DECLARE
  current_value NUMBER;
  seq_val NUMBER;
BEGIN
  SELECT MAX(MY_TABLE.id) INTO current_val FROM MY_TABLE;
  WHILE current_val >= seq_val
  LOOP
    SELECT MY_SEQ.NEXTVAL INTO seq_val FROM dual;
  END LOOP;
END;

Of course, if you encounter this situation once, chances are that you will encounter it many times. Next, you can create a function that takes the table name, key column name, and sequence name and then executes dynamically created sql to fix the problem.

CREATE OR REPLACE PROCEDURE INCREMENT_SEQ(IN TABLE_NAME, IN ID_COLUMN_NAME, IN SEQUENCE_NAME) IS
DECLARE
  current_value NUMBER;
  seq_val NUMBER := -1;
BEGIN
  EXECUTE IMMEDIATE 'select max(' || TABLE_NAME || '.' || ID_COLUMN_NAME || ') into current value from ' || TABLE_NAME;
  WHILE current_val >= seq_val
  LOOP
    EXECUTE IMMEDIATE 'select ' || SEQUENCE_NAME || ".nextval into seq_val from dual';
  end loop;
END INCREMENT_SEQ;

Now, you should be able to fix any sequence/key mismatches simply by calling the procedure.

INCREMENT_SEQ('MY_TABLE', 'ID', 'MY_SEQ');

CREATE OR REPLACE PACKAGE BODY MY_PKG IS
   g_enabled BOOLEAN := TRUE;
 
   PROCEDURE enable_sp() IS
      BEGIN
         g_enabled := TRUE;
      END;
 
   PROCEDURE disable_sp() IS
      BEGIN
         g_enabled := FALSE;
      END;
 
   FUNCTION is_enabled_fn() IS
      l_return_value NUMBER;
 
      BEGIN
         IF g_enabled THEN
            l_return_value := 1;
         ELSE
            l_return_value := 0;
         END IF;
 
         RETURN l_return_value;
      END;
END MY_PKG;

Seems pretty innocent, doesn’t it?

So, I write unit tests in java to test everything. It all seems to be working. It goes through code review. Nothing more serious than cosmetic issues were found. It goes through the qa cycles. It all seems to be working. It gets deployed to production. At first, it seems to be working. Then I start to see some interesting behavior.

Lesson #1:

PL/SQL data types aren’t as straight forward as I would have liked. The variable g_enabled is of type BOOLEAN. This is a data type built into PL/SQL. It is not a data type in Oracle’s version of SQL. Why is this significant? Consider the two following scenario’s and their result (assuming that is_enabled=TRUE) -

BEGIN
 
  DBMS_OUTPUT.put_line(my_pkg.is_enabled_fn());
 
END;

This will print out a 1 to the standard output.

SELECT my_pkg.is_enabled_fn() FROM dual;

This query will return 0.

This was not what I expected. I would have expected the second query to return a 1. The reason it doesn’t, is that the query is not run in a PL/SQL block. This results in the BOOLEAN data type to not be defined and the if statement in is_enabled_fn() to always evaluate to false.

Lesson #2:

Package variables are connection private. I create two connections, A and B, to the database. If I call disable_sp() in connection A, is_enabled_fn() will still return a 1 in connection B. The value of the variable is not shared across the connections. If I were then to create a connection C, is_enabled_fn() will return 0. This is because connection C was created after the value was set in connection A. While it wasn’t what I initially expected, it makes some sense in that the connections don’t share memory. The really big problem comes into play when app servers pool connections and might not close them for weeks at a time.