Category Archives: Life

Oak Table World 2018

Oak Table World 2018 (OTW) just completed at the Children’s Creativity Museum in San Francisco. The event website is “https://otw18.org“.

This year, it was my turn to organize this remarkable little un-conference on behalf of the Oak Table Network, which is often described as a drinking society with an Oracle problem.

What is an “un-conference”? The dictionary definition is…

un·con·fer·ence   /ˈənkänf(ə)rəns/

noun: unconference; plural noun: unconferences

a loosely structured conference emphasizing the
informal exchange of information and ideas between
participants, rather than following a conventionally
structured program of events. Generally this manifests
as a "participant-driven" event.

OTW started out in 2010 with Mogens Norgaard holding a set of tables in the back room of the Chevy’s Tex-Mex Bar & Grill in San Francisco (since closed), just across 3rd St from the Moscone Center where Oracle OpenWorld was being held.

Rather than drinking from the flood pouring from the corporate marketing machines across the street, friends joined Mogens for beer and Tex-Mex to discuss and argue technical topics and drink beer.

Thus was born “Oracle ClosedWorld” as a true unconference. The following year in 2011, Oracle ClosedWorld was held in the upstairs room at The Thirsty Bear, a few doors down from Chevy’s on Howard St, this time with an agenda and a more structured format.

However, the ever-vigilant legal department at Oracle Corporation was not in the least amused by the gentle gibe of the name “Oracle ClosedWorld” from a bunch of drunk geeks, and so after the event they quickly regurgitated a letter offering detailed demands and dire consequences, and so of course we sweetly complied, and the unconference was renamed to “Oak Table World” (OTW). To date, Oracle’s legal team to not impose their will on our continued use of the word “World”, perhaps at least until Oracle achieves actual world domination. So we wait with bated breath for their next move.

The following year, in 2012, Oak Table World found a new home at the Children’s Creativity Museum, which is located at the corner of 4th Street and Howard Street, smack dab in the middle of the Moscone complex. The unconference was then organized by Kyle Hailey, who continued to do so in 2013, 2014, and 2015. In 2016, it was organized by Kellyn Pot’vin-Gorman, in 2017 by Jeremiah Wilton, and in 2018 by Tim Gorman.

The event seems to be slipping away from its original un-conference format, becoming more professionalized, becoming more of a conference-within-a-bigger-conference. I’m not sure if that is a good thing or a bad thing, but once you start laying out money for a venue and catering, things get more conventional pretty quickly.

Achieving a balance

Leave a reply

Please think this through carefully?

Cite a single occasion when a woman did not receive shaming, threats of job termination, counter-accusations, death threats, and personal shunning after she finally found herself unable to continue in the abrasive hell created for her, solely because she appealed to (or didn’t appeal to) a self-obsessed self-righteous forever-child?

The assertion that women are doing this to “enrich themselves” or “because they want to” is simply ludicrous. Just look at the facts…

Who ever benefited financially from bringing harassment charges? Nobody.
Who wins? Nobody.
What is gained? Justice, nothing more.
Who loses? Everybody, at one time or another.

It has always been easier to just bury it and move on, which has been the time-worn advice always given, and which is why so many of these atrocities have gone unresolved for so long. Many will remain unresolved forever. Whether they remain unresolved should be the decision of the victim — not the state, not the employer, and certainly not the perpetrator.

The courage required to speak out and live with the consequences is staggering. Those who do so are heroes, nothing less. These charges are not brought frivolously, but after endless soul-searching.

Women simply want to do their jobs just as men are able, without fear or favor, and with recourse other than quitting or moving on when a man targets her.

Rape culture, which blames victims as well as perpetrators, forcing women to adapt rather than forcing men to be human, is the reason so many feel outrage at recent developments.

Are you an opponent, or an advocate, of rape culture? Can you prove so by word or deed, and not just by a knee-jerk reaction to the question?

What is happening is long overdue, and hopefully will finally achieve a real and lasting balance.

Singing The NoCOUG Blues

Leave a reply

This is a re-post of an interview between myself and Iggy Fernandez, editor of the Journal of the Northern California Oracle Users Group (NoCOUG), Oracle ACE, OakTable member, blogger, and simply an amazing person. The interview starts on page 4 of the August 2014 issue of the NoCOUG Journal, and demonstrates how a gifted interviewer can make someone being interviewed more interesting and coherent.

Singing The NoCOUG Blues

You are old, father Gorman (as the young man said) and your hair has become very white. You must have lots of stories. Tell us a story!

Well, in the first place, it is not my hair that is white. In point of fact, I’m as bald as a cue ball, and it is my skin that is pale from a youth misspent in data centers and fluorescent-lit office centers.

It is a mistake to think of wisdom as something that simply accumulates over time. Wisdom accumulates due to one’s passages through the world, and no wisdom accumulates if one remains stationary. It has been said that experience is what one receives soon after they need it, and experience includes both success and failure. So wisdom accumulates with experience, but it accumulates fastest as a result of failure.

About four years ago, or 26 years into my IT career, I dropped an index on a 60 TB table with 24,000 hourly partitions; the index was over 15 TB in size. It was the main table in that production application, of course.
Over a quarter-century of industry experience as a developer, production support, systems administrator, and database administrator: if that’s not enough time to have important lessons pounded into one’s head, then how much time is needed?

