Monday, April 30, 2012

Benchmarks: Some thoughts / Alguns pensamentos

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

Although I have a perfectly clear disclaimer on the right side of the blog, I'd like to start this article by re-enforcing that disclaimer. Everything I'll write here are my own thoughts and in no way represent my employer view or position. It's probable also that the ideas presented here may go against some respectable people's ideas and some established opinions. I'd like to apologize if someone expects something different. Having said this, the ideas presented here are my real belief, based on my work experience, on my readings and many discussions with some very respectable people.

What is a database benchmark?
Database benchmarks are well defined stress tests and usually when we see references to them chances are that it's all about the TPC council published benchmarks. The TPC council is a non-profit organization whose members are database software vendors, hardware makers, and other IT related organizations. The purpose of the TPC (Transaction Processing Council) is to "define transaction processing and database benchmarks and to disseminate objective, verifiable TPC performance data to the industry".
The TPC has defined several specs for benchmarks. The specs have designations like:

  • TPC-C
    OLTP benchmark
  • TPC-D
    Datawarehouse benchmark (deprecated)
  • TPC-H
    Datawarehouse benchmark (current)
  • TPC-DS
    Decision support benchmark (new)
  • TPC-E
    OLTP benchmark created to replace the TPC-C
The benchmark specs are very detailed and include everything that defines the tests. This include the database schema, the queries that are to be run, the several rules that specify what can and can't be used in terms of features, and also what must be used (like referential and check constraints etc.).
The benchmark reports include the measures taken, which are typically specified in number of transactions per time unit (the transactions are well defined in the specs). They also include the total system cost, which should include hardware and software costs including acquisition and support for a well defined period of time (3 years for example)
And these specs have evolved over time, due to several reasons:

  • New hardware and software features turned earlier specs useless (like materialized views which killed TPC-D)
  • New uses of software made some old specs look a bit outdated, meaning that new specs were created to better match the new reality
Personally I have no reason to assume that TPC was not created with good intentions. But for reasons that will be clarified along this article, I give no credit to the benchmarks. They only measure the will of a supplier to win, and how well it can twist the benchmark rules in order to achieve something worth publishing. Please note that although I have some commercial understanding of the market, I'm basically a technician. If you're talking to top management of big companies, they tend to don't understand any technical related argument, and they might, because of that, give some credit to the benchmarks published on But if you're talking to some technically aware person, I believe it's easy to dismantle a benchmark in around 10m (I'll try it for the top TPC-C published as an exercise).
Having said this, running a publishable benchmark represents an enormous technical and economic effort, and I must grant credit to the companies which do it.

The TPC-E mystery...
TCP-E benchmark specification was introduced because TPC-C had a lot of holes that made it unrealistic. You can easily find several opinions stating it's a better benchmark than it's predecessor.
But if you check the results you'll see that only one database vendor, Microsoft, has publish results for this. The mystery is why? Of course, MS supporters say it's because no one can beat them. No one else believes that. Most people who dedicate some time to study this believe that this is a leap frog game and it really depends on the investment. And if it's still done (or was) with TPC-C, a very mature specification, it should be even easier to do with a relatively new benchmark (the tricks are easier to discover and implement while the specs are still new). I've found several references on the Internet speaking about why no one entered the TPC-E "game", but none of them is conclusive (from my perspective). I can leave some references here for your own research:

You can decide for yourself. Personally I think the issue is related to what Mr. Jerry Keesee (IBM Informix database development director) explained in a public webcast (Chat with the labs) on 29 January 2009. More on that later.
But currently for OLTP, the most popular benchmark is TPC-C. TPC-E apparently is being pushed by hardware vendors (including IBM).

Benchmarks and Informix
Informix was a regular leader of benchmarks in the nineties. It used to partner with hardware vendors to achieve several top result in several categories.
The subject of benchmarks is very sensitive within the Informix community. Many people strongly believe that IBM should run official benchmarks using Informix. IBM never did it after acquiring Informix Software Inc. We may understand or not that position, but the reasons were clearly explained by Mr. Jerry Keesee, in a very clear answer to the question "How come IBM doesn't participate in public benchmarks of IDS? Like the benchmarks?". The question was asked by a well known (and particularly critical of IBM) participant of the Informix forums at the end of a webcast in 29 January 2009. The reasons presented were:
  1. IBM has been doing TPC-C benchmarks with DB2 for a very long time. If we do one with Informix only two things can happen and they're both bad for IBM:
    1. Informix gets a better number, and the competition and analysts would crush us (IBM and DB2)
    2. Informix gets a worse number, and the competition and analysts would crush us (IBM and Informix)
  2. We could consider TPC-E, but currently there's only one vendor (MS) who published results on this kind of benchmark. Once we publish one (which would be better in absolute numbers or cost, since no one publishes a benchmark that doesn't show an improvement), we would have entered a very expensive race, because the vendor who is surpassed will probably reply and the leap frog game would start. Jerry prefers to invest on new features and product improvements which directly bring benefits to the customers.
You can't ask for something clearer than this. Meanwhile a benchmark on MDM (Meter Data Management) was done and published and Informix got a great result but this is not a standard. So it does not satisfy people who really want TPC results.

