If you have any questions, please don’t hesitate to contact me at richard@richardfooteconsulting.com.
FAQ: Webinars for “Oracle Indexing Internals and Best Practices” July 30, 2018
Posted by Richard Foote in Indexing Webinar, Oracle Indexes.2 comments
I’ve been somewhat inundated with questions regarding the “Oracle Indexing Internals and Best Practices” webinar series I’ll be running in October and November since I announced both webinar series last week. So I’ve compiled the following list of frequently asked questions which I’m hoping will address most of those asked.
If you have any additional questions or you’re interested in attending either of these webinar series, please contact me at richard@richardfooteconsulting.com.
FAQ: Webinars for “Oracle Indexing Internals and Best Practices”.
How do I register? Please contact me at richard@richardfooteconsulting.com and I will give you all the necessary registration and payment instructions.
How much does it cost? To attend the full 5 day x 4 hours webinar series costs $1200.00 Australian Dollars. If you’re from Australia, the full cost will be $1320.00 which includes the 10% GST.
What are the payment options? You can pay either by direct bank transfer (I will provide you with all the necessary banking information) or by Credit Card (I will send you a PayPal invoice which allows for Credit Card payments. You do not need a PayPal account for this service).
Are there group discounts? Yes, if you have 3 or more persons from your organisation that is interested in attending a webinar, please contact me for group discount rates.
If my payment hasn’t come through yet, can I still join the webinar? No. For obvious reasons, I must receive full payment before you can be registered for the webinar. I try to provide plenty of prior warning before the webinars to enable obtaining managerial permission and completing payments. Please don’t leave it too late.
Can I get a refund? No. However, if you’re not able to join for some reason, you can either transfer the registration to someone else within your organisation, or you can attend a later webinar at not addition cost. Please contact me ASAP if you’re not able to attend.
Do you run customer dedicated webinars? Yes, if you have 10 or more persons in your organisation interested in attending a webinar, contact me to determine if a webinar just for your organisation might be the better option.
What are the start and end times for each webinar? They are detailed within the webinar description. All times listed are in local Australian time as I’m based in Australia. You will need to convert these times to determine your corresponding local times. Webinars are scheduled to be more favourable in different parts of the world so select the webinar series that best suits you. Note: because of time differences, the webinar could be run in a different day to those listed in your part of the world. For example, the webinar scheduled for 6-10 November 2018 starts on Tuesday, 6 November at 5am in Australia, but this is actually Monday, 5 November at 10am in San Francisco.
What is the schedule for each webinar series? Each webinar series runs for 5 days (Monday-Friday at the targeted time zone), with 4 hours of activity per day. Each day, there are 3 x 1 hour sessions, with a 20 minute break following each one. During the 20 minute break, there is an opportunity for further questions to be asked.
What webinars are currently scheduled?
- Webinar Series 1: 8-12 October 2018 (start 7pm AEDT, end 11pm AEDT)
- Webinar Series 2: 6-10 November 2018 (start 5am AEDT, end 9am AEDT)
Series 1 is in a time zone more suitable for those in Eastern Asia and Europe. Series 2 is more suitable for those in the Americas.
Is the material covered the same as the in person seminars? Yes, the same material is covered. There is however a little more time available during a webinar, so I might be able to cover more topics. Maybe. To see the webinar content, visit my Indexing Seminar page.
Will I be able to ask questions during the webinar? Yes. However, I will mute all connections during the webinar, with questions during the sessions possible via a texting interface. This will reduce noise issues and unnecessary questions from disrupting the presentations. I will try to answer appropriate questions during the presentations or during the 20 minute break following each presentation session. You can also ask me follow up questions after the webinar.
Do you get any webinar materials to keep? Yes. Each attendee will get a softcopy of the some 850+ pages of content in PDF format. This will allow everyone to review all the material after the webinar and to also cut ‘n’ paste the numerous demos I cover and re-run them in your own environments. Note this material is of course copyrighted and that replicating or distributing this material is strictly prohibited.
What webinar software is used? I will be using GoToWebinar.
Are the webinars recorded? No, not initially anyways. Remember, you do have a copy of all the webinar content covered in the supplied PDF.
How do I join the webinar? I will provide full instructions on how to join the webinar beforehand. You will be given a unique link that allows you to join in the fun. Do not distribute this link to anyone else as only one connection is possible per supplied link. I recommend downloading the GoToWebinar interface (I will provide the instructions) in plenty of time prior to joining in the webinar.
When should I login to the webinar? I will start the webinar session 30 minutes prior to the official start to give everybody plenty of time to logon and iron out any issues you might have.
Are there any exercises or hands on labs? No. There are parts where I get customer participation, but there are no labs or requirements to have a database environment on hand. That said, some people do like to periodically cut ‘n’ paste some of my demos from the supplied PDFs and run them in their own database environments during the class. However, the pace I set makes this difficult to do while keeping up with the presentation.
Do I get a certificate for attending? Yes. Everyone will get a certificate of attendance.
Is there a limit to the number of attendees per webinar? Yes. To keep the webinar running smoothly and to give everyone an opportunity to ask some questions, numbers will be strictly limited.
How often are these webinars scheduled? Unsure. I will try and run a webinar series in different time zone friendly every “few months”, but this will depend largely on demand and my availability.
Where can I ask additional questions? As always, please contact me at richard@richardfooteconsulting.com if you have any questions.
Is the “Oracle Indexing Internals and Best Practices” learning experience really as good as people say? Yes, it really is 🙂
For up to date details, please visit my Indexing Webinar page.
Announcement: Webinars for “Oracle Indexing Internals and Best Practices” Now Confirmed !! July 23, 2018
Posted by Richard Foote in Oracle Indexes.add a comment
Exciting News !! I can now confirm the dates for my first webinars of my fully updated and highly acclaimed “Oracle Indexing Internals and Best Practice” seminar. For details of all the extensive content covered in the webinars, please visit my Indexing Seminar page.
The webinars will run for 4 hours each day, spanning a full week period (Monday to Friday) in various timezones that are friendly to different parts of the world.
So that’s 15+ hours of extensive content that will be of benefit to not only DBAs, but also to Developers, Solution Architects and anyone else interested in designing, developing or maintaining high performance Oracle-based applications.
There are currently 2 webinar series scheduled. They are:
- Webinar Series 1: 8-12 October 2018 (start 7pm AEDT, end 11pm AEDT)
- Webinar Series 2: 6-10 November 2018 (start 5am AEDT, end 9am AEDT)
Webinar Series 1 will be in timezones more agreeable to Eastern Asia/Europe. For example, they will start at 1:30pm local time in Mumbai, at 10:00am local time in Paris.
Webinar Series 2 will be in timezones more agreeable to the American Continents. For example they will start at in 1:00pm local time New York and 10:00am local time in San Francisco. (Note: The dates listed are as in Australia, they will actually run between Monday 5 November to Friday 9 November in the Americas).
The cost of each 5 x day series will be $1200.00 Australian Dollars (+GST if applicable and attending from within Australia).
Note: As this will be the first run of these webinars, numbers are strictly limited to ensure the smooth running of these events. Please register early to avoid disappointment as webinars are not scheduled too regularly.
Booking and Payment Instructions
To book your place, please email me at richard@richardfooteconsulting.com and I will send you an invoice with payment instructions. You can pay either by credit card via PayPal (you do not need a PayPal account for this), via a PayPal account or via direct bank transfer. Note: payment must be received before you can attend the webinar.
You can also pay for these webinars directly here if NOT attending from Australia:
Webinar Series 1: 8-12 October 2018 
Webinar Series 2: 6-10 November 2018
Once registered, you will be sent a unique link for each booking with instructions on how to attend the webinar. Prior to the webinar, you will also be sent a soft copy of the webinar materials, with 800+ pages of amazing content, that includes many useful tips and strategies to maximise the benefits of indexes on application/database performance and scalability.
Up to date details and terms and conditions can be found at my Indexing Webinar web page.
If you have any questions, please don’t hesitate to contact me.
Announcement: Venue Confirmed For Upcoming Brussels “Oracle Indexing Internals and Best Practices” Seminar July 18, 2018
Posted by Richard Foote in Oracle Indexes.add a comment
I can finally confirm the venue for my upcoming “Oracle Indexing Internals and Best Practices” seminar in beautiful Brussels, Belgium running on 27-28 September 2018.
The venue will be the Regus Brussels City Centre Training Rooms Facility, Avenue Louise / Louizalaan 65, Stephanie Square, 1050, Brussels.
Note: This will be the last public seminar I’ll run in Europe this year, so with strictly limited places, available places are likely to go fast.
This is a must attend seminar of benefit to not only DBAs, but also to Developers, Solution Architects and anyone else interested in designing, developing or maintaining high performance Oracle-based applications. It’s a fun, but intense, content rich seminar that is suitable for people of all experiences (from beginners to seasoned Oracle experts).
You can book your place now at: https://www.eventbrite.com.au/e/oracle-indexing-internals-best-practices-seminar-with-richard-foote-brussels-tickets-47703933750
The early bird rate is available until 7 September 2018, but it’s likely that places will all be sold out before then.
If you have any questions, or if you wish to pay directly via a raised invoice, then please contact me directly at richard@richardfooteconsulting.com ASAP.
Rebuilding Indexes: Danger With Clustering Factor Calculation (Chilly Down) July 17, 2018
Posted by Richard Foote in CBO, Clustering Factor, Data Clustering, Index Rebuild, Oracle Indexes, TABLE_CACHED_BLOCKS.1 comment so far
Let me start by saying if you don’t already following Jonathan Lewis’s excellent Oracle blog, do yourself a favour. In a recent article, Jonathan highlighted a danger with rebuilding indexes (or indeed creating an index) when used in relation to collecting index statistics with the TABLE_CACHED_BLOCKS preference.
I’ve discussed the importance of the TABLE_CACHED_BLOCKS statistics collection preference a number of times previously, but the issue discussed by Jonathan is worth repeating here.
Let me start by repeating a demo I’ve used previously, by creating a table stored in an ASSM tablespace with data that is well clustered, but reported as being badly clustered due to how the Clustering Factor (CF) is calculated by default.
Firstly, I create a simple table and sequence and run a procedure that populates the table with a monotonically increasing ID column populated via the sequence. But importantly, the procedure is executed concurrently from 3 separate sessions such that the monotonically increasing ID values are not stored in the table in precisely ID order as each of the 3 sessions inserts rows into different sets of table blocks:
SQL> create table bowie_assm (id number, name varchar2(42)); Table created. SQL> create sequence bowie_assm_seq order; Sequence created. SQL> create or replace procedure pop_bowie_assm as 2 begin 3 for i in 1..100000 loop 4 insert into bowie_assm values (bowie_assm_seq.nextval, 'DAVID BOWIE'); 5 commit; 6 end loop; 7 end; 8 / Procedure created.
The following is executed concurrently in 3 different sessions:
SQL> exec pop_bowie_assm PL/SQL procedure successfully completed.
If you can imagine 3 different blocks within the table, block one has rows with ID values 1,4,7,10,13,16…, block two has rows with ID values 2,5,8,11,14,17… and block three has rows with ID values 3,6,9,12,15,18…
So the data is well clustered in that the data for a large number of consecutive IDs are stored within a few blocks, but they’re not stored precisely in ID order within the table.
If we now create an index on the ID column and look at the Clustering Factor (CF) of the index:
SQL> create index bowie_assm_id_i on bowie_assm(id); Index created. SQL> exec dbms_stats.gather_table_stats(ownname=>null, tabname=>'BOWIE_ASSM'); PL/SQL procedure successfully completed. SQL> SELECT t.table_name, i.index_name, t.blocks, t.num_rows, i.clustering_factor 2 FROM user_tables t, user_indexes i 3 WHERE t.table_name = i.table_name AND i.index_name='BOWIE_ASSM_ID_I'; TABLE_NAME INDEX_NAME BLOCKS NUM_ROWS CLUSTERING_FACTOR --------------- -------------------- ---------- ---------- ----------------- BOWIE_ASSM BOWIE_ASSM_ID_I 1000 300000 219416
We note the calculated CF is extremely poor at 219416 (a value much closer to the number of index entries than the number of blocks in the table) as the default calculation notes that most index entries have a rowid that points to a different table block to the previous index entry rowid.
If we run a query that only requires a moderate number of rows (approx. 0.13% of the table) to be returned:
SQL> select * from bowie_assm where id between 42 and 429; 388 rows selected. Execution Plan -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 389 | 6613 | 282 (11) | 00:00:01 | |* 1 | TABLE ACCESS FULL | BOWIE_ASSM | 389 | 6613 | 282 (11) | 00:00:01 | -------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 974 consistent gets 0 physical reads 0 redo size 8869 bytes sent via SQL*Net to client 883 bytes received via SQL*Net from client 27 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 388 rows processed
We note the CBO decides to use a Full Table Scan (FTS) as the index is too costly and inefficient to use with such a poor CF value.
However, if say retrieving 100 rows, the CBO thinks it needs to visit many more table blocks than the 3 blocks that in actual fact contain the 100 rows of interest.
The TABLE_CACHED_BLOCKS statistics preference allows us to modify how the CF is calculated by not incrementing the CF value if an index rowid points to a block that was visited just TABLE_CACHED_BLOCKS ago.
If we now re-calculate the CF but with the TABLE_CACHED_BLOCKS preference set to say 42:
SQL> exec dbms_stats.set_table_prefs(ownname=>user, tabname=>'BOWIE_ASSM', pname=>'TABLE_CACHED_BLOCKS', pvalue=>42); PL/SQL procedure successfully completed. SQL> exec dbms_stats.gather_index_stats(ownname=>user, indname=>'BOWIE_ASSM_ID_I',estimate_percent=> null); PL/SQL procedure successfully completed. SQL> SELECT t.table_name, i.index_name, t.blocks, t.num_rows, i.clustering_factor 2 FROM user_tables t, user_indexes i 3 WHERE t.table_name = i.table_name AND i.index_name='BOWIE_ASSM_ID_I'; TABLE_NAME INDEX_NAME BLOCKS NUM_ROWS CLUSTERING_FACTOR --------------- -------------------- ---------- ---------- ----------------- BOWIE_ASSM BOWIE_ASSM_ID_I 1000 300000 909
We notice the CF has dropped significantly, down to just 909 from its previous 219416 value.
If we now re-run the same query as before:
SQL> select * from bowie_assm where id between 42 and 429; 388 rows selected. Execution Plan ------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | ------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 389 | 6613 | 4 (0) | 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID BATCHED | BOWIE_ASSM | 389 | 6613 | 4 (0) | 00:00:01 | |* 2 | INDEX RANGE SCAN | BOWIE_ASSM_ID_I | 389 | | 2 (0) | 00:00:01 | ------------------------------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 6 consistent gets 0 physical reads 0 redo size 8734 bytes sent via SQL*Net to client 608 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 388 rows processed
We notice the CBO now automatically decides to use the index and more importantly, that at just 6 consistent gets, the query is now much more efficient as a result.
The index was always the more efficient access method, but because of the poor CF that was previously calculated, the CBO got it wrong. Now that a more “accurate” CF is calculated, all is now well.
However, if we now decide to rebuild this index:
alter index bowie_assm_id_i rebuild; Index altered. SQL> select * from bowie_assm where id between 42 and 429; 388 rows selected. Execution Plan -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 389 | 6613 | 282 (11) | 00:00:01 | |* 1 | TABLE ACCESS FULL | BOWIE_ASSM | 389 | 6613 | 282 (11) | 00:00:01 | -------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 3 recursive calls 0 db block gets 956 consistent gets 0 physical reads 0 redo size 4094 bytes sent via SQL*Net to client 608 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 388 rows processed
So we’re back to the less efficient FTS. Why ? A look at the CF reveals the problem:
SQL> SELECT t.table_name, i.index_name, t.blocks, t.num_rows, i.clustering_factor 2 FROM user_tables t, user_indexes i 3 WHERE t.table_name = i.table_name AND i.index_name='BOWIE_ASSM_ID_I'; TABLE_NAME INDEX_NAME BLOCKS NUM_ROWS CLUSTERING_FACTOR --------------- -------------------- ---------- ---------- ----------------- BOWIE_ASSM BOWIE_ASSM_ID_I 1000 300000 219416
When the index is rebuilt and so when the index statistics are implicitly recalculated, the TABLE_CACHED_BLOCKS preference is ignored. This applies even if this preference is set at the schema or database level:
SQL> exec dbms_stats.set_schema_prefs(ownname=>user, pname=>'TABLE_CACHED_BLOCKS', pvalue=>42); PL/SQL procedure successfully completed. SQL> exec dbms_stats.set_database_prefs(pname=>'TABLE_CACHED_BLOCKS', pvalue=>42); PL/SQL procedure successfully completed. SQL> alter index bowie_assm_id_i rebuild online; Index altered. SQL> SELECT t.table_name, i.index_name, t.blocks, t.num_rows, i.clustering_factor 2 FROM user_tables t, user_indexes i 3 WHERE t.table_name = i.table_name AND i.index_name='BOWIE_ASSM_ID_I'; TABLE_NAME INDEX_NAME BLOCKS NUM_ROWS CLUSTERING_FACTOR --------------- -------------------- ---------- ---------- ----------------- BOWIE_ASSM BOWIE_ASSM_ID_I 1000 300000 219416
This issue also applies when an index is newly created, any TABLE_CACHED_BLOCKS setting is ignored, until the time when statistics are again collected via DBMS_STATS:
SQL> drop index bowie_assm_id_i; Index dropped. SQL> create index bowie_assm_id_i on bowie_assm(id); Index created. SQL> SELECT t.table_name, i.index_name, t.blocks, t.num_rows, i.clustering_factor 2 FROM user_tables t, user_indexes i 3 WHERE t.table_name = i.table_name AND i.index_name='BOWIE_ASSM_ID_I'; TABLE_NAME INDEX_NAME BLOCKS NUM_ROWS CLUSTERING_FACTOR --------------- -------------------- ---------- ---------- ----------------- BOWIE_ASSM BOWIE_ASSM_ID_I 1000 300000 219416 SQL> exec dbms_stats.gather_index_stats(ownname=>user, indname=>'BOWIE_ASSM_ID_I',estimate_percent=> null); PL/SQL procedure successfully completed. SQL> SELECT t.table_name, i.index_name, t.blocks, t.num_rows, i.clustering_factor 2 FROM user_tables t, user_indexes i 3 WHERE t.table_name = i.table_name AND i.index_name='BOWIE_ASSM_ID_I'; TABLE_NAME INDEX_NAME BLOCKS NUM_ROWS CLUSTERING_FACTOR --------------- -------------------- ---------- ---------- ----------------- BOWIE_ASSM BOWIE_ASSM_ID_I 1000 300000 909
This is currently being investigation by Oracle as unpublished bug 28292026.
Again, another example of the dangers of blindly rebuilding indexes without a valid justification…
Index Column Order – Impact On Index Branch Blocks Part II (The Weeping Song) July 5, 2018
Posted by Richard Foote in Index Column Order, Index Compression, Oracle Indexes.add a comment
In Part I, I discussed how the order of columns in an index makes no real difference to the effectiveness of the index if all columns are referenced via equality predicates.
If the leading column has a high number of distinct columns, it might result in less necessary data within index branches as less data is required to determine the unique path down to the leaf block containing the first index entry of interest. This might save a moderate number of index branch blocks. The number of branch blocks though has a trivial impact on index performance, if as in the vast majority of cases, the index height remains the same.
However, if one can potentially significantly reduce the number of required leaf blocks within an index, this might not only also significantly reduce the number of associated index branch blocks, but obviously the overall size of the index. This is possible with Basic Index Compression, but such compression is only possible if the leading column(s) has relatively few distinct values.
So going back to the demo in Part I, when the index was created with the ID column leading (which had many distinct values):
SQL> create index ziggy_id_code_i ON ziggy(id, code);
Index created.
SQL> analyze index ziggy_id_code_i validate structure;
Index analyzed.
SQL> select height, lf_blks, br_blks, br_rows_len, btree_space, used_space from index_stats;
HEIGHT LF_BLKS BR_BLKS BR_ROWS_LEN BTREE_SPACE USED_SPACE
---------- ---------- ---------- ----------- ----------- ----------
3 14135 23 176612 113264736 101146313
We note the size of the index, with 14135 leaf blocks and 23 branch blocks.
If we now attempt to compress this index with basic index compression:
SQL> alter index ziggy_id_code_i rebuild compress;
Index altered.
SQL> analyze index ziggy_id_code_i validate structure;
Index analyzed.
SQL> select height, lf_blks, br_blks, br_rows_len, btree_space, used_space from index_stats;
HEIGHT LF_BLKS BR_BLKS BR_ROWS_LEN BTREE_SPACE USED_SPACE
---------- ---------- ---------- ----------- ----------- ----------
3 15795 26 197435 126505652 113167136
We notice basic index compression has been totally ineffective. In fact, the index has increased in size with there now being 15795 leaf blocks and 26 branch blocks. The number of compressed index columns makes no difference, as it’s the leading column with high distinct values that is the problem here.
That’s because the de-duplication at the leaf block level necessary for effective basic index compression is impossible with the ID column leading as there are little to no replicated column values. Basic index compression must have high numbers of replicated column values in at least the leading column(s) to be effective.
If we look at the index with the replicated CODE column as the leading column:
SQL> create index ziggy_code_id_i on ziggy(code,id);
Index created.
SQL> analyze index ziggy_code_id_i validate structure;
Index analyzed.
SQL> select height, lf_blks, br_blks, br_rows_len, btree_space, used_space from index_stats;
HEIGHT LF_BLKS BR_BLKS BR_ROWS_LEN BTREE_SPACE USED_SPACE
---------- ---------- ---------- ----------- ----------- ----------
3 14125 83 656341 113666656 101626042
We notice although the number of leaf blocks are similar to the previous non-compressed index at 14125 leaf blocks, at 83 there are more branch blocks (previous index had just 23). As discussed in Part I, this is because the relatively large sized CODE column must be stored in the branch blocks.
However, this index is compressible with the leading CODE column having duplicate values. Therefore, if we compress the index by compressing just the CODE column:
SQL> alter index ziggy_code_id_i rebuild compress 1;
Index altered.
SQL> analyze index ziggy_code_id_i validate structure;
Index analyzed.
SQL> select height, lf_blks, br_blks, br_rows_len, btree_space, used_space from index_stats;
HEIGHT LF_BLKS BR_BLKS BR_ROWS_LEN BTREE_SPACE USED_SPACE
---------- ---------- ---------- ----------- ----------- ----------
3 4620 28 214696 37166416 33369357
We notice not only has the number of branch blocks reduced (28 down from 83), but more importantly, we have significantly reduced the number of overall leaf blocks (4620 down from 14125).
So if reducing the size of the resultant index is the aim, you will generally get a much better result by using basic index compression and ensuring the columns with the few distinct values are the leading columns, than by potentially moderately reducing branch blocks with the leading column more distinct.
The other advantage to placing the columns with fewer distinct values as the leading columns of an index is that it makes an Index Skip Scan a viable execution path if the leading column(s) is not referenced in a predicate. This is not possible if the leading column is too distinct. I’ve discussed Index Skip Scans previously in this blog.
Note basic index compression is free (you don’t need the Advanced Compression Option), but you do need to be on Enterprise Edition to use this feature.
Announcement: New Europe Seminar in Brussels, Belgium 27-28 September 2018 July 3, 2018
Posted by Richard Foote in Oracle Index Seminar, Oracle Indexes.add a comment
Due to popular demand, I’ll be running another of my acclaimed seminars in Europe later in the year, this time in Brussels, Belgium on 27-28 September 2018.
This is a must attend seminar of benefit to not only DBAs, but also to Developers, Solution Architects and anyone else interested in designing, developing or maintaining high performance Oracle-based applications. It’s a fun, but intense, content rich seminar that is suitable for people of all experiences (from beginners to seasoned Oracle experts). Full seminar content.
I’ve had quite a number of requests to run a seminar in this region, so I anticipate quite some interest. However as always, available places are strictly limited to my small class policy.
For all the details and how to register, visit: https://www.eventbrite.com.au/e/oracle-indexing-internals-best-practices-seminar-with-richard-foote-brussels-tickets-47703933750.
I’m in the process of finalising the venue, but it will definitely be within the Brussels CBD area.
If you have any questions, don’t hesitate to contact me at richard@richardfooteconsulting.com.
Richard Foote's Oracle Blog 