My supervisor at the time was amazing. After the shock of watching it all happen and still not quite believing it had happened, I called him at about 9:00 p.m. local time and told him what occurred. I finished speaking and waited for the axe to fall—for the entirely justified anger to crash down on my head. He was silent for about 3 seconds, and then said calmly, “Well, I guess we need to fix it.”

And that was it.

No anger, no recriminations, no humiliating micro-management. We launched straight into planning what needed to happen to fix it.

He got to work notifying the organization about what had happened, and I got started on the rebuild, which eventually took almost 2 weeks to complete.

Side note…

I didn’t explain how we rebuilt the index within the NoCOUG article, but I did so recently in a recent post to the ORACLE-L email forum…

Here is a high-level description of what worked to rebuild it…

1) Run “create partitioned index … unusable” to create the partitioned index with all partitions empty.

2) Create a shell-script to run NN SQL*Plus processes simultaneously, where “NN” is a number of your choice, each process doing the following…

alter index <index-name> rebuild partition <partition-name> parallel <degree> nologging compute statistics

We ordered the SQL*Plus calls inside the shell-script so that the partitions for the most-recent partitions (i.e. the table was partitioned by a DATE column) were populated first, and then let the builds progress back in time. Depending on the application, you can be doing some or all of the normal activities on the table. Our assumption (which proved correct) was that all DML occurs against the newest partitions, so those were the partitions that needed to be made “usable” first.

This approach won’t eliminate downtime or performance problems, but it will likely minimize them.

It truly happens to all of us. And anyone who pretends otherwise simply hasn’t been doing anything important.

How did I come to drop this index? Well, I wasn’t trying to drop it; it resulted from an accident. I was processing an approved change during an approved production outage. I was trying to disable a unique constraint that was supported by the index. I wanted to do this so that a system-maintenance package I had written could perform partition exchange operations (which were blocked by an enabled constraint) on the table. When I tested the disabling of the constraint in the development environment, I used the command ALTER TABLE … DISABLE CONSTRAINT and it indeed disabled the unique constraint without affecting the unique index. Then I tested the same operation again in the QA/Test environment successfully. But when it came time to do so in production, it dropped the index as well.

Surprise!

I later learned that the unique constraint and the supporting unique index had been created out of line in the development and QA/test environments. That is, first the table was created, then the unique index was created, and finally the table was altered to create the unique constraint on the already-existing unique index.

But in production, the unique constraint and the supporting unique index had been created in-line. When the table was created, the CREATE TABLE statement had the unique constraint within, along with the USING INDEX clause to create the unique index.

So when I altered the table in production, disabling the constraint also caused the index to be dropped.

After the mishap, I found the additional syntax for KEEP INDEX, which could have been added to the end of the ALTER TABLE … DISABLE CONSTRAINT command because Oracle recognized the difference in default behaviors.

But that was a discovery I experienced after I needed it.

As to why my supervisor was so calm and matter-of-fact throughout this disaster, I was not surprised; he was always that way, it seemed. What I learned over beers long after this incident is that, in his early life, he learned the true meaning of the words “emergency” and “catastrophe.”

He was born in Afghanistan, and he was a young child during the 1980s after the Soviets invaded. His family decided to take refuge in Pakistan, so they sought the help of professional smugglers, similar to what we call “coyotes” on the Mexican-American border. These smugglers moved through the mountains bordering Afghanistan and Pakistan at night on foot, using camels to carry baggage and the very old, the sick and injured, and the very young.

My supervisor was about 9 years old at the time, so the smugglers put him on a camel so he would not slow them down. During the night, as they were crossing a ridge, they were spotted by the Soviets, who opened fire on them using machine guns with tracer bullets. Everyone in the caravan dove to the ground to take cover. Unfortunately, they all forgot about the 9-year-old boy on top of the 8-foot-high camel. My supervisor said he saw the bright tracer bullets arching up toward him from down below in the valley, passing over his head so close that he felt he could just reach up and grab them. He wanted to jump down, but he was so high off the ground he was terrified. Finally, someone realized that he was exposed and they pulled him down off the camel.

As he told this story, he laughed and commented that practically nothing he encountered in IT rose to the level of what he defined as an emergency. The worst that could happen was no more catastrophic than changing a tire on a car.

I’ve not yet been able to reach this level of serenity, but it is still something to which I aspire.

We love stories! Tell us another story!

A little over 10 years ago, I was working in downtown L.A. and arrived in the office early (5:00 a.m.) to start a batch job. I had a key card that got me into the building and into the office during the day, but I was unaware that at night they were locking doors in the elevator lobby. I banged on the doors and tried calling people, to no avail. Finally, after a half-hour, out of frustration, I grabbed one of the door handles and just yanked hard.

It popped open.

I looked at it in surprise, thought “sweet!”, walked in to the cubicle farm, sat down, and started my batch job. All was good.

Around 7:00 a.m., the LAPD showed up. There were about a dozen people in the office now, so the two officers began questioning folks nearest the door. From the opposite side of the room, I stood up, called out “Over here,” and ’fessed up.

They told me that if I hadn’t called them over immediately, they would have arrested me by the time they got to me.

Have a nice day, sir.

The NoCOUG Blues