Very recently you may have noticed that the words "TPC-C" and "Informix" were floating around the social networks and some Informix related sites. That's because Eric Vercelletto decided to pick the TPC-C schema and specifications and run a non-oficial database stress test. While some people were jumping around in happiness others were criticizing him. My position is much more neutral, and I think most of the people talking about it never took the time to make a deep analysis of a TPC-C benchmark result. The opinions tend to be divided between something like "yeah!!! Informix finally has a TPC-C benchmark. Now we can show the performance Informix can achieve" and "Oh... The result is so low. He used the free version. It's useless". Really, if you want to speak about it, let's spend some time to look at some facts:
  • The benchmark run by Eric is not a true TPC-C benchmark. It's not official, it's not audited and yes, the number is very low if you compare it to other official published results (which by the way can't be done for legal and technical reasons)
  • Yes, Eric used the Innovator-C edition, which is a cut down version free of costs. It has limits and lacks some features that could help (only 2GB of RAM, no partitioning etc.)
  • Eric fought against technical problems with the clients sending the transactions. In fact he put the clients and the database on the same machine. Something you'll never see in a true benchmark
  • Eric used 4 hard disks. You can find a published result on site with the same number of cores in the database server, that used 200 hard disks. Yes, you read correctly, two hundred hard disks (but for the top results the numbers are on the thousands)
  • The same  published benchmark used 10 cores for the clients and 4 cores for the database server. Compare that to the troubles Eric had with the client programs
  • Eric used 16GB of memory for both the database and the clients. The benchmark I mentioned above used 72GB just for the database server
  • Eric mention his system costs less than 900€. The system that run the above mentioned test was priced at more than $200000
  • Eric mentions he tried a client server configuration, but he could not reach more than 15-20% CPU use on the database server. This of course means he had great problems in the way the benchmark was being done (either not enough CPU power on the clients or other constraints like disk/memory on the DB server). In any case this would never get published if it was a true benchmark until the problems were fixed (in which case the numbers would rise dramatically)
So, given all this, are you assuming I don't appreciate Eric's work? Not so! Eric was a colleague at Informix Portugal around 1999 when I moved from a "4GL guy" onto an "engine guy" and he helped me on that. I know he's technically skilled and I appreciate his effort and his voluntarism to push this issue. What I'm trying to show is that the real TPC-C benchmarks belong to a completely different league. They use an unrealistic amount of hardware including CPUs, memory, disk, caching, Solid State Disks, and also an incredible human power. Every small detail is carefully analyzed and any bottleneck identified is studied to the limit. This sometimes brings real improvements to the products, but many times just creates a "smart scheme" to "fool" the benchmark rules. More on this later.
What Eric did is completely different and I never saw it being done: Take some commodity hardware like the one small customers may use, employ very little human effort, and try to make a stress test. Is it useful? Yes, but mostly for the person doing it, and eventually because it triggers others to do something similar or just talk about it. Is it comparable to the benchmarks you normally see referenced in press releases? No! You can't even start comparing it.
Another situation where I've seen people doing something similar is the Advanced Datatools promoted "fastest Informix DBA" challenge, that usually happens at the IIUG conferences. And it's interesting to see that Lester Knutsen will be showing this soon at Mac Tech. See it for yourself:

Quick overview of the TPC-C top result
I mentioned earlier that I would go through the top TPC-C result published as of today in This benchmark was run by Oracle with version 11gR2 with RAC and partitioning. It achieved a very respectable result of over 30M tpmC (thirty millions of transactions per minute - type C -). The observations below are taken from the full benchmark disclosure report Let's see the facts:
  • [Page 6] The system cost was roughly $30M  (yes, thirty million dollars). Note that this price is not the price list. It includes a discount of $30M (50%).
  • [Page 4] It used 27 servers (oracle RAC nodes) for the database, each one with 4 Sparc processors. This means 1728 cores total (16 cores for each processor).
  • [Page 4] It used a central storage unit containing over 11000 24GB SSDs (Solid State Disks) and 720 2TB 7.2RPM SAS disks
  • [Page 4] Each one of the 27 nodes had 512GB of RAM, for a total of 13.5TB of RAM for the database servers side
  • [Appendix B] Most of the tables and indexes were partitioned in at least 27 pieces. Yes... 27, the same number of nodes. The why is explained below
  • [Appendix B] 27 UNDO tablespaces were created... yes 27 again.
  • [Page 30/TPC-C Spec] Clause of the current TPC-C specs, define that any "New Order" (one of the five transactions) will refer to a "home warehouse" 99% of the times. So if you setup the clients properly, you split them for 27 RAC nodes. And 99% of the "New Order" transactions will use a "home warehouse". This will all be contained in one of the 27 table partitions. Meaning each database node will essentially work with one of the partitions. Now... The "New Order" transaction represented nearly 45% of all the transactions run in this test. The "Payment" transaction represented around 43%. And for this one, 85% of them used a "home warehouse".
  • What is the problem with RAC? The cache fusion... or in other words the piece of the system that guarantees data consistency across the nodes... It's a well known bottleneck, and Oracle usually says you don't have to change the application, but the fact is, if you don't, it will not scale. And TPC-C allows the system to be configured in a way that the various nodes act almost (99% of 45% and 85% of 43%) as if they were isolated nodes. So it scales... I bet you can imagine what Oracle would have to do to get a higher number...: Just add nodes and partitions... (change the application and keep the affinity)
  • [TPC-C Spec] From the other three transactions ("Stock level", "Order Status" and "Delivery") only one ("Delivery") includes data changes. The other two are read-only.
  • From the 3 later bullets you can understand how unrealistic this is, and the tricks used that take full advantage of it. But we still have one strong point about this benchmark: "Ok, I understand they dumped a ton of hardware and used allowed tricks to push the performance numbers... But what about the cost? It's cost per transaction is better than many previous benchmarks!". True! But once again, we must read everything very carefully. If you browse through several of these benchmarks (and this reflects reality) you'll notice that a very significant part of the cost is for software license and maintenance. The specs require the costs to be calculated for a three years period. And surely, all this hardware should raise the software costs, wouldn't it? Err... Yes, but no! Once again, let me explain... The TPC-C specs just require a calculation for 3 years. So what will a smart vendor do? Simply create a license that instead of perpetual is only for 3 years. As you can see here on the Oracle Price list, a processor license of enterprise version would cost you $47500. On the benchmark result [Page 5] you notice that the value is $23750. Then go back to the price list and notice the small letters on page 9. It states that for a 3 Year term license the cost is 50% of the perpetual license. So this cuts the software costs of the benchmark into 50% (without counting the global 50% discount on all prices). In a real situation it would mean a 75% discount on the software, but of course, after the 3 years period you'd need to uninstall the licenses or just buy new ones
  • Finally, support. The benchmarks mentions [Page 5] $62100 for Oracle Incident Server Support package per year. This is exactly 27 * $2300 which accordingly to the price list [Page 13] entitles you to web based support. I cannot find any item in the benchmark that would entitle you to upgrade your software as is normal when you pay S&S (Service and Support). Again, accordingly to the price list small lettered footer this would be 22% (per year) of the perpetual licenses.
So, I'm sure the above would not take more than 10m to explain to any customer. And in my perspective it shows the benchmark was twisted (in a fully legal and compliant manner of course) to increase the performance numbers and to decrease the cost. But neither the technical scenario nor the budget reflect a real customer scenario. This is why, in my opinion these benchmarks are worthless. And finally, if you ask me, I really prefer to have the money (and it's a lot) invested in the R&D of the product or in other marketing activities.

