Saturday, May 26, 2012

Informix 11.70.xC5: It's available / Já está disponível

This article is written in English and Portuguese
Este artigo está disponível em Inglês e  Portguês

English version:
The new fixpack of Informix 11.70 (xC5) is available and the Infocenter documentation was just updated as well as the PDF sets of manuals.
Taken directly from the release notes the new features and functionalities are (comments added after the bullet items):

  • Administration
    • Plan responses to medium-severity and low-severity event alarms
      Mainly a documentation improvement. By describing each possible event ID and the recommended action, IBM is continuing the improvement of the alarm handler allowing the end user to costumize the ALARMPROGRAM scripts
    • IFX_BATCHEDREAD_INDEX environment option
      The batched index read feature can now be controled using SQL through the SET ENVIRONMENT statement
  • Application development
    • Improvement to the keyword analyzer for basic text searching
      An improvement on the way the Basic Text Seach datablade (BTS) handles the keyword analysis to create it's indexes
    • Increased SQL statement length
      It may look a small feature if you never hit the 64KB limit, but it can be a must have if you ever faced that limit. Currently the limit was increased to an absurd 4GB with the exception of the CREATE VIEW which is 2MB
    • Enhanced query performance
      This can be misleading. What it is in fact is that the size of the client/server communication buffer can now be changed to 2GB by using the FET_BUF_SIZE variable. The driver for this was a competitive situation where it was identified that this could be a bottleneck. Note that this can be important for UNLOADs, exports etc.
    • The Change Data Capture API sample program
      Not really a feature. One program that was only found on the docs is now available in $INFORMIXDIR/demo/cdc for convenience
  • Enterprise replication
    • Replication errors on leaf nodes
      Since the leaf nodes in an ER topology can't have much information about errors on other servers, that errors are removed from the syscdrerror tables on leaf nodes
  • Global language support
    • Scan strings with the ifx_gl_complen() functions
      Performance improvement for GLS code
  • Time Series data
    • Count the time-series elements that match expression criteria
      COUNTIF function
    • Remove old time-series data from containers
      Allows the re-use of space after old data removal
    • New operators for aggregating across time-series values
      Improvement to the TSRollup function
  • Data warehousing
    • Refresh data quickly without reloading the whole data mart
      A single partition (fragment) of a fragmented table can be sent to the IWA in-memory database
    • Use high-availability secondary servers to accelerate queries
      HDR, RSS and SDS servers can now be used to create and load datamarts. Previously they could only be used to accelerate queries. This is a big improvement if you want to mix OLTP and BI workloads since you could offload a large part of the BI to the secondary node(s) leaving the primary to the main OLTP work
    • New options added for the use_dwa environment variable
      Several new options for this variable allow you to gain more control about how a session uses the Informix Warehouse Accelerator and to collect more data to understand it's behavior
    • Support for new functions is implemented
      Several new functions are supported in the accelerator, which allows more queries to benefit from it. This time the functions added were: LEN, LENGTH, SUBSTR, SUBSTRING, TODAY, TRIM and YEAR
    • Support for the Solaris Intel x64 operating system added
      This increases the number of platforms where the connection to Informix Warehouse Accelerator is supported. Currently they are: AIX, HP-UX, Solaris Sparc, Solaris Intel and Linux. I'd say the only one missing that matters is Windows!
To be honest, at first glance I didn't find this fixpack had the number of new features that we've become used to in the latest ones. My fellow colleague from tech support immediately found this good (sometimes new features bring new issues and tech support likes "quiet" releases that allow easy rollback to previous versions). But on the other hand if we look into some of these features, we really see that our R&D has been busy. I'm thinking about the Warehouse Accelerator features, the Timeseries and in particular the size of the SQL statements. I believe some people have been struggling with this for many years. And the increase of the maximum client/server communication buffer, can have a dramatic effect on some specific situations. But this is not all. This release has a lot of work that unfortunately is not documented yet. This is divided into two areas:
  1. Performance improvements that can cause issues on some customers or that break undocumented behaviors that applications rely upon. These features have hidden variables that can change the engine behavior if customers hit any issues. Personally I don't like this kind of things, but after seeing some explanations about some of these I tend to understand why this approach was adopted. I have sporadically faced some of these situations over the years and I noticed that one behavior may be desirable in some cases and not in others
  2. New functionality that may be provided to some selected customers or partners while still being developed and improved. This will surely be part of the next major release and the benefit is that they'll be much more stable when they're officially released
So, in short, another fixpack, some significant improvements in Warehouse Accelerator, Timeseries and other very specific points, and a lot of "undercover" work that follows a well established roadmap. Of course I could be accused of "whispering" simply to promote the work of R&D, but if you follow my posts you must agree I don't usually do this. Some stuff that I'm thinking about have recently come up on IIUG mailing list discussion, following up on some other blog's post, so I'm not even the first one to "leak" some of this. Hopefully in the future I'll be able to post something like "do you remember when I whispered about some undercover work? That was this and this and that..." and then you can pick up the "old" 11.70.xC5 fixpack and try a couple of tricks :)

Versão Portuguesa:

O novo fixpack do Informix 11.70 (xC5) está disponível e a documentação no Infocenter e nos PDFs foi actualizada
Tirado diretamente das release notes as novas funcionalidades são (comentários adicionados após cada ponto):

  • Administração
    • Planeamento de respostas para alarmes de baixa e média severidade
      Essencialmente é uma melhoria na documentação. Ao descrever cada possível evento (ID) e as ações recomendadas, a IBM continua a melhorar o gestor de alarmes permitindo ao utilizador final costumizar o seu script para o ALARMPROGRAM
    • Opção de ambiente IFX_BATCHEDREAD_INDEX
      A funcionalidade batched read index pode agora ser controlada por SQL através da instrução SET ENVIRONMENT
  • Desenvolvimento aplicacional
    • Melhoria na análise de palavras chave para a pesquisa básica de texto
      Uma melhoria na forma como o Basic Text Search (BTS) datablade lida com a análise de palavras-chave para criação dos seus índices
    • Aumento do tamanho das instruções SQL
      Pode parecer uma pequena melhoria, se nunca atingiu o limite de 64KB, mas pode ser crítico se alguma vez se deparou com este limite. Desta feita o limite foi aumentado para uns absurdos 4GB, com exceção de um CREATE VIEW que está limitado a 2MB 
    • Performance de queries melhorada
      Esta descrição pode ser enganadora. Não se trata de uma alteração ao optimizador, mas sim da capacidade de aumentar o buffer de comunicação entre o servidor e o cliente para 2GB. Isto pode ser controlado com a variável de ambiente FET_BUF_SIZE que até aqui só podia ir até 32KB. A razão para esta alteração foi uma situação de competição com outra base de dados onde isto foi identificado como um factor limitativo da performance. Note-se que isto pode ser importante para UNLOADs, dbexports etc.
    • Programa de exemplo de Change Data Capture API
      Não é propriamente uma funcionalidade. Um programa que apenas podia ser encontrado no manual pode agora ser mais facilmente utilizado pois existe em $INFORMIXDIR/demo/cdc
  • Enterprise replication
    • Erros de replicação nos leaf node
      Dado que os nós "folha" numa topologia ER não podem ter muita informação sobre erros de outros servidores (acima na cadeia), esses erros foram removidos da syscdrerror nos servidores "folha"
  • Suporte global language
    • Varrer strings com as funções  the ifx_gl_complen()
      Melhoria de performance no código GLS
  • Dados Timeseries
    • Contar os elementos time-series que verificam uma expressão de critério
      Função COUNTIF
    • Remoção de dados antigos de containers de time-series
      Permite a re-utilização de espaço após a eliminação de dados antigos
    • Novos operadores para agregação de valores time-series
      Melhoria na função TSRollup
  • Data warehousing
    • Refrescamento rápido de dados sem re-carregar todo o data mart
      Podemos refrescar apenas uma partição (fragmento) de uma tabela na base de dados in-memory do IWA
    • Utilizar os servidores secundários para acelerar as queries
      Os servidores HDR, RSS e SDS podem ser usados para criar e carregar data marts. Anteriormente apenas podiam ser usados para acelerar queries. Isto é uma grande melhoria se quer misturar utilizações OLTP e BI dado que se pode direcionar toda a carga de BI para os nós secundários, deixando o primário liberto para o trabalho OLTP
    • Novas opções adicionadas à variável use_dwa
      Várias opções foram adicionadas a esta variável para providenciar maior controlo sobre como uma sessão utiliza o Informix Warehouse Accelerator e para recolher mais dados para entender o seu comportamento
    • Suporte para novas funções
      Várias novas funções são suportadas pelo acelerador, o que permitirá que ainda mais queries sejam aceleradas. Desta feita as funções adicionadas foram: LEN, LENGTH, SUBSTR, SUBSTRING, TODAY, TRIM e YEAR
    • Suporte para o sistema operativo Solaris Intel x64
      Aumentou a lista de plataformas que suportam a conexão ao Informix Warehouse Accelerator. Atualmente são: AIX, HP-UX, Solaris Sparc, Solaris Intel e Linux. Diria que a única ausência relevante será o Windows!
Para ser  honesto, à primeira vista, não me pareceu que este fixpack tivesse o mesmo número de funcionalidades a que nos temos habituado nos últimos. O meu colega do suporte técnico considerou imediatamente que isto era positivo (por vezes funcionalidades novas trazem novos problemas e o suporte gosta de versões "calmas", e que permitam regressão com paragem e arranque simples). Mas por outro lado, se olharmos para algumas das novas funcionalidades, verificamos que realmente o desenvolvimento tem estado bastante ocupado.

