quarta-feira, 8 de junho de 2016

Resolvendo o Problema "X"



Pegue suas boas ideias, anote-as e logo depois tente destruí-las! A princípio parece bem estranho, mas depois que li esse artigo no LinkedIn a ideia parece bem sensata e promissora (e até lógica). Gosto ainda mais porque confronta paradoxalmente aquelas frases de Facebook do tipo “Por não saber que era impossível, ele foi lá e fez!” ou “Não tenha medo de propor suas ideias, pois pior é não ter nada o que propor!”, entre muitas outras. Detesto essas frasesinhas...
Astro Teller, diretor dos projetos “MoonShots” da Google, explica que, nos projetos “X” da Google (Google X, Google Glass, Google driveless car, etc.), a empresa incentiva a “pré-morte” das ideias. Ou seja, diferentemente do conceito de post mortem onde você faz um retrospecto de toda ideia tentando encontrar o ponto onde ela falhou, no pre mortem você tenta mostrar e provar de todas as formas porque aquela ideia está fadada ao fracasso.
A estratégia é bastante simples. Você tenta constantemente mostrar as razões as quais sua ideia é inviável, não iria funcionar, não daria para levar adiante, não teria os recursos necessários, etc. As ideias que sobreviverem a essa sabatinada de “desincentivos” serão as que realmente valem a pena levar adiante.
Ora, bastante lógico do meu ponto de vista! Além disso, agregando valor ao camarote, você já tem um esboço do seu Plano de Contingência e Recuperação, seu Plano B, uma vez que já pensou nos possíveis cenários de desastre que sua ideia pode enfrentar.
Vamos tomar por exemplo uma Migração de banco de dados entre diferentes plataformas (Oracle). Nesse cenário consideremos que o banco utiliza ASM. Você escolhe três estratégias:
  1. Usando Conversão na Origem - Você executa os scripts de conversão na origem, transfere os datafiles para fora do asm, copia-os para o outro servidor e insere-os novamente no asm (destino);
  2. Usando Conversão no Destino - Você arranca os datafiles do ASM, transfere os mesmos para o servidor destino e insere-os novamente no ASM destino (a conversão do datafile é feita automáticamente quando você copia-o de volta ao ASM);
  3. Usando Active Databade - O RMAN faz todo o trabalho pra você;
A primeira coisa que precisamos fazer, sempre que possível, é o ensaio do processo, ou seja, fazer uma simulação do processo que será feito no dia “D”. Para os três processos acima o banco precisa estar no mínimo no modo READ-ONLY, ou seja, aberto apenas para consultas. Então normalmente o sistema que utiliza esse banco não estará acessível aos usuários.
Criei um sistema de pontuação que ajuda a decidir uma melhor estratégia para o processo. Os valores podem ser quaisquer um, desde que você estipule um valor “central”. No meu caso escolhi o “5”:
Etapa 1: Tempo em que o banco de dados estará inacessível durante a conversão e/ou transferência dos datafiles para fora do ASM.
  • Usando estratégia 1: Considerar o tempo de conversão+cópia dos datafiles para fora do ASM. 5 pontos;
  • Usando estratégia 2: Considerar o tempo apenas de retirada dos datafiles do ASM: 3 pontos;
  • Usando estratégia 3: O banco ficará inacessível durante todo o processo: 8 pontos;
De cara eu descarto a estratégia 3, pois, somente para criar o ambiente de ensaio, vai ser a que mais penalizará os usuários.
Vamos imaginar agora um desastre qualquer (desligamento inesperado do servidor, problema de hardware, falha lógica, etc.).
  • Usando estratégia 1:
    • Durante conversão/cópia do ASM na origem: Pode ser retomado à partir do datafile que estava sendo trabalhado no momento. 5 pontos;
    • Durante a cópia entre servidores: Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;
    • Durante a cópia dos datafiles para o ASM destino:Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;
  • Usando estratégia 2:
    • Durante cópia do ASM na origem: Pode ser retomado à partir do datafile que estava sendo trabalhado no momento. 5 pontos;
    • Durante a cópia entre servidores: Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;
    • Durante a cópia dos datafiles para o ASM destino:Pode ser retomado à partir do datafile que estava sendo copiado no momento. 5 pontos;