Having said this, I really think what Eric has done is an interesting exercise that may allow you to train your performance tunning skills. And I believe (no inside info here) that database vendors may use the schemas and queries to regularly test the software. It may allow them to notice positive or negative performance changes while they introduce new functionality and performance optimizations.
As for the published benchmarks? They exist solely for the purpose of getting headlines and press releases.

Versão Portuguesa:

Termo de responsabilidade
Apesar de ter um termo de (des)responsabilização perfeitamente claro no lado direito do blog, gostaria de começar este artigo por reforçar esses mesmos termos. Tudo o que escreverei aqui são as minhas próprias opiniões e ideias e de forma nenhuma refletem o ponto de vista ou posição da minha entidade patronal. É provável que algumas ideias apresentadas aqui vão contra as ideias de gente muito respeitável e algumas opiniões bem estabelecidas. Peço desculpa a quem esperasse algo diferente. Tendo dito isto, as ideias apresentadas são as minhas reais convicções, baseadas na minha experiência de trabalho, nas minhas leituras e em muitas discussões com pessoas que respeito muito.

O que é um benchmark de base de dados?
Os benchmarks de base de dados são testes de stress e habitualmente quando vemos referências a eles, é provável que se refiram aos benchmarks publicados pelo TPC council. O TPC Council é uma organização sem fins lucrativos cujos membros são fornecedores de bases de dados, fornecedores de hardware e outras organizações relacionadas com as tecnologias de informação (TI). O propósito do TPC (Transaction Processing Council) é "define transaction processing and database benchmarks and to disseminate objective, verifiable TPC performance data to the industry". Numa tradução livre seria "definir benchmarks de bases de dados e processamento transacional e disseminar dados de permormance objetivos e verificáveis para o mercado". O TPC definiu várias especificações para os benchmarks. As especificações têm designações como:

  • TPC-C
    de OLTP
  • TPC-D
    Benchmark de Datawarehouse (descontinuado)
  • TPC-H
    de Datawarehouse (actual)
  • TPC-DS
    Benchmark de suporte à decisão (novo)
  • TPC-E
    Benchmark de OLTP criado para substituir o TPC-C
As especificações de um benchmark são detalhadas e incluem tudo o que define os testes. Isto incluí o modelo de dados, as queries que devem ser executadas, as várias regras que limitam o que pode e não pode ser usado em termos de funcionalidades e também o que tem de ser usado (como integridade referencial, check constraints etc.)
Os relatórios de benchmark incluem as medidas efetuadas, que são tipicamente especificadas em número de transacções por unidade de tempo (as transações são elas próprias definidas na especificação). Incluem também o custo total dos sistemas, contendo o custo do hardware e software, nomeadamente custo de aquisição e suporte por um período bem definido (3 anos por exemplo)
Estas especificações evoluíram ao longo do tempo por diversas razões:

  • Novas funcionalidades de hardware e software tornaram as especificações antigas inúteis (como as views materializadas que mataram o TPC-D)
  • Novas utilizações do software fazem com que as especificações antigas pareçam ultrapassadas, levando a novas especificações que pretendem refletir melhor a realidade
Pessoalmente não tenho razões para assumir que o TPC não tenha sido criado com boas intenções. Mas pelas razões que irei expôr ao longo deste artigo, não dou crédito aos benchmarks. Estes apenas medem a vontade de um fornecedor em vencer, e quão bem consegue distorcer as regras do benchmark com o objectivo de obter algo que valha a pena publicar. Note-se que apesar de ter algum entendimento comercial do mercado, sou basicamente um técnico. Se tiver uma conversa com a gestão de topo de uma grande empresa, tenderão a não entender qualquer argumento técnico, e poderão por causa disso dar algum crédito aos benchmarks publicados em Mas se estiver a falar com alguma pessoa minimamente técnica, acredito que é fácil "desmontar" um benchmark em cerca de 10m (tentarei fazê-lo como forma de exercício para o resultado TPC-C de topo)
Apesar disto, correr um benchmark publicável representa um enorme esforço técnico e económico, e nesse sentido tenho de dar crédito ás empresas que o fazem.