NoCOUG membership and conference attendance have been declining for years. Are user groups still relevant in the age of Google? Do you see the same trends in other user groups? What are we doing wrong? What can we do to reverse the dismal trend? Give away free stuff like T-shirts and baseball caps? Bigger raffles? Better food?

Yes, the same trends are occurring in other users groups. IT organizations are lean and can’t spare people to go to training. The IT industry is trending older as more and more entry-level functions are sent offshore.
Users groups are about education. Education in general has changed over the past 20 years as online searches, blogs, and webinars have become readily available.

The key to users groups is the quality of educational content that is offered during live events as opposed to online events or written articles.

Although online events are convenient, we all know that we, as attendees, get less from them than we do from face-to-face live events. They’re better than nothing, but communities like NoCOUG have the ability to provide the face-to-face live events that are so effective.

One of the difficulties users groups face is fatigue. It is difficult to organize events month after month, quarter after quarter, year after year. There is a great deal of satisfaction in running such an organization, especially one with the long and rich history enjoyed by NoCOUG. But it is exhausting. Current volunteers have overriding work and life conflicts.

New volunteers are slow to come forward.

One thing to consider is reaching out to the larger national and international Oracle users groups, such as ODTUG, IOUG, OAUG, Quest, and OHUG. These groups have similar missions and most have outreach programs. ODTUG and IOUG in particular organize live onsite events in some cities, and have webinar programs as well. They have content, and NoCOUG has the membership and audience. NoCOUG members should encourage the board to contact these larger Oracle users groups for opportunities to partner locally.

Another growing trend is meet-ups, specifically through Meetup.com. This is a resource that has been embraced by all manner of tech-savvy people, from all points on the spectrum of the IT industry. I strongly urge all NoCOUG members to join Meetup.com, indicate your interests, and watch the flow of announcements visit your inbox. The meet-ups run the gamut from Hadoop to Android to Oracle Exadata to In-Memory to Big Data to Raspberry Pi to vintage Commodore. I think the future of local technical education lies in the intersection of online organization of local face-to-face interaction facilitated by Meetup.com.

Four conferences per year puts a huge burden on volunteers. There have been suggestions from multiple quarters that we organize just one big conference a year like some other user groups. That would involve changing our model from an annual membership fee of less than $100 for four single-day conferences (quarterly) to more than $300 for a single multiple-day conference (annual), but change is scary and success is not guaranteed. What are your thoughts on the quarterly vs. annual models?