Ficamos no zero a zero nos cenários acima. Nada mudou. Porém, em ambos os processos pode haver corrompimento de algum datafile durante o processo de conversão ou cópia. A diferença é que se isso ocorrer durante a conversão na origem, você terá que restaurar o backup, então o tempo de sistema offline para o usuário será maior. Com isso posso descartar a Estratégia 1 também, pois há um risco de ter o sistema offline por um tempo maior para o usuário. Ficamos com a Estratégia 2 como vencedora!  
Então não precisa chorar se suas ideias foram destruídas antes mesmo de serem colocadas em prática. Suas ideias ajudaram a escolher a melhor estratégia, a que tem mais chance de sucesso e a que pode fazer um mundo melhor!

Resolving the "X" Problem



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.   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.   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.   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.
·        Using strategy 1:
Consider the time for conversion + datafiles copy out-from ASM. 5 points;
·        Using strategy 2:
Consider the time only to take out the datafiles out-from ASM. 3 points;
·        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;
·        During the copy between servers: Can be resumed from the datafile that was being copying at the moment of the fail. 5 points;
·         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:
·         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;
·         During the copy between servers: Can be resumed from the datafile that was being copying at the moment of the fail. 5 points;
·         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!

terça-feira, 26 de janeiro de 2016

Too much work... So few sleep!





Since the year had begun I haven't been sleeping very well. I lay down, turn one side, turn another side, and only late at dawn I can sleep. And suddenly I have to get up to work. Even in the weekends I haven't been sleeping enough. This, somehow (or very how), has been affecting my productivity at work and even in my personal tasks.
Searching for the reasons for haven't been sleeping well, the overworking fitted perfectly. The beginning of this year was quite agitated, and has been being since then. When you get home and turn on your laptop, even for personal tasks, it leads your brain in intense activity when you lay down on bed.
A research at the American Journal of Epidemiology showed that a group of person that used to work over 55 hours a week had had worst performance on the tests results, then the group which used to work around 40 hours a week. The tests evaluated verbal memory and skills, fluid intelligence (associated with short-term memory, abstract thinking, creativity, and problem solving), and crystallized intelligence (learning accumulated over the life span in education, work, and cultural experiences). This last one even keep growing until the 60's or 70's years old, and only starts to decrease starting from 80's.
Have notice that when I speak about overworking I'm not talking about only your job by itself. Understand that overworking is also the tasks that you do when you get in your home (or somewhere out of work place). Turn on your laptop for personal stuffs, for example, when you arrive at your home, can contribute in the increasing of your week working hours.
To take the prove in this last Wednesday I resolved to, arriving home, I wouldn't turn on my laptop or TV. I took a shower, had my dinner, put on my pajamas and gone to bed. I put a Classical Music radio station and read a book. My dog laid down by my side and near 20:30 I just turned off. Slept. I woke up  in the other morning totally renewed, in ecstasies, "Good Morning Sun" and "Tinny Kisses of Light". In that day I got a better food, had more energy and even I got a better mood - those who knows me, knows how surreal it is!
So, even being necessary you do overworking sometimes, having more the 48 working hours a week, when you start to feel very tired, not getting a good sleep night, try this. Disconnect of everything that is your normal routine. Disconnect by yourself, with only your dog, with your friends or your partner. Just be abstracted of everything that reminds your routine and have a good night!

Muita atividade... Pouco sono!


Desde o começo desse ano de 2016 não tenho dormido direito. Deito, embolo pra um lado, embolo para o outro e só pelas tantas da madrugada que o sono chega. E logo tenho que levantar para o trabalho. Mesmo fim de semana não tenho conseguido por o sono em dia. Isso, de certa (ou completa) forma vem afetando minha produtividade no trabalho e até pessoal.
Em busca dos motivos de não estar dormindo direito, o excesso de atividades encaixou-se perfeitamente. O começo do ano foi bastante agitado e desde então assim tem sido. Quando você chega em casa e ainda liga o laptop, mesmo que para tarefas e coisas pessoais, deixa seu cérebro em plena atividade ao deitar-se.
Uma pesquisa publicada no Jornal Americano de Epidemiologia mostrou que grupos de pessoas que trabalhavam mais de 55 horas semanais tiveram menores pontuações nos testes do que grupos que trabalhavam até 40 horas semanais. Os testes englobavam memória e habilidades verbais, fluidez da inteligência (associada a memória a curto prazo, pensamento abstrato, criatividade e resolução de problemas.), e inteligência cristalizada (aprendizado acumulado durante a vida educacional, profissional e cultural). Essa última, inclusive, tende a aumentar até os 60 - 70 anos e só começa a diminuir a partir dos 80.
Note que quando falo em excesso de atividades não estou relacionando apenas ao trabalho por si só. Entenda por excesso de atividades, as atividades que você realiza ao chegar em casa. Ligar o laptop para coisas pessoais por exemplo, ao chegar em casa, influencia nas sua carga horária semanal.
Para tirar isso a prova, na última quarta-feira resolvi que, ao chegar em casa, não iria ligar meu laptop nem assistir TV. Tomei meu banho, jantei, coloquei meu pijamas e fui pra cama. Coloquei uma estação de músicas clássicas e fui ler um livro. Meu cachorro deitou-se ao meu lado e as 20:30 aproximadamente eu apaguei. Acordei renovado, extasiado, “bom dia sol” e “beijinhos de luz”. Nesse dia me alimentei melhor, estava mais disposto e até com o humor melhor - quem me conhece sabe como isso é surreal.
Então, mesmo que seja necessário você fazer suas horas extras, prolongar suas atividades para além das 48 horas semanais, quando sentir-se esgotado, sem conseguir dormir direito, tente isso. Desligar-se de tudo que seja rotina por uma noite. Seja sozinho com seu cachorro. Seja com amigos. Seja com sua (seu) companheiro(a). Apenas se abstraia do que remete a sua rotina e tenha uma boa noite!