O mistério do TPC-E...

A especificação de benchmark TCP-E foi introduzida porque o TPC-C tinha uma série de falhas que o tornavam irrealista. É fácil encontrar opiniões que afirma que é um melhor benchmark que o anterior.
Mas se procurarmos os resultados vemos que apenas um vendedor de base de dados, a Microsoft, publicou resultados com esta especificação. O mistério é porquê?. Naturalmente os apoiantes da MS dizem que é porque ninguém os consegue bater. Mais ninguém acredita nisto. A maioria das pessoas que dedicaram algum tempo ao estudo destes benchmarks afirmam que se tornam numa "corrida de rãs" e que realmente dependem do investimento. E se ainda é feito (ou era) com o TPC-C, uma especificação muito madura, deveria ser ainda mais fácil de fazer com um benchmark relativamente novo (os truques são mais fáceis de descobrir e implementar enquanto os benchmarks são novos. Encontrei várias referências na Internet sobre o porquê de ainda ninguém ter entrado no "jogo" do TPC-E, mas nenhuma absolutamente conclusiva (na minha perspetiva). Posso deixar algumas referências para a sua própria pesquisa:

Pode decidir por si mesmo. Pessoalmente penso que o assunto está mais relacionado com o que o Sr. Jerry Keesee (director de desenvolvimento de IBM Informix) explicou num webcast público (Chat with the labs) em 29 de Janeiro de2009. Mais sobre isto adiante
Mas atualmente, para OLTP o benchmark mais popular é o TPC-C. Aparentemente o TPC-E está a ser publicado por vendedores de hardware (incluindo a IBM).

Benchmarks e Informix
A Informix era um líder regular dos benchmarks nos anos noventa. Costumava colaborar com parceiros de hardware para alcançar vários resultados de topo em diversas categorias.
O tema dos benchmarks é muito sensível dentro da comunidade internacional de Informix. Muitas pessoas acreditam fortemente que a IBM devia executar benchmarks oficiais com o Informix. A IBM nunca o fez desde que adquiriu a Informix Software Inc. em 2001. Podemos ou não entender essa postura, mas as razões foram claramente explicadas pelo Sr. Jerry Keesee, numa resposta muito clara à questão "Como é que a IBM não participa em benchmarks públicos de Informix? Como os benchmarks". A questão foi colocada por um participante muito conhecido (e particularmente critico da IBM) dos fóruns de Informix, no final de um webcast em 29 de Janeiro de 2009. As razões apresentadas foram:
  1. A IBM tem feito benchmarks TPC-C com o DB2 desde há longo tempo. Se fôr feito um com Informix apenas duas coisas podem acontecer, e são ambas más para a IBM:
    1. O Informix obtém números melhores e a concorrência e os analistas cairiam em cima da IBM (e do DB2)
    2. O Informix obtém números piores e a concorrência e os analistas cairiam em cima da IBM (e do Informix)
  2. Poder-se-ia considerar o TPC-E, mas atualmente apenas existem resultados publicados de um vendedor de bases de dados (MS). Após a hipotética publicação de resultados com Informix (que seria necessariamente melhor sob alguma perspetiva, dado que ninguém publica números piores) dava-se inicio a uma corrida muito cara, dado que o vendedor ultrapassado tentaria responder e a "corrida de rãs" começaria. E o Jerry prefere investir em novas funcionalidades e melhorias do produto que trazem benefícios diretos aos clientes
Não se pode pedir algo mais claro que isto. Entretanto um benchmark sobre MDM (Meter Data Management) foi executado e publicado, tendo o Informix obtido um excelente resultado. Mas não é considerado um benchmark standard. Portanto não satisfaz quem realmente anseia por um resultado TPC.

Muito recentemente pode ter notado qeu as palavras "TPC-C" e "Informix" andavam a ecoar pelas redes sociais e em alguns websites relacionados com Informix. Isto deveu-se ao Eric Vercelletto ter decidido pegar no modelo de dados TPC-C e nas especificações e ter executado um teste de stress de base de dados não oficial. Enquanto algumas pessoas davam saltos de contentamento outros criticavam-no. A minha posição é bastante mais neutral, e penso que a maioria das pessoas que falam sobre o assunto nunca tiraram um tempo para fazer uma análise profunda de um resultado de um  benchmark TPC-C. As opiniões tendiam a dividir-se entre algo como "Sim!!! Finalmente o Informix tem um benchmark TPC-C. Agora podemos mostrar a performance que o Informix pode atingir" e no extremo oposto "Ehc... O resultado é muito baixo. Ele usou a versão grátis. É inútil". Haja paciência. Se alguém quer falar sobre isto, então passemos algum tempo a ver alguns factos:
  • O benchmark executado pelo Eric não é um verdadeiro benchmark TPC-C. Não é oficial, não é auditado e sim, o número é baixo se o compararmos com os resultados oficiais publicados (o que por sinal não se pode fazer devido a questões legais e técnicas)
  • Sim, o Eric usou a edição Innovator-C, que é uma versão limitada e grátis. Tem limites e falta de funcionalidades que poderiam ajudar (apenas 2GB de RAM, não tem particionamento etc.)
  • O Eric lutou contra problemas técnicos com os clientes que enviam as transações. Na verdade ele colocou os clientes e a base de dados no mesmo sistema. Algo que nunca se vê num benchmark oficial
  • O Eric usou 4 discos rígidos. Podem encontrar-se benchmarks publicados no, com o mesmo número de cores no servidor de base de dados usado pelo Eric, que usaram 200 discos rígidos. Sim, leu corretamente, duzentos discos rígidos (mas para os resultados de topo este número é em milhares)
  • O mesmo benchmark que referi acima usou 10 cores para os clientes e 4 cores para o servidor de base de dados. Compare-se isto com os problemas sentidos pelo Eric com os programas cliente
  • O Eric usou 16GB de memória para colocar a base de dados e os clientes. O benchmark referido usou 72GB apenas para a base de dados
  • O Eric menciona que o custo do sistema é menos de 900€. O sistema onde correu o benchmark referido custava mais de $200000
  • O Eric mencionou que tentou uma configuração cliente/servidor, mas não conseguiu atingir mais que 15-20% de utilização de CPU no servidor de base de dados. Isto evidencia grandes problemas na forma como o benchmark estava a ser feito (ou falta de poder de CPU nos clientes ou outros constrangimentos no lado da base de dados como disco ou memória). Em qualquer caso estes números nunca seriam publicados se fosse um verdadeiro benchmark até que os problemas fossem identificados e resolvidos (situação em que os números subiriam dramaticamente)
Dado tudo isto, se está a assumir que não aprecio o trabalho do Eric, está enganado. O Eric foi um colega na Informix Portugal por volta de 1999, altura em que passei de "um tipo do 4GL" para "um tipo do motor" e ele ajudou-me nisso. Sei que é tecnicamente muito bom e aprecio o esforço e voluntarismo ao pegar neste tema. O que estou a fazer é apenas tentar mostrar que os verdadeiros benchmarks TCP-C pertencem a uma categoria completamente diferente. Usam quantidades irreais de hardware incluindo CPUs, memória, disco, cache, solid state disks e também uma capacidade humana incrível. Todo e qualquer detalhe é cuidadosamente analisado e estudado até ao limite. Isto por vezes trás melhorias reais aos produtos, mas outras apenas cria "esquemas" para "enganar" as regras dos benchmarks. Mais sobre isto adiante.
O que o Eric fez é completamente diferente e nunca vi isso ser feito antes: Pegar em hardware banal, semelhante ao que qualquer pequeno cliente pode usar, empregar um mínimo de esforço humano e executar um teste de stress. É útil? Sim, mas principalmente para quem o faz, e eventualmente porque leva outros a fazer algo semelhante ou apenas falar sobre isso. É comparável com os benchmarks que normalmente vemos referenciados em notas de imprensa, blogs, e outros artigos na Internet? Não! Nem podemos começar a comparar.
Uma outra situação onde vi alguém fazer algo semelhante são os concursos fastest Informix DBA promovidos pela Advanced Datatools que decorrem normalmente durante as conferências do IIUG.
E é interessante verificar que o Lester Knutsen vai mostrar isto brevemente na Mac Tech. Veja por si mesmo:

Revisão rápida do resultado TPC-C de topo
Mencionei antes que iria rever o resultado TPC-C de topo conforme publicação actual em
Este benchmark foi efetuado pela Oracle com a versão 11gR2 com RAC e particionamento. Alcançou um resultado muito respeitável de 30M tpmC (trinta milhões de transações por minuto - tipo C - ). As observações abaixo foram baseadas no relatório completo sobre o benchmark Vejamos os factos:
  • [Página 6] O sistema custa grosso modo $30M (sim, trinta milhões de dólares). Note-se que o preço não é o de tabela. Incluí um desconto de $30M (50%)
  • [Página 4] Usou 27 servidores (nós de RAC) para a base de dados, cada um com 4 processadores SPARC. Isto traduz-se num total de 1728 cores (16 cores por processador)
  • [Página 4] Usou uma unidade central de armazenamento com  mais de 11000 24GB SSDs (Solid State Disks) e 720 discos de 2TB 7.2RPM SAS
  • [Página 4] Cada um dos 27 nós de base de dados tinha 512GB de RAM, para um total de 13.5TB de RAM para o conjunto dos servidores de bases de dados
  • [Apendéce B] A maioria das tabelas e índices foi particionada em pelo menos 27 partições. Sim... 27, o mesmo número de nós. A razão é explicada adiante
  • [Apendíce B] Foram criados 27 UNDO tablespaces... sim, novamente 27
  • [Página  30/Especificação TPC-C] A cláusula da especificação actual do TPC-C define que qualquer transacção "New Order" (uma das cinco transações) se deverá referir a um "home warehouse" em 99% das vezes que é executada. Assim, se configurar os clientes corretamente, divide-os pelos 27 nós de RAC. E 99% das transações "New Order" irão usar um "home warehouse", ou seja dados contidos em apenas uma das 27 partições das tabelas.. Mais... a transação "New Order" representa 45% de todas as transações de todo o teste. A transação "Payment" representa cerca de 43%. E para esta, 85% usam um "home warehouse".
  • Qual é o problema com o RAC? O cache fusion... ou por outras palavras o componente do sistema que garante a consistência da informação entre os nós... é um ponto de contenção reconhecido, e habitualmente a Oracle diz que não é necessário mudar a aplicação, mas o facto é que se não o fizermos não escala. E o TPC-C permite que o sistema seja configurado de uma forma que os vários nós atuam quase (99% em 45% das transações e 85% noutros 43%) como se fossem nós isolados. E logo escala muito melhor... Aposto que consegue imaginar o que a Oracle teria de fazer para obter um número maior... Adicionar nós e partições... (mudar a aplicação e manter a afinidade)
  • [Especificação TPC-C] Das restantes três transações ("Stock level", "Order Status" e "Delivery") apenas uma ("Delivery") incluí alteração de dados. As outras duas são apenas de leitura
  • Dos últimos 3 pontos pode entender-se o quão irrealista isto é e quais os truques para tirar proveito disso. Mas mesmo assim ainda resta um ponto muito forte relativamente a este benchmark: "Ok, compreendo que tenham despejado toneladas de hardware e usado todos os truques permitidos para empurrar os números da performance... Mas e sobre o custo? O custo por transação apresentado é menor que muitos benchmarks anteriores!". Verdade. Mas mais uma vez temos de ler tudo com muita atenção. Se folhear alguns destes benchmarks verificará que uma parte significativa dos custos é para o licenciamento e manutenção (e isto reflete a realidade). As especificações requerem que os custos sejam calculados para um período de três anos. E com certeza que todo este hardware deveria ter feito aumentar os custos de software, certo?! Err... Sim, mas não! Vamos à explicação. Se a especificação requer um custo a 3 anos, o que é que um fornecedor esperto fará? Basta criar uma licença que em vez de perpétua é apenas por 3 anos. Como pode ver na lista de preços da Oracle, uma licença de processador da edição Enterprise custaria $47500. No relatório do benchmark [Página 5] notará que o valor é $23750. Volte agora à lista de preços e repare nas letras pequenas na página 9. Informa que para uma licença com termo de 3 anos, o custo será 50% da licença perpétua. Assim isto corta o custo da base de dados em 50% (não incluindo o desconto global de 50%). Numa situação real isto significaria um desconto de 75% no software, mas claro que ao fim de 3 anos teria de desinstalar o produto ou simplesmente adquirir novamente as licenças
  • Finalmente, o suporte. O benchmark menciona [Página 5] $62100 para o pacote Oracle Incident Server Support, por ano. Isto é exatamente 27 * $2300, o que de acordo com a lista de preços [Página 13]  o habilita apenas a suporte via web. Não consigo encontrar em lado nenhum no benchmark algo que o habilitasse a efetuar upgrades de software como é normal quando se paga S&S (serviço e suporte). Novamente segundo as letras pequenas no rodapé da  lista de preços isto representaria mais 22% (por ano) da licença perpétua
Portanto, tenho a certeza que o exposto acima não demorará mais que 10m a explicar a um cliente. E na minha perspetiva mostra que os benchmarks são distorcidos (de forma completamente legal e dentro das regras claro) para aumentar os números de performance e reduzir os de custo. Mas nem o cenário técnico nem o de orçamento refletem um cenário real. É por isso que, na minha opinião, estes benchmarks são inúteis. Finalmente, se me perguntarem, realmente prefiro ver o dinheiro (e é muito) investido em I&D do produto ou em outras atividades de marketing.

Após tudo isto, penso sinceramente que o Eric fez um exercício interessante que poderá ajudar-nos a treinar as nossas capacidades de performance tunning. E acredito (sem informação privilegiada aqui) que os vendedores de bases de dados podem usar os modelos de dados e queries para testarem regularmente o seu software. Poderá ajudá-los a detetarem alterações positivas ou negativas na performance à medida que introduzem novas funcionalidades e otimizações.
Quanto aos benchmarks publicados? Existem apenas com o propósito de se conseguir cabeçalhos e notas de imprensa

Friday, April 27, 2012

Best practices survey / Inquérito sobre boas práticas

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:
The Informix Documentation Team has just setup another survey. This time the subject is best practices. They want to know how and where would you expect and wish to find these and the subjects you'd be more interested in. The survey takes no more than 5m, so it's a great way to tell them what you'd like to see covered in the future. The survey is here: and the original announcement here:

Versão Portuguesa:
A equipa de documentação Informix anunciou um novo inquérito. Desta feita o assunto é as melhores práticas. Desejam saber como e onde é que espera e gostaria de encontrar informação sobre o tema e quais os assuntos em que estaria mais interessado. O inquérito não demora mais de 5m a preencher, por isso é uma excelente forma de lhes dizer o que gostaria de ver tratado no futuro. O inquérito pode ser preenchido aqui: e o anúncio original está em::

Thursday, April 26, 2012

IIUG 2012: Presentations / Apresentações

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

The 2012 IIUG conference has just taken place this week in San Diego. The echos around the net and social media are very positive. And as usual, the IIUG made available for download the presentations of this year's conference. You can find them in the IIUG member area on the IIUG website. There are more than 100 presentations so you'll have plenty of material to study. From a brief overview I've found interesting that there are a lot of presentations made by customers and partners (as you'd expect and wish for a user conference) and also that the kind of the presentations is very diverse. You can find some "light weight" presentations, several case studies and also some very deep technical ones covering a lot of subjects. I can assure you that just by browsing a few of them I've learn at least a couple of things. So make sure you're a member of IIUG and access it on the member reserved area on the site