I disagree with the idea that changing the conference format requires increasing annual dues. For example, RMOUG in Colorado (http://rmoug.org/) has one large annual conference with three smaller quarterly meetings, and annual dues are $75 and have been so for years. RMOUG uses the annual dues to pay for the three smaller quarterly education workshops (a.k.a. quarterly meetings) and the quarterly newsletter; the single large annual “Training Days” conference pays for itself with its own separate registration fees, which of course are discounted for members.

Think of a large annual event as a self-sufficient, self-sustaining organization within the organization, open to the public with a discount for dues-paying members.

Other Oracle users groups, such as UTOUG in Utah (http://utoug.org/), hold two large conferences annually (in March and November), and this is another way to distribute scarce volunteer resources. This offers a chance for experimentation as well, by hiring one conference-coordinator company to handle one event and another to handle the other, so that not all eggs are in one basket.

The primary goal of larger conferences is ongoing technical education of course, but a secondary goal is to raise funds for the continued existence of the users group and to help subsidize and augment the website, the smaller events, and the newsletter, if necessary.

It costs a fortune to produce and print the NoCOUG Journal, but we take a lot of pride in our unbroken 28-year history, in our tradition of original content, and in being one of the last printed publications by Oracle user groups. Needless to say it also takes a lot of effort. But is there enough value to show for the effort and the cost? We’ve been called a dinosaur. Should we follow the other dinosaurs into oblivion?

I don’t think so. There are all kinds of formats for publication, from tweets to LinkedIn posts to blogs to magazines to books. Magazines like the NoCOUG Journal are an important piece of the educational ecosystem. I don’t think that any of the Oracle users groups who no longer produce newsletters planned to end up this way. They ceased publishing because the organization could no longer sustain them.

I think today the hurdle is that newsletters can no longer be confined within the users group. Both NoCOUG and RMOUG have independently come to the realization that the newsletter must be searchable and findable online by the world, which provides the incentive for authors to submit content. Today, if it cannot be verified online, it isn’t real. If it isn’t real, then there is little incentive for authors to publish.

So making the NoCOUG Journal available online has been key to its own viability, and NoCOUG membership entitles one to a real hard-copy issue, which is a rare and precious bonus in this day and age.

Oracle Database 12c

Mogens Norgaard (the co-founder of the Oak Table Network) claims that “since Oracle 7.3, that fantastic database has had pretty much everything normal customers need,” but the rest of us are not confirmed Luddites. What are the must-have features of Oracle 12c that give customers the incentive to upgrade from 11g to 12c? We’ve heard about pluggable databases and the in-memory option, but they are extra-cost options aren’t they?

I know for a fact that the Automatic Data Optimization (ADO) feature obsolesces about 3,000 lines of complex PL/SQL code that I had written for Oracle 8i, 9i, 10g, and 11g databases. The killer feature within ADO is the ability to move partitions online, without interrupting query operations. Prior to Oracle 12c, accomplishing that alone consumed hundreds of hours of code development, testing, debugging, and release management.

Combining ADO with existing features like OLTP compression and HCC compression truly makes transparent “tiers” of storage within an Oracle database feasible and practical. The ADO feature alone is worth the effort of upgrading to Oracle 12c for an organization with longer data retention requirements for historical analytics or regulatory compliance.

What’s not to love about pluggable databases? How different is the pluggable database architecture from the architecture of SQL Server, DB2, and MySQL?

I think that first, in trying to explain Oracle pluggable databases, most people make it seem more confusing than it should be.

Stop thinking of an Oracle database as consisting of software, a set of processes, and a set of database files.

Instead, think of a database server as consisting of an operating system (OS) and an Oracle 12c container database software; a set of Oracle processes; and the basic control files, log files, and a minimal set of data files. When “gold images” of Oracle database servers are created, whether for jumpstart servers or for virtual machines, the Oracle 12c CDB should be considered part of that base operating system image.

Pluggable databases (PDBs) then are the data files installed along with the application software they support. PDBs are just tablespaces that plug into the working processes and infrastructure of the CDBs.

When PDBs are plugged in, all operational activities involving data protection—such as backups or redundancy like Data Guard replication—are performed at the higher CDB level.

Thus, all operational concerns are handled at the CDBs and the operational infrastructure from the PDBs and the applications.

Once the discussion is shifted at that high level, then the similarities are more visible between the Oracle 12c database and other multitenant databases, such as SQL Server and MySQL. Of course there will always be syntactic and formatting differences, but functionally Oracle 12c has been heavily influenced by its predecessors, such as SQL Server and MySQL.

Bonus Question
Do you have any career advice for the younger people reading this interview so that they can be like you some day? Other than actively participating in user groups!

This sounds corny and trite, but there is no such thing as a useless experience, and while it may be frustrating, it presents the opportunity to build. Understand that everyone starts at the bottom, and enjoy the climb.
Understand that learning causes stress. Stress is stress and too much can be unhealthy, but if it is a result of learning something new, then recognize it for what it is, know it is temporary and transitory, tough it out, and enjoy knowing the outcome when it arrives.

Also, don’t voice a complaint unless you are prepared to present at least one viable solution, if not several. Understand what makes each solution truly viable and what makes it infeasible. If you can’t present a solution to go with the complaint, then more introspection is needed. The term “introspection” is used deliberately, as it implies looking within rather than around.

Help people. Make an impact. Can we go wrong in pursuing either of those as goals? Sometimes I wish I had done more along these lines. Never do I wish I had done less.

Avoiding Regret

1 Reply

After working for a variety of companies in the 1980s, after working for Oracle in the 1990s, after trying (and failing) to build a company with friends at the turn of the century, and after more than a decade working as an independent consultant in this new century, I found myself in a professional dilemma last year.

I know I need to work at least another ten years, probably more like fifteen years, to be able to retire. I had survived the nastiest economic downturn since the Great Depression, the Great Recession of 2008-2011, while self-employed, and felt ready to take on the economic upswing, so I was confident that I could work steadily as an independent Oracle performance tuning consultant for the next 15 years or more.

Problem was: I was getting bored.

I loved my work. I enjoy the “sleuthiness” and the forensic challenge of finding performance problems, testing and recommending solutions, and finding a way to describe it clearly so that my customer can make the right decision. I am confident that I can identify and address any database performance problem facing an application built on Oracle database, and I’ve dozens of successful consulting engagements to bear witness. I have a legion of happy customers and a seemingly endless supply of referrals.

Being confident is a great feeling, and I had spent the past several years just enjoying that feeling of confidence on each engagement, relishing the challenge, the chase, and the conclusion.

But it was becoming routine. The best explanation I have is that I felt like a hammer, and I addressed every problem as if it was some form of nail. I could feel my mental acuity ossifying.

Then, opportunity knocked, in an unexpected form from an unexpected direction.

I have a friend and colleague whom I’ve known for almost 20 years, named Kyle Hailey. Kyle is one of those notably brilliant people, the kind of person to whom you pay attention immediately, whether you meet online or in person. We had both worked at Oracle in the 1990s, and I had stayed in touch with him over the years since.

About four years ago, I became aware that he was involved in a new venture, a startup company called Delphix. I wasn’t sure what it was about, but I paid attention because Kyle was involved. Then, about 3 years ago, I was working as a DBA for a Colorado-based company who had decided to evaluate Delphix’s product.

Representing my customer, my job was to prevent a disaster from taking place. I was to determine if the product had any merit, if the problems being experienced were insurmountable, and if so let my customer know so they could kill the project.

Actually, what my boss said was, “Get rid of them. They’re a pain in my ass“. I was just trying to be nice in the previous paragraph.

So OK. I was supposed to give Delphix the bum’s rush, in a valid techie sort of way. So I called the Delphix person handling the problem, and on the other end of the phone was Kyle. Hmmm, I can give a stranger the bum’s rush, but not a friend. Particularly, not someone whom I respect like a god. So, instead I started working with him to resolve the issue. And resolve it we did. As a result, the company bought Delphix, and the rest is history.

Here’s how we did it…

But first, what does Delphix do? The product itself is a storage appliance on a virtual machine in the data center. It’s all software. It uses sophisticated compression, deduplication, and copy-on-write technical to clone production databases for non-production usage such as development and testing. It does this by importing a copy of the production database into the application, compressing that base copy down to 25-30% of it’s original size. Then, it provides “virtual databases” from that base copy, each virtual database consuming almost no space at first, since almost everything is read from the base copy. As changes are made to each virtual database, copy-on-write technology stores only those changes for only that virtual database. So, each virtual database is presented as a full image of the source database, but costs practically nothing. Even though the Oracle database instances reside on separate servers, the virtual database actually resides on the Delphix engine appliance and is presented via NFS.

I was asked to understand why the virtual databases were slow.

On the other end of the phone was Kyle, and he was easily able to show me with repeatable tests where and what the nature of the performance problems were, and that they were predictable and resolvable.

But I’m not really writing just about Delphix, even though it is very cool and quite earthshaking. Rather, I’m writing about something bigger that has stormed into our industry, bringing to fruition something that I had tried — and failed — to accomplish at the turn of the century. Back then, at the turn of the century, when some colleagues and I tried to build a hosted-application services company, we failed in two ways: 1) we were ahead of our time and 2) we chose the wrong customers.