Estou a pensar em particular nas funcionalidades do Informix Warehouse Accelerator, nas de TimeSeries e muito especificamente no alargamento do limite dos comandos SQL. Sei que alguns clientes têm sofrido com este limite há anos. E o aumento do tamanho máximo do buffer de comunicação pode ter um efeito dramático em situações específicas. Mas isto não é tudo. Esta versão incorpora muito trabalho que infelizmente não está documentado (ainda). Isto divide-se em duas grandes áreas:

  1. Melhorias de performance que podem causar problemas em alguns clientes ou que alteram comportamentos não documentados dos quais algumas aplicações podem depender. Estas funcionalidades tem associadas variáveis não documentadas que podem mudar o comportamento do motor caso os clientes encontrem algum problema. Pessoalmente não gosto deste tipo de configurações, mas após ter visto algumas explicações sobre algumas destas funcionalidades acabo por compreender o porquê de se ter seguido esta abordagem. Já encontrei algumas destas situações esporadicamente e verifiquei que um comportamento pode ser bom para uns casos e mau para outros
  2. Novas funcionalidades que podem ser disponibilizados a clientes e/ou parceiros selecionados enquanto ainda estão a ser desenvolvidas ou melhoradas. Estas serão certamente disponibilizadas numa próxima versão, sendo que o benefício desta abordagem é que quando for feita a introdução formal, estarão muito mais estáveis
Em resumo, mais um fixpack, algumas melhorias significativas no Informix Warehouse Accelerator,  Timeseries e outros pontos muito específicos, e muito trabalho de bastidores que segue um roadmap bem estabelecido. Claro que posso ser acusado de criar "boatos" simplesmente para promover o trabalho do desenvolvimento, mas se segue os meus artigos deverá concordar que tal não é o meu hábito. Algumas das coisas em que estou a pensar quando refiro o trabalho de bastidores foram referidas na lista de email do IIUG recentemente, no seguimento de um artigo de outro blog, portanto nem sequer sou o primeiro  a deixar passar alguma informação mais restrita. Seguramente no futuro ser-me-á possível escrever algo do tipo "lembram-se quando mencionei algum trabalho de bastidores? Referia-me a isto, isto e isto..." e depois poderá pegar na "velha" versão 11.70.xC5 e testar alguns truques :)

Tuesday, May 08, 2012

Informix Warehouse Accelerator: News / Novidades

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

English Version
This is just a very short note to mention a blog post from Martin Muerderer on his excellent blog dedicated to Informix Warehouse Accelerator. He warns us that recent Linux versions (with libstdc++ 4.6) will cause problems for IWA. At startup (ondwa start) the user will get errors like

An assertion 'str.tellg() > 0' failed. Additional info: Invalid size definition '0' encountered for parameter SEND_QUEUE_SIZE

Some workarounds would work and we would be able to start it, but after that further problems will probably arise. I hit this sometime ago while making some home testing and just recently the issue was discussed in the IIUG mailing list

Currently the only solution is to use a supported OS version. But IBM already is aware of this so it should be solved in future fixpacks. The cause seems to be a change in the tellg() method, but I don't have more details.

Additionaly, on another post, Martin tells us about a new video and a new ebook about Informix Warehouse Accelerator.

Versão Portuguesa
Esta pequena nota serve apenas para dar conta de um artigo no excelente blog do Martin Fuereder sobre o Informix Warehouse Accelerator. O Martin avisa-nos que as versões mais recentes de Linux (com a versão 4.6 da libstdc++) causam problemas no IWA. No arranque (ondwa start) o utilizador verá erros como:

An assertion 'str.tellg() > 0' failed. Additional info: Invalid size definition '0' encountered for parameter SEND_QUEUE_SIZE

Embora haja forma de contornar o problema e permitir o arranque, é expectável que surgissem outros problemas durante a utilização. Eu tive este problema enquanto fazia alguns testes caseiros e isto foi discutido recentemente na lista de mail do IIUG.

De momento a única solução é usar um SO suportado. Mas a IBM já tem conhecimento do problema e deverá ser resolvido em fixpacks futuros. A causa para isto parece ser uma mudança no método tellg() mas não possúo mais detalhes.

Para além disto, o Martin informa-nos noutro artigo que existe um novo vídeo e um novo ebook sobre o Informix Warehouse Accelerator

Saturday, May 05, 2012

In memory DBMS / DBMS em memória

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

English Version:

If you've been paying attention lately to the DBMS market you may have noticed that a lot of new things are hapening around in-memory and column stores databases. A set of papers are available from the IEEE Data Engineering Bulletin here:
There are articles about several current offers and yes, Informix Warehouse Accelerator is one of them. It's interesting to see that there is academic activity behind several products being release now. And as we would wish and expect Informix is among them. It's also interesting that although there are many differences between the products there are many similar or common roots. I believe this may be much more than a simple marketing wave. I think this new (not so new, really) technology is here to stay.

Versão Portuguesa:

Se tem prestado atenção ao mercado de DBMS terá notado que estão a acontecer muitas coisas em torno das bases de dados em memória e baseadas em colunas. Um conjunto de artigos do IEEE Data Engineering Bulleten está disponível em:
Existem artigos sobre várias ofertas, e sim, o Informix Warehouse Accelerator é um deles. É interessante ver que existe atividade académica por detrás de vários produtos que estão a ser lançados agora. É também interessante que apesar de haver muitas diferenças entre estes produtos, existem também muitas raízes similares. Acredito que isto pode ser muito mais que apenas uma onda de marketing. Penso que esta nova (não tanto assim) tecnologia veio mesmo para ficar

Tuesday, May 01, 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