Versão Portuguesa:

A conferência de utilizadores de 2012 do IIUG teve lugar esta semana em San Diego. Os relatos espalhados na net e nas redes sociais são bastante positivos. E como habitualmente o IIUG disponibilizou as apresentações efetuadas na conferência deste ano. Pode encontrá-las na área de membros do website do IIUG. São mais de 100 apresentações, portanto terá muito material para estudo. De uma rápida vista de olhos achei interessante que um número grande de apresentações tenham sido feitas por clientes e parceiros (como seria de esperar e desejar de uma conferência de utilizadores), e também que o tipo das apresentações tenha sido muito diverso. Pode encontrar algumas apresentações "leves", vários casos de estudo e algumas muito técnicas cobrindo uma grande variedade de assuntos. Posso garantir que com uma olhadela em algumas já me permitiu aprender um par de coisas.
Por isso garanta que já é (ou se inscreve) membro do IIUG e aceda às apresentações na área do site reservada a membros.

Wednesday, April 18, 2012

OAT survey / Inquérito OAT

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

I've just noticed that the Informix documentation team has just publish a blog entry announcing a very interesting initiative at the 2012 IIUG conference. Users will be able to preview some product (OAT and IWA) enhancements as well as comment about how they use and how they'd like to use Informix, with a special focus on the documentation. The same article references an Informix Administration Survey.
It focus on OAT and how we administer Informix, and it's a great way to influence the future versions.
The survey takes around 5 minutes to complete... so if you can spare the time don't hesitate!