Being ahead of one’s time is not a failure, strictly speaking. It shows a clarity of vision, but bad timing.

However, choosing the wrong customers is absolutely a failure.

Before I explain, please be aware that I’m going to change most of the names, to protect any innocent bystanders…

After leaving Oracle in July 1998, I founded my own little company-of-one, called Evergreen Database Technologies (a.k.a. EvDBT). The dot-com boom was booming, and I wanted to operate as an independent consultant. I had been living in Evergreen in the foothills west of Denver for years, so the choice of name for my company was by no means a brilliant leap of imagination; I just named it after my hometown. Business was brisk, even a bit overheated as Y2K approached, and I was busy. And very happy.

In early 2000, I had been working with another young company called Upstart, and we felt that the information technology (IT) industry was heading in one inescapable direction: hosted services. So I joined Upstart and we decided that providing hosted and managed Oracle E-Business Suites (EBS) was a good business. EBS is the world’s 2nd most prevalent Enterprise Resource Planning (ERP) system and can be dizzyingly complex to deploy. It is deployed in hundreds of different industries and is infinitely customizable, so in order to avoid being eaten alive by customization requests by our potential customers, we at Upstart would have to focus on a specific industry and pre-customize EBS according to the best practices for that industry. We chose the telecommunications industry, because it was an even bigger industry in Colorado then, as it is now. We wanted to focus on small telecommunications companies, being small ourselves. At that time, small telecommunications companies were plentiful because of governmental deregulation in the industry. These companies offered DSL internet and phone services, and in June 2000 our market research told us it was a US$9 billion industry segment and growing.

Unfortunately, all of the big primary telecommunications carriers bought the same market research and were just as quick to catch on, and they undercut the DSL providers, provided cheaper and better service, and put the myriad of small startups out of business practically overnight. “Overnight” is not a big exaggeration.

By October 2000, we at Upstart were stunned to discover that our customer base had literally ceased answering their phones, which is chillingly ominous when you consider they were telecommunication companies. Of course, the carnage directly impacted the companies who had hoped to make money from those companies, such as Upstart. Only 4 months in business ourselves, our target market had vanished like smoke. You might say we were…. a little disconcerted.

We at Upstart had a difference of opinion on how to proceed, with some of the principals arguing to continue sucking down venture-capital funding and stay the course, while others (including me) argued that we had to find some way, any way, to resume generating our own revenue on which to survive. I advocated returning to Upstart’s previous business model of consulting services, but the principals who wanted to stay the course with the managed services model couldn’t be budged. By December 2000, Upstart was bankrupt, and the managed-services principals ransacked the bank accounts and took home golden parachutes for themselves. I jumped back into my own personal lifeboat, my little consulting services company-of-one, Evergreen Database Technologies. And continued doing what I knew best.

This was a scenario that I’m told was repeated in many companies that flamed out during the “dot-bomb” era. There are a million stories in the big city, and mine is one of them.

But let’s just suppose that Upstart had chosen a different customer base, one that didn’t disappear completely within months? Would it still have survived?

There is a good chance that we would still have failed due to being ahead of our times and also ahead of the means to succeed. Hosted and managed applications, which today are called “cloud services”, were made more difficult back then by the fact that software was (and is) designed with the intention of occupying entire servers. The E-Business Suites documentation from Oracle assumed so, and support at Oracle assumed the same. This meant that we, Upstart, had to provision several entire server machines for each customer, which is precisely what they were doing for themselves. There was little reason we could do it cheaper. As a result, we could not operate much more cheaply than our customers had, resulting in very thin cost savings or efficiencies in that area, leaving us with ridiculously small profit margins.

Successful new businesses are not founded on incremental improvement. They must be founded on massive change.

What we needed at that time was server virtualization, which came along a few years later in the form of companies like VMware. Not until server virtualization permitted us to run enterprise software on virtual machines, which could be stacked en masse on physical server machines, could we have hoped to operated in a manner efficient enough to save costs and make money.

Fast forward to today.