quinta-feira, 11 de setembro de 2014

Tablespaces BigFile, Normais e seus tamanhos: Como e quando usá-los

Até a versão 9i do Oracle, você normalmente podia criar tablespaces com datafiles até 32G (aproximadamente). Eles eram (são) chamados "Smallfile Tablespaces". Particularmente prefiro chamá-los de "Normalfiles", porque "Small" me dá uma impressão de um tamanho até 2G ou 4G. Na versão 10g em diante o Oracle te deixa criar tablespaces com datafiles maiores, até 128T dependendo da arquitetura do SO (64 bits) e do tamanho dos blocos (32K).
Usando Tablespaces Smallfile normalmente um administrador de banco de dados pode criar até 1024 datafiles, cada um até 32G - o que nós dá aproximadamente 34T de dados - usando um block size de 8K. Bem sabemos que atualmente esse volume de dados é insignificante para alguns sistemas/empresas, como a Google, VISA, etc. Especialmente aquelas que armazenam vídeos, imagens de alta resolução e áudio.
Uma Tablespace BigFile pode armazenar mais de três vezes um banco de dados completo que utiliza apenas smallfiles, em uma única tablespace. Usando um block size de 32K o banco de dados pode atingir 8 Exabytes. É muito dado armazenado. Infelizmente isso também pode trazer problemas. Quanto maior for o datafile, maior será o tempo para restaurar seu backup ou realizar alguma manutenção nele.
Algumas dessas manutenções requerem que o sistema fique off-line, dependendo do que esteja armazenado nesse datafile. Uma boa prática para evitar isso seria desenhar o modelo de dados de modo que possa dividir as tabelas que guardariam dados grandes (ex.: tabelas com campos BLOB ou CLOB) em tablespaces BigFile, enquanto o restante dos dados permaneceria em tablespaces normais.. Ou ainda você pode particionar a tabela colocando os dados que são menos acessados em uma partição dentro do BigFile. Fazendo isso apenas uma parte do seu sistema ficaria inacessível durante uma manutenção.
Por exemplo, em um sistema de gestão hospitalar e diagnósticos. Você pode colocar as tabelas que armazenam vídeos e imagens para diagnósticos em um BigFile, enquanto o estoque, faturamento e outras rotinas administrativas podem ficar na tablespace normal. Desse modo apenas uma parte do sistema (diagnósticos) ficaria inacessível durante a manutenção.
Por outro lado já existem Appliances (máquinas fechadas com configuração de fábrica direcionada para ambientes e fins específicos) feitos para lidarem com essas necessidades, como o BigData e ExaData da Oracle, InfoSphere e Watson Foundation da IBM, o CISCO USC (da CISCO, claro) e muitos outros.
Então, é melhor você ter um conjunto de pequenos soldados, que movem-se mais rápido e distribuem-se de vários lados, ou um único enorme soldado, movendo-se lentamente e de uma única direção? Tudo depende da sua estratégia!


BigFiles Tablespaces, Normal Tablespaces and Tablespaces Sizes – How and When to use them