Versão Portuguesa:

Reparei que a equipa de documentação do Informix publicou uma entrada no seu blog anunciando uma iniciativa muito interessante na conferência do IIUG de 2012. Os utilizadores poderão antever algumas novas funcionalidades de dois produtos - OAT e IWA - , bem como comentar a forma como usam e como gostariam de usar o Informix, como um foco especial na documentação. O mesmo artigo refere um inquérito sobre administração Informix. Este inquérito foca-se no OAT e na forma como administramos o Informix, e é uma excelente forma de influenciar as versões futuras.
O inquérito demora cerca de 5 minutos a preencher... se puder despender esse tempo não hesite!

Saturday, April 7, 2012

Database wars are over? / As guerras das bases de dados terminaram?

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English Version

"Database wars are over...", "...and relational won", "...and Oracle won". If you search for these terms on your favorite search engine you'll get enough answers to keep you busy for a long time.
At a certain point many believed this was true. And I'm sure many others still do. But if you've been paying attention lately you'll notice this can still be under discussion.
Currently there is a lot of movement in the database arena... Let's see:

  • New versions are popping out: DB2 v10 for LUW, SQL Server 2012 are the most recent examples. Informix is in the early stages for vNext also. Meanwhile we have Informix Warehouse Accelerator that although not a new database per si, it's new technology
  • Datawarehouse appliances and dedicated servers are alive and kicking: Netezza (IBM), GreenPlum (EMC), Parallel Data Warehouse (HP/MS Sql Server), Exadata (Oracle)
  • NoSQL is "the" buzzword. Hadoop and everything about it seems like the next big thing
  • SAP makes bold statements about wanting to be a major database player. More details this Tuesday (April 10)
  • Oracle's CEO, Larry Ellison, says they (SAP) "must be on drugs"