Today, server virtualization is everywhere. Server virtualization is deeply embedded in every data center. You can create virtual machines on your laptop, a stack of blade servers, or a mainframe, emulating almost any operating system that has ever existed, and creating them in such a way that finally makes full use of all the resources of real, physical servers. No longer would system administrators rack, wire, and network physical servers for individual applications using customized specifications for each server. Instead, virtual machines could be configured according to the customized specifications, and those virtual machines run by the dozens on physical machines.

The advent of virtual machines also brought about the operations paradise of abstracting computer servers completely into software, so that they could be built, configured, operated, and destroyed entirely like the software constructs they were. No more racking and wiring, one server per application. Now, banks of “blades” were racked and wired generically, and virtual machines balanced within and across blades, with busier virtual machines moving toward available CPU, memory, and networking resources and quieter virtual machines yielding CPU, memory, and networking to others. Best of all, all of this virtualization converted hardware into software, and could be programmed and controlled like software.

Everything is virtualized, and all was good.

Except storage.

Think about it. It is easy and cheap to provision another virtual machine, using fractions of CPU cores and RAM. But each of those virtual machines needs a full image of operating system, application software, and database. While server virtualization permitted data centers to use physical servers more efficiently, it caused a positive supernova explosion in storage. So much so that analysts like Gartner have predicted a “data crisis” before the end of the decade.

This is where Delphix comes in.

By virtualizing data as well as servers, it is now truly fast, cheap, and easy to provision entire virtual environments. Delphix works with Oracle, and it also works with SQL Server, PostgreSQL, MySQL, DB2, and Sybase. Even more importantly, it also virtualizes file-systems, so that application software as well as databases can be virtualized.

So back in early 2014, Kyle contacted me and asked if I would be interested in joining Delphix. My first reaction was the one I always had, which is “no thanks, I’ve already got a job“. I mean, I’m a successful and flourishing independent consultant. Why would I consider working within any company anymore. Business was brisk, I never had downtime, and the economy was improving. I had successfully been operating as an independent consultant for most of the past 15 years. Why fix what wasn’t broken?

But here was the crux of the matter…

I wanted to try something new, to expand beyond what I had been doing for the past 25 years since I first joined Oracle. If it was a large established company beckoning, I wouldn’t have considered it for a second. But a promising startup company, with a great idea and a four-year track record of success already, and still pre-IPO as well?

I couldn’t resist the gamble. What’s not to like?

It’s possible I’ve made an enormous mistake, but I don’t think so.

Not to turn excessively morbid, but all of us are just a heartbeat away from our common destination. I believe that, when I’m at the last moments of my life, the thing I fear will not be death itself, or pain, or leaving life behind.

It is regret that I fear.

And regret can take many forms, but the most painful regret will undoubtedly be what might have been, the opportunities passed or missed. Career is only one aspect of life, and I don’t want to give it too much significance. I’ve accumulated regrets in how I’ve lived my life, and how I’ve treated people in my life, and in some cases they are small but there are some which will always haunt me.

But with regards to my professional career, as Robert Frost said, I’ve taken the road less traveled, and that has made all the difference. No regrets here.

If you want something done, ask a busy person…

Leave a reply

This is a re-post I originally made on the ODTUG website on 17-Jan 2013 at the beginning of my two-year term on the board of directors...

This past weekend, I attended my first face-to-face Board of Directors meeting with ODTUG. Monty Latiolais, current president of ODTUG, asked me to let him know if there was anything “less than stellar” about my experience, and I have say the answer is “no”. It was a stellar experience, all weekend. Here’s why…

For 20 years, I’ve been a member of the Rocky Mountain Oracle Users Group. My boss at Oracle at the time, Valerie Borthwick, told everyone in our team that the best thing we could do for our career and for our business practice was to “become famous”. Not famous (or infamous) as in “celebrity” or “rock star”, but famous as in “known within our industry”. Today, she would be telling us to blog and tweet, but back then, she was telling us to write and post white papers and to do presentations. Put our ideas out there. Discuss what we knew. Submit to peer reviews.

The biggest thing I learned then is that you cannot claim to know something until you’ve tried to explain it to others. Lots of people know something well. But unless they’ve tried to explain it to others, there will be gaps in knowledge, fuzzy areas in understanding, and lack of depth. Explaining to others fills gaps, clarifies fuzzy areas, and deepens the superficial. Weak points are rapidly exposed while presenting information in public. So, as I found ways to explain what I thought I already knew, I had to fix these problems, and my career flourished.

So in 1995, I joined the board of directors at RMOUG, because I wanted to spend more time around smart people, and see how they make things happen. That’s where I learned my next big lesson, which is when you have an important task, give it to a busy person, because they get it done.

It seems a bit counter-intuitive, but as you stop and observe those around you, it becomes obvious…

Some people like to think about doing things, but never do it
Others plan to do things, but never do it
Others talk themselves out of doing things before they ever get started, so they never do it
And others simply refuse to do anything

The people who are always busy are always getting things done.

That is what I found with the board of ODTUG, busy people who have plenty to do already, doing one more thing.

My favorite kind of people.

One year at Delphix

2 Replies

It’s been over a year since I leapt into the void.

OK, more than a little melodramatic. In many respects, I was leaping from the void by joining a promising and exciting startup company like Delphix.

