I wrote a post a while back call “The Death of UTL_FILE”, and probably because of it’s click-bait title I got lots of feedback, so I’m back to flog that horse . Seriously though, I stand behind my assertion in that post, that the majority of usages of UTL_FILE I’ve seen my career are mimicking the spooling behaviour of a SQL*Plus script. And as that post pointed out, you can now achieve that functionality directly with the scheduler.

That is well and good for writing files from the database, and I added:

“I’ll come back to UTL_FILE to read files in a future post”.

That time has come! Many developers will be aware of the feature known as external tables but a criticism of those has been that whereas UTL_FILE only needs permissions on the appropriate directory object to read a file, an external table requires a DDL definition, which typically means a lot of red tape and processes to follow when trying to implement changes.

Some of that pain was alleviated in 12c Release 2 when it became possible to modify portions of the external table definition on the fly at query execution time. For example, if you needed to change the name of the file name each day, then rather than having to re-craft an external table DDL, or even an ‘alter’ command, it could be done as required by the query:

SQL> select * from ext_emp
  2    external modify ( location ('emp20161002.dat') );

     EMPNO ENAME      JOB              MGR HIREDATE         SAL
---------- ---------- --------- ---------- --------- ---------- ---
      7902 FORD       ANALYST         7566 03-DEC-81       3000
      7934 MILLER     CLERK           7782 23-JAN-82       1300        
      7566 JONES      MANAGER         7839 02-APR-81       2975

That still of course does not alleviate the need for the initial table DDL. But in 18c, you can query an external file and the only thing you need to do so is appropriate privileges on the directory object. Sounds a lot like UTL_FILE, no? In 18c, we can query an external source directly with query. Here’s a simple example using the following data file (emp.dat) as a source:

7369,SMITH,CLERK,7902,800,,20
7499,ALLEN,SALESMAN,7698,1600,300,30
7521,WARD,SALESMAN,7698,1250,500,30
7566,JONES,MANAGER,7839,2975,,20
7654,MARTIN,SALESMAN,7698,1250,1400,30
7698,BLAKE,MANAGER,7839,2850,,30
7782,CLARK,MANAGER,7839,2450,,10
7788,SCOTT,ANALYST,7566,3000,,20
7839,KING,PRESIDENT,,5000,,10
7844,TURNER,SALESMAN,7698,1500,,30
7876,ADAMS,CLERK,7788,1100,,20
7900,JAMES,CLERK,7698,950,,30
7902,FORD,ANALYST,7566,3000,,20
7934,MILLER,CLERK,7782,1300,,10

The query (in this case) just requires the EXTERNAL modifier and a definition of the columns and we’re done!

SQL> select * from
  2  external (
  3     (
  4       empno     number(4),
  5       ename     varchar2(12),
  6       job       varchar2(12),
  7       mgr       number(4),
  8       sal       number(7,2),
  9       comm      number(7,2),
 10       deptno    number(2)
 11     )
 12  type oracle_loader
 13  default directory TMP
 14  location ('emp.dat')
 15  );

     EMPNO ENAME        JOB                 MGR        SAL       COMM     DEPTNO
---------- ------------ ------------ ---------- ---------- ---------- ----------
      7369 SMITH        CLERK              7902        800                    20
      7499 ALLEN        SALESMAN           7698       1600        300         30
      7521 WARD         SALESMAN           7698       1250        500         30
      7566 JONES        MANAGER            7839       2975                    20
      7654 MARTIN       SALESMAN           7698       1250       1400         30
      7698 BLAKE        MANAGER            7839       2850                    30
      7782 CLARK        MANAGER            7839       2450                    10
      7788 SCOTT        ANALYST            7566       3000                    20
      7839 KING         PRESIDENT                     5000                    10
      7844 TURNER       SALESMAN           7698       1500                    30
      7876 ADAMS        CLERK              7788       1100                    20
      7900 JAMES        CLERK              7698        950                    30
      7902 FORD         ANALYST            7566       3000                    20
      7934 MILLER       CLERK              7782       1300                    10

