Resolving the "X" Problem
Autor: Ricardo Gusmão | Publicado: 2016-06-08T11:02:00-03:00






Take you best ideas, write them and after try to destroy them! In a first look this seems to be quite strange, but after I had read this article at LinkedIn the idea seems to be very reasonable (and even logical). I liked even more because it confronts those Facebook quotes like “Because he didn’t know that was impossible, he did it!” or “Never be afraid to show your ideas, because to have no ideas to propose is worst!”, among so many others. Just hate those quotes…

Astro Teller, Chief of Google “MoonShots” projects, explains that, at the “X” Projects from Google (Google X, Google Glass, Google Driveless Car, etc.) the company promotes the “pre mortem” of ideas. That means that, on the contrary of the post mortem concept where you review your original idea trying to find out where it failed, at pre mortem you try to show and prove, in every way, why your idea is faded to fail.

The strategy is very simple. You try constantly to prove that your idea doesn’t worth any effort, wouldn’t work, cannot go further, wouldn’t have enough resources, etc. Those ideas which survive to this attack of “unpromoting” things will be those one which really worth to go on.

Very well, it’s a very logical thing! Besides that, adding value to it, in the end you’ll also have a draft of your contingency plan, your B Plan, once you had had thought all the disasters situations and fail points your idea could pass.

Let’s make an example in a Database migration cross-platform (Oracle). Let’s also consider that the database uses ASM technology. So you take three different strategies:

1. &nbsp; Using Origin Conversion: You execute the conversion scripts, transfer the datafiles out from the ASM, copy the files for the destination server and put them back to the ASM (destination);

2. &nbsp; Using Destination Conversion: You take-off the datafiles from the ASM, transfer files through to the destination server and put them back to the ASM at destination (datafiles conversion are made implicit in this process);

3. &nbsp; Using Active Database: RMAN does all the work for you;

First thing to do, ever its possible, is to rehearse the process to be made in the big day. Simulate it. All the three process above needs to that, at minimum, the database in READ-ONLY mode. So, normally, the software which uses this database won’t be accessible to the end-user.

I made an individual score system to help to choose the best strategy for the process. You can choose any standard value, as long as you chose a “central” value. In my case I choose “5”.

Step 1: Offline system during the datafiles conversion and transferring out-from the ASM.

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Using strategy 1:Consider the time for conversion + datafiles copy out-from ASM. 5 points;

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Using strategy 2:Consider the time only to take out the datafiles out-from ASM. 3 points;

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Using strategy 3: System will remain offline during all process. 8 points;

For sure I avoid the strategy 3, because just to create the Test environment, the end-user will suffer much more then the other two options with the offline system.
Now let’s think about some disaster during the process (Server being halt, power fail, logical fail, hardware problem, etc).

Using Strategy 1:

·  During the conversion/copy of datafiles from ASM at origin: Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; During the copy between servers: Can be resumed from the datafile that was being copying at the moment of the fail. 5 points;

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; During the copy of datafiles to the ASM (destination): Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;

Using strategy 2:

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; During the conversion/copy of datafiles from ASM at origin: Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; During the copy between servers: Can be resumed from the datafile that was being copying at the moment of the fail. 5 points;

· &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; During the copy of datafiles to the ASM (destination): Process can be resumed from the datafile which was in conversion at the moment of the fail. 5 points;

The risks on the two processes above are the same. Nothing changed. But, in both process there’s a possibility of datafile corruption during the process of conversion or copy. The difference is that if its occur during the conversion at the origin side (strategy 1), you’ll have to restore the database/datafile backup. So, the offline system for the end-user will be larger. With this information I also can discard the strategy 1, because of the risk of a bigger time with offline system. The winner is Strategy 2 - Using Destination Conversion!


So my friend, you don’t need to cry if your ideas become destroyed even before they come out from the papers. Your killed ideas helped to chose the best path, the path with better chances of success and that can make a better world for all!