Business was still brisk as an independent consultant at EvDBT, but for the past several years, I was experiencing what I called “just-in-time engagements”. That is, new consulting engagements were just mysteriously showing up at the right time just before the current one was ending. Frankly, it was getting a bit spooky, and I had been on pins and needles for a couple years watching it happen, wondering like a farmer if the day would come when the rain did not appear on time. That day had shown up previously, during the recession of 2001 – 2002, when I experienced about 2-3 weeks of no work early in 2002, but that was the only dry spell I encountered in almost 16 years at EvDBT. However, I wasn’t eager to see another one…

So a little over twelve months ago, on 01-May 2014, I left the world of Oracle technology consulting that I had first entered on January 15, 1990. Well, I haven’t really left Oracle technology, but I’m no longer making a living at it. Oracle is a big part of Delphix, but only a part.

What have been the highlights during my first year at Delphix?

learning data virtualization
learning how to tune virtual databases for Oracle and SQL Server
learning VMware and earning my VCA certification
carving a personal niche within a small company
became proficient at Windows Powershell <- no kidding! true!
continuing to present at Oracle conferences, often traveling and presenting with my brilliant wife, Kellyn Gorman

Yes, Kellyn and I got married during the past year! It took us each a few tries at marriage, but we each hung in there, and got it right this time. They say that remarriage is the triumph of optimism over experience, and I’m delighted to say that optimism trumps experience. We did the deed in grand style, spending the week at Oracle Open World in San Francisco, coming home on Friday and getting married that Sunday in a tiny ceremony with immediate family only. We finished up the RMOUG TD2015 call-for-papers on Wednesday and Kellyn publshed the agenda on Thursday, and then on Saturday we flew to Europe to do a joint-keynote and present at the Slovenian Oracle Users Group in Ljubljana and the Croatian Oracle Users Group in Rovinj. After spending time with Joze and his lovely wife Lili, we blasted out of Croatia and scooted over to beautiful Venice for a quiet, blissful week-long honeymoon, meeting with Lothar and his lovely wife Birgit during the week as well.

Then, it was back to reality through the end of the year, getting swept up in the preparations for the RMOUG conference.

Delphix had a spectacular Q4 ending on 31-January 2015, where that financial quarter alone equaled the earnings from the entire previous fiscal year. Lots of celebrations, victory laps, and high fives at the company all-hands meeting in early February, but what none of us in the Professional Services division saw was the looming tsunami of freshly-sold new deployments cresting just over our heads. That wave crested and crashed down on us, and I found myself buried in work. Just now, four months later in the new fiscal year, I’m finally able to look up and look around to find that winter and spring have passed and summer has arrived.My second year at Delphix has begun, and I’m curious as to what it will bring.

I’m continuing to heed the advice of Tim Minchin, who counsels against pursuing one’s Big Dream and instead suggests passionate dedication to short-term goals, in short that one be “micro-ambitious”. That is say, that thing that is right in front of you right now? Do it the very best you can, and put your back into it. Whether it is a blog post, cutting the lawn, an email, or a new wax ring for the toilet in the basement. Especially the new wax ring – don’t bugger that up! And then do the next thing the same way. And the next. And the next. Before you know it, you’ve climbed a mountain and have made a pretty good career besides.

Not unexpectedly at a small fast-growing company, hints have been made of a transition from the technical track to the managerial track. This would finally reverse the track switch I made over 20 years ago while at Oracle, when I stepped off the managerial track in favor of the technical track. I’ve never looked back on that decision, but should I be “micro-ambitious” here as well, take the new task right in front of me, and work to excel? Or stick to my guns, stay with the technical track?

I’ve learned that it is a mistake to just “go with the flow” and bob along with the prevailing current. If one is to succeed at something new, it must be a whole-hearted plunge accompanied by a full-throated war cry.

So, if you hear a strange noise rather like a cross between a “Tarzan yell” and someone choking on an avocado pit, don’t be alarmed. Just listen a little longer to find whether you hear the “splat” of my corpse hitting pavement, or the “whoosh” as I learn to fly again.

And rest assured, that wax ring in the downstairs toilet? Nailed it.

Hello Delphix!

After almost 16 years as an independent consultant, with a couple side-steps into the world of small consulting-services startups, I’ve accepted an offer from Delphix, a startup building the future of information technology, enabling agile data management and storage virtualization.

I’m closing EvDBT as a business, since the employee count will reduce from one to zero, and finishing up my consulting engagements, starting with my new employer on 01-May 2014.

Thank you, EvDBT. You were my lifeboat and my vehicle to a better career and a better life!

15 years of EvDBT

I worked at Oracle Consulting for eight and a half years, from January 1990 until July 1998, starting as a senior consultant and finishing as a technical manager. In the summer of 1998, I was experiencing a dual crisis in my career, directionally and ethically.

From the directional perspective, Oracle Consulting was sending very clear signals that the way Gary Dodge and I were doing business in the Denver consulting practice was not aligned with corporate goals. The corporation wanted vertical “centers of expertise” with global and national scope. In Denver, Gary and I managed about a dozen generalists, with experience ranging from very junior to very senior, who effectively covered all types of technology. Our goal was to let each person work locally on the type of work they enjoyed, occasionally coercing some to try something different. Many of us had families, and all of us lived in Colorado for a reason.

