About

Mr Gorman is a technical consultant for Delphix, who enable data virtualization integrated with data masking to increase the agility of IT development, testing and operations.

He is current president of RMOUG (Rocky Mtn Oracle Users Group) and has been an active member since 1992.

Mr Gorman also serves on the board of the Project SafeGuard Foundation (PSGF), which manages funds in trust for Project SafeGuard and its mission.

He also serves as an adviser to the boards of the Northern California Oracle Users Group (NoCOUG) and the Northeast Ohio Oracle Users Group (NEOOUG).

Tim Gorman has worked in the information technology (IT) industry since 1984, as an Oracle application developer since 1990, as an Oracle database administrator (DBA) since 1993, and as a skilled optimizer of performance on applications and systems built on Oracle technology since the mid-1990s.

In moving to Delphix in 2014, Tim now optimizes the performance of the IT organization itself, in addition to the systems that organization builds.

Tim has co-authored six books on Oracle technology, and has performed technical review on seven more books, has been an Oracle ACE since 2007 and an Oracle ACE Director  since 2012, has been a member of the Oak Table Network since 2002, and has presented at Oracle Open World, Collaborate, KScope, Hotsos, RMOUG, UKOUG, and Oracle users groups in lots of wonderful places around the world.

Now, switching from the professional third-person voice to the real-life first-person voice…

I live in Westminster (midway between Denver and Boulder) in colorful Colorado with my wife Kellyn who is a Technical Intelligence Manager at Delphix.

Kellyn is an Oracle ACE Director, making ours the only household in the world to boast two Oracle ACE Directors.  Kellyn is also a member of the Oak Table Network, making ours the second household in the world with two Oak Table members.  Kellyn has been a database administrator on Oracle, SQL Server, and MySQL and she blogs and tweets as DBAKevlar, and I am one very lucky guy to call her my wife.

I have two children, my son Peter and my daughter Marika, both of whom are successful and wonderful adults, living in Denver and Ft. Collins CO, respectively.  I live with Kellyn and her daughter Caitlyn and her son Joshua.  Kellyn’s son Sam lives on his own in Boulder.

I’m on Facebook, but I keep that separate for my personal life, and I do not “friend” professional acquaintances unless they have become part of my personal life.  Instead, I’m glad to keep my professional contacts on LinkedIn.

For fun, in winter I snowboard the steeps and deeps, in summer I bicycle (road) long distances, and play squash in any season when I can find someone of like mind.

3 thoughts on “About”

  1. Tim,
    I watched your ODTUG presentation today about data warehouse partitioning. I have a question for you. If we range partition on the time dimension foreign key column in the fact table, will a query that filters on a time dimension column that is not the primary key will the query partition prune? Our experience is that it doesn’t. We use a surrogate key for the time dimension, not actual dates.
    Thanks

    1. Partition-pruning on a partitioned table (like a fact table) can only occur if an equivalence operation (i.e. col = value) is a filter predicate on the partition key column.

      Since a star transformation is performing a join operation to the partitioned fact table, and not filtering with an equivalence predicate, then the Oracle cost-based optimizer will be unable to recognize that partition-pruning should take place.

  2. Tim, thanks for a great refresher (and lots of new things) about DW design and how to implement in Oracle with partitioning. The question I posted during the webinar (about bitmap indexes on the dimensions) was SUPPOSED to be this question: what are the guidelines for making the dimension tables IOTs in a DW? I know the usual rules — very few columns, infrequently accessed columns in the overflow segment, and so forth, but it seems like the 12c (12.1.0.2) optimizer sometimes comes up with a better plan if the dimension table is an IOT, sometimes better if it’s a heap. It could be some factor I’m not aware of, but even when running tests under controlled conditions (flushing buffer cache and shared pool, making sure statistics are up to date) the optimizer seems to “randomly” come up with a better plan when the dimension is an IOT and sometimes not.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.