So, we are definitively seeing news on the technology front. And although it's true that these days databases are a commodity, the fact is that no system is implemented without some sort of database. And it's a key part of any system, because it makes the bridge between bits and bytes and the least intelligible information (which of course needs BI tools for enrichment). And also because if it's critical for performance and availability of the information systems.
Given all this I think great times are ahead of us, assuming you like challenges and new technology to play with.
Focusing on Informix, I think we are seeing the introduction of some of this new technology. Informix Warehouse accelerator walked silently in 11.70.FC2, but new functionality is being delivered on each and every fixpack. FC3 saw the introduction of automatic data mart definition and several new locales. FC4 included the possibility of cluster installation, which brings enormous scalability and also data loading concurrently to queries and some other minor improvements. According to this post from Fred Ho FC5 will bring two other great features: possibility to load the marts from MACH-11 secondary clusters and the possibility to load only partitions that have changed (as opposed to the whole tables)
This clearly shows we have a roadmap, and yes... there's a lot of work to do. Specially as it's being adopted by customers who will easily find more uses than what they anticipated for.

Versão Portuguesa

"Database wars are over...", "...and relational won", "...and Oracle won". Se procurar estes termos (que por opção não traduzi) no seu motor de busca favorito vai obter respostas suficientes para o manterem ocupado durante bastante tempo.
Em dada altura muitos acreditaram que isto era verdade. E tenho a certeza que muitos ainda acreditam. Mas se tem prestado atenção ultimamente já terá notado que isto ainda está sob discussão.

Atualmente existem muitas movimentações no mercado de bases de dados. Vejamos:

  • Há novas versões a aparecer: DB2 v10 para LUW e SQL Server 2012 são os exemplos mais recentes. O Informix está a preparar a próxima versão também. Entretanto temo o Informix Warehouse Accelerator que não sendo em si uma nova base de dados incluí tecnologia nova
  • As appliances de Datawarehouse e servidores dedicados também estão a criar muita agitação: Netezza (IBM), GreenPlum (EMC), Parallel Data Warehouse (HP/MS Sql Server), Exadata (Oracle)
  • NoSQL é "o" novo chavão. Hadoop e tudo à sua volta parece ser o próximo grande boom
  • A SAP faz afirmações ousadas sobre desejar tornar-se num dos maiores vendedores de bases de dados. Mais detalhes serão divulgados esta terça-feira (10 de Abril)
  • O CEO da Oracle, Larry Ellison, afirma que eles (SAP) "must be on drugs" (devem estar sob o efeito de drogas)