14 rows selected.

Of course, UTL_FILE is more about totally flexibility in the content your read. After all, you (typically) read a line from the file and then parse it however you please. But the same is possible with the 18c syntax. Here I’ll take some free format text from the Oracle documentation in a file plain.dat.

9.5 System Triggers
A system trigger is created on either a schema or the database.
Its triggering event is composed of either DDL statements (listed in "ddl_event") or database operation statements (listed in "database_event").
A system trigger fires at exactly one of these timing points:
Before the triggering statement runs
(The trigger is called a BEFORE statement trigger or statement-level BEFORE trigger.)
After the triggering statement runs
(The trigger is called a AFTER statement trigger or statement-level AFTER trigger.)
Instead of the triggering CREATE statement
(The trigger is called an INSTEAD OF CREATE trigger.)
Topics
SCHEMA Triggers
DATABASE Triggers
INSTEAD OF CREATE Triggers
9.5.1 SCHEMA Triggers
A SCHEMA trigger is created on a schema and fires whenever the user who owns it is the current user and initiates the triggering event.
Suppose that both user1 and user2 own schema triggers, and user1 invokes a DR unit owned by user2. Inside the DR unit, user2 is the current user. Therefore, if the DR unit initiates the triggering event of a schema trigger that user2 owns, then that trigger fires. However, if the DR unit initiates the triggering event of a schema trigger that user1 owns, then that trigger does not fire.
Example 9-19 creates a BEFORE statement trigger on the sample schema HR. When a user connected as HR tries to drop a database object, the database fires the trigger before dropping the object.

To mimic the line-by-line read style of UTL_FILE, I can simple define a single column holding a line from the data file.

SQL> select * from
  2  external (
  3     (
  4       text varchar2(4000)
  5     )
  6  type oracle_loader
  7  default directory TMP
  8  location ('plain.dat')
  9  );

TEXT
------------------------------------------------------------
9.5 System Triggers
A system trigger is created on either a schema or the databa
se.

Its triggering event is composed of either DDL statements (l
isted in "ddl_event") or database operation statements (list
ed in "database_event").

A system trigger fires at exactly one of these timing points
:

Before the triggering statement runs
(The trigger is called a BEFORE statement trigger or stateme
nt-level BEFORE trigger.)

After the triggering statement runs
(The trigger is called a AFTER statement trigger or statemen
t-level AFTER trigger.)

Instead of the triggering CREATE statement
(The trigger is called an INSTEAD OF CREATE trigger.)
Topics
SCHEMA Triggers
DATABASE Triggers
INSTEAD OF CREATE Triggers
9.5.1 SCHEMA Triggers
A SCHEMA trigger is created on a schema and fires whenever t
he user who owns it is the current user and initiates the tr
iggering event.

Suppose that both user1 and user2 own schema triggers
Example 9-19 creates a BEFORE statement trigger on the sampl
e schema HR. When a user connected as HR tries to drop a dat
abase object


18 rows selected.

So there is plenty of potential there to reduce the amount of source code to maintain using this nice syntax. The line between database data and external data gets blurrier, which is a great convenience for developers and ad-hoc users in being able to bring all the power of SQL to more data sources.

Footnote: When you query an external data source in 18c in the way mentioned above, behind the scenes, the database may create global temporary tables to support the operation. In the first example above, the database performed the following DDL recursively:

CREATE GLOBAL TEMPORARY TABLE "SCOTT"."SYS_TEMP_0FD9D678B_BDA818A8" SHARING=NONE  
("EMPNO" NUMBER(4),
 "ENAME" VARCHAR2(12) COLLATE "USING_NLS_COMP" ,
 "JOB" VARCHAR2(12) COLLATE "USING_NLS_COMP" ,
 "MGR" NUMBER(4),"SAL" NUMBER(7,2),
 "COMM" NUMBER(7,2),
 "DEPTNO" NUMBER(2) 
) 
IN_MEMORY_METADATA CURSOR_SPECIFIC_SEGMENT INLINE_XT  
STORAGE (OBJNO 4254951307 ) NOPARALLEL

