Você está aquiLeitor de feeds
Leitor de feeds
System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix
AJMoreti - qua, 09/05/2012 - 09:28
Arquivo de configuração
O arquivo de configuração: Unix/Linux
Os parâmetros de configuração do servidor são armazenadas em um arquivo localizado no diretório $INFORMIXDIR/etc.
Especifique o nome do arquivo, definindo a variável de ambiente ONCONFIG. Não especifique o caminho completo, somente o nome do arquivo.
Se a variável de ambiente ONCONFIG não está definido, o nome de arquivo padrão ONCONFIG é usado.
Exemplo:
export ONCONFIG=onconfig.prd
O arquivo de configuração contém muitos parâmetros diferentes que permitem que você configure seu servidor para as suas necessidades específicas. Alguns parâmetros são definidos no momento em que você configura o servidor pela primeira vez e, uma vez que o servidor foi inicializado pela primeira vez, alguns parâmetros não podem ser alterados. A maioria dos parâmetros , no entanto, podem ser modificados após a inicialização do servidor.
Abaixo os seguintes parâmetros no arquivo de configuração deve ser configurado antes de um servidor ser inicializado porque o root dbspace contém as páginas reservadas, informações sobre todos os bancos de dados no servidor e bancos de dados que armazena suas atividades.
- Root dbspace
- Mensagens
- Informações do Servidor
Cada servidor deve ter um rootdbspace. Inicialmente, o root dbspace também contem o phyical e logical logs. No entanto, eles devem ser movidos mais tarde para outros dbspaces.
ROOTNAME rootdbs #Root dbspace nameROOTPATH /dev/online_root # Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device (kilobytes)
ROOTSIZE 300000 # Size of root dbspace (kilobytes)Esses parametros somente podem ser modificados antes de inicializar o servidor pela primeira vez. Não podem ser modificados os espaços alocados para o root dbspace durante a inicialização do servidor.
MensagemConfigurando o caminho das mensagens:
MSGPATH /var/log/idslog/online.log # System message log file path
CONSOLE /dev/console # System console message path
O servidor IDS prove dois destinos diferentes para as mensagens:
- MSGPATH: este parametro indica o caminho e o nome do arquivo onde todas as mensagens serão gravadas. Este arquivo é criado quando o servidor é inicializado pela primeira vez, se ele não existir.
- CONSOLE: este é o caminho onde é especificado onde o servidor ira monstrar as mensagens de console. Uma mensagem de console é muito importante para o administrador do servidor onde o banco de dados reside. Por exemplo, backup e restore requer uma troca de fita, essas mensagens são enviadas para a CONSOLE. Por padrão, este parametro é configurado com o dispositivo de conssole do servidor, porem pode ser configurado para enviar as mesagens para um arquivo.
Informação do SERVER
Configurando informação de um servidor especifico:
SERVERNUM #Unique id corresponding to an IDS serverDBSERVERNAME #Name of default database server name
DBSERVERALIASES #Names of additional database server names
Esses parâmetros devem ser definidos para que o servidor possa ser identificado exclusivamente no computador.
Informação dos Logs
LOGBUFF #Size in kilobytes for the three logical-log buffers in shared memory
LOGFILES #Number of logical-log files
LOGSIZE #Size of logical-log files
PHYSBUFF #Amount of shared memory reserved for the buffers
PHYSFILE #Size of the initial physical log
PHYSDBS #Name of the dbspace in which the physical log resides
Logical Logs
Os arquivos de Logical Logs são coleções de paginas contíguas no disco que são usados para armazenar os registros de transações para o servidor. Esses registros de transações são usados para explorar todas as alterações feitas na base de dados que foram criados em modo logging. Todos os bancos de dados compartilham do mesmo conjunto de arquivos de Logical Logs. Cada servidor deve ter no minimo três arquivos de Logical Logs.
Adicionando arquivos de Logical Logs manualmente:
Você pode adicionar arquivos de Logical Logs manualmente pelos seguintes motivos:
- Para aumentar o espaço alocado em disco para os Logical Logs
- Para alterar o tamanho dos arquivos de Logical Logs
- Para completar uma transação aberta
- Para mover arquivos de Logical Logs para uma dbspace diferente
As duas maneiras que você pode adicionar um arquivo de log lógico são:
- Para adicionar arquivos no final da lista usando o comando onparams –a
- Após o arquivo de Logical Log atual usando o comando onparams –a –i
O seguinte comando adiciona um arquivo de Logical Log até o fim da lista de arquivos de logs no dbspace dbslog, usando o tamanho de arquivo de log especificado pelo parametros de configuração LOGSIZE:
onparams -a –d dbslogO seguinte comando adiciona arquivos de Logical Log de 1000KB após o arquivo de log atual no dbspace dbslog:
onparams -a -d logspace -s 1000 -iPara adicionar um arquivo de Logical Log com um novo tamanho (nesse caso, 250KB), execute o comando abaixo:
onparams -a -d logspace -s 250Você pode dropar um arquivo de Logical Log usando o seguinte comando:
onparams -d -l lognum -yVocê pode mover os arquivos de Logical Logs para:
- Eliminar arquivos de Logical Logs do dbspace corrente
- Adicionar arquivos de Logical Logs para uma nova dbspace
Estratégia para estimar o tamanho e os números de Logical Logs
É mais fácil de gerenciar arquivos de Logical Logs grandes do que muitos arquivos de Logical Logs pequenos. Se os arquivos de Logical Logs não são suficientes, frequentemente checkpoints serão disparados, isso impacta diretamente na performance. Para aplicações que geram uma pequena quantidade de dados de log, começe com 10 arquivos de logs com o tamanho de 100MB. Se um grande número de objetos em uma blobspace são alterados frequentemente, você necessitara de backups frequentes para liberar espaçoss na blobspace.
A expressão a seguir fornece um exemplo de como calcular a configuração de espaço total para os logs, em kilobytes:
LOGSIZE = (((connections * maxrows) * rowsize) / 1024) / LOGFILESA politica de Objetivo de Tempo de Recuperação (RTO – Recovery Time Objective) determina a tolerância de perda de dados em caso de uma falha do servidor. Se esta politica é necessária,
- Utilize backups automaticos de logs sempre que um arquivo de log encher
- Utilize o agendador para criar tarefas que faça backup automatico de logs em determinados intervalos de tempo
- Se o espaço de log ficar cheio antes dos logs serem bacapeados, adicione novos arquivos de logs para permitir a continuidade do processamento das transações
- Utilize o agendador para adicionar tarefas para detectar a situação acima e adicionar logs automaticamente
Physical Log
O servidor tem um log especial que é utilizado para fins de recuperação automática. Esses registros são chamados de Physical Log. O physical log é uma coleção de paginas contiguas no disco.
Quando uma página é lida em um buffer de memória compartilhada e modificada por um usuário, uma copia dessa pagina em sua condição original é gravada dentro do physical log. Essa copia de paginas é conhecida como “before image” (copia da pagina antes de sua alteração). Apenas a primeira mudança da pagina em um buffer causa a gravação do before image no pysical log. Quaisquer alterações posteriores na mesma página não gravará novo before image para serem salvas no physical log. Estas imagens são utilizados por um mecanismo automático de recuperação.
Você pode mover a localização e o tamanho do physical log usando o comando onparams.
A seguir o comando move o physical log para o dbspace dbsphyslog e redimenciona para 3000KB:
onparams -p -d dbspace1 -s 3000Estimando o tamanho do Physical Log
O parametro de configuração PHYSFILE especifica o tamanho do physical log. O tamanho do physical log depende de:
- Da taxa de atividades gerada pelas transações do physical log
- Da utilização do parametro de configuração RTO_SERVER_RESTART para especificar um valor de tempo de recuperação
Checkpoints são acionados quando 75% do physical log esta cheio e o processamento precisa completar antes que o log fique cheio, para que o servidor de banco de dados não bloqueie todas as transações. A fim de evitar que as transações sejam bloqueadas, verifique se o servidor de banco de dados tem espaço suficiente de physical log para conter todas as atividades de transações durante o processamento do checkpoint.
Se você especificar um valor para o parâmetro de configuração RTO_SERVER_RESTART, o servidor monitora a carga de trabalho e acionamentos de checkpoints para atender a politica RTO. Isso gera algumas atividades de Physical Log. Os registros extras é usado para auxiliar o bufferpool durante o fast recovery de modo que a repetição seja executada de forma otimizada. Se o physical log é considerado grande em relação ao tamanho combinado de todos os buffer pools, paginas descarregadas e paginas com falhas que ocorrem durante um fast recovery. Paginas descarregadas e paginas com falhas reduz substancialmente a performance do fast recovery, e o servidor de banco de dados não pode manter a politica RTO.
Para sistemas com espaço de buffer pool menor que 4GB, o physical log pode ser redimensionado para 110% combinado com todos os buffer pools. Para sistemas com um buffer pool maiores que 4GB monitorar as atividade de checkpoint. Se ocorrer checkpoints com muita frequencia e parecem afetar o desempenho, acrescente mais physical log.
Você pode usar o comando onstat –g ckp para visualizar as configurações recomendadas.
You can use the onstat -g ckp command to display configuration recommendations.
Novos parametros do ONCONFIG na versão 11
Parametros de Configuração
Descrição
RTO_SERVER_RESTART
Permite a utilização RTO (Recovery Time Objective) padrões para definir a quantidade de tempo, em segundos, para que o Dynamic Server terá que se recuperar de um problema depois que você reiniciar o DS e colocar o servidor em modo online ou quiescente.
RAS_PLOG_SPEED
A taxa à qual o physical log pode ser recuperado durante um fast recovery.
RAS_LLOG_SPEED
A taxa à qual o logical log pode ser recuperado durante um fast recovery. Não configuravel. IDS atualiza esses valores para refletir a velocidade de recuperação real. ( As unidades são paginas por segundos).
AUTO_CKPTS
Ativa ou desativa checkpoints automaticos.
AUTO_LRU_TUNING
Ativa ou desativa o ajuste automático de LRU
AUTO_AIOVPS
Ativa ou desativa a capacidade do servidor de banco de dados para aumentar o número de AIO VPs automaticamente e descarrega threads quando o servidor detectar que AIO VPs não estão acompanhando a carga de trabalho.
SQLTRACE
Controla o comportamento padrão, como o numero de instruções SQL para rastrear e o modo de rastreamento do recurso de consulta drill-down.
EXPLAIN_STAT
Ativa ou desativa a inclusão de uma seção de estatísticas de querys no arquivo explain.out que a declaração SET EXPLAIN gerou ou o comando onmode –Y session_id pode mostrar.
USELASTCOMMITTED
Especifica se o servidor de banco de dados usa a ultima dos dados comitados quando ocorre um bloqueio.
SHMVIRT_ALLOCSEG
Especifica um limite no qual o IDS deve alocar a memória do servidor e do nivel de alarme ativado se o servidor não poder alocar o novo segmento de memória.
ENCRYPT_HDR
Ativa ou desativa a criptografia entre os servidores HDR pareados.
LOG_INDEX_BUILDS
Define para 1 (um) para habilitar o log das paginas de indice durante a instrução CREATE INDEX. Obrigatorio no nó primario ao utilizar nós Secundario (RSS).
ENCRYPT_SMX
0. Não utiliza criptografia em conexão SMX
1. Negocia a criptografia em conexão SMX
2. Deve-se utilizar criptografia em conexão SMX
Categorias: Blogs em Português
Informix Warehouse Accelerator: News / Novidades
Informix-Techonology - ter, 08/05/2012 - 12:00
This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português
English VersionThis 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 PortuguesaEsta 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
Categorias: Blogs em Português
Informix IWA (DBMS em memória) no IEEE Data Engineering Bulletin
InformixBR - seg, 07/05/2012 - 16:56
Tem sido constante no mercado de DBMS notas falando à respeito das bases de dados em memória e baseadas em colunas(columnar-database).
Um conjunto de artigos do respeitado IEEE Data Engineering Bulleten está disponível aqui.
Existem artigos sobre vários players de mercado, e sim, o Informix Warehouse Accelerator (Business Analytics in (a) Blink. 9-14) é um deles. É interessante ver que existe atividade acadêmica por detrás de vários produtos que serão 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 (nem tanto assim) tecnologia veio mesmo para ficar.
Maiores detalhes sobre o IWA acesse aqui.
* esta nota foi baseada na publicação do nosso colega fnunes.
InformixBR
Categorias: Blogs em Português
In memory DBMS / DBMS em memória
Informix-Techonology - sab, 05/05/2012 - 10:44
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: http://www.informatik.uni-trier.de/~ley/db/journals/debu/debu35.html#BarberBCDHHIKKLLLMMMPQRSSS12
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: http://www.informatik.uni-trier.de/~ley/db/journals/debu/debu35.html#BarberBCDHHIKKLLLMMMPQRSSS12
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
Categorias: Blogs em Português
Comparativo: Oracle X Informix X DB2
InformixBR - qua, 02/05/2012 - 14:50
Comparativo: Oracle x Informix x DB2
estou disponibilizando aqui acesso a uma publicação isenta(non-IBM/Oracle) sobre comparativo de funcionalidades, empacotamento e comercialização dos Bancos de Dados Oracle, Informix e DB2.Vale a pena dar uma conferida!!! Acesse aqui.
InformixBR
Categorias: Blogs em Português
IIUG 2012 - Como foi o evento...
InformixBR - qua, 02/05/2012 - 13:37
bom ..... com o um pequeno delay aqui vão algumas informações interessantes e importantes sobre o IIUG deste ano.
O evento este ano contou com um numero ainda maior de participantes do que nos outros anos, destacando-se a quantidade de clientes, seguido dos parceiros.
As sessões foram em numero maior do que o ano passado, tendo também conteúdos voltado mais para negócios e ainda soluções complementares ao Banco de Dados tais como Optim e Guardium.Contamos ainda com uma apresentação bastante interessante que tratava de BIG DATA, um conceito moderno que a IBM vem liderando o desenvolvimento desta tecnologia com soluções robustas e completas para tratar realmente grannnnnnnndes volumes de dados. O mais interessante ainda foi ver como o Informix está inserido neste contexto.
No mais realmente foi mais um evento bastante proveitoso e diferenciado, como de costume!
Para finalizar, a imagem do inicio da festa na piscina preparada pelo evento :)
InformixBR
Categorias: Blogs em Português
NEW! Best practices and technical papers to help customers learn about and use DB2 V10 features
Information X - qua, 02/05/2012 - 10:47
Pessoal,
a equipe da IBM do Canadá nos enviou uma série de novos documentos para compartilhar com os clientes sobre as features do DB2 10:
Best practices: Storage optimization with deep compression (Authors: Thomas Fanghaenel and Bill Minor)
http://www.ibm.com/developerworks/data/bestpractices/deepcompression/index.html
Best practices: A practical guide to implementing row and column access control (Author: Walid Rjaibi)
http://www.ibm.com/developerworks/data/bestpractices/rcac/index.html
Best Practices: Temporal data management with DB2 (Author: Matthias Nicola)
http://www.ibm.com/developerworks/data/bestpractices/temporal/index.html
DB2 V10.1 Multi-temperature data management recommendations (Authors: Jim Seeger, Karen McCulloch, Naresh Chainani, Kiran Chinta, Aruna De Silva, Vincent Kulandai Samy, and Tom Hart)
http://www.ibm.com/developerworks/data/library/long/dm-1205multitemp/index.html
DB2 V10.1 Query performance enhancements (Author: David Sky)
http://www.ibm.com/developerworks/data/library/long/dm-1205db210performance/index.html
Boa leitura!
FFO
Categorias: Blogs em Português
Benchmarks: Some thoughts / Alguns pensamentos
Informix-Techonology - seg, 30/04/2012 - 22:04
This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português
English version:
Disclaimer
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 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
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:
- A 2008 blog entry from Charles Levine from SQL Server performance team:
http://blogs.msdn.com/b/sqlperf/archive/2008/10/23/tpc-e-raising-the-bar-in-oltp-performance.aspx - A 2008 blog entry from Glenn Paulley from Sybase:
http://iablog.sybase.com/paulley/2008/10/the-state-of-tpc-e/ - A 2008 blog entry from Brian Moran mentioned in the previous post from Sybase Engineer:
http://www.sqlmag.com/article/benchmarks/microsoft-still-the-only-database-vendor-posting-tpc-e-scores
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 TPC.org 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:
- 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:
- Informix gets a better number, and the competition and analysts would crush us (IBM and DB2)
- Informix gets a worse number, and the competition and analysts would crush us (IBM and Informix)
- 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.
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 TPC.org 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)
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: http://www.youtube.com/watch?v=ScDyRrsI3H4&feature=share
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 TPC.org. 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 2.4.1.5 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.
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
Benchmark de OLTP - TPC-D
Benchmark de Datawarehouse (descontinuado) - TPC-H
Benchmark de Datawarehouse (actual) - TPC-DS
Benchmark de suporte à decisão (novo) - TPC-E
Benchmark de OLTP criado para substituir o TPC-C
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
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:
- Um artigo de 2008 de Charles Levine da equipa de performance do SQL Server:
http://blogs.msdn.com/b/sqlperf/archive/2008/10/23/tpc-e-raising-the-bar-in-oltp-performance.aspx - Um artigo de 2008 de Glenn Paulley da Sybase:
http://iablog.sybase.com/paulley/2008/10/the-state-of-tpc-e/ - Um artigo de 2008 de Brian Moran mencionado no artigo anterior do engenheiro da Sybase:
http://www.sqlmag.com/article/benchmarks/microsoft-still-the-only-database-vendor-posting-tpc-e-scores
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 TPC.org?". 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:
- 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:
- O Informix obtém números melhores e a concorrência e os analistas cairiam em cima da IBM (e do DB2)
- O Informix obtém números piores e a concorrência e os analistas cairiam em cima da IBM (e do Informix)
- 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
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 TPC.org, 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)
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: http://www.youtube.com/watch?v=ScDyRrsI3H4&feature=share
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 TPC.org.
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 2.4.1.5 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
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
Categorias: Blogs em Português
Best practices survey / Inquérito sobre boas práticas
Informix-Techonology - sex, 27/04/2012 - 21:23
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: https://www.ibm.com/survey/oid/wsb.dll/s/ag460 and the original announcement here: https://www.ibm.com/developerworks/mydeveloperworks/blogs/idsdoc/entry/informix_best_practices44?lang=en_us
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: https://www.ibm.com/survey/oid/wsb.dll/s/ag460 e o anúncio original está em:: https://www.ibm.com/developerworks/mydeveloperworks/blogs/idsdoc/entry/informix_best_practices44?lang=en_us
Categorias: Blogs em Português
IIUG 2012: Presentations / Apresentações
Informix-Techonology - qui, 26/04/2012 - 21:39
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.
Categorias: Blogs em Português
Script para AFs (Assert Faileds)
IMartins - qui, 26/04/2012 - 08:05
Quando ocorre algo muito grave no banco de dados é gerado um arquivo de "dump" chamado Assert Failed (AF), que faz uma foto da situação do banco no momento que ocorreu o problema.
Este AF pode ser gerado de modo forçado também (veja aqui como).
Categorias: Blogs em Português
System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix
AJMoreti - qua, 25/04/2012 - 15:31
Configurando a Conectividade
Existem três metodos disponiveis para a configuração da conectividade entre client-server e o sistema on-line:
- Através de uma conexão de memória compartilhada. Quando a aplicação cliente o e servidor de banco de dados estão no mesmo computador, este é o método preferido de comunicação. Aplicação e o servidor de banco de dados trabalha no mesmo segmento de memória compartilhada.
- Através de uma conexão TCP/IP, usando SOCKETS ou uma interface de programação TLI. TCP/IP pode ser usado em ambas comunicações,locais e remoto.
- Através de uma conexão “stram pipe”. Isso é uma conexão local, metodo de comunicacao que o UNIX utiliza.
Quando um aplicativo tenta uma conexão com um servidor de banco de dados, há algumas informações basicas que necessitam ser configuradas para fazer a conexão. Essas informações estão armazenadas em $INFORMIXDIR/etc/sqlhosts, um arquivo que deve ficar no diretorio $INFORMIXDIR/etc. Para alterar o local do arquivo slqhosts, utilize a variavel de ambiente INFORMIXSQLHOSTS. Cada servidor que hospeda um banco de dados ou um cliente deve ter um arquivo sqlhosts.
Cada entrada (cada linha) do arquivo sqlhosts contem as informações para um banco de dados. Utilize espaços em brancos (espaços, tabulação ou ambos) para separar os campos. Não inclua espaços em branco ou tabulação dentro de um campo. Para colocar comentarios no arquivo sqlhosts, inicie a linha com um caracter (#). Você também pode deixar linhas totalmente me branco para facilitar a leitura. Regras de sintaxe adicionais para cada um dos campos serão fornecidos nas postagens seguintes, que descrevem as entradas no arquivo sqlhosts. Use um editor de texto padrão para inserir as informações no arquivo sqlhots.
Exemplo de um arquivo sqlhosts dbservername nettype hostname servicename tst onipcshm isis tst tstsoc onsoctcp isis tstsrv prdsoc onsoctcp vishnu prdsrvdbserver corresponde à variavel de ambiente INFORMIXSERVER e DBSERVERNAME ou DBSERVERALIASES no arquivo ONCONFIG.
A coluna nettype contém informações cruciais sobre tipo de servidor de banco de dados e como as conexões vão ser feitas. O nettype consiste em oito letras dividas em três categorias.
As duas primeiras letras representam o produto do banco de dados. As proximas três letras referem-se a interface de programação usado para a conexão. As três ultimas letras referem-se ao protocolo especifico ou mecanismo IPC.
onde:
d = produto,
i = interface,
p = protocolo
ddiiippp
on – Dynamic Server
se – Standard Engine
ipc – Conexão IPC
tli – Conexão TLI
soc – Conexão socket
shm – Shared memory
str – Stream pipes
tcp – Protocolo TCP/IP
spx – Protocolo IPX/SPX
Hostname é o nome do servidor que esta armazenado o banco de dados.
Todos os nomes de serviços é necessario estar no /etc/services.
Exemplo de um arquivo /etc/services
tstsrv 1550/tcp prdsrv 1540/tcpCategorias: Blogs em Português
Re: onstat -g ses (DUVIDA)
Forum Informix em Português do IIUG - qua, 25/04/2012 - 11:26
Obrigado pela resposta e pelo script Cesar Inacio Martins; Cesar o seu site pra mim é uma referencia em informix, obrigado por compartilhar o seu conhecimento nele, o seu site me ajudou em muito a entender o informix. ******************************************************************************* To post a response via email (IIUG members only): 1. Address it to iiug-por@iiug.org 2. Include the bracketed message number in the subject line: [208] *******************************************************************************
Categorias: Forums de Informix em Português
Re: onstat -g ses (DUVIDA)
Forum Informix em Português do IIUG - qua, 25/04/2012 - 11:01
É em bytes. meios de monitora-lo: onstat -g ses | sort -nk7 onsstat -g ses | awk 'NF == 9 && $7 ~/[0-9]+/{x=x+$7} END {printf "total: %10.2f MB\n",x/1024/1024}' On 25/4/2012 10:46, LONDONMS LONDONMS wrote: > Procurei na documentação e não consegui encontrar algo que tire esta minha > duvida, o comando ONSTAT -G SES tem dois parametro lá chamados TOTAL MEMORY e > USED MEMORY - a minha duvida é o valor que esta lá é em Kb, Mb ou Gb ? > > Na documentação fala assim; > > total memory - The amount of memory allocated for this session > used memory - The amount of memory actually used by this session > > Londonms > São Paulo/SP > > > > > ******************************************************************************* To post a response via email (IIUG members only): 1. Address it to iiug-por@iiug.org 2. Include the bracketed message number in the subject line: [207] *******************************************************************************
Categorias: Forums de Informix em Português
onstat -g ses (DUVIDA)
Forum Informix em Português do IIUG - qua, 25/04/2012 - 10:46
Procurei na documentação e não consegui encontrar algo que tire esta minha duvida, o comando ONSTAT -G SES tem dois parametro lá chamados TOTAL MEMORY e USED MEMORY - a minha duvida é o valor que esta lá é em Kb, Mb ou Gb ? Na documentação fala assim; total memory - The amount of memory allocated for this session used memory - The amount of memory actually used by this session Londonms São Paulo/SP ******************************************************************************* To post a response via email (IIUG members only): 1. Address it to iiug-por@iiug.org 2. Include the bracketed message number in the subject line: [206] *******************************************************************************
Categorias: Forums de Informix em Português
Planejamento para um cluster de alta disponibilidade em Informix
AJMoreti - ter, 24/04/2012 - 14:27
Antes de você iniciar a configuração dos servidores e banco de dados para usar com um cluster de alta disponibilidade, você pode querer fazer um planejamento inicial. A lista a seguir contem as tarefas a realizar:
- Escolher e adquirir hardware apropriados;
- Se você estiver usando mais de um servidor de banco de dados para armazenar dados que você deseja replicar, migrar dados e redistribuir, veja se existe a possibilidade de ser gerenciado por um unico servidor de dados.
- Assegurar que todos os banco de dados que você deseja replicar esteja em modo “transaction loggin”.
- Desenvolver aplicativos para fazer uso de ambos os servidores de banco de dados de replicação.
- Criar uma programação para iniciar o HDR pela primeira vez.
- Projetar um espaço de armazenamento e programação dos backups de logical logs para o servidor de banco de dados primario.
- Produzir um plano de como lidar com falhas de um servidor de banco de dados e como reiniciar o HDR após uma falha.
Para configurar seu sistema como um cluster de alta disponibilidade, você deve tomar as seguintes ações:
- Conheça os requisitos de hardware e sistema operacional;
- Atender aos requisitos dos dados de banco de dados;
- Atender aos requisitos de configuração do banco de dados;
- Configurar a conectividade.
Vamos explanar cada item acima.
Você pode configurar seu sistema para usar o Secure Sockets Layer (SSL), um protocolo de comunicação que garante a privacidade e integridade dos dados transmitidos através da rede, para a comunicação do HDR. Você pode usar o protocolo SSL para conexões entre os servidor primario e secundario e para conexões com servidores secundarios Remote Standalone(RS) e Shared Disk(SD) em uma configuração de alta disponibilidade.
Requisitos de Hardware e Sistema OperacionalPara um cluster de alta disponibilidade funcionar, o hardware deve atender a certos requisitos.
O hardware deve atender aos seguintes requisitos:
- Os servidores primario e secundario deve ser capaz de executar a mesma imagem do IBM Informix, mesmo que eles não tenham Hardware e Sistemas Operacionais identicos. Por exemplo, você pode usar servidores com diferentes Sistemas Operacionais Linux 32-bit porque nesses Sistemas Operacionais a imagem do Informix poderá ser executada. Nesta situação, você não pode adicionar um Servidor com Sistema Operacional Linux 64-bit porque nesse Sistema Operacional é exigida uma outra imagem do Informix, (Informix 64-bit). Verifique o arquivo “machine notes”: você poderá utilizar alguma combinação de hardware e Sistemas Operacionais suportados no mesmo arquivo “machine notes”.
- Os Hardwares que executa os servidores primario e secundario devem suportar conectividade com redes.
- A quantidade de espaço em disco alocado para os dbspaces secundario devem ser identicos ao servidor primario. O tipo de espaço em disco é irrelevante; você pode usar uma mistura de raw devices com cooked files nos dois servidores.
- Os chunks nos dois servidores devem estar no mesmo caminho. Os links simbólicos são permitidos em plataformas UNIXs, mas não na plataforma Windows.
Os dados e banco de dados deve atender aos seguintes requisitos:
- Todos os dados devem ser “logged”.
Todos os banco de dados que você quer replicar deve estar em modo “transaction logging”.
Este requisito é importante porque o servidor de banco de dados secundario utiliza os registros de logical logs do servidor primario para se auto atualizar. Se o banco de dados primario não utiliza o logical logs, não será capaz de gerar os logical logs para atualizar os outros servidores. Os registros podem ser “buffered” ou “unbuffered”. - Os dados deve estar localizado no mesmo dbspace ou sbspaces
Se o servidor primario tem “simple large objects” armazenados em blobspaces, modificações nos dados dentro dessa blobspace não são replicados como parte do processamento normal do HDR. No entanto, dados “simple large objects” são replicados.
”Smart large objects”, que são armazenados em sbspaces, são replicados. O sbspace deve estar em “logged”. “User-defined types” (UDTs) são replicados, a menos que eles estejam armazenados no Sistma Operacional. - Os servidores secundarios não deve usar compressão de disco.
Se você utilizar o recurso de compressão de disco do Informix, dados que é comprimido na tabela de origem é comprimido na tabela de destino. Você não pode executar operações de compactação em um servidor HDR secundario., RS secundario ou SD secundario, porque o servidor HDR de destino deve ter os mesmos dados e layout físico com o servidor de origem.
Para os servidores de alta disponibilidade do cluster funcionar, você deve configurar completamente cada um dos servidores de banco de dados.
Estes tópicos descrevem as considerações de configuração para os pares de cluster de servidor de banco de dados:
- Versão do servidor de banco de dados
- Configuração do dbspace e chunk
- Tamanhos de paginas em ambientes HDR
- Espelhamento
- Configuração do Physical-log
- Dbspace e dispositivos de backup para logical-log
- Configuração dos Logical-logs
- Configuração dos parametros do HDR
A versão do servidor de banco de dados no servidor primario e secundario deve ser identicas.
Configuração do dbspace e chunkO numero de dbspaces, o numero de chunks, os seus tamanhos, os nomes de caminhos, e seus offsets devem ser identicos nos servidores, primario e secundarios. Além disso, a configuração deve conter pelo menos um dbspace temporário se o HDR secundario for usado para gerar atividades de relatorios.
somente UNIX:
Você deve usar links simbolicos para os chunks criados em raw devices.
Importante: Se você não usar links simbolicos para os nomes do caminho dos chunks, você não poderá mudar o nome do caminho de um chunk facilmente.
Os seguintes parâmetros do ONCONFIG devem ter o mesmo valor em cada um dos servidores HDR:
- ROOTNAME
- ROOTOFFSET
- ROOTPATH
- ROOTSIZE
O tamanho de paginas de um dbspace, e e as especificações do buffer pool são propagadas automaticamente do servidor primario para o servidor secundario. Embora o servidor primario e os secundarios devem ter os mesmos buffer pools, os números de buffers em buffer bool não são obrigatórios.
EspelhamentoVocê não é obrigado a definir o parametro MIRROR para o mesmo valor nos dois servidores de banco de dados; você pode habilitar o espelhamento em um servidor de banco de dados e desabilitar no outro servidor. Entretanto, se você especificar um chunk espelhado para o rootdbs do servidor primario, você tera que especificar um chunk espelhado também para o servidor secundario. Portanto, os seguintes parametros do ONCONFIG deve ser definido para o mesmo valor em ambos os servidores de banco de dados:
- MIRROROFFSET
- MIRRORPATH
O physical log deve ser identico em ambos os servidores. A seguir os parametros do ONCONFIG que devem ser os mesmos valores em cada servidor:
- PHYSBUFF
- PHYSFILE
Você pode especificar diferentes dispositivos de fitas para os servidores primario e secundario.
Se você usa o ON-Bar, configure os parametros de configuração do ON-Bar com os mesmos valores em ambos os servidores.
Se você utiliza o ontape, o tamanho do dispositivo e o bloco do dispositivo para o dispositivo de armazenamento e logical-log devem ser identicos. A seguir os parametros do ONCONFIG que devem ter os mesmos valores em ambos os servidores:
- LTAPEBLK
- LTAPESIZE
- TAPEBLK
- TAPESIZE
Todos os registros de logical-logs são replicados para o servidor secundario. Você deve configurar os numeros de arquivos de logical-log e o tamanho dos logical-log com valores iguais em ambos os servidores. Abaixo segue parametros do ONCONFIG que devem ter os mesmos valores:
- LOGBUFF
- LOGFILES
- LOGSIZE
- DYNAMIC_LOGS
A seguir os parametros de configuração do HDR que devem conter o mesmo valor em ambos os servidores:
- DRAUTO
- DRINTERVAL
- DRTIMEOUT
Categorias: Blogs em Português
System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix
AJMoreti - seg, 23/04/2012 - 09:11
Gerenciando espaço em disco
O servidor de banco de dados utiliza as seguintes físicas para gerenciar disco:
- Chunk
- Page
- Extent
- Blobpage
- Sbpage
Chunk
Chunk é uma unidade de disco ou um espaço físico atribuído para o servidor. Um chunk pode ser um raw device (device de character especial) ou arquivo UNIX (cooked file). Quando atribuir chunk para o server, você precisa especificar os três valores seguintes:
- Pathname: o caminho do arquivo ou o nome do raw device a ser utilizado para o chunk.
- Offset: a distância física, especificado em KB a partir do início do dispositivo onde a leitura e escrita do dispositivo começa. Se você criar chunks usando cooked files, use o offset como zero; o offset maior que zero é somente usado com raw devices.
- Size: é o tamanho do espaço criado em KB, atribuido para ser utilizado com raw device a partir do offset ou o tamanho do arquivo UNIX usado para o chunk.
O server tem um limite lógico de 32.767 chunks. No entando, o Kernel do UNIX pode ter limitações para o numero de arquivos de um processo.
Page
É a unidade basica que o server utiliza para I/O é paginas. Começando pela versão 10 do IDS, o tamanho da pagina não é mais corrigido com base na plataforma do produto. Qualquer chunk/dbspaces criado após o root dbspace pode ter tamanhos de paginas entre 2K à 16K. Usando multiplos de tamanho de paginas como padrão. Um conjunto de buffers é criado se não existir paginas do tamanho especificado.
Extent
Coleção de paginas fisicas continuas em um disco. Tamanhos das extents da tabela são especificados no momento da criação da tabela.
Blobpage
Blobpage é a unidade básica de armazenamento para os dados tipos blobs armazenados em blobspaces. O tamanho da blobpage pode ser configurado para ser múltipo do tamanho de paginas do sistema.
Sbpage
Um sbpage é um tipo de pagina que o server usa para armazenar objetos grandes (smart large objects) dentro de um sbspace. Ao contrario dos blobpages, sbpages não são configuraveis. Sbpage é do mesmo tamanho das paginas do servidor de banco de dados.
Unidades Lógicas
O servidor de banco de dados armazena as dados nas seguintes unidades lógicas:
- Dbspace
- Blobspace
- Sbspace
- Tblspace
Dbspace
Dbspace é uma coleção lógica de um ou mais chunks usados para armazenar bando de dados e tabelas. Cada dbspace deve ter pelo menos um chunk atribuido a ele.
Blobspace
Um blobspace é uma unidade lógica de armazenamento composto de um ou mais chunks que armazena somente dados TEXT e BYTE. O servidor de banco de dados gravados em blobspaces diretamente em discos. Estes dados não passam pela shared memory residente.
Sbspace
Um sbspace é um unidade lógica de armazenamento composto de um ou mais chunks que armazena os “smart large objects”, isso incluem BLOB, CLOB e UDTs (user-defined data type).
Tblspace
Tblspace é uma coleção de todos os extents alocados para armazenar informações para uma detrminada tabela ou índice em um único dbspace. Espaço representado por uma tblspace não são continuas necessáriamente, mas o espaço representado por qualquer uma das extents são continuos.
Criando dbspace com onspaces
onspaces
-c
-d <dbspace>
-k <pagesize>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
-t <tempspace>
onde
spacename é o nome da dbspace a ser criada.
pagesize é o tamanho das paginas a ser criada para o novo dbspace.
mpathname é o pathname do mirror
moffset é o offset do mirror
offset é offset dentro do dispositivo em KB.
pathname é o caminho para inicializar o chunk.
-t indica que o dbspace criado é temporario.
Exemplo: Para criar um dbspace espelhado de 1 milhão de KB chamado de dbspace1 com offset de 200.000 KB para inicializar um chunk primario e um offset de 450.000 para o chunk espelhado.
onspaces –c –d dbspace1 –p /dev/rdsk/device1 –o 200000 –s 1000000 –m /dev/rdsk/device2 450000
Criando blobspace
onspaces
-c
-b <spacename>
-g <blobpagesize>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
Exemplo: Para criar um blobspace espelhado de 1 milhão de KB chamado de blobsp1 com offset de 200.000 KB para inicializar ambos chunks (primario) e um chunk espelhado e um blobpage de 100 KB (2K tamanho da pagina do sistema).
onspaces –c –b blobsp1 –g 50 –p /dev/rdsk/device8 –o 200000 –s 1000000 –m /dev/rsdk/device9 200000
Criando um sbspace
-c
-S <spacename>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
-t
-Ms <metasize>
-Mo <metaoffset>
-Df <options>
onde
spacename é o nome do blobspace a ser criado.
blobpagesize é o tamanho do blobpage em número de páginas em disco.
mpathname é o pathname do espelhamento
moffset é o offset do mirror
pathname é o caminho do chunk.
size é o tamanho do chunk em KB.
-t indica se o dbspace criado é temporario
metasize é o tamanho da área do sbspace em KB
metaoffset é o tamanho da área do offset do sbspace em KB.
Exemplo: Para criar um sbspace espelhado de 1 milhão de KB chamado de sbspace1 com um offset de 200.000 KB para inizializar ambos chunks (primario) e um chunk espelhado , com um metadado no tamanho de 7500 KB com 10000 KB de offset e uma expectativa média de smart blobsize de 32KB.
onspaces –c –S sbspace1 –p /dev/rdsk/device5 –o 200000 –s 1000000 –m /dev/rdsk/device6 200000 –Ms 7500 –Mo 10000 –Df “AVG_LO_SIZE=32”
Eliminando Espaços
O utilitario onspaces pode ser usado para eliminar um dbspace, blobspace ou sbspace via linha de comando do sistema. Antes de um dbspace ser eliminado, todos os bancos e tabelas criados nesse dbspace deve ser eliminado.
Antes de um blobspace ser eliminado, todas as tabelas que possuem coluna TEXT/BYTE do blobspace tem que ser eliminado.
Exemplo:
onspaces –d dbspace1
Adicionando um chunk para um dbspace ou blobspace
O utilitario onspaces pode ser usado para adicionar um chunk num dbspaces ou blobspaces.
onspaces
-a <spacename>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
Exemplo: Para adicionar um chunk espelhado de 500.000 KB para o dbspace dbspace2 com 100.000 KB de offset.
onspaces –a dbspace2 –p /dev/rdsk/device4 –o 100000 –s 500000
Adicionando um chunk para um sbspace
o utilitario onspace pode ser usado para adicionar chunk para um sbspace.
Exemplo: Para adicionar um chunk espelhado de 100.000KB a um sbspace (sbspace1) com um offset de 20.000 KB para inicializar ambos chunks e metadado de 750 KB e 1000 KB de offset.
onspaces –a sbspace1 –p /dev/rdsk/chunk6 –o 20000 –s 100000 –m /dev/rdsk/chunk7 –Ms 750 –Mo 1000
SQL admin API
Você pode usar as nova função SQL de administração para funções API para realizar tarefas administrativas remotamente através do EXECUTE FUNCTION de SQL. Eles são as funções ADMIN e TASK. Estes fornecem uma interface SQL para administração como uma linha de comandos. Só podem ser chamado pelo usuário informix e são definidos no banco de dados sysadmin.
As funções ADMIN e TASK executa uma tarefa especifica o que equivale a um utilitário administrativo, insere uma nova linha dos historicos de comandos na tabela command_history do banco de dados sysadmin.
Criando um dbspace usando a função TASK()
EXECUTE FUNCTION TASK (‘create dbspace’, ‘dbs1’, ‘/dev/rdsk/device1’,’200000’,’1000000’);
Output: (expression) Space ‘dbs1’ added.
Eliminando um dbspace usando a função TASK()
EXECUTE FUNCTION TASK (‘drop dbspace’,’dbs1’);
Output (expression) Space ‘dbs1’ dropped.
** WARNING ** A level 0 archive will need to be done before any chunks from
DBspace dbs1 can be reused (see Dynamic Server Administrator’s manual).
Adicionando espelhamento para o dbspace acima usando a função TASK()
EXECUTE FUNCTION TASK (‘add mirror’, ‘dbs1’,’/dev/rdsk/device1’,’200000’,’/dev/rdsk/device2’,’450000’);
Output: (expression) Mirror chunk ‘/dev/rdsk/device2’ added to space ‘dbs1’
Criando um blobspace usando a função TASK()
EXECUTE FUNCTION TASK (‘create blobspace’, ‘blobsp1’, ‘/dev/rdsk/device8’, ‘50’,’200000’,’1000000’);
Output: (expression) Space ‘blobsp1’ added.
Categorias: Blogs em Português
OAT survey / Inquérito OAT
Informix-Techonology - qua, 18/04/2012 - 21:54
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!
Categorias: Blogs em Português
Guia do Iniciante para HDR no IDS 11.50
AJMoreti - qua, 18/04/2012 - 16:54
Conceitos e Beneficios do HDR
- HDR permite que todos os dados em uma instancia IDS seja copiada em um outro servidor em uma rede;
- É uma “instace level”, tecnologia de replicação para fornecer copias de seus dados para outros servidores Informix.
- Não tem restrições, como exigir chaves primarias em suas tabelas, etc. Exige que seus bancos de dados sejam “logged”, no entento, sua tecnologia é baseada nos registros de logs. Isso não replica dados BLOBspaces.
- Sistemas Operacionais subjacentes e versão do IDS deve ser identica nos servidores envolvidos o HDR.
- Beneficios em caso de desastres: Servidores e Dados são redundantes minimizando o downtime
- Pode-se criar um Servidor de relatorios com o servidor secundario, tendo o beneficio da performance: descarregamentos de algumas atividades, queries no servidor secundario. Melhor performance.
- Dados locais para usuarios remotos, melhor performance.
HDR antes da versão 11
- Primario: Este é o servidor que os usuários normalmente se conectam. Permite atualizações de dados, como de costume. Este é a fonte de dados copiado para o secundario.
- Secundario: Um servidor de backup somente leitura que recebe atualizações do primario.
HDR (IDS 11.50)
- Primario: Este é o servidor que os usuários normalmente se concectam. Permite atualizações de dados como de costume. Este é a fonte de dados copiado para o secundario.
Uma das melhorias mais importantes em HDR a partir da versão 11.10 é que agora você pode ter multiplos servidores secundarios, ates você estava limitado a somente um servidor secundario. Alem disso, existem diferentes tipos de servidores secundarios que lhe permite uma configuração adequada para suas necessidades empresarias. - Secundario: Servidor de backup que recebe os dados do servidor primario. Ele também permite UPDATEs usando o “redirect writes” (ex, as atualizações são realmente enviadas para o servidor primario e, em seguida recebidos através de replicação.
- Checkpoints entre o servidor Primario e o HDR secundario são sempre sincronizados.
- Commits entre o servidor Primario e o servidor secundario pode ou não ser sincronizados (depende da sua configuração).
- Servidor secundario Standalone remoto (RSS): Um novo tipo de servidor secundario foi introduzido na versão 11.10 o que é atualizado em modo assincrono e tem mais conectividade mais flexivel com o servidor primário.
- Adequado para usar como um servidor de relatorios e tambem locais distantes geograficamente e em redes de baixa velocidade, para fazer balanceamento de CPU, memoria, e tambem como um rápido e facil failover se o servidor primario falhar.
- Requer indexação em paginas de logging.
- Shared Disk Secondary (SDS): Um novo tipo de servidor secundario introduzido na versão 11.10. Tal como o nome implica, ele não tem sua própria copia separada do espaços de disco. Discos compartilhados com o servidor primario.
- Normalmente usado com arrays de discos ou SAN
HDR no IDS 11.50
- Os servidores que participam do HDR são servidores IDS regulares, colocado em um papel especifico ( primario, HDR, secundario, RSS, SDS) usando o comando onmode.
- Pode haver um servidor primario, zero ou um HDR secundario, e zero, um multiplos servidores RSS e SDS em um clauster MACH 11 ( MACH = Multi node Active Cluster for High availability)
- Servidores RSS/SDS pode ser seus unicos servidores secundarios, ou eles podem ser utilizados com um HDR secundario.
- HDR é inicialmente configurado com um backup nivel zero e um physical restore (execto para servidores SDS).
- Após a configuração inicial, os dados entre os servidores são mantidos em sincronia usando os logical logs.
- DRINTERVAL – parametro onconfig que controla se a replicação ocorre de maneira assincrona ou sincrona.
- DRINTERVAL –1 – (sincrono, ex. servidor primario aguarda por notificação vindo do servidor secundario antes de descarregar o logical-log buffer, como um commit)
- DRINTERVAL outro valor exeto –1 ( assincrono – exemplo 30 segundos)
- HDR Threads
- drprsend: (primario) envia buffers
- drsecrecv: (secundario) recebe buffers
- drprping: (primario) checa a conectividade
- drsecping: (secundario) checa a conectividade
- drsecapply: (secundario) recepção da copia do buffer para o recuperação do buffer
- logrecvr: (secundario) recuperação logica – atualização dos dbspaces
- RSS_send: usa uma comunicação full duplex ( ex. sem aguardar o recebimento de uma notificação), esse thread envia paginas de logs para um servidor RSS. (roda no servidor primario)
- RSS_recv: recebe paginas de logs vinda do servidor primario. (roda no servidor RSS)
- RSS_apply: copia o conteudo do buffer de recepção para o buffer de recuperação. (roda no RSS server)
- Atualizando o servidor secundario através do Redirected Writes
- uma das melhorias mais significantes na versão HDR 11.50
- Servidores secundarios (todos os tipos) agora permitem atualizações de dados.
- As atualizações são transferidas para o servidor primario e então propagadas de volta para o servidor secundario
- Inserts, updates e deletes para a maioria dos tipos de dados são suportados.
- Usando as novas caracteristicas de controle de versões do IDS faz escritas redirecionadas trabalhando com maior eficiencia.
- Gerencimaneto de conectividade
- Novo componente de software que gerencia os pedidos de conexões a partir das aplicações clientes.
- Permite você definir niveis de serviços (SLAs) e configuração automatica failover.
- Monitora todos os servidores dentro do clauster.
- Pode decidir sobre o servidor mais adequado para a conexão da aplicação cliente.
- Planejar um servidor HDR é obrigação
- Requisitos de negocios ( ex. planejamento de recuperação de desastre, capacidade adicional de comunicação, dados locais) conduz a configuração técnica.
- Com base nos requisitos de negocios, hardware/software disponiveis e redes disponiveis, você decidira sobre o tipo e o numero de secundários.
- Sistema Operacional e versão do Informix tem que ser identica.
- Layouts dos chunks deve ser identico ( mas espelhamentos de chunks não há necessidade)
- Banco de dados devem ser logged.
Planejamento e configuração do HDR
DRAUTO
0 (OFF) – significa não mudar automaticamente o tipo de servidor.
1 (RETAIN_TYPE) – significa mudar automaticamente do secundario para o padrao se a replicação falhar, volta para o secundario quando o HDR reinicializar.
2 (REVERSE_TYPE) – significa mudar automaticamente do secundario para o padrao numa falha, para o primario quando o HDR reinicializar.
DRIDXAUTO
0 (off) significa que não há replicação automatica de indices para o secundario caso esteja corrompido.
1 (on) significa replicação automatica dos indices para o servidor secundario se os indices estiverem corrompidos. A configuração habilitada é requerida para servidores RSS.
DRINTERVAL
Interalo maximo, em segundos, entre a descarga do buffer de replição.
Valores aceitos –1, 0 e valores positivos inteiros
Valor padrão é de 30 segundos o que significa que se pode levar até 30 segundos para que as alterações do servidores primarios seja replicado para o servidor secundario.
-1 – significa configuração sincrona.
DRLOSTFOUND
Caminho para os arquivos lost&found da replicação.
Quando a replicação assincrona é utilizada e em caso de falha, isso possibilita que algumas transações sejam comitadas no servidor primario mas não no servidor secundario. Essas transações são armazenadas em um arquivo em lost&found.
DRTIMEOUT
Periodo de tempo, em segundos, que o servidor primario aguarda para receber uma notificação vinda do servidor secundario.
Após este periodo de tempo decorrido e sem notificação de recebimento, o Informix reconhece que houve uma falha.
Default é 30 segundos.
Passo a passo:
Requisitos e planejamento são completos e seguindo um cenário tipico é selecionado:
Primeiro passo:
Assegurar que todos os servidores tem o TCP/IP necessário configurados como por exemplo /etc/hosts.
vishnu server
vishnu:~ # cat /etc/hosts
#
# hosts This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server.
# Syntax:
#
# IP-Address Full-Qualified-Hostname Short-Hostname
#
127.0.0.1 localhost
10.0.1.5 vishnu.ajmsolutions vishnu
10.0.1.9 isis.ajmsolutions isis
vishnu:~ #
isis server
isis:~ # cat /etc/hosts
#
# hosts This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server.
# Syntax:
#
# IP-Address Full-Qualified-Hostname Short-Hostname
#
127.0.0.1 localhost
10.0.1.9 isis.ajmsolutions isis
10.0.1.5 vishnu.ajmsolutions vishnu
127.0.0.2 isis.ajmsolutions isis
isis:~ #
Segundo passo:
Assegurar que todos os servidores estão em modo de confiança entre si (“trust mode”) - /etc/hosts.equiv
vishnu server
vishnu:~ # cat /etc/hosts.equiv
#
# hosts.equiv This file describes the names of the hosts which are
# to be considered "equivalent", i.e. which are to be
# trusted enough for allowing rsh(1) commands.
#
# hostname
isis
vishnu:~ #
isis server
isis:~ # cat /etc/hosts.equiv
#
# hosts.equiv This file describes the names of the hosts which are
# to be considered "equivalent", i.e. which are to be
# trusted enough for allowing rsh(1) commands.
#
# hostname
vishnu
isis:~ #
Terceiro Passo:
Verifique se o serviço do informix (ports) de cada servidor não esta bloqueado e esta sendo reconhecido em cada servidor (/etc/services)
vishnu server
vishnu:~ # cat /etc/services |egrep "prdsrv|tstsrv"
prdsrv 1540/tcp
tstsrv 1550/tcp
vishnu:~ #
isis server
isis:~ # cat /etc/services |egrep "prdsrv|tstsrv"
prdsrv 1540/tcp
tstsrv 1550/tcp
isis:~ #
Quarto Passo:
Garantir que cada servidor tem entradas dos outros servidores em seus arquivos sqlhosts do Informix. Você deve usar uma conexão TCP/IP e não conexões de memorias compartilhadas para configuração do HDR.
vishnu server
informix@vishnu:/> cat $INFORMIXDIR/etc/sqlhosts
#**************************************************************************
#
# Licensed Material - Property Of IBM
#
# "Restricted Materials of IBM"
#
# IBM Informix Dynamic Server
# (c) Copyright IBM Corporation 1996, 2004 All rights reserved.
#
# Title: sqlhosts.demo
# Description:
# Default sqlhosts file for running demos.
#
#**************************************************************************
# IANA (www.iana.org) assigned port number/service names for Informix:
# sqlexec 9088/tcp
# sqlexec-ssl 9089/tcp
prd onipcshm vishnu prd
prdsoc onsoctcp vishnu prdsrv
tstsoc onsoctcp isis tstsrv
isis server
informix@isis:~> cat $INFORMIXDIR/etc/sqlhosts
#**************************************************************************
#
# Licensed Material - Property Of IBM
#
# "Restricted Materials of IBM"
#
# IBM Informix Dynamic Server
# Copyright IBM Corporation 1996, 2009
#
# Title: sqlhosts.demo
# Description: Default sqlhosts file for running demos.
#
#**************************************************************************
# The connectivity information for each database server includes four fields
# of required information and one optional field. You can also configure
# database server groups.
#
# The format for the five fields of connectivity information for a database
# server is one line in the UNIX sqlhosts file, as follows:
#
# <dbservename> <nettype> <hostname> <servicename> <options>
#
# dbservername is the name of a database server on the network.
#
# nettype is an 8-character string specifying the protocol in this format:
#
# ddiiippp
#
# where
# dd = Database product [|ol|on|dr]
# iii = Interface type [ipc|soc|tli|sql]
# ppp = Protocol [imc|nmp|shm|spx|str|tcp|ssl|mux]
#
# hostname is the name of the computer where the database server resides.
#
# servicename is a service name entry from the services file.
#
# options in the fifth field:
#
# b=<connection buffer size>
# c=<connection redirection>
# g=<group name>
# i=<group identifier>
# e=<end of group>
# m=<multiplexed connection>
# k=<keep alive setting>
# r=<client security setting>
# s=<server security setting>
# csm=<communication support module>
#
# To create an entry for a group, put a group name in the dbservername field,
# the word group in the nettype field, a hyphen in both the hostname and the
# servicename fileds, and i=<group identifier> in the options field.
#
# For additional information on the parameters, see the IBM Informix
# Administrator's Guide.
#**************************************************************************
# IANA (www.iana.org) assigned port number/service names for Informix:
# sqlexec 9088/tcp
# sqlexec-ssl 9089/tcp
tst onipcshm isis tst
tstsoc onsoctcp isis tstsrv
prdsoc onsoctcp vishnu prdsrv
informix@isis:~>
Quinto Passo:
Assegure-se que os seguintes valores do ONCONFIG estejam identicos entre os servidores.
ROOTNAME, ROOTPATH, ROOTOFFSET, ROOTSIZE
PHYSDBS, PHYSFILE
TAPEBLK, TAPESIZE, LTAPEBLK, LTAPESIZE
LOGFILES, LOGSIZE
DRAUTO, DRINTERVAL, DRTIMEOUT
Sexto Passo:
Pegue um archive nivel 0 do servidor primario (vamos utilizar mais adiante)
Setima Passo:
Configurar o servidor primario para iniciar como um primario ligando ao servidor secundario
informix@vishnu:~/etc> onmode -d primary tstsoc
Oitavo Passo
Restaurar o archive nivel 0 como uma restauração fisica no HDR secundario.
informix@isis:~> ontape -p
Restore will use level 0 archive file /ontapeDir/archiveDir/isis_0_L0. Press Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC8GE
Archive date: Wed Apr 18 11:58:18 2012
User id: informix
Terminal id: /dev/pts/0
Archive level: 0
Tape device: /ontapeDir/archiveDir/
Tape blocksize (in k): 32
Tape size (in k): system defined for directory
Tape number in series: 1
Spaces to restore:1 [rootdbs ]
2 [dbsphyslog ]
3 [dbslog ]
4 [dbsnfe ]
5 [prd ]
6 [dbscrm ]
Archive Information
IBM Informix Dynamic Server Copyright 2001, 2010 IBM Corporation.
Initialization Time 07/17/2011 00:47:09
System Page Size 2048
Version 18
Index Page Logging OFF
Archive CheckPoint Time 04/18/2012 11:58:17
Dbspaces
number flags fchunk nchunks flags owner name
1 40001 1 1 N B informix rootdbs
2 40001 2 1 N B informix dbsphyslog
3 40001 3 1 N B informix dbslog
4 42001 4 1 N TB informix dbstmp1
5 42001 5 1 N TB informix dbstmp2
6 42001 6 1 N TB informix dbstmp3
7 40001 7 1 N B informix dbsnfe
8 40001 8 8 N B informix prd
9 40001 16 1 N B informix dbscrm
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 150000 114833 PO-B /dbroot/rootdbs
2 2 0 500053 0 PO-B /dblogs/physlog/dbsphyslog
3 3 0 1750053 0 PO-B /dblogs/logs/dbslog
4 4 0 200053 199527 PO-B /dbtmp/dbstmp.1
5 5 0 200053 199750 PO-B /dbtmp/dbstmp.2
6 6 0 200053 199644 PO-B /dbtmp/dbstmp.3
7 7 0 1500053 1145313 PO-B /dbnfe/dbsnfe
8 8 0 1500053 63 PO-B /dblogix/prd.1
9 8 0 1500003 16 PO-B /dblogix/prd.2
10 8 0 1500003 18 PO-B /dblogix/prd.3
11 8 0 1500003 175 PO-B /dblogix/prd.4
12 8 0 1500003 284 PO-B /dblogix/prd.5
13 8 0 1500003 86187 PO-B /dblogix/prd.6
14 8 0 1500003 1500000 PO-B /dblogix/prd.7
15 8 0 1500003 1500000 PO-B /dblogix/prd.8
16 9 0 1000053 697460 PO-B /dblogix/crm.1
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)y
File created: /ontapeDir/logicalLogs/isis_0_Log0000000007
File created: /ontapeDir/logicalLogs/isis_0_Log0000000008
Log salvage is complete, continuing restore of archive.
Restore a level 1 archive (y/n) n
Nono Passo:
Configure o servidor HDR secundario para inicializar como secundario ligando ao servidor primario
informix@isis:~/etc> onmode –d secondary prdsoc
Décimo Passo:
Verifique se agora você tem um HDR pariado
vishnu server
informix@vishnu:~> onstat -g dri
IBM Informix Dynamic Server Version 11.50.FC8GE -- On-Line (Prim) -- Up 03:04:24 -- 2857436 Kbytes
Data Replication at 0xd4caf028:
Type State Paired server Last DR CKPT (id/pg) Supports Proxy Writes
primary on tstsoc -1 / -1 NA
DRINTERVAL 30
DRTIMEOUT 30
DRAUTO 0
DRLOSTFOUND /usr/informix/etc/dr.lostfound
DRIDXAUTO 0
ENCRYPT_HDR 0
Backlog 0
informix@vishnu:~>
isis server
informix@isis:~> onstat -g dri
IBM Informix Dynamic Server Version 11.50.FC8GE -- Fast Recovery (Sec) -- Up 01:03:41 -- 2889780 Kbytes
Data Replication at 0xf320f028:
Type State Paired server Last DR CKPT (id/pg) Supports Proxy Writes
HDR Secondary on prdsoc -1 / -1 N
DRINTERVAL 30
DRTIMEOUT 30
DRAUTO 0
DRLOSTFOUND /usr/informix/etc/dr.lostfound
DRIDXAUTO 0
ENCRYPT_HDR 0
Backlog 0
informix@isis:~>
Categorias: Blogs em Português
A Fábrica do Futuro
AJMoreti - ter, 17/04/2012 - 17:01
A fábrica do futuro caracteriza-se por outros aspectos, além de uma instalação repleta de robôs e um elevado grau de automação, e está devidamente organizada em torno da tecnologia, do computador, que integra, por softwares especialmente desenvolvidos, praticamente todas as atividades. Nela, há o uso generalizado de ferramentas como CAD, MRP II, ERP, EDI, e acima de tudo, destaca-se a presença do trabalhador do conhecimento ( o knowledge worker, o colaborador que usa a cabeça, o saber, mais do que as mãos). Podemos dizer que a fábrica do futuro apresenta as seguintes características:
- Organização da produção: focada na alta produtividade. As atividades que não agregam valor são eliminadas. A filosofia de fazer certo desde a primeira vez é levada a extremos. Os refugos e retrabalhos não são admitidos. Os métodos de trabalho têm mecanismos para a prevenção de problemas. Os níveis de estoques são baixíssimos, poís o just-in-time esta em toda parte, e os componentes são entregues diretamente nas linhas de fabricação e/ou montagem. As fabricas são extremamente limpas e organizadas, em decorrência da aplicação sistemática do housekeeping. Os colaboradores são treinados em várias funções, desde a operação, preparação e manutenção até projetos de novos produtos e/ou processos produtivos, são todos controlados por computadores por meio de software integrados.
Hoje já existem muitas fábricas do futuro em plena operação, a exemplo dos sistemas denominados produção enxuta, que surgiram no Japão e estão se espalhando por todo o mundo.
A autoridade do colaborador, no que se refere à qualidade do produto, é praticamente ilimitada. Ele pode, a qualquer instante, parar a linha de produção, uma vez constatada uma não-conformidade já ocorrida ou latente. O espirito de grupo e de compromisso mútuo está presente. Todos os outros colaboradores procuram ajudar na solução do problema para que a linha volte à normalidade o mais rápido possível. Metodologias de identificação e solução de problemas são amplamente difundidas e incorporadas à cultura de todos os colaboradores. A gestão dos processos é feita pela utilização de indicadores de desempenho amplamente discutidos e aceitos por todos os colaboradores que estiverem intimamente ligados aos objetivos estratégicos e táticos da empresa; - Projeto dos produtos e dos processos: os projetos dos produtos são desenvolvidos juntamente com os processos onde serão fabricados. A engenharia simultânea é aplicada em larga escala, passando a ser lugar-comum em todas as empresas. A atenção aos objetivos dos clientes guia o projeto, e a utilização de técnicas como o desdobramento da função qualidade (QFD) e a análise de falhas (FMEA) assegura maior qualidade e confiabilidade aos produtos. Os produtos têm um menor número de componentes, o que diminui os riscos de falhas e os custos, sem que se perca a flexibilidade, pois os produtos são modulados.
- Layout: é o elemento determinante da fábrica do futuro. As fábricas grandes até então tidas como padrão são divididas em várias pequenas unidades dentro da fábrica original, devidamente focalizadas, organizadas em células de produção, com elevado grau de automação. Os novos projetos contemplam áreas reduzidas para estoques de matérias-primas e produtos acabados, e não há previsão de áreas para retrabalho. Até mesmo as áreas reservadas para os produtos em processos são reduzidas, pois as linhas são balanceadas de forma a permitir um fluxo contínuo e sem acúmulo em determinados pontos de processo. Esse processo de mudança permite que possa se dobrar a produção utilizando-se a metade da área até então usada.
- Comunicação visual: as informações sobre produção, produtividade, objetivos atingidos e a atingir, porcentagem de refugos, etc., estão dispostas em quadros espalhados por todas as instalações, para serem lidos, analisados e criticados por todos os colaboradores. A era dos gerentes que guardam informações para deter o poder esta chegando ao fim. Na fábrica do futuro as informações são disponibilizadas em tempo real, como a utilização de painéis eletrônicos conectados a vários terminais de entrada de dados. A utilização de cores é explorada ao máximo, com cartões kanban, contêineres, bancadas, etc., coloridos de forma a transmitir uma ou mais informações sobre o andamento dos processos.
- posto de trabalho: o posto de trabalho é projetado tendo em vista os conceitos de ergonomia, procurando o conforto, bem-estar e segurança dos colaboradores. Além disso, a fábrica do futuro é ecologicamente correta. isto é, não é poluidora. São certificadas nos termos da ISO 14000 ou normas correspondentes. A preocupação em trabalhar com materiais recicláveis está presente em todas elas.
Fonte: Martins, P. G.; Laugeni, F. P. (2006). Administração da Produção. São Paulo. Saraiva.
Categorias: Blogs em Português