Until Oracle version 9i you normally only could create tablespaces with datafiles up to 32G (near that). They're called “Smallfile Tablespaces”. Particularly I prefer to call them “Normalfile”, because Small gives an impression of a size up to 2G or 4G. With version 10g and further, Oracle lets you create tablespaces with larger datafiles, up to 128T depending on the OS architecture (64 bits) and block size (32k).

 With a Smallfile Tablespace, normally the database administrator can create up to 1024 datafiles with 32G each – which gives nearly 34T of data – using 8K block size. We know that nowadays this amount of data isn't significant for some systems/companies, like Google, VISA, etc. Specially those which store videos, high resolution images and audio.
 A BigFile Tablespace can store more then three times a hole database that uses smallfiles, in a unique tablespace. Using a 32K block size, the database can reach 8 exabytes.  It's a huge amount of data. Unfortunately this can also bring some problem. As bigger is the datafile, as longer will be the time to restore its backup or do some maintenance on it.
 Some of those maintenance must bring the system offline depending on what is stored in the datafile. A good practice to avoid it, is to design your database in a way that you can divide tables that store large data (e.g.: Tables with BLOB or CLOB data) into a big file tablespace while the others in a normal tablespace. Or also you can partioned the table putting the less accessed data into the big file tablespace. In doing this, only a part of your system will be inaccessible during a maintenance.
 For example, in an Hospital Informatics System you can divide the tables which stores videos and images for diagnosis in a big file, while the stock, billing and administrative routines can stay in a normal tablespace, making that the system become available for those routines while only the diagnosis part will be offline for a maintenance.


On another hand there are Appliances (closed servers with a factory made configuration ready and directed for an specified needing) built to deal with those necessities, like BigData or ExaData, from Oracle, InfoSphere and Watson Foundations, from IBM, the CISCO USC and many others.

 So, is better you have a bunch of small soldiers, that move faster and from many sides, or one big and strong soldier, moving slowly and in a unique direction, in your army? All depends on your strategy! 




quinta-feira, 24 de abril de 2014

And if there was Black Metal bands 5.000 years ago?

 
"There shall not be found among you anyone who burns his son or his daughter as an offering,[a] anyone who practices divination or tells fortunes or interprets omens, or a sorcerer 11 or a charmer or a medium or a necromancer or one who inquires of the dead, for whoever does these things is an abomination to the Lord" Dt. 18, 10 - 12
Black Metal bands probably would have all of its components burned and stoned (not necessarily in this order) in those times, 5.000 years ago. With its lyrics full filed with death, witchcraft, references to ancient satanic rituals and demons, those bands become easy targets of religious fanatic or simply unenlightened people, who believe that the mere fact that you wear a shirt of any of these bands and listen to their music turns you into a follower of Lucifer. Okay that early black metal was part of a movement against Christianity, often encouraging followers to literally burn churches. But particularly I listen black metal as well as other types and rock bands and doesn't mean that I'm a worshiper of the devil and make sacrifices with newborns on the Sabbath.
Even recently, I found a band that seems to be little known here in Recife, and why not say here in Brazil: Acid Witch. The band is from Detroit and brings a sound that differs from the traditional riffs of the Black Sabbath. They even use a keyboard in many songs (very unusual for black metal). All production is done by members of the band, bringing back that old underground attitude is missing nowadays. And I found the keyboards very cool.
I also found a very cool Metal website (Black Metal, Death, Classicals, etc...). You can find (and download) a lot of good stuff there, like Sacrificia Mortuorum (France), Nartvind (Belgium), Dauden I Mørke (USA), Ghremdrakk (Belgium), Darkspace (Switzerland), Akerbeltz (Spain), Vomitor (Autralia), besides, of course, the Norwegian Immortal. I even found national stuffs like Catacumba, Hecate, Funeral WinterDust and Omfalos.
Another website which I indicate to buy t-shirts (and other stuffs) is Hell'sHeadbangers. I bought an Acid Witch t-shirt there, and it arrived a few days ago. Ok, it was two months later but it's acceptable, once the product comes from abroad and pass through a several of brazilian customhouse bureaucracy to arrive at my home. If you want something faster I suggest the RockStore with a nice variety of t-shirts or TudoRock with good prices.
I went to the old downtown (Recife Antigo) try to drink some beer, listening the good and old nordic metal, but I heard, and confirmed my suspicious, that the Bar do Metal (Bar of the Metal), in the Bom Jesus Lane, is closed. Now I'm looking for another similar place. A company partner told me that in Tomazina Street, after the Burburinho bar, they play metal in one of those bars. I went there one of these days but all the place was too obscure. I miss the Bar do Metal near the Ponte do Janga (Janga's Bridge)...
Locations of visitors to this page
Côcos pelo Mundo