Attempting to adhere to corporate direction, when we received a request from a local customer, we began to first contact the relevant national or global “center of expertise”. Most often, we would be told that nobody was available within the next few weeks (or months) and that, when they did become available, the rates charged would reflect a very senior person coupled with travel expenses. We would feed that response back to the customer, who understandably became concerned or irate, and asked for one of our local generalists, whom they had probably used previously, which would have been our first response anyway. In almost each case, we would end up staffing one of our local folks in the engagement, who completed the engagement often before the national or global group’s person became available. As this continued, the pressure from corporate became more direct, complaining about a “black hole in the Rockies”. So, looking ahead into the future at Oracle, I saw a model of business with which I wasn’t comfortable: our local people getting on planes to work elsewhere, while out-of-town personnel were flying into Colorado to work here. Perhaps it looked good from a higher level, but from our street-level view, it was absurd.

However, I also had a more serious ethical problem. I had been sent to Los Angeles to work an engagement involving my primary expertise at the time: Oracle Parallel Server on IBM RS6000/SP clusters. The customer was a start-up website job board. Both IBM and Oracle were determined to sell some massive hardware and software in there, and were working together toward common purpose with rare cooperation.

Except the customer wasn’t cooperating.

Instead, they had come up with a far less-expensive scheme involving dozens of commodity servers, where the one server contained a master database to which new job postings were added and changes were made, which was then replicated to dozens of read-only database servers using backup/restore, with a connection load-balancer directing traffic. This allowed their read-mostly website to scale as needed by off-loading the reads from the master database and segregating writes from the read-only databases. It was fast, cheap, and easy — a rare occasion when it wasn’t necessary to choose only two. It was novel for the time, I was impressed, and said so. Nowadays, such a thing is called a reader farm and can easily be implemented using Active Data Guard.

However, the IBM and Oracle teams were adamantly opposed – fast, cheap, and easy would ruin the lucrative deal they had planned for themselves. So I was directly ordered by the regional vice-president in charge of the deal to reject as unworkable the customer’s plans and instead extol the virtues of Oracle Parallel Server and IBM RS6000/SP clustered servers one way or the other, and recommend it strongly in conclusion.

What to do?

I certainly did not enjoy being ordered to lie. Not asked, but ordered. On the other hand, I worked for Oracle and I had a boss and that boss stated very clearly what to do, as he had every right to do. After all, no blood would be spilled, no babies would be killed.

So my solution to the ethical dilemma was:

Complete the engagement as directed
Prevent it from happening again

I am not smart enough to avoid making mistakes, but I believe in making mistakes only once. I did what I was told to do, enduring the astonished looks from the good folks who couldn’t believe I was spouting such nonsense. I subsequently resigned from Oracle, to avoid ever having to make that mistake again. But having resigned from one well-regarded corporation, the question became: are there any corporations, anywhere in the world, where I would not be asked to do something like that again?

The answer was simple and, in August 1998, Evergreen Database Technologies, Inc opened for business.

The first person I told of my decision to resign was Gary Dodge. He wasn’t my supervisor, but we were peers. I entered his office and closed the door, and he looked up and commented, “Oh, that’s not a good sign.” I sat down and told him, and he nodded and said, “Well, good thing you closed the door, because I’m leaving also.” He didn’t leave Oracle, but he left consulting, for the same directional reasons as I. So, we didn’t inform our management together, but we informed them at the same time.

EvDBT hasn’t been open continuously over the past 15 years; I have far too much to learn. I spent a few years attempting to start another consulting-services company with some colleagues, and that ended unsuccessfully. Any deal that starts with handshakes inevitably ends with lawyers, so my lesson is to always start with lawyers so that it ends with handshakes.

At one point, I hired in with Compaq Professional Services because they offered an intriguing opportunity. However, my timing was bad, as Compaq was absorbed by HP a few months after I started, and knowing that I would not enjoy the noise and mess of the mating of the elephants, I moved on.

Thank you all for the past 15 years, and I look forward to the next 15 years.

Update on Friday 18-Oct 2013: I’ve received some criticism and questions for my perceived criticism of Oracle in this article, particularly with the ethical dilemma described above. I didn’t write this to criticize Oracle as a company, the situation simply happened while I was working there. It is a large company like many others. Corporations are comprised of people who respond in varying ways to the incentives given them. I’m personally aware of many people with similar roles at Oracle who have not and never will react to their incentives in that particular way. Likewise, I know of a few who would have reacted far worse. It’s all part of the grand pageant of human behavior.

The person who ordered me to do my job was not himself facing an ethical dilemma. He had brought me onto the engagement to expedite the deal, and he never imagined that I would balk; it just wasn’t professional.

He had a task to do, and I began to jeopardize the success of that task. I would hope to be as decisive and effective as he.

Remembering Gary Dodge…

Leave a reply

The world lost a remarkable person this week, my friend and mentor Gary Dodge.

He is survived by his wife Luann, to whom he was married 33 years, by his daughter Brigid and by his son Ryan, and by a tight-knit and equally talented and accomplished family. And by friends and admirers too numerous to count, worldwide.

As long as I knew him, his email signature stated, “Building tomorrow’s legacy systems today, one crisis at a time“, succinctly expressing his dry, lightly-warped sense of humor, suitable even in an uptight business environment.

He is deeply missed. Thank you, Gary.