That should not be cause for concern, but if you have hundreds of differently structured external data sources, and/or triggers that fire on DDL operations on the database, then you might see some impact. As with all things, thorough testing should always precede production implementation.

Here is a little example using tcpdump and strace to troubleshoot a network issue with an Oracle connection. It may not be the best approach for all cases, but just an example, as this is a copy/paste of my screen after I analyzed it. I just changed the server names.

At some point, the communication between two servers was hanging, with both endpoints waiting on read() — like ‘SQL*Net message from client’ wait event on the server. This issue occurred only on some circumstances: a case that always reproduced was RMAN correctly connected to the catalog, but hanging when we did a ‘show all’.

Client netstat and strace

I have RMAN started and connected to the catalog.

I identify my client process, in this case the RMAN executable. I display its TCP connection with netstat and its current system calls with strace:

[root@client tmp]# netstat -p | grep "/rman"

Proto Local Address Foreign Address State
tcp   client:37051  server:1521      ESTABLISHED 192131/rman

[root@client tmp]# strace -yttp 192131
Process 192131 attached
10:41:29.168494 read(0,

I can see the connection from client to server on port 1521 and the process is waiting on user input (stdin).

Server netstat and strace

On the remote side, I see the same TCP connection (same hosts and ports):

[root@server log]# netstat -p | grep ":37051"

Proto Local Address Foreign Address State
tcp   server:1521   client:37051    ESTABLISHED 36761/oraclePDBR2

and the process is waiting on socket (‘SQL*Net message from client’):

[root@server log]# strace -yttp 36761
Process 36761 attached
10:41:43.745239 read(20<socket:[3785769780]>,

Client/server dialogue

Here is where I run ‘show all;’ which will get hung. I’ll show all the network dialogue from this point.

I run tcpdump in background to show the packets sent on client :

[root@client tmp]# tcpdump -i bond0 src client and dst server &

and on server:

[root@server tmp]# tcpdump -i bond0 src server and dst client &

In both I have strace attached to the processes identified by netstat -p (strace -y to show file name for descriptors and -tt to show timestamp)

Here are the traces just after I run ‘show all;’ on the client, which queries the server.

The client sends a statement. Here is the write (from strace) and TCP message (from tcpdump):

10:43:44.309812 write(15, "\3+\0\0\6\0\0\0\0\0\21i{\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\5\0\0"..., 811) = 811

10:43:44.309853 IP client.37051 > server.1521: Flags [P.], seq 34484:35295, ack 17685, win 442, length 811

The server receives it and strace displays the end of the line with the read() return code (which is the size of the message):

"\3+\0\0\6\0\0\0\0\0\21i{\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\5\0\0"..., 8208) = 811

In the meanwhile, the client waits for the answer:

10:43:44.309892 read(15,

Then the server answers:

10:43:44.356795 write(20, "\0\355\0\0\6\0\0\0\0\0\v\1\5q\6\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 237

10:43:44.356830 IP server.1521> client.37051: Flags [P.], seq 17685:17922, ack 35296, win 442, length 237

) = 237

We see strace printing the call (write 237 bytes), then tcpdump showing the packet going out (same size: bytes 17685 to 17922 in this server->client stream), and then strace continues the line when the write() system call returns, displaying the number of bytes written.

Sending this packet is also the occasion to acknowledge what was received — up to byte 35296 of the client->server message.

The client gets it, strace showing the end of the read() line:

10:43:44.357178 IP client.37051 > server.1521: Flags [.], ack 17922, win 442, length 0

"\0\355\0\0\6\0\0\0\0\0\v\1\5q\6\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 8208) = 237

Note that an empty message (length=0) was sent by the client to acknowledge that it has received up to byte 17922 in the server->client message.

After having sent its answer, the server waits for the next query (and acknowledges what was received recently with a length 0 packet):

10:43:44.356894 read(20, 

10:43:44.357493 IP server.1521> client.37051: Flags [.], ack 36267, win 442, length 0

The client sends a new query:

10:43:44.357368 write(15, "\3\313\0\0\6\0\0\0\0\0\21i}\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\4\0\0"..., 971

10:43:44.357416 IP client.37051 > server.1521: Flags [P.], seq 35295:36266, ack 17922, win 442, length 971
) = 971

and waits for the response:

10:43:44.357461 read(15, "\0\356\0\0\6\0\0\0\0\0\v\1\5\n\7\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 8208) = 238

From here, I start to show the full line with the return code (238 bytes) but remember that only the ‘10:43:44.357461 read(15,’ part is displayed by strace before the message is actually received. The buffer content and size is written later.

Here is the server receiving the message from the client and sending the answer:

"\3\313\0\0\6\0\0\0\0\0\21i}\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\4\0\0"..., 8208) = 971

10:43:44.365296 write(20, "\0\356\0\0\6\0\0\0\0\0\v\1\5\n\7\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 238

10:43:44.365326 IP server.1521> client.37051: Flags [P.], seq 17922:18160, ack 36267, win 442, length 238

) = 238

We have seen that the client got it (the 238 bytes). It sends a new query (365 bytes), waits for the answer which is 237 bytes:

10:43:44.365766 write(15, "\1m\0\0\6\0\0\0\0\0\21i\177\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\2\0\0"..., 365) = 365

10:43:44.365817 IP client.37051 > server.1521: Flags [P.], seq 36266:36631, ack 18160, win 442, length 365

10:43:44.365870 read(15, "\0\355\0\0\6\0\0\0\0\0\v\1\5\221\1\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 8208) = 237

Here is the server part for this dialogue, receiving the 365 bytes query and writing the 237 bytes answer:

10:43:44.365408 read(20, "\1m\0\0\6\0\0\0\0\0\21i\177\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\2\0\0"..., 8208) = 365

10:43:44.366793 write(20, "\0\355\0\0\6\0\0\0\0\0\v\1\5\221\1\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 237

10:43:44.366829 IP server.1521> client.37051: Flags [P.], seq 18160:18397, ack 36632, win 442, length 237

) = 237

There are a few more exchanges where the client sends 381 bytes, the server answers 236 bytes, then the client sends 297 bytes and the server answers in 181 bytes. Here is the client strace and tcpddump for this:

10:43:44.367199 write(15, "\1}\0\0\6\0\0\0\0\0\21i\201\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\4\0\0"..., 381) = 381

10:43:44.367229 IP client.37051 > server.1521: Flags [P.], seq 36631:37012, ack 18397, win 442, length 381

10:43:44.367272 read(15, 
"\0\354\0\0\6\0\0\0\0\0\v\1\5L\1\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 8208) = 236

10:43:44.368522 write(15, "\1)\0\0\6\0\0\0\0\0\21i\203\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\5\0\0"..., 297) = 297

10:43:44.368555 IP client.37051 > server.1521: Flags [P.], seq 37012:37309, ack 18633, win 442, length 297

10:43:44.368598 read(15, "\0\265\0\0\6\0\0\0\0\0\10\6\0\252I(\35\2\7\0\0\2\0\0\0\1\0\0\0\0\0\0"..., 8208) = 181

and the strace and tcpdump on the server side:

10:43:44.366884 read(20, "\1}\0\0\6\0\0\0\0\0\21i\201\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\4\0\0"..., 8208) = 381

10:43:44.368031 write(20, "\0\354\0\0\6\0\0\0\0\0\v\1\5L\1\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 236

10:43:44.368084 IP server.1521> client.37051: Flags [P.], seq 18397:18633, ack 37013, win 442, length 236
) = 236

10:43:44.368181 read(20, "\1)\0\0\6\0\0\0\0\0\21i\203\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\5\0\0"..., 8208) = 297

10:43:44.370926 write(20, "\0\265\0\0\6\0\0\0\0\0\10\6\0\252I(\35\2\7\0\0\2\0\0\0\1\0\0\0\0\0\0"..., 181) = 181

10:43:44.370949 IP server.1521 > client.37051: Flags [P.], seq 18633:18814, ack 37310, win 442, length 181

10:43:44.371006 read(20, 

The client which got the 181 bytes answer from the server, now sends a new query:

10:43:44.413973 write(15, "\10V\0\0\6\0\0\0\0\0\21i\205\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\2\0\0"..., 2134

10:43:44.414020 IP client.37051 > server.1521: Flags [P.], seq 37309:39443, ack 18814, win 442, length 2134

) = 2134

and then waits for the answer:

10:43:44.414115 read(15,

but this is where it hangs. Remember where we are:

• the server has acknowledged up byte 37310 in messages from client and is waiting to read from the socket
• the client is acknowledging up to byte 18814 in messages from server and sends more bytes (from 37309 to 39443)

But the server didn’t receive them and is still waiting:

10:43:44.371006 read(20,

Both side waiting… this is where tcpdump will be helpful. strace shows only one write() call, which writes to the TCP buffer. But tcpdump shows many attempts to send this to the server:

10:43:44.617869 IP client.37051 > server.1521: Flags [P.], seq 37309:39443, ack 18814, win 442, length 2134

10:43:45.025804 IP client.37051 > server.1521: Flags [P.], seq 37309:39443, ack 18814, win 442, length 2134

10:43:45.841818 IP client.37051 > server.1521: Flags [P.], seq 37309:39443, ack 18814, win 442, length 2134

10:43:47.473818 IP client.37051 > server.1521: Flags [P.], seq 37309:39443, ack 18814, win 442, length 2134

10:43:50.737837 IP client.37051 > server.1521: Flags [P.], seq 37309:39443, ack 18814, win 442, length 2134

Same packet, same size, the 37309 to 39443 bytes of the client->server conversation. The last acknowledge from the server was 37310 — he never received this packet. And because it is TCP, it retries. The write() was done because it writes to the buffer, so the application is just waiting for the answer.

A packet has disappeared in the client->server conversation. This is a job for the network team, but there’s something to remark here. Many messages were ok, but not this one. What is special? The size is larger: 2134 bytes. The maximum we had before was 971.

Simple ping…

Those numbers may already ring a bell, but let’s try to PING with some different packets sizes. Up to 1472 goes through:

[root@client tmp]# ping -c 5 -s 1472 -W 5 server
PING client (10.30.13.62) 1472(1500) bytes of data.
1480 bytes from server(10.30.13.62): icmp_seq=1 ttl=58 time=0.607 ms
1480 bytes from server(10.30.13.62): icmp_seq=2 ttl=58 time=0.477 ms
1480 bytes from server(10.30.13.62): icmp_seq=3 ttl=58 time=0.494 ms
1480 bytes from server(10.30.13.62): icmp_seq=4 ttl=58 time=0.474 ms
1480 bytes from server(10.30.13.62): icmp_seq=5 ttl=58 time=0.533 ms

But larger fails:

[root@client tmp]# ping -c 5 -s 1473 -W 5 server
PING server (10.30.13.62) 1473(1501) bytes of data.

--- server ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 9000ms

All packets were lost.

The default Ethernet MTU (maximum transmission size) is 1500 bytes but we use Jumbo Frames here, as defined by the interface:

[root@client tmp]# ip a | grep mtu
...
8: bond0:  mtu 9000 qdisc noqueue state UP

There is probably a router in the middle which does not allow Jumbo Frames… This is now a job for the network guys. However, if I need a quick workaround I can limit the Session Data Unit on Oracle side, like:

(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=myservice))(SDU=1430)(ADDRESS=(PROTOCOL=TCP)(HOST=server)(PORT=1521)))

With SDU at 1430 the length of the packets (as displayed by tcpdump) are at maximum 1460 bytes (NS and NT layers add 30 bytes) which is the maximum that can go through MTU 1500 (as IP and TCP headers add 20 bytes each).

If you wonder why ping was able to send packets up to 1472 bytes, that’s because the ICMP header is only 8 bytes instead of the TCP 20 bytes.

One of the very cool things about DBMS_JOB is that a job does not “exist” as such until the session that submitted the job commits the transaction. (This in my opinion is a critical feature that is missing from the DBMS_SCHEDULER package which, other than this omission, is superior to DBMS_JOB in every way).

Because DBMS_JOB is transactional, we can use it to make “non-transactional” things appear transactional. For example, if part of the workflow for hiring someone is to send an email to the Human Resources department, we can do the email via job submission so that an email is not sent if the employee record is not created successfully or is rolled back manually, eg:

begin
  insert into EMP (empno, ename) values (123, 'CONNOR');
  dbms_job.submit( :j,'notify_hr(empno=>123);');
end;

This post is not about that – that cool usage scenario is well known. But as a consequence, people tend to think that as soon as I commit, the job will spring into life. This is typically the case, but there are no guarantees that your job will run immediately, even if job queue processes are available.

Here’s a couple of examples of that in action

--
-- This one is almost instant
--
SQL> create table t
  2   ( submitted timestamp,
  3     started   timestamp );

Table created.

SQL>
SQL> create or replace
  2  procedure prc is
  3  begin
  4    update t set started = systimestamp;
  5    commit;
  6  end;
  7  /

Procedure created.

SQL>
SQL> declare
  2    j int;
  3  begin
  4    dbms_job.submit( j,'prc;');
  5    insert into t(submitted) values (systimestamp);
  6    commit;
  7  end;
  8  /

PL/SQL procedure successfully completed.

SQL>
SQL> col submitted format a32
SQL> col started format a32
SQL> select * from t;

SUBMITTED                        STARTED
-------------------------------- --------------------------------
13-FEB-19 09.31.10.956989 PM     13-FEB-19 09.31.10.994153 PM

--
-- This one not so much :-)
--

SQL> declare
  2    j int;
  3  begin
  4    dbms_job.submit( j,'prc;');
  5    insert into t(submitted) values (systimestamp);
  6    commit;
  7  end;
  8  /

PL/SQL procedure successfully completed.

SQL>
SQL> col submitted format a32
SQL> col started format a32
SQL> select * from t;

SUBMITTED                        STARTED
-------------------------------- --------------------------------
14-FEB-19 01.22.45.928000 PM

SQL> /

SUBMITTED                        STARTED
-------------------------------- --------------------------------
14-FEB-19 01.22.45.928000 PM

SQL> /

SUBMITTED                        STARTED
-------------------------------- --------------------------------
14-FEB-19 01.22.45.928000 PM     14-FEB-19 01.22.59.775000 PM

In particular, I tend to notice this more on Windows platforms than others. MOS Note 2109840.1 is also a good starting point if you are seeing huge delays – you may have hit upon a bug.

So just be aware that DBMS_JOB will run your job soon after committing, but “soon” is a flexible term

It’s always so good to see a user community growing. Last week was the first ever technical conference for obug (or is it OBUG) – the Oracle Benelux User Group. It was an excellent couple of days, packed with a fantastic range of presenting talent and an enthusiastic audience. I was honoured to be asked to be one of the presenters.

https://mwidlake.files.wordpress.com/2019/02/screenhunter-100.jpg?w=920&... 920w, https://mwidlake.files.wordpress.com/2019/02/screenhunter-100.jpg?w=150&... 150w, https://mwidlake.files.wordpress.com/2019/02/screenhunter-100.jpg?w=300&... 300w, https://mwidlake.files.wordpress.com/2019/02/screenhunter-100.jpg?w=768&... 768w" sizes="(max-width: 460px) 100vw, 460px" />

A smorgasbord of talking
technical talent

The event was held in a cinema, which lends itself well to a conference. Riga Dev Days use a cinema also and it works because every seat in the room has a great view of the screen. the screen is large, the projector is (of course) pretty good, and if you want sound it is top quality sound. The icing on the cake is that the seats are padded and comfortable. Poor seating is a real pain (literally) at an event where you are sitting most of the day. One potential drawback of a cinema is ensuring you have areas for catering and coffee, but the chosen venue was able to provide that as well.

https://mwidlake.files.wordpress.com/2019/02/hjft3318.jpg?w=150&h=108 150w, https://mwidlake.files.wordpress.com/2019/02/hjft3318.jpg?w=300&h=215 300w, https://mwidlake.files.wordpress.com/2019/02/hjft3318.jpg?w=768&h=551 768w, https://mwidlake.files.wordpress.com/2019/02/hjft3318.jpg 837w" sizes="(max-width: 460px) 100vw, 460px" />

Belgium Speakers

I have to tip my hat in deep admiration to Philippe Fierens, Pieter Van Puymbroeck, and Janny Ekelson for the organisation of the event and how well they looked after all the speakers. I don’t think most people have any idea how much hard work, stress and energy is involved in organising these things. I certainly didn’t until I started helping helping organise conferences for the UK Oracle User Group and we have the support of staff who have done this a dozen times. These guys were doing the whole thing and doing it for the first time. Well done!

As this was obug’s first technical conference, Pieter & Philippe followed the example of the Polish User Group when they organised their first conference – they went and asked lots of speakers they knew if they would present. (That’s a nice thing about User Groups too, you learn how to run your own group better). It helps that they are both accomplished presenters themselves and part of the speaker circuit. It’s an odd thing, if you ask one us attention-seeking, self-opinionated, egotistical speakers to present – we are inclined to say yes :-). (I should point out, some speakers are not egotistical or self opinionated. Some). I did hear the odd muttering about a call for papers not happening but, if I was organising my first conference, I would not want the hassle and risk of C4P. I would be pestering my friends and contacts in the same way.

https://mwidlake.files.wordpress.com/2019/02/img_9645.jpg?w=920&h=690 920w, https://mwidlake.files.wordpress.com/2019/02/img_9645.jpg?w=150&h=113 150w, https://mwidlake.files.wordpress.com/2019/02/img_9645.jpg?w=300&h=225 300w, https://mwidlake.files.wordpress.com/2019/02/img_9645.jpg?w=768&h=576 768w" sizes="(max-width: 460px) 100vw, 460px" />

It was a very sociable conference. I mean, we were in Belgium which is renowned for beer and chocolate, it would have been wrong not to partake in them. I’m of the opinion that the social side of user groups is as important as the presentations and workshops. There seems to be a strong correlation to me between those who socialise during a conference and those that get the most out of it. You can learn a lot by spending time with people who have suffered the same issues with tech as you, or who know more about some aspect of Oracle. I got into an interesting chat about potentially pre-checking the second table in a join before you bother scanning the first table, as a cheap – if -rare – optimisation. And I met a guy who’s partner was thinking about making hats, just like my wife does. Oh, and the obligatory discussion about making bread.

As well as the excellent talks and socialising there was also the access to Oracle product managers and experts. There were several at the conference, a couple of whom who I had never met or only briefly. I can’t tell you how much it can help to be able to contact the person in charge of SQL Developer or Exadata and ask “can you find me someone I can chat to about ‘Blargh'”.

There was one final highlight of obug. We had the classic “4 I.T. experts clustered around a laptop that simply won’t run the presentation”. It’s one of those eternal truths of working in the industry that, no matter how good you are in your chosen field, presentations make it all break and you can’t fix it quickly :-). We got there.

It was an excellent conference and I really, *really* hope they do it again next year.

{Oh, I should add – I do not know who took the photo of Roger, Flora, Frits and Ricardo, I stole it off the whatsapp stream we speakers used. Thank you to whoever and let me know if you want crediting}