Portanto estamos mesmo a assistir a novidades na vertente tecnológica. E apesar de ser aceite que hoje em dia a base de dados é uma comodidade, a verdade é que nenhum sistema é implementado sem algum tipo de base de dados. E estas são uma peça chave em qualquer sistema porque fazem a ponte entre os bits e bytes e o mínimo a que podemos chamar informação (que naturalmente necessita de ferramentas de BI para enriquecimento da mesma). E as BDs são também peças chave na performance e disponibilidade dos sistemas.
Tento tudo isto em conta, julgo que temos tempos interessantes pela frente, assumindo que gosta de desafios e nova tecnologia para "brincar".

Pondo o foco no Informix, penso que estamos a assistir à introdução de alguma desta nova tecnologia. O Informix Warehouse Accelerator entrou silenciosamente na versão 11.70.FC2, mas novas funcionalidades estão a ser incluídas em todos os fixpacks. A FC3 viu a introdução da definição automática de data marts e vários novos locales. A FC4 incluí a possibilidade de utilização em cluster, que oferece enorme escalabilidade, e também carregamento de dados em simultâneo com a execução de queries e mais alguns melhoramentos. Segundo este artigo do Fred Ho a FC5 vai trazer duas novas funcionalidades: A possibilidade de carregar os data marts a partir de nós secundários de um cluster MACH-11 e a possibilidade de carregar apenas partições que tenham sido alteradas (em vez de carregar a totalidade das tabelas).
Isto mostra claramente que existe um roadmap e sim... existe muito trabalho para fazer. Especialmente à medida que o produto vai sendo adotado pelos clientes que irão facilmente encontrar mais usos do que tinham antecipado.

Wednesday, April 4, 2012

2012 Informix Roadshow Lisboa: Closing notes / Notas de fecho

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English Version

The 2012 Informix Roadshow in Lisbon ended yesterday. The highlights of the second workshop day were Informix Warehouse Accelerator, compression and Genero.

Attendees were impressed by the ease of use of IWA and has planned in literally a couple of hours they managed to install the server component, the client management tool, define a data mart, load it, test the queries and even look into the workload analyzer that allows automatic mart definition. And all these achievable in a laptop with 4GB of memory (mart used roughly 1GB of in-memory data). The underlying Informix instance was provided fully configured and loaded.

The session about compression was also very well received and Scott gave us some important tips for it's use (not only the chargeable components - compression itself -, but also the free stuff - repack/shrink/defrag -)

Before finishing we also had a session on Genero, particularly interesting for the 4GL users present.
So, this was a great event, and a big special thank you to Scott for coming here and provide us (IBMers, clients and partners) all this info and his own experiences.

Versão Portuguesa

O Roadshow Informix 2012 em Lisboa terminou ontem. Os pontos altos do segundo dia de workshop foram o Informix Warehouse Accelerator, compressão e Genero.

Os presentes ficaram impressionados com a facilidade de utilização do IWA, e como planeado em literalmente um par de horas conseguiram instalar o componente servidor, a ferramenta de gestão, definir um data mart, carregá-lo, testar as queries e mesmo espreitar o analisador de carga que permite a definição automática de data marts. E tudo isto é possível num portátil com 4GB de memória (o data mart ocupava cerca de 1GB de dados em memória). A instância base de Informix foi fornecida completamente configurada.

A sessão sobre compressão foi também muito bem recebida e o Scott deixou-nos algumas dicas para o seu uso (não apenas o componente pago - a compressão propriamente dita - mas também as funcionalidades grátis - repack/shrink/defrag - )

Antes do encerramento ainda tivemos a sessão sobre Genero, particularmente interessante para os utilizadores 4GL presentes.
Portanto, foi um excelente evento, e um grande obrigado ao Scott por ter vindo cá e nos ter deixado a todos (IBMers, clientes e parceiros) toda esta informação e as suas próprias experiências.

Monday, April 2, 2012

2012 Informix Roadshow: Having fun / Boa forma de passar dois dias

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English Version

As announced earlier, the Lisbon 2012 Informix roadshow is happening. Today we assisted several presentations on 11.7 new features, security enhancements, storage provisioning and flexible grid.
Just after lunch students had the chance to experiment with the storage provisioning lab.

Tomorrow there will be final flexible grid details, a quick overview about Mashups and then we'll entered the main topic of the day; Informix Warehouse Accelerator. There will be an overview presentation and a lab which I just finished testing. It's impressive how in about one hour and an half I could go through the lab: Install the software, install the optimizer studio, define a data mart, load it, test it, and try the automatic workload analysis tool to create the data marts that can take advantage of the acceleration. Remarkably simple, but I suppose we should not expect any different from Informix.

Thanks a lot to Scott Pickett for the nice presentations!

Versão Portuguesa

Como anunciado anteriormente, o Informix Roadshow 2012 está a decorrer em Lisboa. Hoje assistimos a várias apresentações sobre as novas funcionalidades da 11.7, melhorias de segurança, storage provisioning e flexible grid.
Logo a seguir ao almoço os formandos tiveram oportunidade de experimentar o laboratório sobre storage provisioning.

Amanhã serão apresentados os últimos detalhes sobre flexible grid, uma rápida apresentação sobre Mashups e depois entraremos no tópico principal do dia: Informix Warehouse Accelerator. Haverá uma apresentação teórica e um laboratório que acabei de testar. É impressionante como em cerca de hora e meia é possível concluir o exercício: Instalar o software, instalar o optimizer studio, definir um data mart, carregá-lo, testá-lo e experimentar o analisador automático que permite derivar data marts que possam tirar proveito da aceleração.
Notavelmente simples, mas suponho que não seria de esperar outra coisa do Informix

Um muito obrigado ao Scott Pickett pelas óptimas apresentações!