Tecnologia da Informação

Utilizando os Manuais do SuSE

2012-02-07T16:36:00.001-02:00

Ola Pessoal, hoje vou escrever um pouco de como utilizar melhor as paginas (man) do SuSE, porem esse texto vai servir para muitas outras distribuições.

Em todas as distribuições Linux, são instalados os manuais e são muito uteis em varios momentos na vida de um administrador de sistema Unix em geral, então fica aqui algumas dicas de como utilizar melhor esses manuais.

Suponha que você queira encontra paginas de manual para determinados comandos que você nao saiba o nome porem tem relacionamento com uma determinada palavra. Utilizando o comando apropos ele pesquisara em uma base de dados e mostrara algumas informações, vamos ver um exemplo:

amilcar@isis:~> apropos cron
Config::Crontab (3pm) - Read/Write Vixie compatible crontab(5) files
cron (8)             - daemon to execute scheduled commands (ISC Cron V4.1)
crontab (1)          - maintain crontab files for individual users (ISC Cron V4.1)
crontab (1p)         - schedule periodic background work
crontab (5)          - tables for driving cron (ISC Cron V4.1)

no exemplo acima podemos observar que o comando apropos nos traz sugestão de todos os manuais que ele encontrou sobre o assunto cron.

Temos tambem o comando whatis que é uma forma de mostrar comandos que contem palavra que voce digitar:

amilcar@isis:~> whatis ls
ls (1)               - list directory contents
ls (1p)              - list directory contents
amilcar@isis:~> whatis cron
cron (8)             - daemon to execute scheduled commands (ISC Cron V4.1)
amilcar@isis:~> whatis whatis nslookup
whatis (1)           - display manual page descriptions
nslookup (1)         - query Internet name servers interactively
amilcar@isis:~>

E a maneira de exibir a pagina de manual para um comando é o comando man

amilcar@isis:~> man head
Man: find all matching manual pages
* head (1)
head (1p)
Man: What manual page do you want?
Man:

HEAD(1) User Commands HEAD(1)

NAME
head - output the first part of files

SYNOPSIS
head [OPTION]... [FILE]...

DESCRIPTION
Print the first 10 lines of each FILE to standard output. With more than one FILE, precede each with a header giving the file
name. With no FILE, or when FILE is -, read standard input.

Mandatory arguments to long options are mandatory for short options too.

-c, --bytes=[-]N
print the first N bytes of each file; with the leading `-', print all but the last N bytes of each file

-n, --lines=[-]N
print the first N lines instead of the first 10; with the leading `-', print all but the last N lines of each file

-q, --quiet, --silent
never print headers giving file names

-v, --verbose
always print headers giving file names

--help display this help and exit

--version
output version information and exit

N may have a multiplier suffix: b 512, kB 1000, K 1024, MB 1000*1000, M 1024*1024, GB 1000*1000*1000, G 1024*1024*1024, and so on
for T, P, E, Z, Y.

AUTHOR
Written by David MacKenzie and Jim Meyering.

REPORTING BUGS
Report bugs to <bug-coreutils@gnu.org>.

COPYRIGHT
Copyright Â© 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

Manual page head(1) line 1

O comando anterior exibe a pagina de manual encontrado para o comando head. Como você viu no exemplo anterior, alguns comandos podem ter multiplas paginas de manuais. Por exemplo, o comando acima, “man head” possui 2 manuais, isso porque os manuais são organizados em sessões, como mostro na tabela abaixo:

Sessão	Descrição
0	Arquivos de Cabeçalho (geralmente encontrado em /usr/include)
1	Programas executaveis ou comandos shell
2	System calls
3	Library calls
4	Arquivos especiais
5	Arquivos formatados e convencionados
6	Games
7	Diversos
8	Comandos de Administração de Sistemas
9	Rotinas de Kernel (não é padrao)

O código a seguir mostra alguns exemplos de outras opções úteis com o comando man.

amilcar@isis:~> man mount -a
Man: find all matching manual pages
* mount (8)
mount (2)
Man: What manual page do you want?
Man:

Mostra todas as páginas de manual relacionadas com componente

amilcar@isis:~> man 5 crontab
amilcar@isis:~>

Mostra a sessão 5 para o manual do crontab

amilcar@isis:~> man -f mount
mount (2) - mount file system
mount (8) - mount a file system
amilcar@isis:~>

Mesmo que o comando whatis

amilcar@isis:~> man -k mount
auto.master (5)      - Master Map for automounter
autofs (5)           - Format of the automounter maps
autofs (8)           - Control Script for automounter
automount (8)        - manage autofs mount points
free (1)             - Display amount of free and used memory in the system
mdu (1)              - display the amount of space occupied by an MSDOS directory
mklost+found (8)     - create a lost+found directory on a mounted Linux second extended file system
mmount (1)           - mount an MSDOS disk
mount (2)            - mount file system
mount (8)            - mount a file system
mount.cifs (8)       - mount using the Common Internet File System (CIFS)
mount.nfs (8)        - mount a Network File System
mount.ntfs (8)       - Third Generation Read/Write NTFS Driver
mount.ntfs-3g (8)    - Third Generation Read/Write NTFS Driver
mountd (8)           - NFS mount daemon
mountpoint (1)       - see if a directory is a mountpoint
ntfs-3g.probe (8)    - Probe an NTFS volume mountability
ntfsmount (8)        - NTFS module for FUSE.
rpc.mountd (8)       - NFS mount daemon
setup (2)            - setup devices and file systems, mount root file system
showmount (8)        - show mount information for an NFS server
sleep (1)            - delay for a specified amount of time
umount (2)           - unmount file system
umount (8)           - unmount file systems
umount.cifs (8)      - for normal, non-root users, to unmount their own Common Internet File System (CIFS) mounts
umount.nfs (8)       - unmount a Network File System
umount2 (2)          - unmount file system
amilcar@isis:~>

Mesmo que o comando apropos

Para quem gosta de pesquisar na net, pode pesquisar qualquer manual de comando no seguinte site: Linux Man Pages

Usando o help no openSuSE

2012-02-06T17:19:00.001-02:00

A opção –h ou - - help são muitas vezes utilizados para mostrar ajuda de um determinado comando. Segue abaixo um exemplo ilustrando o help para o comando ls:

amilcar@isis:~> ls --help | less
Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.

Mandatory arguments to long options are mandatory for short options too.
-a, --all                  do not ignore entries starting with .
-A, --almost-all           do not list implied . and ..
      --author               with -l, print the author of each file
-b, --escape               print octal escapes for nongraphic characters
      --block-size=SIZE      use SIZE-byte blocks
-B, --ignore-backups       do not list implied entries ending with ~
-c                         with -lt: sort by, and show, ctime (time of last
                               modification of file status information)
                               with -l: show ctime and sort by name
                               otherwise: sort by ctime
-C                         list entries by columns
      --color[=WHEN]         control whether color is used to distinguish file
                               types. WHEN may be `never', `always', or `auto'
-d, --directory            list directory entries instead of contents,
                               and do not dereference symbolic links
-D, --dired                generate output designed for Emacs' dired mode
-f                         do not sort, enable -aU, disable -ls --color
-F, --classify             append indicator (one of */=>@|) to entries
      --file-type            likewise, except do not append `*'
      --format=WORD          across -x, commas -m, horizontal -x, long -l,
                               single-column -1, verbose -l, vertical -C
      --full-time            like -l --time-style=full-iso
-g                         like -l, but do not list owner
      --group-directories-first
                             group directories before files.
                               augment with a --sort option, but any
                               use of --sort=none (-U) disables grouping
-G, --no-group             in a long listing, don't print group names
-h, --human-readable       with -l, print sizes in human readable format
                               (e.g., 1K 234M 2G)
      --si                   likewise, but use powers of 1000 not 1024

A saida anterior mostra como o comando ls é usado e disponibiliza uma lista de opções. Canalizando a saída para o comando less. Você pode formatar as mensagem de help utilizando o comando card. Por exemplo:

amilcar@isis:~> card ls --output=/tmp/ls.ps
[/tmp/card.7334.R2KJSi/card (Reference Card): 2 pages on 1 sheet]
[Total: 2 pages on 1 sheet] saved into the file `/tmp/ls.ps'
amilcar@isis:~> lpr ls.ps

O resultado mostrado aqui é o ls.ps que você pode abrir em leitor de PostScript para visualiza-lo. Você tambem pode utilizar o comando lpr para imprimir o documentos gerado, se você não utilizar a opção –output, isso podera ser enviado para uma impressora padrão automaticamente.

Bom fica aqui a dica muito importante de como utilizar o help do Linux, isso é importante para aprendermos sobre as opções e a utilização correta de um determinado comando, hoje podemos localizar o help desses comando também na net, é só pesquisar que tem muitos sites bons explicando os comandos.

ate a proxima.

Iniciando com SuSE

2012-01-20T16:35:00.001-02:00

A maioria das versões de Linux, assim como Unix, define o prompt de comando padrão como um sinal de dolar, $, para usuários comuns e para o root #). o SuSE, entretanto, define o prompt de comando padrão como um sinal de maior (>), mas segue a convenção dos Linux usando o sinal de cerquilha ou libra # para o usuario root. Ao longo dos meus post, você vai ver $ para o prompt de shell para comandos que podem rodar como qualquer usuario (não querer privilegios especiais).

Voce pode customizar seu prompt da maneira que voce quiser, usando o comando abaixo:

$ export PS1=" [\u@\h \w]\\$ "
[amilcar@isis /root]$

Este comando configura o prompt com seu nome, @ o hostname corrente, com o diretorio de trabalho atual, tudo dentro dos colchetes, seguido pelo $ que é o prompt tradicional.

Encontrando Comandos

Alguns dos comandos que vou descrever em meus post, pode não ser encontrados na sua distribuição ou dependendo do usuario que você estiver logado, ou se digitar o comando errado, irá aparecer uma mensagem similar a essa:

[amilcar@isis ~]$ comandoinexistente
bash: comandoinexistente: command not found

Algumas das razões para voltar essa mensagem de erro:

Você pode ter digitado o comando errado;

O comando pode não existir em seu PATH;

Pode ser necessario do usuario root para executar o comando;

O comando pode nao estar instalado no computador;

Abaixo alguns comandos para extrair informações do comandos que deseja usar:

[amilcar@isis ~]$ type mount (Mostra o primeiro comando do PATH)
mount is /bin/mount
[amilcar@isis ~]$ ]

[amilcar@isis ~]$ whereis mount            (Mostra binarios, fontes e manuais)
mount: /bin/mount /sbin/mount.nfs /sbin/mount.cifs /sbin/mount.nfs4 /sbin/mount.ntfs /sbin/mount.ntfs-3g /usr/share/man/man2/mount.2.gz /usr/share/man/man8/mount.8.gz
[amilcar@isis ~]$

[amilcar@isis ~]$ which mount      (procura pelo comando em qualquer lugar da file system)
/bin/mount
[amilcar@isis ~]$

[amilcar@isis ~]$ rpm -qal |grep mount          (encontrar pelo comando em qualquer pacote instalado)
/usr/bin/mmount
/usr/share/man/man1/mmount.1.gz
/usr/share/zsh/4.3.6/functions/_fusermount
/usr/share/zsh/4.3.6/functions/_mount
/usr/share/zsh/4.3.6/functions/_showmount
/usr/lib64/hal/hal-storage-cleanup-all-mountpoints
/usr/lib64/hal/hal-storage-cleanup-mountpoint
/usr/lib64/hal/hal-storage-mount
/usr/lib64/hal/hal-storage-unmount
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/ncp_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/nfs4_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/nfs_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/smb_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/rpcsvc/mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/sys/mount.ph
/sbin/mount.nfs
/sbin/mount.nfs4
/sbin/umount.nfs
/sbin/umount.nfs4
…………………
…………………

[amilcar@isis ~]$ rpm -q --whatprovides tar (procura pelo pacote que prove o comando)
tar-1.20-23.12.1
[amilcar@isis ~]$

Se o comando que voce procura nao estiver instalado, voce pode fazer a instalação do pacote usando o shell ou GUI:

Instalação pelo Shell – digite yast na linha de comandoe siga as orientações do YaST2. Também pode ser instalado via zypper ou ainda com o rpm.
Instalação via GUI – pode ser instalado pela versão grafica do YaST2, você vai precisar da senha do root para rodar a aplicação.

Usando o recurso GLS

2012-01-20T14:46:00.001-02:00

O recurso de Suporte de Linguagem Global (Global Language Support – GLS) permite que produtos IBM Informix lide com diferentes idiomas, convenções culturais, e conjuntos de códigos para a Ásia, Africa, Europa, Latino Americano, e países do Oriente Médio.

O recurso GLS permite que você crie bancos de dados usando os diacríticos, de sequência , e convenções monetárias e hora do idioma que você selecionar. Não existe nenhum parametro de configuração no ONCONFIG para o GLS, essas configurações são realizadas nas variaveis de ambiente do sistema.

Em um banco de dados, algumas das tarefas por ele realizado dependem das convenções de linguagem e cultura dos dados que eles manipulam. Por exemplo, o servidor de banco de dados deve classificar dados do Brasil diferentemente dos dados de caracteres coreanos. Uma aplicação Cliente deve exibir a moeda canadense diferentemente da moeda Tailandesa.

Se o servidor de banco de dados Informix ® ou produto cliente inclui o código para executar essas tarefas, cada um precisaria ser escrito especialmente para lidar com um conjuento diferentes de culturas especifica de dados.

Com suporte ao GLS, produtos IBM Informix não precisa especificar como processar informações especificas de cultura diretamente. Informações específicas de cultura reside em um local GLS. Quando um produto IBM Informix necessita de informações especificas de culturas, ele chama a biblioteca GLS, que acessa o local GLS e retorna as informações para os produtos IBM Informix.

O recurso GLS é uma forma portátil de suporte de informação específicos de culturas. Embora muitos sistemas operacionais oferecem suporte para varios tipos de idiomas, esse suporte é geralmente para o proprio sistema operacional. Não existem ainda padrões para o formato de informações especificas de culturas e idiomas. Esta falta de conformidade significa que se você mover um aplicativo de um ambiente de uma determinada região para uma outra região, talvez seja necessario mudar o suporte de linguagem do sistema operacional.

O recurso GLS pode acessar informações especificas de cultura em um UNIX® e ou no Windows®. Produtos IBM Informix pode localizar as informações de localidade em qualquer plataforma para o qual são portados.

Nota para o Ambiente Windows®
Para que o GLS suporte um local não padrão, a versão do Windows® que voce esta usando tambem deve suportar essa localidade. Ou seja, voce não pode suportar um aplicativo japonês no Windows, a menos que a aplicação esta rodando na versão japonesa do Windows®.
Fim da Nota.

Para utilizar o recurso GLS, as tarefas que voce precisa para realizar depende se você é um administrador de sistemas, administrador de banco de dados, usuario final de um aplicativo, usuario final de um utilitario de servidor de banco de dados ou desenvolvedor de aplicações.

Função

Tarefas

Administrador de sistema, administrador de banco de dados, e ou usuario final do aplicativo

Para locais não padrão, configure as variaveis de ambientes DB_LOCALE, CLIENT_LOCALE, e SERVER_LOCALE.
Para customizar os formatos par asuarios finais, configure as variaveis de ambientes GL_DATE, GL_DATETIME e DBMONEY. Para o Informix SQL/C você pode configurar a variavel DBTIME ao inves da variavel GL_DATETIME.

Para configurar um ambiente GLS para Informix ESQL / C, configure as variáveis de ambiente CC8BITLEVEL e ESQLMF.
Para executar uma configuração adicional para o ambiente GLS, definir as variaveis de ambiente DBLANG e GLS8BITFSYS.

Locale em Informix

2012-01-13T10:12:00.001-02:00

Locale

A GLS ou descrição locais (Locale) é um conjunto de arquivos que contêm informações específicas para uma determinada língua e cultura:

O nome do conjunto de códigos que os dados do aplicativo usa;
A ordem de agrupamento a ser usado para dados de caracteres;
O formato em que diferentes tipos de dados aparece para usuários finais;

O locale padrão é a localidade que a instalação do Windows ® utiliza. Por exemplo, Instalações do Windows em Inglês dos EUA usam o locale en_us.1252.

Caracteres de Byte Único

Esta publicação representa caracteres de byte único como uma série de letras minúsculas. O formato para a representação de um caractere de byte único é:

Aqui a representa qualquer caractere de byte único, não para a letra "a" em si.

O formato para a representação de uma seqüência de caracteres de byte único é a seguinte:

a b c d e ……….z

Aqui a representa o primeiro caracter e z representa o ultimo caractere da sring. Por exemplo, se a string informix consiste de oito caracteres de byte unico, o seguinte formato representa essa string de 8 caracteres abstratamente:

abcdefgh

Caracteres Multibyte

Não é a ideia dessa publicação tentar mostrar a aparencia real de carecteres multibyte no texto, exemplos ou diagramas. Em vez disso, a convenção a seguir mostra como caracteres multibyte são armazenados abstratamente:

A¹……………Aⁿ

De um a quatro letras maiusculas identicas, cada um seguido por um numero diferente sobrescrito, representa um caractere multibyte. Os sobrescritos mostram o byte n do caracter multibyte, onde n tem valores entre dois e quatro, por exemplo, os seguintes simbolos representam um caractere multibyte que consiste de dois bytes:

A¹A²

A notação a seguir representa um caractere multibyte que consite em quatro bytes (o comprimento máximo de um caractere multibyte):

A¹A²A³A⁴

O proximo exemplo mostra uma sequencia de caracteres multibyte em uma instrução SQL:

CREATE DATABASE A¹A²B¹B²C¹C²D¹D²E¹E²;

Esta instrução cria um banco de dados cujo nome é composto de cinco caracteres multibyte, cada um dos quais é de dois byte.

Caracteres de byte unico e multibyte na mesma string

Para um conjunto de código multibyte, uma determinada string pode ser composto por caracteres de byte único e multibyte. Para representar essa string mista, esta publicação simplesmente combina os formatos de caracteres multibyte e byte unico. O próximo exemplo representa uma string com quatro caracteres, onde o primeiro e o quarto caracter são byte unico, e o segundo e terceiro caracteres são multibyte que consistem de dois bytes cada um:

aA¹A²B¹B²b

Caracteres de espaço em branco na String

Espaço me branco é uma serie de um ou mais caracteres que são apresentados como espaço em branco, cada localidade GLS define quais caracteres são caracteres de espaço em branco.

Por exemplo, tanto o TAB (ASCII 9) e no espaço em branco (ASCII 32) pode ser definido como caracteres espaço em branco em uma localidade, mas certas combinação de tecla CTRL e outro caracter pode ser definido como caracteres de espaço em branco em uma localidade diferente.

A convenção para a representação de um espaço de byte unico branco nesta publicação é a letra “s”. A notação a seguir representa um espaço de byte unico branco:

No conjunto de codigo ASCII, um exemplo de um espçao em branco de um unico byte é o caractere em branco (ASCII 32). Para representar uma string que consiste de dois caracteres ASCII em branco, a publicação utiliza a seguinte notação:

A notação a seguir representa um caractere de espaço multibyte branco:

s¹...sⁿ

Aqui S¹ representa o primeiro byte do caractere espaço em branco, e sⁿ representa o último byte do caractere espaço em branco, onde n pode variar entre dois e quatro. A notação a seguir representa 4-byte de um caractere espaço em branco:

s¹s²s³s⁴

Entendendo melhor Caracteres de espaços em branco

Combinações de caracteres com espaços em branco podem ocorrer em  strings entre aspas, em colunas CHAR que contêm menos caracteres do que o comprimento da coluna declarada, e em outros contextos. Por exemplo, se uma coluna CHAR(5) em um conjunto de códigos de byte único contém três caracteres, a string é preenchido com dois espaços em branco de modo que seu comprimento é igual ao comprimento da coluna:

abcss

O próximo exemplo representa uma string de cinco caracteres (tres caracteres de dados e dois caracteres em branco à direita) em um conjunto de código multibyte , onde cada um dos caracteres de dados e caracteres  de espaço em branco é composto de dois bytes:

A¹A²B¹B²C¹C²s¹s²s¹s²

Em algumas localidades, uma string pode conter caracteres espaço em branco de bytes de códigos unico e multibyte. Por exemplo, considere a seguinte seqüência:

abcss¹s²sss¹s²

A string tem três caracteres de byte único (abc), um caractere de byte único de espaço em branco (s), um caractere de espaço multibyte branco ( s¹s² ), dois caractere de byte único de espaço em branco (ss), e um character de espaço em branco multibyte (s¹s²).

Comparando SuSE com outras distribuições Linux

2011-12-13T14:03:00.001-02:00

Usando openSuSE pode ser a melhor maneira de aprender Linux se você tiver a intenção de se tornar um profissional Linux. Com seu foco no desenvolvimento comunitario, voce pode ter certeza que voce esta recebendo alguns dos mais recentes e melhores software de codigo aberto disponivel. Utilizando o openSuSE voce ganhara habilidades em niveis de ambientes empresariais.

Alem da Novell, Red Hat Inc. é outra grande corporação que distribui Linux no mercado. Os Sistemas Operacionais da Red Hat segue o mesmo modelo dual de distribuição, com o Red Hat Enterprise Linux (RHEL) sendo uma distribuição comercial e o Fedora como um sistema Livre.

Debian é considerado uma distribuição Linux de altissima qualidade, com um forte compromisso com os ideiais do software de código aberto. Alguns derivados de distribuição Linux, como o popular Linux Ubuntu e o KNOPPIX são baseado no Debian. E embora o Debian é bom para utilizar-se em pequenas empresas, o projeto não tem uma infra-estrutura de empresas como (treinamento, suporte, documentação e assim por diante) que é construida em torno do SuSE Enterprise Linux e Red Hat Enterprise.

Sobre SuSE, Novell e Linux

2011-12-08T08:45:00.001-02:00

SuSE (pronuncia-se SOO-zuh) é um Sistema Operacional Linux de propriedade da Novell, Inc. SuSE representado pela empresa de Software Alemã System-Entwicklung. o SuSE foi baseado no Slackware Linux, e tornou-se oficialmente uma distribuição independente em 1996, quando foi lançada a sua primeira versão:

SuSE foi, e permanece, uma das distribuições de Linux mais popular da Europa.

Em novembro de 2003, a Novell adquriu o SuSE e incorporou a distribuição em seus projetos. Hoje existem 3 edições para o SuSE:

SuSE Linux Enterprise Desktop (SLED) edição comercial, baseado em assinatura, produzido pela Novell, Inc. cujo objetivo é fornecer um ambiente de Desktop empresarial, oferecendo suporte, treinamentos, documentações, certificações de hardware, entre outros produtos.
SuSE Linux Enterprise Server (SLES) tambem uma edição comercial, porem uma edição focada em servidores.
openSuSE, uma versão de codigo aberto do SuSE, livre, e sem as opções de suporte ofertada pela Novell, foi iniciada pela Novell em 2005. openSuSE é uma comunidade do sistema operacional que é distribuida livremente e tornou-se conhecida pela sua estabilidade e suporte a hardware.

SuSE Linux

2011-11-08T14:27:00.001-02:00

Depois que você ja teve alguma experiencia com linux, você nao precisa de alguem dizendo a você para clicar no botão ajuda ou para arrastar um arquivo para a lixeira para exclui-lo . O que você precisa é de um bom livro ou um site que mostrem comandos poderosos e as opções que permitem você controlar seu sistema Linux, como os processos, usuarios, media de armazenamento, recursos de redes, e serviços do sistema associados com tudo isso.

Como podem perceber sou um adpto da SuSE, gosto muito dessa distribuição, talvez por usar e acompanhar toda a sua evolução desde 1994 quando surgiu a versão 1.0 baseada no Slackware. Vou tentar nos proximos dias ou proximos meses quem sabe, passar varios conceitos e comandos do OpenSuSE e do SuSE Linux da Novell para ajudar a você a se tornar um usuario avançado em Linux. Se você é um administrador de Sistemas ou um usuario comum, esses artigos vai mostrar-lhes comandos para criar sistemas de arquivos, solucionar problemas de redes, aumentar o nivel de segurança, e mostrar muita coisa que você gostaria de saber sobre o seu sistema Linux.

Quem me inspiriou a escrever esse artigo foi Christopher Negus e Françõis Caen, que escreveram um livro chamado SUSE LINUX TOOLBOX (1000+ Commands for OpenSuSE and SUSE Enterprise, li o livro e gostei muito, eles estão de Parabens pela iniciativa, esse livro foi publicado nos Estados Unidos da America em Indianopolis e Simultaneamente no Canada, para os interessados na aquisição do Livro, procure no Amazon.com pelo ISBN: 978-0-470-08292-9.

Os artigos que vou escrever, foi inspirado nesse livro, e vai ser focado em comandos de linhas de comandos do openSuSE.

Uma breve historia da Novell’s com o SuSE

para saber mais, vá ate o link do wikipedia http://pt.wikipedia.org/wiki/OpenSUSE

O mais interessante da historia e poucos sabem é que existe um acordo de cooperação entre a Novell e a Microsoft que teve inicio em 2006 e com termino em 2011, porem ja foi renovado por mais 4 anos. O acordo previa a colaboração entre as duas empresas para que trabalhassem em direção ao suporte e interoperabilidade entre os sistemas operacionais Windows e Linux. É bom deixar claro que a Microsoft não contribui para o desenvolvimento do SuSE e tambem esse acordo não se extende ao OpenSuSE, somente ao SuSE Linux Enterprise da Novell.

Então até os proximos artigos,

PAM–Plugglable Authentication Modules

2011-10-11T10:37:00.001-03:00

Já faz alguns dias que venho quebrando a cabeça com o PAM, muito minucioso para configurar, porem muito eficiente para quem busca segurança. Já faz dias que estou vasculhando a Internet, procurando por documentos e dicas, participando de fóruns para tentar entender como realmente funciona o aplicativo para poder configurar dois servidores.

O meu objetivo com o PAM, é configurar uma autenticação segura, onde, por exemplo, se o usuário errar a senha por cinco vezes bloqueia o acesso, e somente é liberado se o root liberar, também configurar o comprimento da senha, que seria no caso de seis caracteres, porem teria que ter uma maiúscula e um numero formando essa senha, ate esse momento que estou escrevendo esse artigo não consegui sucesso ainda.

Mas o que é realmente o PAM?

O PAM é uma biblioteca que permite usuários autenticar em ambientes como o Linux ou Unix (HP-UX,
AIX, Solaris, entre outros). O grande objetivo do desenvolvimento do PAM deu-se devido ao problema encontrado quando era preciso fazer o login de um usuário, utilizando uma senha criptografada através de acesso remoto. Além disso, como cada programa possuía seu método próprio de login, caso fosse necessário mudar o método de autenticação, os programas teria que ser alterados para reconhecer este novo método. Foi neste momento, que a SUN MICROSYSTEMS criou o PAM, um aplicativo centralizador da tarefa de autenticação, com isso não seria mais necessário cada programa se preocupar com o papel de autenticador, pois esta seria a tarefa do PAM e casso fosse mudado o critério de autenticação, por questão de segurança, somente seria necessários alterar o método no próprio PAM.

Qual a Vantagem do PAM

A principal vantagem do PAM, além de centralizador das funções de autenticação do login e senha, é que ele é capaz de selecionar, se configurar para tal, os programas aos quais os usuários que fez o login pode ou não acessar. Desta forma, um usuário que quisesse usufruir de aplicativos de áudio e vídeo, por exemplo, remotamente, poderia ser bloqueado o que não aconteceria caso ele estivesse utilizando estes aplicativos localmente.

Configuração do Módulo PAM

Os arquivos de configuração do PAM, no Linux, normalmente estão localizados no diretório /etc/pam.d/.

Nestes arquivos, a linha de configuração é dada como:

Service-name module-type control-flag modulo-path args

Nome do Serviço

Esta associado ao nome do serviço a esta entrada. Por exemplo, ftpd, rlogind, su e outros.

Divisão dos Módulos – Module-Type

Como o próprio nome diz, o PAM é um conjunto de módulos, no qual cada um recebe uma ou mais funções especiais dentro do processo de autenticação. Essa função que cada modulo tem é determinado pelas divisões dos módulos do PAM, que são: AUTH, ACCOUNT, PASSWORD, SESSION.

AUTH

A divisão AUTH trata da autenticação, seja por login/senha ou autenticação biométrica (voz, retina, impressão digital, por exemplo).

ACCOUNT

Esta divisão, terá o papel de autorização ou não autorização para o uso de programas com base no login, determinando assim, o usuário apto a utilizar aquele programa ou não.

PASSWORD

É responsável pela troca de senha.

SESSION

Determina qual será o ambiente do usuário com base no seu login.

É importante salientar, neste momento, que o PAM é o conjunto de módulos e como tal, não precisa ter todos os módulos existentes e possíveis para funcionar, basta ter aqueles os quais o administrador acha necessário trabalhar, e que, alguns módulos possuem apenas uma das divisões acima citadas enquanto outros chegam a ter todas as divisões.

Controle das Flags – Control-flag

O control-flag é utilizado para indicar de que forma a biblioteca do PAM reagirá ao sucesso ou falha do módulo que esta associado. Outra função que a control-flag pode executar é dando prioridades a cada módulo, visto que eles podem ser empilhados.

Existem dois modos de sintaxe para o control-flag um mais antigo e tradicional que divide a sintaxe em: REQUIRED, REQUISITE, SUFFICIENT, OPTIONAL. O modo mais novo, mais elaborado e especifico separa da seguinte forma: VALUE=ACTION. A parte ACTION é nomeada como IGNORE, BAD, DIE, OK, DONE, RESET.

Controle de Sintaxe do Modo Tradicional

REQUIRED

Estabelece que: a falha do módulo utilizando a sintaxe REQUIRED, não será mostrada ao usuário até que todos os módulos estejam sendo executados.

REQUISITE

Parecido com o REQUIRED, porem no caso de falha, o controle é retornado direto a aplicação. Esta flag é muito utilizada para proteger um usuário que tente colocar sua senha quando o meio esta inseguro.

SUFFICIENT

A falha deste modulo não implica em falha da autenticação como um todo. Se o modulo falhar, o próximo da classe é executado. Se não houver próximo, então a classe retorna com sucesso. Se, por outro lado, o modulo terminar com sucesso, então os módulos seguintes dessa classe não serão executados. Este parâmetro é bastante usado no caso de usar LDAP para autenticação, por exemplo, ou outra fonte de dados.

OPTIONAL

Módulos marcados como ptional praticamente não influencia o resultado da autenticação como um todo. Eles terão alguma influencia somente caso os módulos anteriores da mesma classe não apresentem um resultado definitivo.

Exemplos de Modulos do PAM – Module Path

Existem muitos módulos disponíveis como: pam_access, pam_chroot, pam_cracklib, pam_deny, pam_env, pam_filter, pam_ftp, pam_group, pam_issue, pam_krb4, pam_lastlog, pam_limits, pam_listfile, pam_mail, pam_mkhomedir, pam_motd, pam_nologin, pam_permit, pam_pwdb, pam_radius, pam_rhosts_auth, pam_rootok, pam_securetty, pam_tally, pam_time, pam_unix, pam_userdb, pam_warn, pam_wheel, pam_tally2.

Porem, somente os módulos principais serão mostrados e explicados a seguir.

Securetty Module – pam_securetty

Module-Type: AUTH

Autor: Elliot Lee

Características: este modulo simplesmente verifica em qual terminal o root esta tentando fazer login, então a partir dele é possivel restringir os locais em que o root pode fazer login. Logo,a principal característica do pam_securetty é evitar o login do root em terminais inseguros. Vale ressaltar, que para o pam_securetty,nenhum terminal esta liberado para o login, o root que devera configurar este modulo para ele possa fazer o login em outro terminal.

Password Database Module – pam_pwdb

Module-Type: ACCOUNT, AUTH, PASSWORD, SESSION

Autores: Cristian Gafton e Andrew G. Morgan

Caracteristica: Este é o principal modulo do programa login, para tanto ele se encarrega de fazer a verificação do nome do usuário e senha, assim, autorizando o usuário ou não. Este modulo ainda aceita alguns parâmetros em sua configuração: shadow, nullok, md5, use_authtok.

Shadow: permite o uso de senhas shadow ou convencionais.

Nullok: permite o uso de senha em branco.

Md5: usa criptografia md5 em vez de cript padrão.

Use_authok: indica que o modulo deve usar a autenticação já fornecida para os módulos anteriores, para não interrogar o usuário novamente.

No-login Module – pam_nologin

Module-Type: ACCOUNT, AUTH

Autor: Michael K. Johnson

Caracteristica: este modulo é muito útil quando se deseja fazer a manutenção do sistema. Com ele funcionando, não será permitido a nenhum usuário fazer o login com exceção do root. É importante citar que, usuários que já estiverem feito o login não serão afetados com a adição deste modulo.

Cracklib pluggable password strength-checker – pam-cracklib

Module-Type: PASSWORD

Autor: Cristian Gafton

Caracteristica: este modulo fara a verificação da fragilidade de uma nova senha. Para isto, ele avalia algumas características como:

Polindrome: a nova senha é um palindrome da antiga?

Case change only: a nova senha é a antiga com apenas a diferença da caixa(maiúscula e minúscula)?

Simiar: a nova senha é similar a antiga? Ou seja, se existe caracteres repetidos. Ele estipula um numero mínimo para o uso dos mesmo caracteres da senha antiga.

Simple: a nova senha é muito pequena?

Rotated: a nova senha é a antiga, porem invertida?

Already used: a opção para nova senha já foi utilizada no passado?

Access Module – pam_access

Module-Type: ACCOUNT

Autor: Alexei Nogin

Caracteristica: verifica quais usuários podem fazer login e em qual local (terminal, remoto, domínio, etc.)

Resource Limits Module – pam_limits

Module-Type: SESSION

Autor: Cristian Gafton

Caracteristica: este modulo limita o uso dos recursos como : uso da CPU, memoria e outros. Sua linha de configuração de entrada é:

Domain: pode ser o nome de um usuário ou grupo.

Type: pode ser de dois tipos: hard ou soft. Para o hard o usuário não pode alterar os recursos pre-definidos, já para o modo soft o usuário é capaz de alterar os recursos, porem sem ultrapassar os limites do modo hard.

Item: pode ser cada um dos seguintes:

Core: tamanho máximo para arquivos core (KB)

Data: tamanho máximo do seguimento de dados de um processo de memoria

Fsize: tamanho máximo para novos arquivos.

Memlock: tamanho máximo de memoria que um processo pode bloquear na memoria física.

Nofile: quantidade máxima de arquivos abertos ao mesmo tempo

Rss: tamanho máximo que um processo pode manter na memoria física

Stack: tamanho máximo da pilha

Cpu: tempo máximo do uso da CPU

Nproc: quantidade máxima de processos disponíveis para um único usuário

As: limite de espaço de endereçamento

Maxlogins: quantidade máxima de logins para este usuário ou grupo

Priority: a prioridade com os processos deste usuário serão executados.

Value: determina o valor para opção do Item.

Argumentos – Args

Os args, argumentos, fazem parte de uma lista de símbolos que podem ser colocados ao final de cada modulo, se desejado. Estes argumentos são semelhantes aos argumentos disponíveis em um comando do Linux.

Manual - Linux-PAM (PAM_TALLY2)

2011-10-06T15:26:00.001-03:00

NAME

pam_tally2 – Modulo contador de login (contagem)

SINOPSE

pam_tally2.so [file=/path/to/counter] [onerr=[fail|succeed]] [magic_root] [even_deny_root] [deny=n] [lock_time=n] [unlock_time=n] [root_unlock_time] [serialize] [audit] [silent] [no_login_info]

pam_tally2 [—file /path/to/counter] [—user username] [—reset[n]] [—quiet]

DESCRIPTION

Este módulo mantem uma contagem das tentativas de acessos, pode reiniciar a contagem com sucesso, pode negar acesso se muitas tentativas falham.

pam_tally2 divide-se em duas partes: pam_tally2.so e pam_tally2. O primeiro é o módulo do PAM e o segundo um programa stand-alone. pam_tally2 é um aplicativo (opcional) que pode ser usado para consultar e manipular o arquivo de contagem. O programa pode exibir a contagem do usuário, parametrizar contagem de usuário ou limpar todas as contagem. Parametrizações para fazer a contagem podem ser uteis para bloquear os usuários sem alterar suas senhas. Por exemplo, pode-se limpar todas as contagem a meia-noite usando-se o cron.

Normalmente, falhas de acesso com o usuário root não fara com que a conta root fique bloqueada, para evitar ataques de negação de serviço: se o seu usuários não recebe contas de shell e o root só podem fazer login via su ou no console da maquina (não telnet/rsh, etc), isso é seguro.

OPÇÕES

OPÇÕES GLOBAIS

Estas opções podem ser usadas no modulo auth e account.

onerr=[fail|succeed]

se algo estranho acontece (como não conseguir abrir o arquivo), retorna com PAM_SUCCESS se onerr=succeed é dado senão um código de erro do PAM.

file=/path/to/counter

arquivo onde será mantida a contagem. o padrão é /var/log/tallylog.

audit

Irá registrar o nome do usuário no log do sistema se o usuário não for encontrado.

silent

não existe mensagens de informações.

no_log_info

não grava mensagens de log via syslog(3).

AUTH OPTIONS

Primeira fase de autenticação contra as tentativas de login e verifica se deve ser negado acesso ao usuário. Se o usuário é autenticado, o processo de login continua para o pam_setcred(3) e o contador é zerado.

deny=n

Nega o acesso se a contagem para este usuário excede n.

lock_time=n

Sempre negar n segundos após tentativas mal sucedidas.

unlock_time=n

Permite o acesso após n segundos após as tentativas de falhas.

magic_root

Se o módulo é chamado por um usuário com uid=0 o contador não é incrementado. O administrador de sistemas deve utilizar isso para usuários de serviços como o su, caso contrario, este argumento deve ser omitido.

no_lock_time

não utiliza o campo .fail_locktime no arquivo /var/log/faillog para este usuário.

even_deny_root

conta root pode tornar-se indisponivel.

root_unlock_time=n

Esta opção implica na opção even_deny_root. Permite o acesso após n segundos após as tentativas de falhas. Se esta opção for utilizada o usuário root será bloqueado para um periodo de tempo especificado depois que ele ultrapassou o seu máximo de tentativas permitidas.

serialize

serializar o acesso ao arquivo de registro usando bloqueios.

OPÇÃO ACCOUNT

Redefine tentativas do contador se o usuário não é root. Esta fase pode ser usado opcionalmente por serviços que não chamam o pam_setcred(3) corretamente ou se a reinicialização deve ser feito independentemente do fracasso de contas dos outros módulos.

magic_root

Se o módulo é chamado por um usuário com uid=0 o contador não é incrementado. O administrador de sistemas deve utilizar isso para usuários de serviços como o su, caso contrario, este argumento deve ser omitido.

VALORES RETORNADOS

PAM_AUTH_ERR

uma opção invalida foi dada, o módulo não foi capaz de recuperar o nome do usuário, nenhum arquivo counter válido foi encontrado, ou muitos logins falhos.

PAM_SUCCESS

tudo que foi bem sucedido

PAM_USER_UNKNOWN

usuário não conhecido

NOTA

pam_tally2 não é compatível com o formato de arquivo do antigo pam_tally. Isto é causado pela exigência de compatibilidade entre o formato de arquivo tallylog entre arquiteturas de 32bits e 64bits em sistemas multiarch.

EXEMPLOS

adicione as seguintes linhas ao arquivo /etc/pam.d/login para bloquear a conta após 4 tentativas de falhas no login. A conta do root também será bloqueada. As contas serão automaticamente desbloqueada após 20 minutos.

auth                       required                                 pam_securetty.so
auth                       required                                 pam_tally2.so deny=4 even_deny_root unlock_time=1200
auth                       required                                 pam_env.so
auth                       required                                 pam_unix.so
auth                       required                                 pam_nologin.so
account                required                                 pam_unix.so
password            required                                 pam_unix.so
session                required                                 pam_limits.so
session                required                                 pam_unix.so
session                required                                 pam_lastlog.so nowtmp
session                optional                                 pam_mail.so standard

Entendendo e Configurando o PAM

2011-09-30T11:07:00.001-03:00

por Vishal Srivistava, Associate Software Engineer, IBM

Conceitos básicos sobre o Pluggable Authentication Module e como configurá-lo e gravar um aplicativo de login

Resumo: A API do Pluggable Authentication Module (PAM) expõe um conjunto de funções que os programadores de aplicativos usam para funções relacionadas à segurança, como autenticação do usuário, criptografia de dados, LDAP, etc. Neste artigo, você terá um guia básico para o modelo do PAM no Linux, aprenderá a configurar o PAM e a designar um aplicativo de login do PAM de amostra em 10 etapas bem fáceis.

Para usuários Linux, compartilhar arquivos certamente é uma tarefa trabalhosa. Por exemplo, exige demais ter que lembrar de várias senhas e redesignar os aplicativos de acesso do sistema (como login, su, password, ftp , etc.) é demorado. Somando a essa dificuldade está o processo de autenticação, em que um sistema identifica um usuário e fornece controle de acesso ideal para esse usuário.

Um histórico do uso do PAM

O PAM é uma API que cuida da autenticação de um usuário para um serviço. Antes do PAM, aplicativos como login (e rlogin, telnet, rsh) procuravam pelo nome do usuário em /etc/passwd e depois comparavam os dois e autenticavam o nome digitado pelo usuário. Todos os aplicativos usavam esses serviços compartilhados, embora os detalhes da implementação e a autoridade para configurá-los não fossem compartilhados.

Em seguida, os desenvolvedores do aplicativo tentavam codificar seus próprios processos. Com isso veio a necessidade de separar o aplicativo e o módulo de segurança (um módulo de segurança comum pode ser compartilhado por aplicativos e ser configurado conforme necessário).

O mecanismo PAM integra vários esquemas de autenticação de nível inferior em uma API de nível superior que permite que os programas que dependem da autenticação sejam gravados independentemente do esquema de autenticação subjacente. O principal recurso do PAM e a configuração dinâmica da autenticação através de um arquivo /etc/pam.d ou /etc/pam.conf.

O PAM pode ser configurado para impedir que determinados programas autentiquem os usuários e para avisar quando determinados programas tentam fazer a autenticação. Os programas do PAM usam os módulos do PAM (módulos de autenticação): Eles são anexados aos aplicativos no tempo de execução para funcionar.

A Figura 1 mostra o fluxo básico do modelo do PAM.

Quais sistemas operacionais suportam o PAM?

O PAM foi desenvolvido primeiramente pela Sun Microsystems em 1995 e é suportado pelas seguintes versões de sistemas operacionais (e superior):

RedHat 5.0
SUSE 6.2
Debian 2.2
Mandrake 5.2
Caldera 1.3
TurboLinux 3.6

O PAM também é suportado por versões recentes do Solaris™, AIX®, HP-UX e Mac OS® X. Mais tarde, ele foi padronizado como parte do processo de padronização X/Open UNIX® (na arquitetura X/Open single sign-on service (XSSO)).

Que tipo de PAM posso obter?

Embora eles não sejam estritamente classificadas, podemos dizer que há três tipos de PAM:

Linux-PAM: O Linux-PAM abrange todo o PAM discutido neste artigo. A arquitetura principal do PAM em qualquer plataforma Unix é semelhante à versão PAM do Linux.
OpenPAM: O OpenPAM é outra implementação do PAM desenvolvida pelos laboratórios Dag-Erling Smorgrav em NAI como parte do programa de pesquisa DARPA-CHATS. Por ser um software livre, ele é usado principalmente pelo FreeBSD, NetBSD e por aplicativos (além do Mac OS X).
Java™ PAM ou JPam: O PAM é basicamente um módulo de autenticação padrão que suporta Linux e UNIX. O JPam atua como uma ponte entre a parte Java e o PAM comum. Ele permite o uso dos módulos ou recursos do PAM (como auth, account, passwd, session , etc.) pelos aplicativos baseados em Java. Ele fornece o JAAS e APIs diretas e suporte para a maioria dos sistemas operacionais e arquiteturas do Unix.

Embora esses sejam PAMs diferentes, a funcionalidade principal permanece a mesma.

Como são os módulos do PAM?

A instalação do PAM é um processo etapa por etapa. Consulte Recursos para obter instruções de instalação.

Os módulos do PAM são classificados por tipo de módulo. Qualquer módulo fornecido deve implementar pelo menos uma das quatro funções de tipo de módulo:

O módulo de autenticação é usado para autenticar usuários ou configurar/cancelar credenciais.
Os módulos de gerenciamento de conta executam ações relacionadas ao acesso, à expiração de conta e de credencial, restrições/regras de senha, etc.
O módulo de gerenciamento de sessão é usado para inicializar e terminar sessões.
O módulo de gerenciamento de senha executa ações relacionadas à alteração/atualização de senha.

O PAM fornece recursos funcionais diferentes, como autenticação de conexão única, controle de acesso, etc. A implementação de cada um é manipulada por módulos diferentes. A seguir há alguns dos principais módulos:

pam_access fornece o controle de acesso de login log-daemon-style usando nome de login/domínio, dependendo das regras predefinidas no arquivo /etc/security/access.conf.
pam_cracklib verifica as senhas em relação às regras de senha.
pam_env sets/unsets verifica as variáveis de ambiente a partir de /etc/security/pam_env_conf.
pam_debug depura o PAM.
pam_deny bloqueia os módulos do PAM.
pam_echo imprime as mensagens.
pam_exec executa um comando externo.
pam_ftp é o módulo para acesso anônimo.
pam_localuser requer que o usuário seja listado em /etc/passwd.
pam_unix fornece autenticação de senha tradicional de /etc/passwd.

Há vários outros módulos (pam_userdb, pam_warn, pam_xauth), que usam um conjunto de valores que eles retornam. (Os detalhes desses módulos podem ser obtidos no guia de administração do PAM em Recursos.)

Configurando o PAM

A configuração do PAM é geralmente implementada no arquivo de configuração que reside em /etc/pam.d ou /etc/pam.conf (para versões antigas).

A Estrutura do Arquivo de Configuração

Para cada serviço que usa o PAM, há um arquivo correspondente no diretório, que contém as regras ou as instruções sobre como as informações de autenticação e de conta devem ser obtidas para esse serviço. Geralmente há uma regra por linha.

Os campos nos arquivos de configuração do PAM incluem:

Service_name Especifica o nome do serviço/aplicativo. (O padrão é OTHER.)
Module_type especifica o tipo de módulo (auth/account/session/passwd) para o serviço correspondente no campo Service_name.
Control_flag especifica o comportamento de pilha do módulo. Os seguintes valores podem ser usados: requisito, necessário, suficiente e opcional.
Module_path especifica o nome do caminho para o objeto de biblioteca que implementa o módulo. Ele é configurado para /lib/security por padrão.
Module_options/module_args (campos opcionais) especificam as opções ou os argumentos que podem ser passados para os módulos de serviços.

Os módulos são chamados na ordem em que eles são listados no arquivo de configuração, dependendo do que o Control_flag para cada entrada permite. Os valores de control_flag incluem:

Requisite: Todos os módulos necessários em uma pilha devem ser aceitos como um resultado com êxito. Se um ou mais dos módulos necessários falharem, todos os módulos necessários na pilha serão implementados, mas o primeiro erro será retornado.
Sufficient: Se um módulo sinalizado como suficiente obtiver êxito e nenhum módulo anterior ou suficiente falhar, todos os módulos restantes na pilha serão ignorados e o êxito será retornado.
Optional: Se nenhum dos módulos na pilha for necessário e nenhum módulo suficiente obtiver êxito, pelo menos um módulo opcional do serviço/aplicativo precisa obter êxito.

Exemplos de Arquivos de Configuração do PAM

A Tabela 1 mostra alguns exemplos de arquivos de configuração do PAM em vários sistemas operacionais.

Sistema	Encontrado em …	Tipo	Controle (Flag)	Módulo
Red Hat	/etc/pam.d	auth	requerid	/lib/security/pam_unix.so
Red Hat	/etc/pam.d	account	sufficient	/lib/security/pam_unix.so
Red Hat	/etc/pam.d	session	required	/lib/security/pam_limit.so
AIX	/etc/pam.conf	auth	requerid	/usr/lib/security/pam_aix
AIX	/etc/pam.conf	account	required	/usr/lib/security/pam_aix
AIX	/etc/pam.conf	password	required	/usr/lib/security/pam_aix
zSUSE 64-bit \| 32-bit	/etc/pam.conf	auth	required	/lib64/security/pam_unix.so \| /lib/security/pam_unix.so
zSUSE 64-bit \| 32-bit	/etc/pam.conf	account	required	/lib64/security/pam_unix.so \| /lib/security/pam_unix.so
zSUSE 64-bit \| 32-bit	/etc/pam.conf	session	required	/lib64/security/pam_unix.so \| /lib/security/pam_unix.so
Solaris	/etc/pam.conf	auth	required	/usr/lib/security/pam_unix.so.1
Solaris	/etc/pam.conf	account	required	/usr/lib/security/pam_unix.so.1
Solaris	/etc/pam.conf	password	required	/usr/lib/security/pam_unix.so.1
HP-UX	/etc/pam.conf	auth	required	libpam_unix.so.1
HP-UX	/etc/pam.conf	account	required	libpam_unix.so.1
HP-UX	/etc/pam.conf	password	required	libpam_unix.so.1

O "Outro" Arquivo do PAM

O arquivo de configuração padrão do PAM /etc/pam.d é usado por todos os outros serviços que não são explicitamente configurados e talvez seja o arquivo padrão mais simples e robusto do qual o PAM depende. O conteúdo é semelhante ao seguinte:

/etc/pam.d/other File

auth        required     pam_warn.so
auth        required     pam_deny.so
account     required     pam_warn.so
account     required     pam_deny.so
password    required     pam_warn.so
password    required     pam_deny.so
session     required     pam_warn.so
session     required     pam_deny.so

O arquivo é muito simples. Para todos os tipos de módulo, Control_flag é o mesmo: required. Dois módulos são chamados:

Primeiro, pam_warn.so é chamado para registrar informações sobre a tentativa em progresso.

Em seguida, pam_deny.so é chamado apenas para retornar uma falha e impedir que qualquer tipo de conexão ou de autenticação seja executado.

Portanto, qualquer serviço que use o PAM deve ser configurado explicitamente para permitir a autenticação, caso contrário, as tentativas falharão.

Dez etapas para designar um Aplicativo de Login Simples do PAM

Essas 10 etapas ajudam a implementar seu próprio aplicativo PAM e a entender as funções de uma sessão do PAM:

Inclua os arquivos de cabeçalho para a implementação PAM (por exemplo, pam_appl.h, pam_misc.h).

Na função main , inicialize a biblioteca do PAM libpam.so (que carrega os módulos especificados no arquivo de configuração para o aplicativo) usando um manipulador exclusivo.

Tente autenticação para todos os módulos e manipule os cenários de falha.

Verifique os detalhes de credencial e de conta do usuário.

Abra uma nova sessão do PAM.

Configure o ambiente para o usuário usando as credencias.

Quando o usuário estiver concluído, remova a configuração do ambiente do usuário.

Feche a sessão do PAM.

Saia da biblioteca libpam.so com o valor do identificador.

SAIR.

Conclusão

Depender do PAM para ajudar a lutar pelos esforços de autenticação de nível inferior em um todo mais gerenciável é uma maneira de simplificar esse mecanismo de segurança. Neste artigo, você aprendeu:

A arquitetura básica do PAM

Como configurar os módulos do PAM

A descrição de um aplicativo de login do PAM como um guia para entender como eles funcionam.

Configuração do arquivo PAM

2011-09-29T12:46:00.001-03:00

Quando um aplicativo PAM é iniciado, ele ativa o PAM-API.

Esta ativação realiza uma série de tarefas, sendo a mais importante a leitura do arquivo de configuração: /etc/pam.conf. alternativamente, este pode ser o conteúdo do diretório /etc/pam.d. A presença deste diretório fará com que PAM ignore o arquivo /etc/pam.conf.
Esses arquivos do PAM é que vai fazer as tarefas de autenticação.

Visão Geral do PAM

2011-09-28T15:44:00.001-03:00

Para quem não conhece, nós começaremos por um exemplo. Uma aplicação que concede alguns serviços para os usuários; login é um programa. O Login faz duas coisas, ele primeiro verifica se o usuário solicitante é quem ele diz ser e segundo lhe fornece o serviço solicitado: no caso do login o serviço é um comando Shell (bash, tcsh, zsh, etc.) rodando com a identidade do usuário.

Tradicionalmente, o primeiro passo é realizado através da aplicação de Login que solicita ao usuário uma senha e então verifica se a autenticação confere com o sistema, se o usuário é quem diz ser, o sistema vai para o segundo passo. Esta é a tarefa que é delegada ao Linux-PAM.

Do ponto de vista do programador da aplicação (neste caso, a pessoa que escreveu a aplicação de Login), Linux-Pam cuida dessa tarefa de autenticação – verificar a autenticação do usuário.

A flexibilidade do Linux-PAM é que você, o administrador de sistema, tem a liberdade para estipular qual o esquema de autenticação será usado. Você tem a liberdade para configurar o esquema para um ou todas aplicações PAM do seu Linux.

Isto é, você pode autenticar de qualquer coisa desde confiança simples (pam_permit) à algo paranoico como uma combinação de escaneamento de retina, autenticação por voz e uma simples senha.

Pam lida com quatro tipos distintos de gestão. Estes são: gerenciamento de autenticação; gerenciamento de contas; gerenciamento de sessão e gerenciamento de senhas.

A associação de gestão preferencial com o comportamento de uma aplicação é feita com entradas no arquivo de configurações do PAM.

A associação do sistema de gestão preferencial com o comportamento de uma aplicação é feita com entradas no arquivo de configuração relevantes Linux-PAM. As funções de gerenciamento são realizadas por módulos específicos no arquivo de configuração.

As funções de gestão são realizadas por módulos especificados no arquivo de configuração.

Abaixo uma ilustração que a organização geral do PAM:

+--------------------+
| Aplicação: X    |
+--------------------+           /   +------------+      +=============================+
|Autenticação- [---->—\—] Linux – |—< |   Arquivo de Configuração PAM |
|            +             [----<—/—] PAM       |      |=============================|
| conversation()[—+      \   |                |      | X auth …… a.so                               |
+--------------------+    |          +-n—n-----+      | X auth …… b.so                               |
|                           |    |              |    |              |                                               _____ /
|     Usuário        |    A             |    |               |                                      -----‘
|                           |     |             V   A               |_________________´
+--------------------+     + ---------|---|--------------------+----------------+-----------------+
                                           +----u---u--------+              |                      |                      |
                                           |   auth…           |--------[ a ]-------------[ b ]-------------[ c ]
                                           +------------------+
                                           |     acct …          |-------[ b ]--------------[ d ]
                                           +------------------+
                                           |   password    |--------[ b ]--------------[ c ]
                                           +------------------+
                                           |   session        |--------[ e ]--------------[ c ]
                                           +------------------+

A titulo de explicação, a esquerda da figure representa à aplicação; aplicação X. Tal interface de aplicativos com a biblioteca Linux-PAM e não conhece nenhuma das especificidades de seu método de autenticação configurado. A biblioteca Linux-PAM (no centro) consulta o conteúdo do arquivo de configuração do PAM e carrega os módulos que são apropriados para a aplicação X. Esses módulos dividem-se em um dos quatros grupos de gestão (inferior-centro) e são empilhados na ordem em que aparecem no arquivo de configuração. Estes módulos, quando chamado pelo PAM, executa tarefas de autenticação de diferentes aplicações. Informações textuais, exigidos ou oferecidos aos usuários, podem ser trocados através do uso do aplicativo fornecido pela função conversation.

Se um programa vai usar o PAM, então ele tem que ter funções PAM explicitamente codificadas no programa. Se você tem aceso aos código fontes você pode adicionar apropriadamente as funções PAM. Se você não tem acesso ao código fonte, e os binários não incluem funções do PAM, então não é possível usar o PAM.

Introdução ao PAM para Linux

2011-09-27T17:17:00.001-03:00

Linux-PAM (Pluggable Authentication Modules for Linux) é uma coleção de bibliotecas compartilhadas que permite ao administrador de sistema escolher como a aplicação autentica os usuários.

Em outras palavras, sem recompilar uma aplicação adaptada ao PAM, é possível alternar entre o mecanismo de autenticação que ele usa. De fato, pode-se atualizar inteiramente o sistema de autenticação local em afetar os próprios aplicativos.

Historicamente uma aplicação exige que um determinado usuário seja autenticado, e para isso a aplicação teve que ser compilado para usar um mecanismo de autenticação específico. Por exemplo, no caso dos UN*X tradicionais, a identidade do usuário é verificada por uma senha que o usuário digita corretamente. Essa senha, depois de ter sido prefixada por duas vezes, é criptografada (com crypt). O usuário é então autenticado, se essa senha encriptada é idêntica ao segundo campo de entrada do usuário no banco de dados de senha do sistema (o arquivo /etc/passwd). Na maioria dos sistemas UNIX se não todas, as formas de privilégios são feito com base neste sistema de autenticação único. Esse tipo de autenticação vem na forma de um identificador único de usuário (UID) e membros de vários grupos.
Serviços e aplicações são autenticados baseados na identificação (UID) e no grupo (GID) do usuário. Tradicionalmente, os membros dos grupos são baseado nas entradas do arquivo /etc/group.

Este é o objetivo do Projeto Linux-PAM para separar o desenvolvimento de permissões de privilégio de software do desenvolvimento de redes seguras e esquemas de autenticação apropriadas. Isto é realizado através de uma biblioteca de funções que um aplicativo pode usar para solicitar que um usuário seja autenticado. Esta biblioteca PAM é configurada localmente com um arquivo de sistema, /etc/pam.conf (ou uma serie de arquivos locais em /etc/pam.d/) para autenticar uma solicitação do usuário dos módulos de autenticação disponíveis localmente. Os módulos são geralmente localizados no diretório /lib/security ou /lib64/security e toma a forma de arquivos de objetos carregável dinamicamente.

Informix–Conexão Segura

2011-09-19T16:43:00.001-03:00

Pode-se administrar a segurança das conexões do servidor do banco de dados usando a autenticação e os processos de autorização.

Um usuário deve ser autenticado com uma instalação segura fornecendo um ID de usuário válido e uma senha segura que correspondam as credenciais de uma conta de usuários do sistema operacional de onde esta instalado o Informix. Um tipo de método de autenticação é baseada no próprio sistema operacional, em que um ID de usuário e senha são passadas diretamente para o sistema operacional para verificação. Podemos também configurar as autenticações de conexões usando módulos de autenticação. Dependendo do sistema operacional, podemos usar um dos seguintes tipos de módulos de autenticação:

Autenticação pelo PAM para Informix rodando em UNIX ou Linux. Podemos utilizar esse modulo para implementar mecanismos alternativos de autenticação. Você pode usar os módulos para implementar um mecanismo de autenticação alternativa que você cria para uma aplicação especifica.
Suporte de autenticação à Lightweight Directory Access Protocol (LDAP) para Windows. Utilize o módulo LDAP quando quiser utilizar a autenticação do informix pelo LDAP.

Usuários autenticados devem especificar um banco de dados ao qual se conectar. Um usuário pode executar ações em determinados banco de dados ou acessar objetos, desde que tenham sido autorizados pelo DBA. Por exemplo, usuários com privilégios de CONNECT pode se conectar a um banco de dados e executar consultas, enquanto que usuários com privilégios RESOURCE podem criar objetos.

Você pode garantir que senhas de autenticação de conexão são seguras, criptografando usando um módulo de suporte de comunicação (CSM). O CSM com senha simples (SPWDCSM) fornece criptografia de senha. SPWDCSM esta disponível para todas as plataformas.

Se quiser pode-se autenticar por um ambiente Single Sign-On (SSO), pode-se usar também o Generic Security Services CSM (GSSCM) para implementar uma autenticação Kerberos. Além disso, o protocolo Kerberos tem vários recursos internos que podem proporcionar benefícios de segurança, mesmo que simples e senhas CSM criptografadas. Autenticação SSO verifica a identidade de um usuário,

SSO autenticação verifica a identidade de um usuário e facilita o gerenciamento centralizado de usuários e senhas. Se os serviços de confidencialidade e integridade estão habilitados no GSSCSM, o Kerberos criptografa as transmissões de dados e assegura que a troca de dados entre o usuário e o servidor de banco de dados seja uma conexão segura.

Conexões com o HDR não podem usar esses módulos de autenticações, mas pode funcionar com estes módulos, restringindo as portas de rede específica para a replicação e conexões de alta disponibilidade.

Pode-se configurar o IBM Informix para verificar se o ID do usuário que está executando o programa corresponde ao ID do usuário que está tentando se conectar ao banco de dados.

Você pode configurar o IBM Informix para verificar se o ID do usuário que está executando o programa corresponde ao ID do usuário que está tentando se conectar ao banco de dados.

Você pode limitar os ataques de negação de serviço para impedir que conexões legítimas para o servidor de banco de dados seja bloqueada.

Abaixo mais detalhes sobre a autenticação PAM

Pluggable authentication modules para sistemas rodando no UNIX ou Linux

O Pluggable Authentication Module (PAM) é uma estrutura de módulos muito bem definidas para suportar diferentes tipos de autenticação, originalmente desenvolvido pela Sun Microsystems. PAM é suportado em ambas plataformas de 32 e 64 bits, nos sistemas Solaris, Linux, HP-UX e AIX.

Administradores de Sistema pode usar o PAM para implementar diferentes mecanismos de autenticação para diferentes tipos de aplicações. Por exemplo, a autenticação de login no UNIX pode ser diferente da autenticação de um servidor de banco de dados. PAM permite muitos cenários em uma única maquina, porque os serviços de autenticação são aplicadas em camadas.

Administradores de Sistema pode usar o PAM para habilitar um aplicativo para selecionar o método de autenticação conforme exigido,

PAM para habilitar um aplicativo para selecionar o autenticação conforme exigido e empilhamento do modulo. Alguns módulos podem ser empilhados um após o outro, permitindo assim que a aplicação será autenticado de varias maneiras, antes de conceder acesso. PAM fornece um conjunto de APIs para suportar a autenticação, gerenciamento de contas, gerenciamento de sessões e gerenciamento de senhas.

O Administrador de Sistema pode habilitar ou desabilitar o uso do PAM.Por padrão, o servidor de banco de dados utiliza o mecanismo de autenticação tradicional do Informix ( que se baseia no mecanismo BSD – rhosts) a fim de evitar mudanças importantes para os utilizadores.

Para utilizar o PAM com o IBM Informix:

O Banco de dados Informix deve estar em um Sistema Operacional que suporta o PAM.
Aplicações Clientes deve ser escrito com um versão mais recente do SDK.
O serviço do PAM deve estar devidamente configurado no Sistema Operacional.
Deve-se decidir qual o método de autenticação que o PAM vai prover: conexão do cliente através de password, digitando uma senha correta em prompt ( por exemplo, um servidor de autenticação RADIUS) ou ambas as combinações.
Linux somente: Quando configurar o PAM para exigir senha e autenticação baseada em resposta, o serviço do PAM sempre ignora a senha enviada na solicitação de conexão do cliente e pede a senha uma segunda vez.
Você deve garantir que a Replicação e clusters de alta disponibilidade não serão afetadas pela autenticação PAM.
Deve-se modificar o arquivo sqlhosts no servidor, tanto para a aplicação quanto para o servidor de bando de dados;

O serviço PAM

O serviço PAM identifica o módulo PAM.

O módulo PAM tipicamente esta localizado no diretório /etc/security e seus parâmetros são listados no arquivo /etc/pam.conf.

No Linux, o arquivo /etc/pam.conf pode ser substituído por um diretório chamado /etc/pam.d, onde há um arquivo para cada serviço. Se /etc/pam.d existe, /etc/pam.conf é ignorado pelo Linux.

Métodos de autenticação com o módulo PAM

O módulo PAM determinará se um usuário poderá autenticar-se fornecendo uma senha, respondendo corretamente a um desafio ou ambos.

A implementação PAM no IBM Informix tira proveito do fato de que as solicitações de conexão explicita, o cliente envia uma senha para o servidor. Pode-se configurar o PAM para fazer esta senha o único requisito para autenticação no servidor.

Quando configurar o PAM para usar o protocolo baseado em resposta, a autenticação é concluída depois que o usuário digita a resposta correta para uma pergunta ou outra. Com este modo de autenticação um aplicativo deve ser projetado para responder ao desafio corretamente antes de conectar ao servidor de banco de dados. Pode-se configurar a autenticação do PAM para utilizar somente o modo baseado em resposta, de forma que o PAM ignore as senhas de conexão do cliente.

Linux somente: Se o PAM é configurado para utilizar o protocolo baseado em resposta, a senha vindo dos clientes são sempre ignoradas. O serviço PAM no Linux pede a senha do usuário uma segunda vez se ambos os modos de autenticação estão habilitados.

Tamanho necessário da pilha para o PAM

Pode-se customizar o tamanho das pilhas disponíveis para o módulos do PAM.

O PAM carrega recursos do Sistema Operacional ou módulos do PAM fornecidos por terceiros (bibliotecas compartilhadas) para as threads do Informix. Os requisitos do tamanho das pilhas não podem ser previsto. Para uma instancia, no Linux alguns módulos exigem mais do que 128 KB de espaço de pilha. Use o parâmetro de configuração PAM_STACKSIZE para modificar o valor.

Por exemplo, configure o parâmetro PAM_STACKSIZE no arquivo onconfig como abaixo:

PAM_STACKSIZE 64 # Stack size needed for the PAM modules (Kbytes)

No UNIX, o valor padrão do PAM_STACKSIZE é 32 KB.

No Linux, o valor padrão é 128 KB mais o valor do STACKSIZE.

Configurando um servidor de banco de dados para utilizar o PAM

Para configurar um servidor para utilizar o PAM, o administrador de sistemas devera saber:

O nome do modulo PAM;
Se o módulo PAM esta utilizando o método baseado em respostas além de aceitar um nome de usuário e senha.

Abaixo um exemplo do arquivo sqlhosts configurado para utilizar a autenticação PAM baseado em resposta:

prdsoc onsoctcp isis prdsrv s=4, pam_serv=(pam_cha1), pamauth=(challenge)

Abaixo um exemplo do arquivo sqlhosts configurado para utilizar a autenticação PAM baseado em autenticação com senhas:

prdsoc onsoctcp isis prdsrv s=4, pam_serv=(pam_pass), pamauth=(password)

Processadores PA-RISC ( Precision Architeture Risc)

2011-08-11T12:05:00.001-03:00

Todos os HP 9000 da serie 800 utilizavam a tecnologia “Precision Architecture Risc (PA-Risc)”. O PA-RISC esta construído dentro dos princípios de Reduced instruction Set Computing (RISC) o que implica a implementação de poucos componentes fornecendo uma confiabilidade superior que quando comparado com sistemas CISC (Complex Instruction Set Computer).

Os estudos mostram que equipamentos CISC gastavam 80% do tempo executando instruções simples (soma, subtração, etc) e os restantes 20% em operações complexas, fazendo uso ainda dos microcódigo (microcódigo: ocorre o acesso à instrução e dentro do processador tem um código que acessa o hardware). No Risc isso não acontece porque tudo já é executado em hardware (elimina microcódigo) as instruções complexas ficam por conta do compilador e todas as operações são feitas em registradores.

A base do PA-RISC é um set de instruções contendo 140 instruções de formato fixo cuidadosamente selecionadas.

O paralelismo de instruções, pipelining (técnica que sobre passa o processamento de instruções, de modo que uma instrução pode iniciar sua execução antes que a anterior tenha terminado) é utilizado eficientemente pelo HP PA-RISC em 5 estágios, aliados a compiladores otimizados e ao seu projeto Load/Store, melhoram a execução de instruções em um único ciclo e expandem a performance do sistema.

O PA-RISC utiliza o sistema operacional HP-UX que é o sistema operacional SYSTEM V da AT&T com implementações desenvolvidas pela Hewlett-Packard como: gráficos, suporte a linguagem nativa e algumas construções do Unix BSD.

O Hardware do PA-Risc

Certas operações do sistema, como o boot, podem necessitar da especificação do endereço de hardware. Portanto, é interessante que os administradores de sistemas conheça a configuração de seu hardware com os respectivos endereços.

Cada periférico possui um único endereço de hardware que identifica a path de conexão da CPU para o device propriamente dito. Essa path é composta pelo endereço de todos os elementos que aparecem entre a CPU e o periférico.

SPU – System Processing Unit. São as unidades de processamento do sistema, sendo basicamente a CPU e memoria.

BUS – São circuitos através do qual os dados trafegam entre os módulos do hardware (CPU, Memoria, Chanel Adapter, device adapter). As placas dos periféricos são conectadas no bus. As maquinas de BUS HP-PB (HP-Precision Bus) com exceção da 890, utilizam somente um BUS, já o modelo 890 utiliza 2 estruturas de BUS; PMB (Processor Main Bus) para processador e memória e HP-PB para I/O.

SLOTS – Local físico onde serão conectados as placas. Cada slot tem um número/letra. Nas maquinas HP-PB, todos os slots são conectados no Bus de precisão.

Device Adapter – É a interface que liga o Bus ao periférico, são conhecidos também I/O cards. Os principais devices adapters são:

SCSI – Small Computer System Interface. Tecnologia nova que trabalha com conect/desconect para o Bus, permitindo que periféricos de velocidade diferentes sejam conectados a mesma placa (Discos, Fitas, DVDs, etc).
Pode-se conectar até 7 devices SCSI para cada adaptador (endereçados de 0 a 6): O ultimo device SCSI deve ter um terminador. O comprimento do cabo não deve exceder 6m.
HP-IB – HP Interface Bus – Suporta Discos, Fitas, drivers DVD-ROM, impressoras e ploters. Este Device Adapter tem função para aqueles que possuem periféricos HP-IB antigos e querem aproveita-los. Uma desvantagem deste Device Adapter é o fato de não permitir a conexão de periféricos com velocidades diferentes ( Discos e Fitas por exemplo).
Pode-se conectar até 4 discos HP-IB. O comprimento do cabo não deve exceder 20m, para interface de velocidade padrão e 15m, para alta velocidade.
Um extensor pode ser utilizado para transmissões a distancia entre SPU e o periférico atingido, até 1.25km (exceto para discos).
MUX – Suporta qualquer ligação serial RS-232, plotters, Access Port e alguns podem ligar modems. Podem ser de 8 e de 16 saídas. O comprimento do cabo pode estar entre 5 e 15 m.
LAN – Local Área Network. Conecta redes padrão Ethernet e IEEE 802-3.
GPIO – General Purpose I/O. Device Adapter utilizado para Conectar periféricos específicos.
PSI – Placa programável onde se carrega os protocolos IBM SNA ou X25.

Processadores Itanium

2011-08-11T09:18:00.001-03:00

Tambem Conhecido como IA-64 foi desenvolvido pela Intel e HP, para plataformas SMP de 64 bits “puro-sangue”.

A tecnologia Itanium não usa a arquitetura RISC nem CISC, na verdade a Intel criou uma nova arquitetura chamada de EPIC. Aqui se inicia a 8ª Geração de Processadores.

Esse processador é incompatível com Sistemas Operacionais desenvolvidos para os processadores da linha X86-64, pois estes são compatíveis com 32 e 64 bits.

Fontes de Pesquisas: wikipedia.org, clube do hardware, documentos do site da HP e Intel

Historia do Itanium

História

Desenvolvimento: 1989-2000

Em 1989, a HP determinou que as arquiteturas reduced instruction set computer (RISC) estavam se aproximando do limite de processamento de uma instrução por ciclo.

A HP começou a estudar uma nova arquitetura, mais tarde nomeado Explicitly Parallel instruction Computing (EPIC).

Essa arquitetura permite que o processador execute múltiplas instruções em cada ciclo de clock. Essa arquitetura de very long instruction word (VLIW), em que uma única palavra de instrução contém instruções múltiplas. Com a EPIC, o compilador determina antecipadamente quais instruções podem ser executadas ao mesmo tempo, tão simplesmente o microprocessador executa as instruções e não precisa definir mecanismos para determinar quais as instruções executar em paralelo.

O principal objetivo desta abordagem é primeiramente permitir uma mais profunda inspeção do código, identificando oportunidades adicionais para execução paralela, e, depois, para simplificar o design do processador e reduzir o consumo de energia, eliminando a necessidade de circuitos de programação para o tempo de execução.

A HP determinou que já não era rentável para os sistemas individuais corporativos das empresas, como ela própria, desenvolver microprocessadores proprietários, então a HP buscou uma parceria com a Intel em 1994 para desenvolver a arquitetura IA-64, que derivou da EPIC. Intel estava disposta a empreender um esforço de desenvolvimento muito grande na IA-64, na expectativa de que o microprocessador resultante seria utilizado pela maioria dos fabricantes de sistemas das empresas. A HP e a Intel deram início a um grande esforço de desenvolvimento conjunto com a meta de entregar o primeiro produto, Merced, em 1998. Durante o desenvolvimento, Intel, HP e analistas da indústria previram que IA-64 iria dominar servidores, workstations e desktops high-end, e eventualmente suplantar as arquiteturas RISC e complex instruction set computer (CISC) para todos os aplicativos de uso geral. A Compaq e Silicon Graphics decidiu abandonar desenvolvimento das arquiteturas Alpha e MIPS, respectivamente, com intenção de migrar para IA-64. Vários grupos desenvolveram sistemas operacionais para a arquitetura, incluindo Microsoft Windows, Linux e variantes UNIX, tais como HP-UX, Solaris, Tru64 UNIX, e Monterey/64 (as três últimas foram canceladas antes de chegar ao mercado). Em 1997, tornou-se evidente que a arquitectura IA-64 e o compilador eram muito mais difíceis de implementar do que se pensava inicialmente, e a entrega de Merced começou a escorregar. As dificuldades técnicas incluindo o transistor de altas contagens necessárias para apoiar as largas instruções e os caches de grandes dimensões. Houve também problemas estruturais no âmbito do projecto, como os dois elementos da equipe conjunta utilizarem métodos diferentes e terem diferentes prioridades. Desde que o Merced foi o primeiro processador EPIC, o esforço de desenvolvimento encontrou mais problemas imprevistos do que a equipe estava acostumada. Além disso, o conceito EPIC depende de capacidade do compilador que nunca haviam sido implementadas antes, de forma que mais investigação era necessário. A Intel anunciou o nome oficial do processador Itanium, em 4 de outubro de 1999. Em poucas horas, o nome Itanic havia sido cunhado em um newsgroup da Usenet, uma referência ao Titanic, o "transatlântico inafundável" que afundou em 1912. Itanic desde então tem sido frequentemente utilizado por The Register, Scott McNealy, e outros[o que implica que o investimento multibilionário no Itanium e à enorme expectativa precoce seria seguido por sua morte relativamente rápida.

Itanium (Merced): 2001

Até o momento que o Itanium foi lançado em junho de 2001, seu desempenho não era superior aos concorrentes processadores RISC e CISC. O Itanium competiu no low-end (principalmente 4-CPU e sistemas menores) com servidores baseados em processadores x86, e em high-end com arquitetura IBM, POWER e a Sun Microsystems com arquitetura SPARC. A Intel reposicionou o Itanium para focalizar no negócio high-end e computação HPC, na tentativa de duplicar o sucesso horizontal do x86 no mercado (isto é, única arquitetura, vários fornecedores de sistemas). O sucesso desta versão do processador inicial foi limitada a substituir PA-RISC em sistemas HP, Alpha em sistemas Compaq e MIPS em sistemas SGI, embora a IBM também entregou um supercomputador baseado neste processador. POWER and SPARC manteve-se forte, enquanto a arquitetura 32-bit x86 continuou a crescer para dentro do espaço da empresa. Com as economias de escala, alimentada pela sua enorme base instalada, x86 manteve-se o eminente "horizonte" na arquitetura em computação empresarial. Apenas alguns milhares de sistemas que usam o processador Itanium original “Merced” foram vendidos, devido ao desempenho relativamente fraco, alto custo e disponibilidade de software limitado. Reconhecendo que a falta de software poderia ser um problema sério para o futuro, a Intel fez milhares destes primeiros sistemas disponíveis para os fornecedores de software independentes (ISVs) para estimular o desenvolvimento. HP e Intel trouxe a próxima geração do processador Itanium 2 ao mercado um ano depois.

Itanium 2: 2002-presente

Itanium 2 em 2003

O processador Itanium 2 foi lançado em 2002, e foi comercializado para servidores corporativos e não para toda a gama de computadores high-end. O primeiro Itanium 2, com o codinome de McKinley, foi desenvolvido em conjunto pela HP e Intel. Ele aliviava muitos dos problemas de desempenho do processador Itanium original, que foram causados por um subsistema de memória ineficiente. McKinley continha 221 milhões de transistores, dos quais 25 milhões foram para a lógica, medido 19,5 milímetros de 21,6 mm (421mm 2)e foi fabricadas em 180 nm, volume de processamento CMOS com seis camadas de metalização de alumínio. Em 2003, a AMD lançou o Opteron, que implementou a sua arquitetura de 64-bit (x86-64). Opteron ganhou rápida aceitação no mercado de servidores corporativos porque forneceu uma atualização fácil de x86. A Intel respondeu através da implementação da arquitetura x86-64 em seus microprocessadores Xeon em 2004. A Intel lançou um novo Itanium 2 membro da família, codinome Madison, em 2003. Madison usava um processo de 130 nm e foi a base de todos os novos processadores Itanium até Montecito ser lançado em junho de 2006. Em março de 2005, a Intel anunciou que estava trabalhando em um novo processador Itanium, codinome Tukwila, a ser lançado em 2007. Tukwila teria quatro núcleos de processador e substituirá o BUS do Itanium com uma nova interface comum de sistemas, que também seria usado por um novo processador Xeon. Mais tarde naquele ano, a Intel revisa a data de entrega do Tukwila para final de 2008. Em novembro de 2005, os principais fabricantes de servidores Itanium se juntaram com a Intel e um número de fornecedores de software para formar o Itanium Solutions Alliance para promover a arquitetura e acelerar a portabilidade de software. A Aliança anunciou que seus membros iriam investir US $ 10 bilhões em soluções Itanium no final da década. Em 2006, a Intel entregou o Montecito, um processador dual-core, que praticamente dobrou o desempenho e diminuiu o consumo de energia por cerca de 20 por cento. A Intel lançou a versão Itanium atual, codinome Montvale, em novembro de 2007. Em maio de 2009, o cronograma para Tukwila, e seu acompanhamento foi novamente revisto, com liberação para OEMs prevista para o primeiro trimestre de 2010. Em comparação com a família de processadores Xeon Server, Itanium não é um produto de alto volume para Intel. A Intel não divulgou o número de produção, mas um analista da indústria estima que a taxa de produção foi de 200.000 processadores por ano em 2007. Segundo o Gartner, o número total de servidores Itanium vendidos por todos os fornecedores em 2007 foi de cerca de 55.000. Isso se compara com os 417.000 servidores RISC (espalhados por todos os vendedores RISC) e 8,4 milhões de servidores x86. De 2001 a 2007 a IDC reporta que um total de 184.000 sistemas baseados em Itanium foram vendidos. Para o mercado de sistemas, o combinado POWER / SPARC / Itanium, em um relatório da IDC informa que o POWER captou 42% e SPARC captou 32%, enquanto as receitas baseadas no sistema Itanium chegaram a 26% no segundo trimestre de 2008. De acordo com um analista da IDC, em HP 2007 representou, talvez, 80% das receitas sistemas Itanium. Segundo o Gartner, a HP em 2008 representaram 95% das vendas Itanium.

A Intel tem amplamente documentado o conjunto de instruções de processadores e microarquitetura, e da imprensa técnica forneceu revisões. A arquitetura foi renomeado várias vezes durante sua história. HP inicialmente chamou-PA-WideWord. Intel mais tarde chamou IA-64, depois de processadores Itanium Architecture (IPA), antes de se estabelecer em Intel Itanium Architecture, mas ainda é amplamente referido como IA-64. É uma arquitetura de 64 bits, totalmente paralela rica em registros. A base da palavra de dados é de 64 bits, byte endereçável. O espaço de endereçamento lógico é 2 64 bytes. A arquitetura implementa pressuposição, especulação, e previsão de desvio. Ele usa um mecanismo de hardware para renomeação de registro, em vez de simples registo de janelas para a passagem de parâmetro. O mesmo mecanismo também é utilizado para permitir a execução paralela de loops. Especulação, previsão, pressuposição, e renomeação estão sob o controle do compilador: cada instrução inclui bits extras para isso. Esta abordagem é a característica distintiva da arquitetura. A arquitetura implementa 128 registros inteiros, 128 registros de ponto flutuante, 64 pressuposição de um bits, e oito registros derivados. Os registros de ponto flutuante de 82 bits preserva a precisão dos resultados intermediários.

Execução da instrução

Cada instrução 128-bit contém três instruções, e a busca do mecanismo pode ler as duas instruções por clock do cache L1 no pipeline. Quando o compilador pode tirar o máximo proveito deste, o processador pode executar seis instruções por ciclo de clock. O processador tem trinta unidades de execução funcional em onze grupos. Cada unidade pode executar um subconjunto específico do conjunto de instruções, e cada unidade é executado a uma taxa de uma instrução por ciclo de execução, a menos barreiras à espera de dados. Embora nem todas as unidades de participação em um grupo executam subconjuntos idênticos do conjunto de instruções, instruções comuns podem ser executadas em várias unidades.

Os grupos de unidade de execução incluem:

Seis ALUs de propósito geral, duas unidades integras, uma unidade de mudança
Quatro unidades de dados de cache
Seis unidades de multimídia, duas unidades de deslocamento paralelo, um multiplicador paralelo, uma contagem de população
Duas unidades com ponto flutuante de 82-bits com acumulação-múltipla, Duas unidades com ponto flutuante SIMD com acumulação-múltipla (duas operações de 32-bit cada)
Três unidades derivadas

O compilador pode freqüentemente agrupar instruções em conjunto de seis que podem ser executadas ao mesmo tempo. Desde que a unidades de ponto flutuante implemente uma operação de acumulação-múltipla, uma instrução de um único ponto flutuante pode executar o trabalho de duas instruções quando a aplicação requer uma multiplicação seguido por um acréscimo (Isto é muito comum em processamento científico). Quando isso ocorre, o processador pode executar quatro FLOPS por ciclo. Por exemplo, a 800 MHz Itanium tiveram uma avaliação teórica de 3,2 g FLOPS e os mais rápidos processadores Itanium 2, a 1,67 GHz, foi avaliado em 6,67 GFLOPS.

Arquitetura de Memória

De 2002 a 2006, os processadores Itanium 2 compartilhavam uma hierarquia de cache comum. Eles tinham 16 KiB de cache L1 de instruções e 16 KiB de Nível 1 cache de dados. A cache L2 foi unificada (tanto de instruções e dados) e é de 256 KiB. A cache de nível 3 também foi unificada e varia em tamanho de 1,5 MiB a 24 MiB. Os 256 KiB de cache L2 contém lógica suficiente para lidar com operações de semáforo sem perturbar a unidade lógica aritmética principal (ALU). A memória principal é acessada através de um BUS para uma off-chip chip set. O Itanium 2 BUS foi inicialmente chamado de McKinley BUS, mas agora é normalmente referido como o Itanium BUS. A velocidade do BUS vem aumentando com lançamentos novos processadores. As transferências de BUS 2 × 128 bits por ciclo de clock, então a 200 MHz BUS McKinley transfere 6,4 GiB / s), e os 533 MHz BUS Montecito transfere17,056 GiB / s Alterações de arquitetura Processadores Itanium lançado antes de 2006 tinha suporte de hardware para o IA-32 arquitetura para permitir suporte para aplicativos de servidor legado, mas o desempenho para o código IA-32 era muito pior do que para o código nativo e também pior do que o desempenho dos processadores x86 contemporâneos. Em 2005, a Intel desenvolveu o IA-32 Execution Layer (IA-32 EL), um emulador de software que fornece um melhor desempenho. Com Montecito, da Intel, portanto, eliminado suporte de hardware para IA-32 do código. Em 2006, com o lançamento do Montecito, a Intel fez uma série de melhorias para a arquitetura do processador de base, incluindo:

Hardware multithreading: Cada núcleo do processador mantém contexto para duas linhas de execução. Quando uma barreira de contexto aparece durante o acesso a memória, o outro segmento pode executar. Intel chama isso de “coarse multithreading” para distingui-lo da tecnologia hiper-threading, A Intel integra em alguns processadores x86 e x86-64. “Coarse multithreading” está bem adaptado à arquitetura Intel Itanium e resulta em um ganho de desempenho significativo.
Suporte de hardware para virtualização: Intel adicionou Intel Virtualization Technology (Intel VT), que fornece ao hardware assistências para funções de virtualização do núcleo. A virtualização permite que um software “hypervisor” para executar várias instâncias do sistema operabcional do processador simultaneamente.
Melhorias Cache: Montecito acrescentado um cache L2 dividido, que incluí 1 cache L2 dedicado MiB para obter instruções. O original 256 KiB de cache L2 foi convertido para um cache de dados dedicado. Montecito também incluídos até 12 MiB de cache on-die L3.

Suporte de Hardware

A partir de 2009 Vários fabricantes oferecem sistemas Itanium, incluindo HP, SGI, NEC, Fujitsu, Hitachi, e Groupe Bull. Além disso, a Intel oferece um chassi que podem ser usados por integradores de sistema para construir sistemas Itanium. A HP, o único dos principais fabricantes da indústria de quatro servidores para oferecer sistemas baseados em Itanium, hoje, produz pelo menos 80% de todos os sistemas Itanium. A HP teve 7200 sistemas vendidos no primeiro trimestre de 2006. A maior parte dos sistemas vendidos são servidores corporativos e máquinas para a computação em larga escala técnica, com um preço médio de venda por sistema extra de E.U. $ 200.000. Um sistema típico utiliza oito ou mais processadores Itanium.

Chipsets

A Interface BUS Itanium se comunica com o restante do sistema através de um chipset. Fabricantes de servidores Enterprise diferenciam seus sistemas através da concepção e desenvolvimento de chipsets que a interface do processador de memória, interligações, e os controladores de periféricos. O chipset é o coração do sistema de arquitetura de nível para cada projeto do sistema. Desenvolvimento de um chipset custa dezenas de milhões de dólares e representa um importante compromisso para a utilização do Itanium. A IBM criou um chipset em 2003, e a Intel em 2002, mas nenhum deles desenvolveu chipsets para suportar novas tecnologias como DDR2 ou PCI Express... atualmente, existem chipsets modernos para sistemas de apoio às tecnologias, como são fabricados pela HP, Fujitsu, SGI, NEC e Hitachi. O próximo processador Itanium (Tukwila) foi desenhado para compartilhar um chipset comum com o processador Intel Xeon EX (processador Intel Xeon projetado para quatro processadores e servidores maiores). O objetivo é agilizar o desenvolvimento do sistema e reduzir os custos para OEMs de servidor, muitos dos quais desenvolvem tanto para servidores Itanium quanto para Xeon.

O mais novo processador Intel Itanium série 9300 (Tukwila)

Os servidores baseados em Itanium fornecem desempenho escalável e poderoso para ambientes de UNIX e mainframe, e também excelente disponibilidade para as suas aplicações mais críticas. Esses sistemas são ideais para as cargas de trabalho mais intensas de hoje, como aplicações de banco de dados, inteligência corporativa e planejamento de recursos corporativos (ERP).

O mais novo processador Intel Itanium série 9300 fornece mais do dobro do desempenho da geração anterior, além de até seis vezes mais largura de banda de memória, até nove vezes mais largura de banda de interconexão e até oito vezes mais capacidade de memória. Fornece uma incrível escalabilidade e uma base poderosa, flexível e com maior eficiência energética para virtualização, consolidação e gerenciamento de carga de trabalho do data center.

Configuração de Clusters

2011-08-10T17:30:00.001-03:00

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;
Conheça os requisitos do Banco de Dados;
Conheça os requisitos do Servidor de Banco de dados;
Configuração da Conectividade.

Cada item desses tópicos serão explicados abaixo.

Você pode configurar seu sistema para usar o protocolo SSL (Secure Sockets Layer), um protocolo de comunicação que garante a privacidade e integridade dos dados transmitidos através da rede, para comunicação HDR. Você pode usar o protocolo SSL para conexão entre o servidor primário e secundário e para conexões com RS (Remote Standalone) e SD (Shared Disk) de servidores secundários em uma configuração de alta disponibilidade. Para obter informações de como usar o protocolo SSL, veja a sessão “Secure Sockets Layer Communication Protocol Encryption” do IBM Informix Security Guide.

Requisitos de Hardware e Sistema Operacional

Para o funcionamento do cluster de alta disponibilidade, o hardware deve atender certos requisitos.

O hardware deve atender aos seguintes requisitos:

O servidor primário e secundário deve ser capaz de executar a mesma imagem do IBM Informix, mesmo que eles não tenha hardware ou o sistema operacional idêntico. Por exemplo, você pode usar servidores com diferentes sistemas operacionais Linux de 32 bits, porque esses sistemas operacionais pode executar a imagem do Informix. Nessa situação, você não pode adicionar um server com um Linux 64-bit porque esse sistema operacional requer uma imagem de Informix diferente. Cheque o arquivo “machine notes”: você pode usar qualquer combinação de hardware e sistema operacional listado nesse arquivo.
O hardware que roda como primário e secundário deve suportar redes.
A quantidade de espaço em disco alocado para os dbspaces no servidor primário e secundário devem ser iguais. O tipo de espaço em disco é irrelevante; você pode usar uma mistura de raw device com file system.
Os chunks em cada servidores devem ter os mesmos caminhos. Links simbólicos são permitidos para a plataforma UNIX, mas não para a plataforma Windows.

Requisitos do Banco de Dados

O Banco de dados deve atender os seguintes requisitos:

Todos os dados devem ser logged.
Todos os bancos de dados que vai ser replicado devem estar em modo transacional.

Este requisito é importante porque o servidor de banco de dados secundário usa registros de logical-log vindo do servidor primário para atualizar os dados que ele gerencia. Se o banco de dados gerenciado pelo servidor primário não esta em modo transacional, para esse banco de dados não será gerado registros de logs, sendo assim o servidor de banco de dados secundário não terá meios para atualizar os dados.
Os dados devem residir no mesmo dbspace ou sbspaces.
Se o seu banco de dados primário tem objetos armazenados em blobspaces, modificações nos dados dentro desses blobspaces não é replicado como parte normal do processamento HDR. No entanto, objetos grandes mas simples são replicados.
Objetos grandes, que são armazenados em sbspaces, são replicados. Os sbspaces devem estar em modo transacional. Tipos definidos por usuários (UDTs) são replicados, a menos que estejam armazenados em arquivos do sistema operacional. Tipos de dados com out-of-row são replicados se os dados estão armazenados em sbspace ou em uma tabela diferente no mesmo servidor de banco de dados.
O servidor secundário não pode usar compressão de disco.
Se você usar o recurso do Informix de compressão de disco, dados que são comprimidos na tabela de origem vão ser comprimidos nas tabelas de destino. Você não pode executar compressão no HDR secundário, RS secundário ou SD secundário, porque o HDR destino deve ter as mesmas configurações de dados e físico como o servidor de origem

Requisitos do Servidor do Banco de Dados

Para um par cluster de servidores de alta disponibilidade funcionar, você deve configurar totalmente cada um dos servidores. Você pode então usar os aspectos relevantes para configurar os pares de servidores.

Estes tópicos descrevem as considerações de configuração a seguir para os pares de cluster:

Versão do Banco de dados;
Configuração do dbspace e chunk;
Tamanhos de paginas não padrão em um ambiente HDR;
Espelhamento;
Configuração do Physical-log;
Dbspace e dispositivo de backup para logical-log;
Configuração do Logical-log
Parâmetros de configurações do HDR;

Versão do Banco de dados

As versões do Informix no servidor primário e secundário deve ser idêntica.

Configuração do dbspace e chunk

o numero de dbspaces, o numero de chunks, seus tamanhos, seus caminhos e seus offsets devem ser idênticos no servidor de banco de dados primário e secundário. Além disso, a configuração deve conter pelo menos um dbspace temporário se o servidor HDR secundário for usado para criação de relatórios de atividades.

Somente no UNIX:

Você poderá usar links simbólicos para os chunks.

Importante: Se você não utilizar links simbólicos para os chunks, você não poderá alterar os caminhos facilmente

Os seguintes parâmetros no ONCONFIG deve ter o mesmo valor em cada servidor de banco de dados:

ROOTNAME
ROOTOFFSET
ROOTPATH
ROOTSIZE

Tamanhos de paginas não padrão em um ambiente HDR

O tamanho de paginas de um dbspace e as especificações de buffer são automaticamente propagadas a partir do servidor primário para o secundário. Embora ambos os servidores devem ter o mesmo buffer pools, o numero de buffer no buffer pool não precisam corresponder.

Espelhamento

Você não deve configurar o parâmetro MIRROR para o mesmo valor nos dois servidores de banco de dados; você pode habilitar espelhamentos em um servidor de banco de dados e desabilitar o espelhamento no outro. Entretanto, se você especificar um chunk espelho para um chunk root do servidor primário, você deve também especificar um chunk espelho para o chunk root do servidor secundário. Portanto, os seguintes parâmetros do ONCONFIG devem ser configurados com o mesmo valor em ambos os servidores:

MIRROROFFSET
MIRRORPATH

Configuração do Physical-log

O Physical-log deve ser idêntico em ambos os servidores. Os seguintes parâmetros do ONCONFIG devem ter os mesmos valores em cada servidores:

PHYSBUFF
PHYSFILE

Dbspace e dispositivo de backup para logical-log

Você pode especificar diferentes dispositivos para o servidor primário e secundário.

Se você usar o ON-Bar, configure os parâmetros de configuração do ON-Bar com os mesmos valores em ambos os servers. Para informações dos parâmetros do ON-Bar veja o IBM Informix Backup and Restore Guide.

Se você usa o ontape, o tamanho e o bloco do dispositivo devem ser idênticos. A seguir os parâmetros do ONCONFIG que devem ser o mesmo valor em ambos os servidores:

LTAPEBLK
LTAPESIZE
TAPEBLK
TAPESIZE

Configuração do Logical-log

Todos os registros de logs são replicados para o servidor secundário. Você pode configurar o mesmo numero de Logical-log e também com o mesmo tamanho em ambos os servidores. A seguir os parametros do ONCONFIG que devem ser o mesmo valor em ambos os servidores:

LOGBUFF
LOGFILES
LOGSIZE
DYNAMIC_LOGS

Logical-logs que são adicionados dinamicamente no servidor primário são replicados automaticamente para o servidor secundário. Embora o valor de DYNAMIC_LOGS no servidor secundário não tem nenhum efeito, DYNAMIC_LOGS mantem em sincronia com os valores do servidor primário.

Parâmetros de configurações do HDR

Os seguintes parâmetros de configuração do HDR devem ser definidos com valores iguais em ambos o servidores:

DRAUTO
DRINTERVAL
DRTIMEOUT

Para servidores secundários em cluster de alta disponibilidade HDR, RSS e SDS, Logical-log em tabelas temporárias devem sempre ser desativado, definindo o parâmetro de configuração TEMPTAB_NOLOG a 1.

A Arquitetura Multithreaded

2011-07-26T11:42:00.001-03:00

O que é uma Thread?

Uma Thread é uma sequencia de instruções sendo executadas em um programa.

Antes, observaremos a arquitetura do servidor, pois é útil examinar o conceito usual de uma thread.

Uma thread pode ser interpretada como uma sequencia de instruções sendo executadas em um programa. Quando múltiplas thread são executadas em uma mesma entidade (no nosso caso, um processo), ela é chamada de multithreading.

Single-Threaded vs. Multithreaded

Um processo regular UNIX que não implementa threads pode ser pensado como um processo single-threaded, apesar de não ser chamado assim. Uma sequencia de instruções é executada para este processo, e o sistema operacional é responsável por agendar e executar esses processos.

Multithreading é um método de muitas execuções repetidas de um processo para diferentes usuários sem ter que formar muitas instancias daquele processo ao nível do sistema operacional.

Um processo multhreaded pode ter threads múltiplas pesquisando dentro de um processo UNIX, cada um executando sequencialmente e dando o controle para outras threads em um ponto especifico de tempo. A forma como uma arquitetura multithread é executada é o que difere de uma arquitetura de single-thread recebendo e executando solicitações de um processo de um único usuário.

Multithreading é um conceito ao nível do sistema por onde os programas realmente executam instruções ao nível da maquina para manipular os processos, então esse é executado para vários usuários ao invés de apenas um. O programa executa estas instruções totalmente ao nível do usuário, e não nível do Kernel do UNIX. Longe de afetar o UNIX, um processo em arquitetura multithread é um processo único, como qualquer outro processo.

Um programa Single-Threaded

Considerar como o UNIX trabalha com multiprocessamento.

Cada processo UNIX tem um espaço de endereço consistindo em três segmentos: text, data e stack. O segmento text contem a instrução da maquina que gera o programa de codificação executável. Os segmentos stack contem variáveis locais usada pelos programas funcionais. Finalmente, o segmento data contem o programa global e as variáveis estáticas, strings, array e outros dados.

Em uma maquina monoprocessada que esteja executando 1000 processos, somente um processo esta sendo executado pelo UNIX em algum momento. Cada processo esta sendo executado dentro de uma quantidade especifica de tempo antes dele ser pré-desocupado (interrompido) pelo kernel de maneira que o próximo processo agendado possa ser executado. Quando um processo em execução é pré-desocupado, devem ser salvas informações suficientes de maneira que o processo possa ser reiniciado mais tarde. Esta informação é chamada de context do processo. O context consiste basicamente dos seguintes componentes:

O program counter, o qual especifica o endereço das próximas instruções a serem executadas.
O stack pointer, o qual contem o endereço atual da próxima entrada no stack.
O general purpose registers, os quais contem os dados gerados pelo processo durante essa execução.

Existem outros componentes do context do processo UNIX, chamado de system level context, porem não vamos abortar, pois não são críticos para a compreensão de multithreading.

Um Context Switch (Alternância de Contexto)

Em UNIX, um context switch ocorre quando um processo em execução é interrompido pelo sistema operacional. Para fazer isto, o sistema operacional salva, correntemente, o context do processo em execução em estruturas de dados pré-alocadas em memoria e carrega o contexto do próximo processo agendado.

Carregar o context envolve restauração do program counter, o stack pointer e todos os general purpose registers para os valores salvos pelo sistema operacional na ultima vez que o processo em execução foi pré-desocupado. Uma vez completo, o processo continua sua execução a partir da linha de código especificada pelo program counter.

Um processo Multithreaded

O processo multithread, cada thread tem o seu próprio context, isto é, seu próprio local no código ( program counter ) e suas próprias variáveis de dados. Um processo multithread trabalha muito parecido com o sistema operacional na maneira da troca de um context de uma thread para outra.

O próprio processo executa instruções de maquinas para realizar uma copia da thread executada no momento e trazer a próxima thread agendada. Isto permite basicamente o mesmo resultado que o sistema operacional alcança fazendo um context switch. O resultado é que o program counter aponta para uma nova instrução dentro do segmento text, o stack pointer aponta para uma diferente área de memoria e os general purpose register são restaurados para os valores previamente salvados por este context. No caso do IDS Multithreading, o stack de uma thread é mantido em shared memory para se mover entre os processos do servidor (virtual processors). O tamanho padrão de stack é 32 kilobytes por cada userthread. O servidor verifica o overflow do stack e automaticamente expande o tamanho stack.

Uma vez que o processo multithread age como um mini sistema operacional, ele é responsável por manter coisas do tipo:

Agendamento: a thread atual decide quando ceder controle de um processo e transferir controle para outra thread. A thread atual tambem decide qual a próxima thread que será executada baseado em mecanismo de prioridade interno.
Troca de Context: quando a thread atual decide que é a hora de executar outra thread, ele deve executar instruções de maquina para efetuar a troca de context entre as threads.

Agendamentos e a troca de context ainda são efetuados pelo UNIX normalmente. O processo multithread efetua agendamento e a troca de context de threads. Mantenha estes dois conceitos separados.

Virtual Processors

Os processos que compõe o database server são conhecidos para Virtual Processors. Cada VP pertence a um virtual processor class. Um VP class é um grupo de processos responsáveis por um conjunto especifico de tarefas (na forma de threads), como, por exemplo, gravar para o logical log ou ler dados do disco. Isto quer dizer que um VP de uma certa classe pode somente pesquisar thread de uma mesma classe. Uma classe de VP pode ter um ou mais VPs, a qual na maior parte dos casos é configurada pelo administrador do sistema. O nome de um VP executável é oninit. Todos os VPs de todas as classes são exemplos de mesmo programa, oninit.

Executando uma Thread

Uma Thread esta sendo executada em um processador particular, ou esta em uma de uma serie de filas. As filas ready (ready queues) mantem os contexts de threads esperando para executa-los em um processador. Quando um processador esta livre, ele obterá o context de uma thread de uma ready queue. Ha um mecanismo de prioridade interno que determina qual thread o processador obterá da fila. O processador os substitui o context atual com o context da nova thread e continua o processamento daquela thread.

As ready queues são compartilhadas entre processadores de mesma classe de modo que uma thread possa migrar entre vários processadores durante sua existência (apesar do server tender em manter a execução de uma thread em um mesmo processo). Este mecanismo mentem o trabalho balanceado entre os processos e garante que uma thread será executada se algum processador estiver disponível.

Passando o controle para outra Thread

A um ponto especifico de execução, a thread cede o controle do processador para outra thread. Algumas ações comuns que poderiam fazer a thread ceder são:

Aguardando por uma operação de leitura ou de gravação no disco;
Aguardando por uma solicitação do processo de aplicação;
Aguardando por um lock ou outro recurso;
Não há mais trabalho a fazer.

Uma thread tambem poderia ceder o controle por nenhuma razão, além de dar a uma outra thread uma chance de ser executada.

Quando um thread cede controle, ela é responsável pela colocação de seu próprio context em uma de muitas filas de espera (wait queue) ou uma fila de aguardo (sleep queue). As wait queue são usadas basicamente para esperar uma operação. As sleep queues são usadas por threads que necessitam ser reativadas depois de um período de tempo.

O processador, então, pega o context de uma thread qualquer de uma ready queue e a substitui seu context com a nova thread. O processador continua a execução com o novo context.

Vantagens das Threads do Servidor

Algumas das vantagens do server threads são listadas abaixo:

São necessários poucos processos para fazer o mesmo trabalho. Este é particularmente eficiente em um ambiente OLTP quando há um grande numero de usuários. Você pode pensar nisto como fan-in, onde há um grande numero de processos de aplicação com um pequeno numero de processos do database server suportando suas solicitações. Uma vantagem adicional é que um sistema que pode suportar mais usuários porque ha menos processos que necessitam ser suportados pelo sistema operacional.
Além das capacidades fan-in, o server tambem oferece uma capacidade fan-out. Múltiplos processos do database server podem fazer o trabalho por uma aplicação.
A arquitetura multithreaded substitui muito a troca do context feito pelo sistema operacional com a troca do context feitos pelos processos dentro do database server. Uma troca de context é mais rápido quando feito dentro de um processo porque ha menos informações para trocar.
O processo do database server faz o seu próprio agendamento de thread. Isto dignifica que o DBMS, a frente do que o sistema operacional determina a prioridade de tarefas.
Algumas características oferecidas por um sistema multi-processado fazem deste tipo de arquitetura, muito mais eficiente. Por exemplo, nós poderíamos dar um importante processo do database server direitos exclusivos para usar um processador em partilhar.

Fan-out

Uma das vantagens do server está em suas capacidades fan-out. Isto significa que usuários podem levar vantagens de múltiplos processadores do database server (e múltiplos CPUs, se disponível) trabalhando simultaneamente para fazer o trabalho deles.

o Server criará múltiplas threads que farão o trabalho de um usuário para as operações seguintes:

Ordenação
Indexação
Recuperação

Atualizando o Informix (In-Place)

2011-07-25T07:18:00.001-03:00

Na atualização do Informix sempre surge duvidas, devo atualizar no mesmo diretório? não vou perder meus dados que estão lá? não vai danificar meu chunk primário?

A IBM diz que atualizar o Informix diretamente para a versão atual, deve-se instalar o produto em um novo diretório, copiando alguns arquivos de configuração e iniciar o servidor para automaticamente converter os dados de sua base atual.

Segundo a IBM pode-se atualizar diretamente qualquer desses produtos: Informix Versão 11.10, 10.00, 9.40, 9.30, 9.21 ou 7.31

A atualização é um método de migração in-loco que usa uma base teste e produção.

A atualização é um método de migração in-loco que usa seu teste existentes e hardware de produção. O sistema operacional nesses servidores devem ser suportados pelo Informix. Além disso, você deve ter espaço suficiente para a conversão dos dados.

Uma atualização segura consiste de alguns procedimentos:

Prepare seu sistema, que inclui fechar todas as transações, verifique a integridade dos dados com o utilitário oncheck, e faça um backup do nível 0. ( Se você estiver utilizando o Enterprise Replication ou cluster de alta disponibilidade, você deve para esse serviço e realizar algumas tarefas adicionais).

Uma boa pratica é fazer backup de todos os arquivos de configuração, tanto do sistema operacional quanto do Informix.
Instale o novo produto no servidor.

Importante: A forma mais segura de atualizar o Informix é instalar uma nova versão em outro diretório. Para economizar espaço você pode selecionar somente os produtos que necessita para a instalação. Somente depois de testar a instancia do servidor com as configurações semelhantes ao de produção é que vamos aplicar essa atualização no servidor de produção, depois de validado esse ambiente de produção, pode-se remover a versão antiga.

Se você não tem espaço em seu servidor para suportar as duas versões, instale a nova versão sobre a versão existente. Nesse caso você não pode selecionar a instalação de componentes.
Certifique-se também nesse caso, que você tenha a mídia da versão anterior, pois se algo der errado não pode reverter isso.
Copie o arquivo ONCONFIG para o novo diretório do Informix.
Inicialize a instancia com a nova versão do Informix. Os dados do banco serão convertidos automaticamente.
Se você tiver problemas de performance, rode o UPDATE STATISTICS e UPDATE STATISTICS FOR PROCEDURE.

Esse tipo de migração minimiza os riscos. Se algo der errado você poderá voltar a versão antiga. Em caso de problema durante a conversão então terá que voltar o backup nível 0.

Atualizando o Informix (In-Place)

2011-07-22T23:33:00.001-03:00

Na atualização do Informix sempre surge duvidas, devo atualizar no mesmo diretório? não vou perder meus dados que estão lá? não vai danificar meu chunk primário?

Segundo a IBM pode-se atualizar diretamente qualquer desses produtos: Informix Versão 11.10, 10.00, 9.40, 9.30, 9.21 ou 7.31

A atualização é um método de migração in-loco que usa uma base teste e produção.

Uma atualização segura consiste de alguns procedimentos:

Prepare seu sistema, que inclui fechar todas as transações, verifique a integridade dos dados com o utilitário oncheck, e faça um backup do nível 0. ( Se você estiver utilizando o Enterprise Replication ou cluster de alta disponibilidade, você deve para esse serviço e realizar algumas tarefas adicionais).

Uma boa pratica é fazer backup de todos os arquivos de configuração, tanto do sistema operacional quanto do Informix.
Instale o novo produto no servidor.

Importante: A forma mais segura de atualizar o Informix é instalar uma nova versão em outro diretório. Para economizar espaço você pode selecionar somente os produtos que necessita para a instalação. Somente depois de testar a instancia do servidor com as configurações semelhantes ao de produção é que vamos aplicar essa atualização no servidor de produção, depois de validado esse ambiente de produção, pode-se remover a versão antiga.

Se você não tem espaço em seu servidor para suportar as duas versões, instale a nova versão sobre a versão existente. Nesse caso você não pode selecionar a instalação de componentes.
Certifique-se também nesse caso, que você tenha a mídia da versão anterior, pois se algo der errado não pode reverter isso.
Copie o arquivo ONCONFIG para o novo diretório do Informix.
Inicialize a instancia com a nova versão do Informix. Os dados do banco serão convertidos automaticamente.
Se você tiver problemas de performance, rode o UPDATE STATISTICS e UPDATE STATISTICS FOR PROCEDURE.

Esse tipo de migração minimiza os riscos. Se algo der errado você poderá voltar a versão antiga. Em caso de problema durante a conversão então terá que voltar o backup nível 0.

Warning no arquivo online.log

2011-07-22T09:25:00.001-03:00

Saudações,

Olhando o meu online.log , arquivo de log do informix, me deparei com um warning que se refere a prioridade do PDQ, o bloco do warning estou postando a seguir:

Warning: PDQ functionality is not supported in IDS Growth Edition.
The value of MAX_PDQPRIORITY cannot be set to 100. It is reset to 0.

Bem, vamos tentar entender o que é exatamente esse warning.

Existem vários tipos de Edição do Informix, além do Growth Edition, temos o Enterprise, entre outros.

Mas a pergunta chave aqui é… o que é esse parâmetro MAX_PDQPRIORITY?

MAX_PDQPRIORITY limita os recursos PDQ que o servidor de banco de dados pode atribuir a qualquer consulta DSS. MAX_PDQPRIORITY é um fator que é usado para dimensionar o valor de prioridade PDQ definidas pelos usuários. Por exemplo, suponha que o DBA atribuiu à MAX_PDQPRIORITY um valor de 80.

MAX_PDQPRIORITY é um fator que é usado para dimensionar o valor de prioridade PDQ definidas pelos usuários. Se um usuário configura a variável de ambiente PDQPRIORITY para 50 e executa a query, o banco de dados vai executar essa query com um prioridade de 40.

Podemos usar o onmode para alterar o valor do MAX_PDQPRIORITY quando o servidor de banco estiver online.

No IDS, os recursos PDQ incluem memoria, CPU, I/O em discos e scan threads, e se o valor de MAX_PDQPRIORITY for muito baixo, a performance pode cair muito.

Por padrão no onconfig.std o valor de PDQ_PRIORITY é 100.

PDQ é abreviação de Parallel Database Query e o objetivo do PDQ é melhorar a performance das queries que são executadas no banco de dados.

Infelizmente esse recurso somente esta disponível em algumas edições do Informix e como percebemos na versão Growth não esta disponível.

Como não gosto muito de ficar vendo warning nos arquivos de log, fiz algumas ações para passar o valor de MAX_PRIORITY para 0, assim não fico mais recebendo essa mensagem de warning.

a primeira ação foi rodar o onmode –D 0, esse comando define a prioridade do PDQ deve ser usado um valor de 0 a 100, porem não resolveu o problema, então fiz a mudança manualmente no arquivo onconfig alterando o valor da variável MAX_PDQPRIORITY para 0. Feito isso o warning não sai mais no online.log.

Rastreamento de endereço IP com Xtrace

2011-07-21T09:38:00.001-03:00

Resolução de Problemas

Problema

Rastreamento do endereço IP e numero de porta com xtrace no IBM Informix Dynamic Server

Resolvendo o problema

No IDS versão 10x em diante o usuario com privilegios administrativos pode rastrear o endereço IP de todos os cliente conexão com o servidor de banco de dados usando o utilitario IDS Xtrace.

Esta facilidade é util no diagnostico de problemas com conexão no banco de dados vinda de clientes (conexão de entradas).

Esta facilidade é aplicavel somente nos servidores IDS que tem chamadas SOC (Sockets) usando conexão TCP (Transmission Control Protocol) e TLI (Transport Level Interface) utilizando TCP e SPX.

Passos para Utilização

Para rastrear o IP faça o seguinte:

Verifique o status do IDS Server;
Certifique-se de que o IDS esta ativo e no modo ‘On-Line’. O comando ‘onstat –‘ pode ser usado para se verificar o status do server.
Defina os valores das variaveis. Este passo é opcional.
O valor padrão do xtrace é 4096. Este valor pode ser mudado quanto o xtrace estiver no modo off.
Exemplo:

xtrace size 8000
Inicializar os componentes do IP trace
Setar o componente ‘XTF_IPTRACE’ e a variavel ‘XTF_SYSCALLS’ para o IP trace
Exemplo:

xtrace heavy –c XTF_IPTRACE –f XTF_SYSCALLS
Iniciar o rastreamento
Isso forçara o IDS a coletar todos os dados relacionados as conexões para dentro do repositorio. O tamanho desse repositorio é definido na variavel xtrace size.
Exemplo:

xtrace on
Analisar os detalhes das conexões dos clientes.
Os detalhes do xtrace pode ser visualizado usando o comando xtrace view.
Exemplo:

xtrace view

Abaixo uma saida do xtrace:
For Sockets:
Quando um host name existe
accpsocket - Accepted IP Address <Hex Address>(<Host Name>)Quando um host name nao existe
accpsocket - Accepted IP Address <Hex Address>For TLI:
Quando um host name existe
accptli - Rejected IP Address <Hex Address>(<Host Name>)accptli - Queuing IP Address <Hex Address>(<Host Name>)accptli - Failed accept IP Address <Hex Address>(<Host Name>)accptli - Accepting IP Address <Hex Address>(<Host Name>)Quando um host name nao existe
accptli - Rejected IP Address <Hex Address>accptli - Rejected IP Address <Hex Address>accptli - Queuing IP Address <Hex Address>accptli - Failed accept IP Address <Hex Address>accptli - Accepting IP Address <Hex Address>
Finalizando o rastreamento
O rastreamento é finalizado com o comando xtrace off
Exemplo:

xtrace off

Usos do Shell

2011-07-20T11:19:00.001-03:00

Uma das maiores funções do shell é para interpretar comandos digitados em linhas de comandos. O shell analisa a linha de comando, quebra-os em palavras (chamados de tokens), separados por um espaço em branco, que consiste em tabulações, espaços ou nova linha. Se a palavra contem metacaracteres especiais, o shell avalia-os tambem. O shell trata processamentos em primeiro plano (foreground) e tambem em segundo plano (background). Apos a linha de comando ser processada, o shell procura pelo comando e inicia a sua execução.

Outra função importante do shell é a personalização do ambiente dos usuários, feito normalmente em arquivos de inicialização. Estes arquivos contem definições para a configuração de terminais e características de ambientes gráficos; configuração de variáveis que define as pesquisas de comandos (search path), permissões, prompts e tipos de terminais, e configurações de variáveis requeridas por aplicações especificas como um x-window, programas para processar textos, e bibliotecas para linguagem de programação. O Korn Shell e o C Shell tambem fornece uma maior personalização com o histórico e aliases, variáveis embutida configura proteção contra sobreposição de arquivos, de forma não intencional, e notifica o usuário quando tarefas foram completadas.

O shell pode ser usado como um interpretador de linguagem de programação. Programas Shell, chamados de scripts, consiste de uma lista de comando em um arquivo. Os programas são criados em um editor. Estes arquivos consistem de comandos UNIX em forma de programação como atribuições de variáveis, condições e loops. Os shell scripts não precisam ser compilados. O shell interpreta cada linha do script como se tivesse sido digitado via teclado. Porque o shell é responsável por interpretar os comandos, é necessário que o usuário tenha conhecimento dos comandos UNIX.

Eventos Importantes no Servidor IDS

2011-07-20T08:44:00.001-03:00

Data Caching

Quando o servidor quer acessar algum dado, ela deve achar a pagina onde aquele dado esta alocado. Uma vez que a pagina é localizada, esta é lida do disco para dentro de um dos buffers no shared memory buffer pool. Uma vez que esta pagina esta no buffer pool, qualquer outro usuário que queira ler aquela pagina pode faze-lo sem ter que lê-lo novamente do disco; as pagina no shared memory buffer pool são compartilhadas por todo os processos do servidor.

A leitura de pagina do disco dentro do shared memory buffers é conhecida como data caching. Se o dado na pagina é modificado por um servidor (durante um INSERT, DELETE ou UPDATE), ela é modificada diretamente no buffer. Isto quer dizer que todo o processo do servidor terá acesso imediato para o dado modificado.

Os buffers modificados em shared memory serão copiados de volta para o disco mais tarde.

Checkpoints

Como as paginas são lidas dos discos para dentro da shared memory buffers e então modificadas dentro destes buffers, as paginas dos discos e as copias destas paginas no shared memory buffers tornam-se fora de sincronização. É necessário, nesta ocasião, ressincronizar estes dois de modo que eles estejam iguais. Esta ressincronização é executada por um evento do sistema conhecido como checkpoint. Durante um checkpoint, todas as paginas na shared memory buffers que foram modificadas são copiadas de volta para o disco. Este trabalho é executado por um dos virtuais processors. Quando o checkpoint esta terminado, todas as paginas na shared memory buffers estão novamente sincronizadas com as paginas do disco.

Point of Recovery

Estes checkpoints também sevem como um recovery point. Se o sistema sofre um crash, nenhuma mudança feita pelas paginas em shared memory esta sincronizada com as paginas de disco. Mas nós sabemos, que somente as mudanças feitas deste o ultimo checkpoint não estão sincronizadas no disco. O mecanismo automático de recovery se previne de recuperar essas mudanças feitas desde o ultimo checkpoint.

Componente do Disco

2011-07-18T12:26:00.001-03:00

Chunks

O servidor não usa o sistema de arquivo do UNIX para fazer a sua administração de espaço em disco, mas apropriadamente, ele utiliza seus próprios mecanismos de gerenciamento do espaço em disco – mecanismos que são bem melhores adaptados à gerencia de banco de dados do que o sistema de arquivo do UNIX.

É necessário construir um espaço disponível para o servidor. Este espaço é associado em unidades chamadas chunks. Um chunk é uma unidade de espaço continuo que é associado ao servidor para seu uso; o servidor administrará o uso do espaço dentro de cada chunk. Um chunk pode ser um raw device do UNIX.

Paginas

Quando um chunk é associado ao servidor, ele será quebrado em pequenas unidades chamadas paginas. A pagina é a unidade básica de I/O de um servidor Informix. Todos os dados em um servidor são guardados em paginas. Por exemplo, se você quiser guardar uma linha de uma tabela do banco de dados, o dado para esta linha deve ser guardado em uma pagina. Quando o dado é lido do disco para um buffer na shared memory, a pagina inteira na qual este dado esta guardado será lida para dentro do buffer. Uma grande quantidade de dados pode ser guarda em uma única pagina.

Page Size

O tamanho de uma pagina usada por um servidor é determinado quando o porte é feito para uma maquina / sistema em particular. O tamanho mais comum de pagina usado é 2 Kbytes, embora alguns sistemas usem um tamanho de 4 Kbytes.

O tamanho da pagina para um servidor não pode ser alterado. Isto é exceto, para blobpages, as quais são atualmente um tamanho logico de paginas ou um numero que representa um múltiplo do tamanho da pagina do servidor.

Tblspaces

Um tblspace é um termo logico usado para referir-se a uma coleção logica de todas as paginas alocadas para uma determinada tabela ou um fragmento de tabela se sua tabela esta fragmentada.

O espaço representando por um tblspace não é necessariamente continuo, aqui pode haver paginas espalhadas por um chunk, ou pode haver paginas de uma tabela em diferentes chunks.

Para tabelas não fragmentadas, um tblspace residira sempre em um dbspace. Se o dbspace tem somente um chunk associado a ele, então todas as paginas de um tblspace residirão sobre este único chunk. Se o dbspace tem vários chunks associados a ele, as paginas de um tblspace podem residir em qualquer dum dos chunks naquele dbspace.

Para tabelas fragmentadas, cada fragmento tem um tablespace id único. Este numero de tablespace é o partnum na systables do catalogo do sistema, e o campo partn em sysframents.

Dbspaces

Um dbspace é uma coleção de chunks. Cada dbspace deve ter no mínimo um chunk associado a ele inicialmente; este é conhecido como primary chunk. Dbspaces podem ter tantos chunks associados a ele quanto necessário. Se você esgotar o espaço em um dbspace particular ( em virtude de que todos os chunks associados a ele estão cheios), você pode adicionar chunks extras a ele.

Banco de dados e tabelas pode ser criados em dbspaces separados. Isto significa que aquela tabela ou banco de dados pode crescer tanto quanto o espaço disponível naquele dbspace. Você não pode controlar em quais chunks dentro de um dbspace um banco de dados serão criados em um device físico em especifico, você de associar somente aqueles chunks residentes no device físico ao dbspace.

Root Dbspace

Cada servidor deve ter no mínimo um dbspace; o root dbspace. Este é onde todas as informações importantes do sistema que controlam o servidor estão localizados.

Agrupamento Logico

dbspaces e tblspaces

Podemos pensar em dbspaces e tblspaces como agrupamentos lógicos de espaço físico.

Um dbspace é um agrupamento logico de chunks físicos. Os chunks pode estar em diferentes discos, contudo eles são parte de um mesmo dbspace.
Um tblspace é um agrupamento logico de extents. Os extents dentro de um tblspace podem estar em chunks diferentes (e, portanto em discos diferentes).

Tipo de Dado Blob

Bynary Large Objects, BLOBs, são conjuntos de bytes de comprimento e valor indeterminado. Um BLOB pode ser uma imagem ou som digitalizado, um modulo de programa ou um contrato legal.

Qualquer coisa que você pode guardar em um arquivo de um computador você pode guardar um um BLOB.

O limite teórico para o tamanho deles é de 2 gigabytes; este tamanho é baseado no maior valor que pode ser armazenado em inteiro de 4-bytes.

Ha dois tipos de BLOBs: TEXT e BYTE. O tipo de dado TEXT é usado para armazenar textos ASCII como memorandos capítulos de manuais e documentos de negócios. O tipo de dado BYTE é usado para arquivar qualquer classe de dado binário, como planilhas, módulos de programas de carga, e imagens e sons digitalizados.

Blobspace

Um blobspace é uma entidade logica que representa uma coleção de espaços físicos na forma de chunks.

Cada blobspace deve ter no mínimo um chink associado a ele; o qual é conhecido como o primary chunk. Blobspaces podem ter tantos chunks associados a ele quanto for necessário.

Colunas BYTE e TEXT podem ser colocadas em blobspace separados. Isto significa que os dados destas colunas blob serão guardados naquele blobspace. Você não pode controlar em qual chunk, dentro de um blobspace o dado blob será guardado. Um servidor pode ter tantos blobspaces quanto queria. Qualquer blobspace pode conter dados blob de diferentes colunas de diferentes tabelas, mesmo de diferentes banco de dados. O blobspace forma um conjunto de espaço de armazenamento que pode ser usado por qualquer coluna blob no servidor.

Todos os arquivos de blobs em um único blobspace, mesmo que estes estejam em tabelas diferentes , usarão o mesmo tamanho de blobpage. Cada blobspace arquiva um dado blob usando o mesmo tamanho de blobpage. Você pode ter vários blobspaces, e cada blobspace pode ter um diferente tamanho de blobpage do que os outros.

Mirroring (Espelhamento)

Mirroring é um processo de replicação de dados automático. O servidor permite a escolha de Mirroring ao nível de dbspaces ou blobspaces. Em casos quando há requerimentos para segurança e disponibilidade, o disco mirroring é um dos vários aspectos para escolher. Sem o disco mirroring, o retorno de uma queda de um disco geraria:

Torna o dado indisponível para o usuário.
Substituição do hardware que teve a falha.
Restauração de fitas de backup.
Rollback de alguns logs de transação.

Com o disco mirroring, a recuperação pode ser completada sem nenhuma interrupção para a disposição de dados.

A escolha para o mirror de disco é feita quando o servidor esta sendo inicializado (initialize). Apesar disso, mirror de dbspaces ou blobspaces individuais, pode ser feito a qualquer momento.

Quanto um dbspaces ou blobspace é espelhado, ambos, primary chunk e mirror chunk são especificados nas criações do espaço ou sempre que um novo chunk precisar ser adicionado. As escritas feitas para o primary chunk e para o mirror chunk são assíncronas. As leituras são separadas entre o primary e o mirror chunk para o aumento de performance.

Logical Logs

Dentro dos limites de um servidor, uma certa quantidade do espaço do disco será reservada para o logical logs.

O logical logs são coleções de paginas continuas de um disco que são usadas para registrar transações arquivadas para o servidor. Estas transações registradas são usadas para mapear todas as mudanças que são feitas no database server. Toda mudança no banco esta registrada no logical log. Cada servidor deve ter no mínimo três logical logs.

Physical Log

O servidor tem um log especial que é usado para propósitos de recuperação automática. Este log é chamado de physical log. O physical log é uma coleção de paginas continuas sobre o disco.

Quando uma pagina tem que ser lida dentro de um shared memory buffer, e um usuário quer modificar dados naquela pagina, antes que a mudança seja feita, uma copia da pagina em sua forma original é gravada no physical log. Esta copia de pagina é conhecida como before image. Somente a primeira mudança para uma pagina em um buffer ocasionará um before image para ser gravada no physical log. Outras mudanças subsequentes para aquela mesma pagina não causarão before images adicionais para serem escritas no physical log. Estas before images serão usados por um mecanismo automático de recuperação.

Shared Memory: The Message Portion

2011-07-18T11:14:00.001-03:00

A message portion da shared memory ou porção de comunicação é alocada quando o servidor é iniciado. A message portion contém os message buffers para as aplicações clientes locais que usam a shared memory na comunicação com o servidor.

As aplicações cliente e o servidor ligam-se ao mesmo segmento de shared memory. O cliente deixa mensagens para o servidor na porção message e depois recupera as mensagens do servidor para ele. O tamanho da porção message é aproximadamente de 12 Kb para cada usuário que use a shared memory para se comunicar com o servidor.

The Virtual Portion: Exemplo de Cache

2011-07-18T10:49:00.001-03:00

A virtual portion da shared memory contem memory pools que são designados a manter tabelas de catalogo do sistema para uso das sessões.

Qualquer sessão executando um comando SQL que necessite de informações sobre as tabelas pela primeira vez, deve recuperar estas informações das tabelas de catalogo do sistema. Isto exige uma leitura de disco para obtenção das paginas das tabelas de catalogo do sistema que não estão nos shared memory buffer pools. Uma vez que o servidor de banco de dados lê as paginas que contem o catalogo do sistema, a informação para a tabela é colocada em uma estrutura que é mais eficiente para a o acesso do servidor de banco de dados.

Esta estrutura é parte do shared memory dictionary pool. Apos o primeiro acesso de uma usuário, todos os usuários podem acessar os dictionary pools para obter a informação do dictionary da tabela, ganhando tempo e memoria.

Outro exemplo de manutenção de tabelas em memoria é a manutenção de stores procedures. O valor default para este pool é de 50 stored procedures. Deste modo, usuários acessando stored procedures não terão que recupera-las sempre do disco.

Datas de Calendário em Informix

2011-07-08T17:09:00.001-03:00

O tipo de dados DATE armazena uma data do calendário. Um valor DATE é um numero inteiro representando o numero de dias corridos desde meia-noite do dia 31 de dezembro de 1899.

O formato DATE tem precisão suficiente para realizar as datas para o futuro distante (58.000 séculos). Valores DATE negativos são interpretados como contagem de dias antes da data de época; isto é, um valor DATE –1 representa 30 de dezembro de 1899.

Os valores DATE por ser inteiros, podem ser usados em expressões aritméticas. Por exemplo, você pode querer a média de uma coluna DATE, ou você pode adicionar 7 ou 365 para uma coluna DATE. Além disso, um rico conjunto de funções existem especificamente para manipular valores de data.

O tipo de dados DATE é compacto, 4 bytes por item. Funções aritméticas e comparações são executadas rapidamente em colunas DATE.

Função MONTHS_BETWEEN

A função MONTHS_BETWEEN requer dois argumentos, cada um dos quais podem ser uma expressão DATE ou DATETIME. Se o primeiro argumento maior que o primeiro, o valor retornado é positivo.

O valor retornado é tipo DECIMAL, representando a diferença entre os dois argumentos, expresso como um valor decimal. Se o primeiro argumento é menor que o segundo argumento, o valor retornado é negativo.

Se as datas do argumentos forem os mesmos dias de um mês ou são os últimos dias de um mês, o resultado é um numero inteiro. Senão um resultado em fração é retornado, com base em um mês de 31 dias. Esta parte fracionaria também pode incluir a diferença na hora, minutos ou segundos, a menos que ambos os argumentos sejam uma expressão DATE.

Abaixo uma query chamando uma função MONTHS_BETWEEN, usando dois valores DATE.

SELECT MONTHS_BETWEEN((SELECT DATE(parametro_dat)
                                        FROM ped_info_compl
                                        WHERE empresa = a.empresa
                                        AND pedido = a.pedido
                                        AND campo = 'Data Final Projeto'), (SELECT DATE(parametro_dat)
                                                                                         FROM ped_info_compl
                                                                                         WHERE empresa = a.empresa
                                                                                         AND pedido = a.pedido
                                                                                         AND campo = 'Data Inicial Projeto'))
FROM ped_info_compl a
WHERE a.empresa = '01'
AND a.pedido = 18188

O valor retornado da query acima seria de 12 meses, nesse exemplo que coloquei ai, o primeiro argumento desse pedido esta com com o campo definido em DATATIME e seu conteúdo é 2011-07-06 00:00:00 e o segundo argumento tem o seguinte conteúdo 2012-07-06 00:00:00, por isso o retorno seria 12 inteiros.

Função ADD_MONTH

A função ADD_MONTHS trabalha com a expressão DATETIME ou DATE como um primeiro argumento, e requer como segundo argumento um inteiro, especificando o numero de meses para adicionar ao primeiro argumento. O secundo argumento pode ser positivo ou negativo.

O Valor que é retornado é a soma de um valor DATE ou DATETIME do primeiro argumento e um valor INTERVAL UNITS MONTH que é baseado em um numero de meses especificado no segundo argumento.

O tipo de dados retornados depende do tipo de dados do primeiro argumento:

Se o primeiro argumento for um valor DATE, ADD_MONTHS retornara um valor DATE;
Se o primeiro argumento for um valor DATETIME, ADD_MONTHS retornara um valor DATETIME YEAR TO FRACTIONS(5), com os mesmos valores para unidades de tempo menor do dia como no primeiro argumento.

Se a unidade de tempo day e month especificado no primeiro argumento é o ultimo dia do mês, ou se o mês resultante tem menos dias que o primeiro argumento, então o valor retornado é o ultimo dia do mês em questão. Caso contrario o valor retornara a mesma quantidade de dias do mês do primeiro argumento.

O valor retornado pode ser um ano diferente, se o mês resultante for maior que dezembro ( ou o segundo argumento for um numero negativo, menor que janeiro) do ano do primeiro argumento. Veja os exemplos abaixo:

Uma Query onde é um resultado normal

SELECT order_date
FROM ami_backlog_prev
WHERE order_num = 18188

Resultado

order_date
-------------
04/05/2011

Adicionando 5 meses

SELECT ADD_MONTHS(order_date,5)
FROM ami_backlog_prev
WHERE order_num = 18188

(expression)
---------------
04/10/2011

Adicionando 12 meses

SELECT ADD_MONTHS(order_date,12)
FROM ami_backlog_prev
WHERE order_num = 18188

(expression)
---------------
04/05/2012

Tirando 3 meses

SELECT ADD_MONTHS(order_date,-3)
FROM ami_backlog_prev
WHERE order_num = 18188

(expression)
---------------
04/02/2011

Tirando 12 meses

SELECT ADD_MONTHS(order_date,-12)
FROM ami_backlog_prev
WHERE order_num = 18188

(expression)
---------------
04/05/2010

Função DATE

A função DATE converte um argumento para um valor DATE. O seu argumento não DATE pode ser qualquer expressão que possa ser convertido para um valor DATE, geralmente um CHAR, DATETIME ou um valor INTEIRO, veja o exemplo abaixo:

SELECT *
FROM pedidos
WHERE num_pedido < DATE ('31/12/07’)

Execução de Gatilhos (Triggers)

2011-07-04T14:49:00.001-03:00

Um gatilho (trigger) é um mecanismo de banco de dados que executa uma instrução SQL automaticamente quando um determinado evento ocorrer. Você pode criar um gatilho em uma tabela para executar um SELECT, INSERT, UPDATE ou DELETE.

Quando se cria um gatilho com a declaração CREATE TRIGGER, o database server coloca informações sobre a trigger no system catalog (systriggers). O server coloca a declaração de que o gatilho é executado dentro do system catalog (systrigbody). Além disso, tabelas de dicionário são armazenados na memoria para indicar se a tabela possui gatilhos definidos para ele. Sempre que o servidor executa uma declaração SELECT, INSERT, UPDATE ou DELETE, verifica se um gatilho esta definido para o tipo de declaração e a tabela e coluna na qual a instrução opera. Se uma declaração requer um gatilho pra ser executado, o server recupera o texto de instrução de systrigbody e executa a rotina SPL, quando necessário, antes, durante e apos a instrução.

SINTAXE:

>>-CREATE TRIGGER--+---------------------+--trigger------------->
                   |                (1)  |
                   '-| Owner Name |------'
 
>--+---------------------------------------------------+-------->
   |                        (2)                        |
   +-| Trigger on a Table |----------------------------+
   |  (3)                                              |
   '--------INSTEAD OF--+----------------------------+-'
                        |                       (4)  |
                        '-| Trigger on a View |------'
 
    (3)   .-ENABLED--.
>---------+-DISABLED-+-----------------------------------------><

Um gatilho, exceto se for desativado, executa automaticamente um conjunto de instruções SQL, chamada trigger action, quando um evento especifico de gatilho ocorrer.

Quando se dispara um gatilho

Pode-se utilizar a declaração CREATE TRIGGER de duas maneiras distintas:

Pode-se definir um gatilho em um tabela no banco de dados corrente;

Para o IDS, pode-se também definir um gatilho INSTEAD OF em uma view no banco de dados corrente.

Qualquer instrução SQL que é uma instancia do evento da trigger é chamado de instrução de acionamento (triggering statement), quando o evento ocorre, gatilhos definidos em tabelas e gatilhos definidos em view são tratadas de maneiras diferentes quando executada:

Para tabelas, o trigger event e o trigger action são executados

Para views, somente o trigger action é executado, ao invés do evento.

A declaração CREATE TRIGGER pode suportar a integridade dos dados no banco através de definição de regras pelas operações DML (o triggering events) o que faz com que o servidor tome ações especificas.

pode suportar a integridade dos dados no banco de dados através da definição de regras pelas quais especificado operações DML (a fatos geradores) fazer com que o servidor de banco de dados para tomar ações especificadas.

Exemplo de gatilho em uma tabela:

|--+-+-DELETE----------------------------+--ON--table--| DELETE and SELECT Subclauses |-+--|
   | |  (1)                              |                                              |
   | '--------SELECT--+----------------+-'                                              |
   |                  |     .-,------. |                                                |
   |                  |     V        | |                                                |
   |                  '-OF----column-+-'                                                |
   +-UPDATE--+----------------+--ON--table--| UPDATE Subclauses |-----------------------+
   |         |     .-,------. |                                                         |
   |         |     V        | |                                                         |
   |         '-OF----column-+-'                                                         |
   |                                          (2)                               (3)     |
   '-INSERT--ON--table--+-| NEW Declaration |-------| Correlated Table Action |------+--'
                        |                   (4)                                      |
                        '-| Action Clause |------------------------------------------'

Sub-clausula DELETE e SELECT:

                      (4)
|--+-| Action Clause |--------------------------------------------------------------------+--|
   |                     (5)                               (3)                            |
   +-| OLD Declaration |-------| Correlated Table Action |--------------------------------+
   |                     (5)                       (2)                               (3)  |
   '-| OLD Declaration |-------| NEW Declaration |-------| Correlated Table Action |------'

Gatilho em uma View:

   (1)
|--------------------------------------------------------------->
 
>--+-INSERT ON--view--+------------------------------+------------------------+-->
   |                  '-REFERENCING NEW--+----+--new-'                        |
   |                                     '-AS-'                               |
   +-DELETE ON--view--+-------------------------------+-----------------------+
   |                  '-REFERENCING--OLD--+----+--old-'                       |
   |                                      '-AS-'                              |
   '-UPDATE ON--view--+-----------------------------------------------------+-'
                      +-REFERENCING--OLD--+----+--old--+------------------+-+
                      |                   '-AS-'       '-NEW--+----+--new-' |
                      |                                       '-AS-'        |
                      '-REFERENCING--NEW--+----+--new--+------------------+-'
                                          '-AS-'       '-OLD--+----+--old-'
                                                              '-AS-'

Restrições dos Gatilhos

Para criar uma trigger em uma tabela ou uma View, deve-se possuir direitos sobre a tabela ou view, ou ter status de DBA.

A tabela na qual esta criando o gatilho deve existir no banco de dados. Não pode criar uma trigger em qualquer das seguintes situações:

Uma tabela de diagnostico, uma tabela violada ou uma tabela em outro banco de dados;

uma raw table, uma tabela temporária ou tabela do system catalog.

No DB-Acess, se você quiser definir um gatilho como parte de uma esquema, coloque a declaração CREATE TRIGGER dentro de uma declaração CREATE SCHEMA.

Se você estiver incorporando uma instrução CREATE TRIGGER em um programa de ESQL/C, não se pode utilizar uma variável na definição da trigger.

Não pode usar a declaração DROP TRIGGER para remover uma trigger existente. Se você usar DROP TABLE ou DROP VIEW para remover gatilhos em tabelas ou view do banco de dados, todas as triggers nessa tabela ou view serão dropadas.

A Virtual Portion pode crescer

2011-06-30T09:03:00.001-03:00

Segmento inicial

Tamanho Configurável

Segmento Adicional

Tamanho Configurável

Por causa da natureza das informações armazenadas na virtual portion da shared memory, a quantidade de shared memory usada pelo servidor varia dependendo da atividade. Em momentos de grande atividade, mais shared memory pools são criados, e os pools existentes podem ser expandidos. Se mais espaço for necessário para a porção virtual, segmentos adicionais de shared memory são acrescentados automaticamente.

Uma vez que os segmentos de shared memory são alocados para o servidor, eles somente podem ser liberados pelo administrador executando o utilitário onmode ou mudando o servidor para o modo off-line.

Shared Memory: The Virtual Portion

2011-06-28T10:36:00.001-03:00

A virtual portion da shared memory é usada para muitos propósitos. Alguns destes propósitos são listados a seguir:

Mapeamento dos Dados das Sessões – cada sessão tem seu próprio pool o qual contem os dados particulares da sessão. O nome de um session pool é o mesmo session_id que é dado ao usuário. Quando uma sessão desconecta-se de um servidor , este session pool é liberado.
Cache das informações do dicionário – os dictionary pools mantem em memoria as informações das tabelas de catalogo do sistema.
Cache das stored procedures – stored procedures usadas por uma sessão são mantidas nos procedures pools.
Informações de Thread – MT pools mantem estruturas e stacks usadas para controlar as threads.
Ordenação – o espaço temporário para ordenação de dados é alocado como um sort pool.
Big Buffer – Big Buffer são usados pelo AIO VPs que gravam um grande bloco de paginas para o disco de uma vez. É alocado um Big Buffer por AIO VP.
Informação Global – dados diversos não pertencentes a uma sessão em especifico são guardados no global pool.

Alocação de Shared Memory: The Virtual Portion

2011-06-28T10:16:00.001-03:00

Quando o servidor necessita de memória para um propósito especifico, ele reserva uma memória não usada dentro da virtual portion. A memória reservada para um propósito especifico é conhecida como um shared memory pool. Um memory pool é alocado para um propósito especifico; por exemplo, para armazenar dados particulares de um usuário. Atualmente, existem mais de 50 tipos de shared memory pools que podem ser alocados. Os pools podem ser alocados a qualquer momento e são liberados quando eles não são mais necessários. Quando o espaço de um pool é liberado, o espaço é disponibilizado para que o servidor possa reutilizá-lo.

O Servidor controla alocações de memória para um memory pool mapeando o uso da memória com paginas bitmap. A memória é alocada da virtual portion para uso do servidor em incrementos de 8Kb, valor este que não pode ser modificado. Cada bit em uma pagina bitmap mapeia um bloco de 8Kb.

The Resident Portion: LRUs

2011-06-28T10:07:00.001-03:00

Quando o servidor precisa trazer uma página do disco para a shared memory, ele deve primeiro localizar um buffer para dentro do qual colocará a página. Todo buffer é mapeado através de diversas listas conectadas de ponteiros conhecidas como filas Least Recently Used (LRU). Os pares de filas LRU têm uma fila livre, a FLRU (LRU Livre) e uma fila modificada, a MLRU (LRU modificada).

Quando o servidor é colocado em modo on-line pela primeira vez, todas as páginas dos buffers (as quais estão vazias), são distribuídas igualmente nas FLRU dos pares de LRU. Esta distribuição é para balancear a associação das páginas do buffer dentre as filas de FLRU de modo que uma fila não gere um gargalo.

Quando uma thread de usuário precisa de um buffer, o servidor seleciona um Least Recently Used buffer randomicamente em uma das filas de FLRU que não estão reservadas por nenhuma outra thread de usuário. Se a página está sendo modificada, o buffer é colocado em um Most Recently Used buffer na fila de MLRU. Se a página foi lida, mas não foi modificada, o buffer é retornado para o Most Recently Used buffer na fila de FLRU.

The Resident Portion: Logical Log Buffers

2011-06-28T10:03:00.001-03:00

O logical logs é um log, ou atualmente uma coleção de logs, em disco que recebe as entradas DML (Insert, Update, Delete) de banco de dados com log, assim como DDL para todas as tabelas. Com servidores IBM Informix, o mesmo grupo de logs é compartilhado por todos bancos de dados. Transações de diferentes bancos de dados são intercaladas no interior dos logs de transação.

Como a quantidade de dados gravados nestes logs pode ser grande, para ajudar a reduzir a quantidade de I/O físico necessário para gravar os dados no disco, o dado é primeiro colocado em um buffer, o qual será transferido para o disco mais tarde. O servidor aloca três buffers, para uso com os logical logs.

Historia do Shell

2011-06-27T17:19:00.001-03:00

A primeira versão do shell padrão do UNIX foi introduzido na V7 (Sétima edição pela AT&T) no final de 1979, e foi batizado pelo nome do seu criador, Stephen Bourne. O Bourne Shell é uma linguagem de programação baseada em uma linguagem de programação chamada Algol. E foi utilizado primeiramente para gerenciar tarefas de administração do sistema. Embora popular pela sua simplicidade e velocidade, ele não tem muitas características para o uso interativo, como o histórico, aliases e controle de tarefas.

O C Shell, desenvolvido pela Universidade da Califórnia em Berkeley no final de 1970, foi lançado como parte do UNIX 2BSD. O Shell, foi escrito por Bill Joy, oferecendo um numero adicional de características não encontradas no Bourne Shell. O C Shell é baseado na linguagem de programação C, e quando usada como linguagem de programação, compartilha uma sintaxe similar ao C. Ele também oferece melhorias para o uso interativo, como o histórico de linha de comando, aliases e controles de tarefas. o C Shell foi projetado para grandes Servidores e por isso características adicionais foram adicionadas, o C Shell tem uma tendência de ser mais lento, tanto em Servidores de pequeno porte quanto Servidores de Grande porte em comparação ao Bourne Shell.

Tanto o Bourne Shell e o C Shell disponível, usuários UNIX tinha agora uma escolha e conflitos para saber qual o melhor Shell. David Korn, da AT&T, criou o Korn Shell pelos meados dos anos 80. Foi lançado em 1986 e tornou-se oficialmente parte da distribuição UNIX SVR4 em 1988. O Korn Shell, é realmente um superconjunto do Bourne Shell, rodando não somente nos sistemas UNIX, mas também no OS/2, VMS e mesmo no DOS. isso fornece alta compatibilidade com o Bourne Shell, acrescenta muitas características popular do C Shell, e é muito rápido e eficiente. O Korn Shell passou por uma serie de revisões.

Introdução ao UNIX SHELLs

2011-06-22T17:39:00.001-03:00

Definição e função

O Shell é um programa especial usado como uma interface entre o usuário e o coração do Sistema Operacional UNIX, chamado de kernel, como mostra a figura abaixo:

O kernel é carregado na memoria no momento do boot e gerencia o sistema ate o momento do shutdown. Isso cria e controla processos, e gerencia memorias, sistemas de arquivos, comunicações, e assim por diante. Todos os outros programas, incluindo shells scripts residem fora do disco. O kernel carrega esses programas em memoria, executa-os, e limpa o sistema quando terminar. O shell é um programa que inicializa quando você faz um logon. Isso permite os usuários interagir com o kernel interpretando os comandos digitados pelo usuário em linha de comando ou em um shell script.

Quando você faz logon, um shell interativo é iniciado e um prompt fica aguardando a sua entrada. Depois de digitar um comando, é de responsabilidade do shell: (a) analisar a linha de comando; (b) lidar com wildcards, redirecionamentos, pipes e controle dos trabalhos; e (c) pesquisar pelo comando e se encontrado, executar o comando. Quando você estuda UNIX pela primeira vez, recomendo passar uma boa parte de seu tempo digitando comandos em prompt. Use a interatividade do shell.

Se você costuma executar um conjunto de comando regularmente, você pode querer automatizar essas tarefas. Um arquivo de script permite que você crie um conjunto de comandos, e então execute esse script. Um shell script é muito parecido com um arquivo de lote do Windows: É uma lista de comandos UNIX e então esse arquivo é executado. Scripts mais sofisticados contem instruções de programação para criar decisões, looping, e muito mais. Escrever um script não requer somente estudar técnicas de programação, mas sim que você tenha um bom conhecimento dos utilitários UNIX e como eles trabalham. Existem alguns utilitários, como grep, sed e awk, que são ferramentas extremamente poderosas usadas em scripts para a manipulação das saídas dos comandos. Depois que você se familiarizar com essas ferramentas e com construção de programas, você estará pronto para escrever scripts poderosos. Ao executar comandos dentro de scripts, você estará usando o shell como uma linguagem de programação.

Os três principais Shells

Os três principais Shells e suportados na maioria dos sistemas UNIX são o Bourne Shell (AT&T Shell), o C Shell (Berkeley), e o Korn Shell (superconjunto do Bourne Shell). Todos esses três Shells se comportam praticamente da mesma forma quando executado, mas tem algumas diferenças na sintaxe e eficiência quando utilizado como linguagem de programação.

O Bourne Shell é o shell padrão do UNIX, e o shell é usado para administrar o sistema. A maioria dos scripts de administração do sistema, como os scripts rc start e stop e shutdown são scripts Bourne Shell, e quando em modo single user, este é o shell usado pelo root. Este shell foi escrito pela AT&T e é conhecido por ser objetivo, compacto e rápido. O prompt padrão do Bourne Shell é o sinal de dólar ($).

O C shell foi desenvolvido e adicionado uma serie de característica pela Berkeley, como o histórico de linha de comando, aliases, cálculos aritméticos controles de tarefas. O C Shell tem sido melhor em comparação ao Bourne Shell para usuários que rodam em shell interativo, mas administradores preferem o Bourne Shell para script, porque o Bourne Shell são simples e bem mais rápidos comparado com scripts escrito em C Shell. O prompt padrão do C Shell é o sinal de porcentagem (%).

O Korn Shell é um superconjunto do Bourne Shell escrito por David Korn da AT&T. Uma serie de recursos foram adicionados a esse shell além das melhorias do C Shell. As características do Korn Shell inclui um histórico editável, aliases, funções, expressões regulares, cálculos aritméticos, controles de tarefas e debug, entre outras. O Bourne Shell é quase totalmente compatível com o Korn Shell. O prompt padrão do Korn Shell é o sinal de dólar ($).

The Resident Portion: Physical Log Buffers

2011-06-21T15:36:00.001-03:00

Outra parte importante da resident portion da shared memory é usada para log buffers. O physical log é um log especial usado para mecanismos de tolerância à falhas do servidor. Ele contém as Before images (apenas a primeira cópia) de páginas de dados e índices que estão no buffer pool e estão sendo modificadas desde o momento que elas foram lidas do disco.

Para reduzir a quantidade de I/O físico associado com a manutenção desde log, os buffers são usados na gravação do log; ao invés de gravar cada entrada diretamente no disco, as entradas são gravadas em um buffer, o qual é transferido para o disco mais tarde. Como o servidor tem o controle sobre quando estes buffers são transferidos para o disco, ele pode garantir que eles serão transferidos quando necessário.

The Resident Portion: Buffer Pool

2011-06-15T11:19:00.001-03:00

A maior parte da resident portion da shared memory é usada para o buffer pool (também conhecido como buffer cache), o qual é uma coleção de buffers dedicados a armazenar em cache, os dados do disco. Armazenar páginas de dados em shared memory permite que muitos usuários leiam e gravem dados sem no momento ter de realizar leituras e gravações nos discos. Nos capítulos seguintes, você aprenderá como especificar o número de buffers para usar em seu servidor.

Shared Memory: the Resident Portion

2011-06-15T11:14:00.001-03:00

O principal uso da resident portion da shared memory é para conter o buffer pool. O buffer pooI mantém páginas de dados das tabelas dos bancos de dados. A resident portion também mantém o controle de outros recursos do servidor.

O servidor alocará algumas coleções de estruturas de dados nesta porção da shared memory. Estas estruturas são algumas vezes conhecidas como tabelas internas, mas tenha em mente que não são como as tabelas de banco de dados.

O servidor de banco de dados associa uma tabela interna para cada um dos principais recursos do servidor. O tamanho dessas tabelas internas é configurável ajustando o tamanho do recurso da shared memory usando o onmonitor, ou modificando o arquivo onconfig.

O componente Shared Memory

2011-06-15T10:59:00.001-03:00

A shared memory no servidor é dividida em três porções. Cada uma destas porções é listada abaixo e explicada em maiores detalhes nos capítulos posteriores.

· Resident portion – a porção resident portion contém o buffer pool e outras informações do sistema. Esta parte da shared memory pode ser configurada para permanecer residente na memória principal (se esta capacidade é suportada pelo sistema operacional).

· Virtual portion – a virtual portion contém informações sobre as threads e sessões, e os dados que são usados por elas. Estas informações crescem e diminuem constantemente, sendo que o servidor de banco de dados é responsável pelo controle de alocação e liberação de memória nesta porção.

· Message portion – a message portion armazena os message buffers que são usados na comunicação entre o cliente e o servidor quando o método de comunicação é feito através da shared memory.

Componente de Processo: Virtual Processors

2011-06-15T10:52:00.001-03:00

Os processos que compõe o servidor de banco de dados são conhecidos como virtual processors.

Cada virtual processor pertence a uma classe de virtual processor. A classe VP é um ou mais processos responsáveis por um conjunto específico de tarefas ( na forma de threads), como gravações para o logical log ou leitura de dados do disco. Isto significa que um VP de uma certa classe pode somente executar threads da mesma classe. Cada VP na classe VP é apenas outra instância do mesmo programa. Um VP pode pertencer somente a uma classe. Uma classe VP pode ter um ou mais VPs, o que em muitos casos é configurável pelo administrador do sistema.

VPs são executados como root. Isto é necessário porque o VP deve executar certas tarefas como o usuário que iniciou a tarefa (como gravar a saída de um SET EXPLAIN ou executar o SYSTEM da SPL). Tendo VPs executando como root, tem-se o beneficio adicional de proteção dos processos do servidor de banco de dados. Somente root ou informix pode eliminar um VP. Se você executar um processo de status no UNIX, o virtual processors aparecerá como processos chamados de oninit.

Visão da Arquitetura

2011-06-09T08:32:00.001-03:00

O servidor é composto por três grandes componentes. Os componentes são introduzidos nas paginas seguintes e discutidos em detalhes nos capítulos posteriores.

O Componente Processo

O componente Processo define o database Server. Os processos que definem o database Server são conhecidos como virtual processors. Ao nível do UNIX esses processos são chamados oninit. Cada virtual processor (VP) pertence a uma classe de virtual processor. Uma classe de VP é um conjunto de processos responsáveis por um conjunto especifico de tarefas.

O Componente Shared Memory

O Segundo componente é a Shared Memory. A Shared Memory é feita de três porções: residente, virtual e de mensagem. A Shared Memory é usada para:

· Cópia dos dados do disco para shared memory para acesso mais rápido (resident portion);

· Manutenção e controle dos recursos solicitados pelos processos (virtual portion);

· Um mecanismo de comunicação para os processos cliente e servidor falarem entre si para coordenar suas atividades (message portion).

O Componente Disco

Seguindo, há o componente disco. Esta é um coleção de uma ou mais unidades de espaço em disco designado para o sistema do servidor. Todos os dados nos banco de dados, além de toda a informação do sistema necessário para manter o servidor, são armazenados dentro do componente disco.

O Servidor de Banco de Dados Informix

2011-05-06T20:14:00.001-03:00

O servidor implementa uma arquitetura multi-thread. Isto quer dizer que:

Menos processos são exigidos para executar as atividades do SGBD;
Um processo que pode fazer o trabalho para mais de uma aplicação através do uso de threads.

Esses processos são coletivamente conhecidos como database server. Você pode dinamicamente alocar processos para o database server quanto necessário, por isso o termo DYNAMIC SERVER.

A arquitetura multithreaded permite uma melhor escalabilidade. Isto quer dizer que quanto mais usuários são adicionados, uma quantidade mínima de recursos adicionais é exigida pelo servidor para acomodar esses usuários. Isto devido a escalabilidade e a eficiente implementação multithreaded.

Visão Geral da Arvore de Diretórios

2011-04-19T10:08:00.001-03:00

Vamos descrever aqui as partes importantes da arvore de diretórios do UNIX em particular do LINUX, em matéria passada já postei sobre a estrutura do HP-UX, baseado no Sistema de Arquivos Padrão do LINUX – FSSTND. Ele descreve a forma usual de dividir a arvore de diretórios em diferentes sistemas de arquivos com diferentes propósitos, justificando a adoção de cada divisão. Algumas opções alternativas de particionamento vamos descrever também.

O Filesystem Hierarchy Standard (padrão para sistema de arquivos hierárquico), ou FHS, define os principais diretórios, e o seu conteúdo, em um sistema operacional Linux ou do tipo Unix. A versão atual é a 2.3, anunciada em 29 de janeiro de 2004.

No início do ano de 1996, surgiu um movimento, com o apoio da comunidade de desenvolvedores do BSD, que visava o desenvolvimento de versões do FSSTND para outros sistemas do tipo Unix, além do Linux. A partir desta iniciativa foi realizado um esforço para determinar os problemas comuns aos sistemas do tipo Unix. Como resultado da ampliação do escopo do problema, o nome do padrão foi alterado para Filesystem Hierarchy Standard (FHS) (padrão para sistemas de arquivo hierárquicos).

O FHS é mantido pelo Free Standards Group, uma organização sem fins lucrativos formada por importantes empresas de hardware e software, como HP, Red Hat, IBM e Dell. Ainda hoje, a grande maioria das distribuições Linux, incluindo membros da Free Standards Group, não adotam o padrão proposto. Em particular, diretórios (paths) criados pelo FHS, como o /srv/, não foram adotados em grande escala. Alguns sistemas Unix e Linux rompem com o padrão FHS, como o GoboLinux. O Mac OS X utiliza uma estrutura com nomes legíveis por seres humanos em conjunto com um sistema baseado no FHS.

A intenção dessa matéria é apresentar uma visão geral sob um ponto de vista de sistema de arquivos.

A arvore de diretórios deve ser dividida em partes menores, cada uma com o seu próprio disco ou partição, facilitando questões como limites de tamanho de disco ou a geração de cópias de segurança. Os sistemas de arquivo mais importantes são o raiz (root), representando por uma /, /usr, /var e /home. Cada parte tem um proposito diferente.

O sistema de arquivos raiz é especifico de cada maquina (ele é geralmente armazenado em disco local, apesar de poder ser um disco em memoria e contem os arquivos necessários para a inicialização do sistema e para permitir o acesso aos demais sistemas de arquivos. O conteúdo do sistema de arquivos raiz devera ser suficiente ainda para que o sistema possa ser executado em modo monousuário. ele contem ainda ferramentas para resolver eventuais problemas de disco e recuperar arquivos a partir de copias de segurança.
O sistema de arquivos /usr contem os comandos, bibliotecas, paginas de manuais e outros arquivos imutáveis, necessários para a operação normal do sistema. Os arquivos no /usr não devem ser específicos para uma determinada maquina e não devem ser alterados durante o uso normal. Isso permite que estes arquivos possam ser compartilhados através da rede, o que pode ser bastante interessante pela possível economia de espaço em disco, ( o, /usr pode conter facilmente centenas de megabytes) torna a administração mais simples (uma vez que somente o /usr na maquina principal necessita ser atualizado e mantido em dia). Mesmo que este sistema de arquivos esteja no disco local, ele deve ser montado com autorização de somente leitura, para diminuir a chance de corrupção de arquivos durante um eventual acidente.
O sistema de arquivos /var contém arquivos mutáveis, como diretórios de arquivos temporários, spool (para correio eletrônico, news, impressões, etc), logs, paginas de manual formatadas, etc… Tradicionalmente o conteúdo do /var era montado em algum lugar sob o /usr, porem isso tornava impossível montar o /usr com permissões de somente leitura.
O sistema de arquivos /home contem os diretórios pessoais dos usuários, ou seja, todas as informações armazenadas por estes no sistema. Separar diretórios pessoais em sua própria arvore de diretórios ou sistema de arquivos simplifica a geração de copias de segurança, uma vez que outras partes do sistema normalmente não necessitam de copias com a mesma frequência. Um /home muito grande pode ser dividido em diversos sistemas de arquivos que requerem um nível adicional na sua denominação, por exemplo, (/home/amilcar ou /home/funcionário).

A estrutura dos sistemas de arquivos UNIX prevê um agrupamento de acordo com o proposito. Os comandos estão todos em uma determinada área, todos os arquivos de dados em outra área, documentação em uma terceira, e assim por diante. Uma alternativa seria agrupar os arquivos de acordo com os programas a que eles pertençam, isto é, os arquivos do Emacs estariam todos em um único diretório, todos os arquivos do vim em outro, e assim por diante. O problema dessa abordagem reside no compartilhamento de arquivos (um diretório de programa contém todos os tipos de arquivos: estáticos, dinâmicos, compartilhados e não compartilhados,…) e algumas vezes em encontrar alguns desses arquivos ( por exemplo uma pagina de manual a ser pesquisada em um grande numero de diretórios é um pesadelo para a administração).

A estrutura do sistema de arquivos

2011-04-05T13:44:00.001-03:00

O sistema de arquivos é dividido em diversas partes, normalmente utilizado uma estrutura em arvore, com um sistema de arquivos chamado raiz (root), simbolizado por ‘/’. Debaixo deste podemos ter diversos outros: /bin, /lib, /etc, /dev/,etc…

Um sistema de arquivos /usr pode conter programas e dados não atualizáveis, o /var pode conter dados variáveis (como arquivos de log) e um sistema /home pode ter arquivos pessoais de todos os usuários. Dependendo da configuração de hardware e das definições do administrador do sistema, a divisão pode variar substancialmente, sendo possível inclusive que todos os conteúdos estejam em um único sistema de arquivos.

Principais Serviços de um Sistema UNIX

2011-04-04T14:42:00.001-03:00

init

O mais importante serviço isolado disponível em um sistema UNIX é denominado init. O init é o primeiro processo iniciado em todos os sistemas UNIX, apos a carga do kernel do sistema. Quando o init é disparado, ele continua o processo de inicialização do sistema, executando diversas tarefas necessárias ao funcionamento do UNIX (checando e montando sistemas de arquivos, iniciando serviços,etc).

A lista exata de tarefas que o init realiza depende do estado em que ele esta. O init provê o conceito de modo monousuário, no qual ninguém, além do root, pode entrar no sistema, sendo utilizado somente o shell do console do sistema, ou o modo multiusuário, o modo padrão de inicio do sistema. Algumas versões generalizam isso, denominando-os níveis de execução; sendo os modos mono e multiusuário considerado como níveis, podendo existir diversos outros, como por exemplo , aquele que permite a execução do X (interface gráfica) na console.

Em uma operação normal, o init certifica-se que o getty esta sendo executado (permite acesso aos usuários) e adota processos órfãos (processos cujos programas que o iniciaram (chamado de pais) morreram (não esta sendo mais executado)). No UNIX todos os processos devem estar em uma estrutura do tipo árvore, devendo todos eles terem um “pai”.

Quando um sistema é desligado, é o init que se encarrega de finalizar todos os outros processos, desmontar todos os sistemas de arquivos e parar o processador junto com tudo o mais que esteja sendo executado.

Acesso a partir de terminais

Os acessos a partir de terminais (via linhas seriais) e através do console (quando não esta sendo executado o X), são disponibilizados pelo getty. o init inicia uma instancia distinta do getty para cada terminal, no qual o acesso é permitido. O getty lê o nome do usuário e executa o programa de acesso login, o qual por sua vez processa a validação da senha do usuário. Caso usuário e senha sejam validos, o login inicia o shell do usuário. Quando um shell é finalizado, isto é, o usuário sai do sistema, ou quando o login é finalizado porque usuário ou senha são incorretos, o init inicia uma nova instancia do getty. O kernel não tem conhecimentos dos acessos, pois tudo isso é controlado pelos programas de sistema.

Syslog

O kernel e muitos programas do sistema produzem vários avisos, mensagens de erros, e outros alertas. É importante que estas mensagens possam ser lidas outra hora, mesmo que isto demore muito tempo desde o ocorrido. Para que isso seja possível elas devem ser gravadas em um arquivo. O programa responsável por este arquivamento é o syslog. Ele pode ser configurado para gravar as mensagens em diferentes arquivos de acordo com o nível de importância ou origem. As mensagens do kernel são frequentemente direcionadas para arquivos distintos, pois estas mensagens são normalmente mais importantes e necessitam ser lidas com amis frequência para se evitar/sanar problemas.

Comandos periódicos: cron e at

Tanto administradores do sistema como usuários comuns necessitam executar periodicamente determinados programas. O administrador do sistema quer executar um comando para limpar os diretórios que contenham arquivos temporários antigos ( /tmp e /var/tmp ), evitando assim que os discos rígidos fiquem cheios de arquivos sem utilidade, uma vez que nem todos os programas apagam os arquivos temporários após a sua execução.

o cron foi criado para atender a essa demanda. Cada usuário tem uma tabela do cron (crontab) à sua disposição, onde se inclui os comandos desejados e a frequência com que eles devem ser executados. O daemon do cron encarrega-se de executar os comandos nos dias e horários definidos.

O comando at é similar ao cron, mas esta limitado a uma única execução: o comando é executado em um determinado horário fornecido, mas não repedidas vezes.

Interface Gráfica

O UNIX e o Linux não incorporam a interface do usuário ao kernel. Ela é implementada pelos programas a nível de usuário, tanto no modo texto como no ambiente gráfico.

Esta solução gera uma maior flexibilidade para o sistema, mas, pela facilidade de implementação, pode-se ter uma multiplicidade exagerada de interfaces, uma para cada programa, tornando o sistema mais complexo de ser utilizado.

O ambiente gráfico usado com o Linux é chamado de X Window (X). O X na verdade não implementa a interface gráfica, somente disponibiliza um sistema de janelas, onde outros programas podem implementar um ambiente gráfico. Algumas interfaces gráficas mais populares para o Linux são: KDE, GNOME, WINDOWS MAKER.
No ambiente UNIX sendo o CDE.

Rede

Rede pode ser definida como a conexão entre dois ou mais computadores,s de forma que eles possam comunicar-se entre si. Os métodos de conexão e comunicação são um tanto complexo, porem os resultados são muito uteis.

Os sistemas UNIX tem muitas características de rede. Os serviços básicos de impressão, copias de segurança, sistemas de arquivos, etc, podem ser realizadas através da rede. Isso pode tornar a administração do sistema mais simples, uma vez que permite a suas administração de forma centralizada, mantendo os benefícios do processamento distribuído e do uso de microcomputadores, gerando menores custos e melhor tolerância a falhas.

Acesso via Rede

Os acessos via rede são um pouco diferentes dos acessos normais, onde há uma linha serial distinta para cada terminal, através da qual é possível acessar o sistema. Nos casos de acessos via rede, para cada usuário que conecta-se ao sistema, há uma conexão virtual separada, podendo haver um numero ilimitado delas. Não é mais possível executar um getty para cada conexão virtual possível. Existem muitas formas diferentes de conectar-se via rede, sendo o telnet e rlogin os mais utilizados em redes TCP/IP, hoje sendo o ssh um serviço mais utilizado e mais seguro.

Acessos via rede tem, ao invés de inúmeros getty, um servidor controlando o acesso ( o telnet o rlogin e o SSH utilizam servidores distintos), o qual monitora as tentativas de conexão. Quando algum usuário tenta conectar-se, o servidor inicia uma nova instancia de si próprio para controlar esta conexão enquanto o servidor original continua monitorando novas tentativas. As novas instancias funcionam de maneira similar ao getty.

Sistemas de arquivos em Rede (NFS)

Uma das maiores facilidades disponibilizadas pelos serviços de rede é o compartilhamento de arquivos através de sistemas de arquivos em rede. O mais usado é conhecido como NFS (Network File System), tendo sido desenvolvido pela Sun.

Com um sistema de arquivos em rede, qualquer operação com arquivos executados por um programa em uma maquina, é enviada pela rede para outro computador. Esse procedimento faz o programa “pensar” que todos os arquivos encontram-se no mesmo equipamento onde ele esta sendo executado. Isto torna o compartilhamento de informações muito simples, já que não requer nenhuma modificação nos programas utilizados.

Correio Eletrônico

O correio eletrônico é normalmente o mais importante meio de comunicação entre os usuários. Uma mensagem eletrônica é armazenada em um arquivo, formatada de maneira especial, e programa de correio específicos são utilizados para ler e enviar mensagens.

Cada usuário tem uma caixa de entrada de mensagens ( um arquivo com um formato especial) onde todas as novas mensagens são armazenadas. Quando alguém envia uma nova mensagem, o programa de correio localiza a caixa do destinatário e adiciona a nova mensagem ao arquivo de mensagens. Caso a caixa de entrada esteja em outra maquina, a mensagem é enviada através da rede para o equipamento que mantem os arquivos de correio do destinatário.

O sistema de correio é constituído por uma serie de programas. A entrega de mensagens para usuários remotos é realizada por uma programa especifico ( o agente de transferência de mensagens ou MTA, como por exemplo o sendmail ou qmail), enquanto os programas de usuários são também distintos (agente de correio de usuário MUA, por exemplo: pine, elm, evolution). As caixas postais são normalmente armazenadas no diretório /var/spool/mail.

Impressão

Somente um usuário pode utilizar uma impressora a cada vez, mais seria anti-econômico não compartilhar esse recurso entre os demais usuários da rede. A impressora é gerenciada por um software que implementa o conceito de fila de impressão: todos os trabalhos são colocados em uma fila e todas vez que a impressora finaliza um trabalho de impressão, o seguinte é iniciado automaticamente. Isso evita que os usuários tenham que organizar esta fila ou que haja problemas no controle de uso da impressora.

O software de fila de impressão também trava os trabalhos de impressão em disco, ou seja os textos são mantidos em um arquivo enquanto estejam na fila de impressão. Isso permite que uma aplicação transfira rapidamente os trabalhos de impressão para o software gerenciador da fila, não tendo que esperar que o trabalho de impressão seja finalizado para continuar a sua execução.

Partes importantes do kernel

2011-03-31T16:52:00.001-03:00

O Kernel do linux é formado por diferentes partes: gerenciador de processos, gerenciador de memória, controle de dispositivos de hardware, controle de sistemas de arquivos, gerenciador de rede e vários outros. A figura abaixo mostra alguns deles.

Provavelmente as partes mais importantes do kernel ( nada funciona sem elas ) são o gerenciador de memória e o gerenciador de processos. O gerenciador de memória é o responsável pela atribuição de áreas de memoria e áreas de troca (swap) para os processos, para os demais componentes do kernel e para o cache de disco. O gerenciador de processos cria processos e implementa multitarefa através da troca de processos ativos no processador.

No nível mais baixo, o kernel contem controladores (drives) para cada tipo de hardware suportado. Uma vez que existem inúmeros hardwares, o numero de controladores também é muito grande. A similaridade de funcionalidades permite que se tenham classes de controladores para suportar funções similares, ou seja, cada membro de uma determinada classe de hardwares tem a mesma interface com o resto do kernel, mas diferem somente no que é necessário para implementar as suas características especificas. Por exemplo, todos os discos rígidos parecem iguais para o resto do kernel, isto é, todos tem operações como “inicialize o dispositivo”, “leia o setor N” e “grave o setor N”.

Alguns serviços de software disponibilizados pelo kernel tem propriedades similares, e podem ser também derivados em classes. Por exemplo, os diversos protocolos de rede foram abstraídos em uma interface de programação, a biblioteca BSD de socket. Outro exemplo é a camada do sistema virtual de arquivos (VFS), a qual abstrai as operações dos diversos sistemas de arquivos de suas implementações. quando alguma entidade tenta utilizar um sistema de arquivos, a requisição é direcionada ao VFS, o qual a reencaminha para o controlador adequado ao sistema de arquivos solicitado.

Visão Geral de um Sistema Linux

2011-03-30T18:11:00.001-03:00

Um sistema operacional UNIX consiste de um núcleo (kernel) e alguns programas do sistema. Há ainda aplicações que executam diversas tarefas. O kernel é o coração do sistema operacional. Ele mantem o controle dos arquivos em disco, inicializa programas e executa-os de forma concorrente, aloca memória e outros recursos para os diversos processos, recebe e envia pacotes da rede, e assim por diante. O kernel faz muito pouco sozinho, na verdade ele provê ferramentas com as quais os serviços podem ser desenvolvidos. Ele ainda evita que qualquer um possa acessar diretamente os componentes de hardware, forçando o uso das ferramentas disponíveis. Deste modo, o kernel mantem uma certa proteção entre os usuários. As ferramentas disponibilizadas pelo kernel são utilizados através das chamadas ao sistema (system calls).

Os programas de sistema utilizam as ferramentas disponibilizadas pelo kernel para implementar os diversos serviços necessários ao sistema operacional. Programas de sistema e todos os demais programas, são executados ‘sobre o kernel’, o qual é denominado modo usuário (user mode). a diferença entre programas de sistemas e aplicações esta no seu objetivo: as ultimas visam que coisas uteis sejam realizadas (brincar, caso seja um jogo), enquanto os primeiros são necessários para manter o sistema operacional funcionando. Um editor de texto é uma aplicação, o telnet é um programa de sistema. a diferença é algumas vezes muito pequena, e somente é importante para classificadores compulsivos.

Um sistema operacional pode ainda conter compiladores e suas bibliotecas correspondentes (gcc e C no caso do Linux), ainda que nem todas as linguagens devam ser parte integrante do sistema operacional. Documentação e até mesmo jogos podem fazer parte. Tradicionalmente o sistema operacional tem sido definido como o conteúdo nos discos de instalação, o que no Linux pode variar bastante, já que ele pode ser encontrado em diversos sites ao redor do mundo.

Datas de Calendário em Informix

2011-03-14T15:16:00.001-03:00

Datas de calendário em Banco de Dados Informix são armazenados como inteiros representando o numero de dias corridos desde 31 de dezembro de 1899. Como valores DATE são inteiros, eles podem ser usados em expressões aritméticas. Por exemplo:

SELECT order_date + 5 FROM orders

O exemplo acima adiciona cinco dias para cada data do pedido.

Quando a data é exibida por um servidor de banco de dados IBM Informix, o formato padrão é mm/dd/aaaa. Funções podem ser aplicadas para os valores armazenados em um tipo de dado DATE para modificar o modo de exibição, ou extrair o dia, dia da semana, e assim por diante.

Os tipos de dados cronológicos adicionais são:

DATETIME – registra um ponto exato no tempo, com precisão de um ano até uma fração de segundo. Quando você define uma coluna DATETIME. você pode especificar a sua precisão.
INTERVAL- armazena a medida de tempo entre dois tipos de dados DATETIME.

Algumas das funções relatadas para data e hora são listadas abaixo. Você pode usar essas funções na clausula SELECT ou na clausula WHERE de uma query. Essas funções retornam um valor que corresponde à expressão ou argumentos que você usa para chamar a função.

DAY (expressão date / datetime) – retorna um valor inteiro que representa o dia do mês.
MONTH (expressão date / datetime) – retorna um valor inteiro que representa o mês.
WEEKDAY (expressão date / datetime) – retorna um inteiro que representa o dia da semana (de 0 a 6, onde Domingo é 0 (zero)).
YEAR (expressão date / datetime) – retorna um inteiro de quatro dígitos que representa o ano.
DATE (expressão nondate) – retorna um valor DATE que corresponde a uma expressão caractere com a qual você chamou.
EXTEND (expressão date / datetime, [ primeiro ao ultimo]) – ajusta a precisão do valor DATE ou DATETIME.
MDY (mês, dia, ano) – retorna um DATE no formato mm/dd/aaaa com o mês, dia e ano informados.
CURRENT – retorna um valor DATETIME do instante corrente.

Uma expressão date / datetime é uma expressão que corresponde a um valor DATE ou DATETIME.

Exemplos:

Comparando Datas

SELECT customer_num, call_dtime
FROM cust_calls
WHERE call_dtime >= ‘2011-03-14’;

SELECT customer_num, call_dtime
FROM cust_calls
WHERE call_dtime >= DATE(‘03/14/2011’)

Extraindo o Mês

SELECT customer_num, MONTH(call_dtime)
FROM cust_calls

As funções TODAY e CURRENT

SELECT customer_num, MONTH(call_dtime)

FROM cust_calls

WHERE MONTH(call_dtime) = MONTH(CURRENT)

AND YEAR(call_dtime) < YEAR(CURRENT);

SELECT customer_num, MONTH(call_dtime)

FROM cust_calls

WHERE MONTH(call_dtime) = MONTH(TODAY)

AND YEAR(call_dtime) < YEAR(TODAY);

Também as funções TODAY ou CURRENT podem ser usadas para extrair o mês, dia, ano ou dia da semana da data do sistema. Esse exemplo usa a função TODAY e CURRENT para comparar os valores da coluna call_dtime para o mesmo mês corrente, mas do ano anterior.

A função TODAY retorna a data do sistema como um tipo DATE. A função CURRENT retorna o valor como um DATETIME.

A função EXTEND

SELECT customer_num call_dtime

FROM cust_calls

SELECT customer_num, EXTEND(call_dtime, month to minute)

FROM cust_calls

O primeiro exemplo acima retorna os valores de customer_num e call_dtime da tabela cust_calls sem o uso da função EXTEND. no segundo exemplo, a função EXTEND restringe os valores DATETIME da coluna call_dtime da tabela cust_calls exibindo somente os sub-campos especificados, de um mês ate minuto. Note que o ano não é retornado nesse exemplo.

A função TO_CHAR

SELECT TO_CHAR(call_dtime, ‘%A %B %d %Y %R’)

FROM cust_calls

A função TO_CHAR converte um valor DATE ou DATETIME para uma sequencia de caractere. A sequencia de caracteres contem a data no formato requisitado. Se você omitir todos os símbolos de formato, o formato padrão de data é usado.

Símbolo:	Faixa de caractere retornada:
%A	Nome completo do dia da semana
%B	Nome completo do mês
%d	Dia do mês como um decimal
%m	Mês como um decimal
%Y	Ano como um decimal de 4 dígitos
%R	Hora do dia no formato de 24 horas

Nota: A função TO_CHAR foi introduzida com o IDS 7.3

A função TO_DATE

SELECT * FROM cust_calls

WHERE call_dtime = TO_DATE(‘2011-03-14 14:56’,’%Y-%m-%d %H:%M’)

A função TO_DATE converte uma sequencia de caracteres para um valor DATETIME. A sequencia de caracteres é convertida de acordo como o formato especificado. Os símbolos de formato para a função TO_CHAR pode ser usados, bem como:

Símbolo:	Faixa de caractere retornada:
%H	Numero de horas
%M	Numero de minutos

Se você omitir o formato, o formato padrão do DATETIME é usado para converter a expressão.

UNIQUE ou DISTINCT?

2011-03-11T10:56:00.003-03:00

Use DISTINCT ou UNIQUE para exigir que as colunas em que o índice baseia-se aceitar apenas os dados únicos. Se você não especificar a palavra-chave UNIQUE ou DISTINCT, o índice vai permitir valores duplicados nas colunas indexadas ( ou um conjunto de colunas indexadas). O exemplo abaixo cria um índice único:

CREATE UNIQUE INDEX c_num_ix ON customer (customer_num)

Um índice único impede valores duplicados na coluna customer_num. A coluna com um índice único pode ter, no máximo, um valor NULL.

A palavra-chave DISTINCT e UNIQUE são sinônimos neste contexto, a declaração abaixo tem o mesmo efeito da declaração acima:

CREATE DISTINCT INDEX c_num_ix ON customer (customer_num)

Os índices em ambos os exemplos é mantida em ordem ascendente, qual é a ordem padrão.

Você também pode evitar dados duplicados em uma coluna ou um conjunto de colunas criando um UNIQUE CONSTRAINT com a declaração CREATE TABLE ou ALTER TABLE.

Em uma Query você pode evitar as linhas duplicadas de dados no resultado retornado incluindo a palavra-chave DISTINCT, ou o seu sinônimo UNIQUE, em seu comando SELECT. UNIQUE é uma extensão do IBM Informix para o padrão ANSI.

Quando você usa a palavra-chave DISTINCT ou UNIQUE, você deve coloca-la imediatamente apos o comando SELECT, no inicio de seleção. Ele é aplicado para toda a linha.

A palavra-chave DISTINCT ou UNIQUE, suprime os valores duplicados.

Usando Expressões Regulares no SquidGuard

2011-03-09T14:28:00.001-03:00

Nunca será possível adicionar todas as paginas que deseja bloquear pelos arquivos domains e url. Para alcançar um nível maior de segurança podemos usar o expressionlists.
Em uma expressionlist podemos entrar com palavras que provavelmente não se encontram em partes nos domains e urls. Cada domains e url serão comparados com as entradas encontradas em expressionlist.

Atenção: Somente use o expressionlist se você tem certeza que não se enquadram em sites inocentes. Além disso o uso dessas listas podem impactar na performance do sistema.

Adicionando listas de expressões na configuração.
Listas de Expressões são incluídas na tag dest. O exemplo abaixo mostra como fica o arquivo de configuração do squidGuad:

Usando a lista de expressões para bloquear porn

dest porn {
      domainlist        porn/domains
      urllist                porn/urls
      expressionlist   porn/expressions
}
Podemos adicionar a lista de expressões para cada destino definido (lembre-se: Performance!). SquidGuard procura pelo arquivo de expressões definido em dbhome.

Sintaxe das listas de expressões
O formato do arquivo expressionlist são linhas com expressões regulares:

.	Corresponde a qualquer caracter (use “\.” para corresponder a um “.”)
[abc]	Corresponde a um dos caracteres (“[abc]” corresponde a um dos caracteres “a” ou “b” ou “c”).
[c-g]	Corresponde a um dos caracteres no range (“[c-g]” corresponde a um dos caracteres “c” ou “d” ou “e” ou “f” ou “g”. ”[a-z0-9]” corresponde a qualquer letra ou digito. ”[-/.:?]” corresponde a um único “-“ ou “/” ou “.” ou “:” ou “?”).
?	Nenhum ou um dos anteriores (“words?” corresponderá “word” e “words” ”[abc]?” corresponderá há “a” ou “b” ou “c” ou nada (“”))
*	Nenhum ou mais das anteriores (“words” corresponderá há “word”, “words” e “wordssssss”. “.” correspondera a qualquer coisa incluindo nada)
+	Um ou mais das anteriores (“xxx+” correspondera a uma sequencia de 3 ou mais “x”).
(expr1\|expr2)	Uma das expressões. Uma expressão similar (“(foo\|bar)” correspondera há “foo” ou “bar”. ”(foo\|bar)?” correspondera a “foo” ou “bar” ou nada (“”)).
$	Final da linha (“(foo\|bar)$” correspondera a “foo” ou “bar” somente no final da linha.
\x	Desativar o significado especial de x, where x é caráter especial em regex “.?*+()^$[]{}\” (“\.” correspondera a um unico “.”, “\\” a um unico “\”, etc…)

As entradas para as listas de expressões são cleartext. Assim, um começo para bloquear um possivel material sexual, corresponde à expressão poderia parecer:

(^|[-\?+=/_])(bondage|boobs?|busty?|hardcore|porno?|sex|xxx+)([-\?+=/_]|$)

até mais.

Configuração Básica com squidGuard

2011-02-18T15:34:00.001-02:00

Neste artigo não vou abordar a instalação do squidGuard e sim a configuração do squidguard.conf. Depois do squidGuard instalado com sucesso, você pode configurar o software de acordo com suas necessidades. abaixo alguns exemplos de configurações básicas.

1. Uma configuração simples: uma categoria, uma regra para todos.

#
# Arquivo de Configuração para o squidGuard
#
dbhome /var/lib/squidGuard/db
logdir     /var/log/squidGuard

dest porno {
                 domainlist   blacklist/domains
                 urllist         blacklist/urls
                 }
acl {
          default {
                        pass !porno all
                        redirect http://10.0.1.8/block.html
                      }
       }

As entradas tem o seguinte significado:

dbhome Local onde se encontra os arquivos de controle, por exemplo (blacklist ou whitelist);

logdir Local onde serão armazenados os arquivos de logs.

dest Definição das categorias. Nessas categorias você pode definir os arquivos arquivos com domínios, urls e expressões regulares.

acl Definições de bloqueios. Em nosso exemplo somente a acl default foi definida. Você pode definir mais que uma acl. A categoria porno que definimos em dest é bloqueada pela expressão !porno. Temos que adicionar o identificador all depois dos blocklist ou os usuários não conseguirão navegar.
A diretiva redirect é mandatória, o squid mostrará um html avisando sobre o aviso do bloqueio.

2. Bloqueando mais de uma categoria:

Primeiro defina as categorias, como fizemos anteriormente, por exemplo: definindo 3 categorias

dest ads        {
                domainlist      blacklists/ads/domains
                urllist            blacklists/ads/urls
                }

dest agressivo {
                domainlist      blacklists/aggressive/domains
                urllist            blacklists/aggressive/urls
                }

dest aud-vid    {
                domainlist      blacklists/audio-video/domains
                urllist            blacklists/audio-video/urls
                }

Agora veja como fica a acl

acl {
         default {
                        pass !ads !agressivo !aud-vid all
                        redirect http://10.0.1.8/block.html
                      }
      }

3. Whitelist

As vezes é necessario liberar determinados sites, em corporações é normal a liberação de sites de bancos por exemplo.

dest bancos {
                 domainlist   whitelist/bancos/domains
                 urllist         whitelist/bancos/urls
                 }
acl {
          default {
                        pass bancos !ads !agressivo !aud-vid all
all
                        redirect http://10.0.1.8/block.html
                      }
       }

No exemplo acima nos assumimos que a whitelist esta localizada no diretório whitelist e determinamos um subdiretório bancos e tambem repare que nao usamos a exclamação para negar nesse caso.

Como utilizar o zypper com o OpenSuSE

2010-11-29T11:59:00.001-02:00

Instalando e removendo software

Para instalar um pacote registrado no repositorio use:

mozart:/etc/samba # zypper install samba-doc
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
samba-doc

1 new package to install.
Overall download size: 13.3 MiB. After the operation, additional 24.2 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package samba-doc-3.4.3-3.6.1.noarch (1/1), 13.3 MiB (24.2 MiB unpacked)
Retrieving: samba-doc-3.4.3-3.6.1.noarch.rpm [done (82.1 KiB/s)]
Installing: samba-doc-3.4.3-3.6.1 [done]
mozart:/etc/samba #

Para remover um pacote instalado use:

mozart:/etc/samba # zypper remove augeas-lenses
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be REMOVED:
augeas-lenses

1 package to remove.
After the operation, 151.0 KiB will be freed.
Continue? [y/n/?] (y): y
Removing augeas-lenses-0.5.0-2.2 [done]
There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs.
mozart:/etc/samba #

Atualizando Pacotes:

Há duas maneiras de atualizar os pacotes com zypper. Para atualizar todas as correções oficiais, rode o comando abaixo:

mozart:/etc/samba # zypper update

nesse caso, todos os patches que estão disponiveis no repositorio serao verificados e instalados, se necessario.

Para à atualização de um único pacote, rode o comando abaixo:

mozart:/etc/samba # zypper update aaa_base
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be upgraded:
aaa_base

1 package to upgrade.
Overall download size: 148.0 KiB. No additional space will be used or freed after the operation.
Continue? [y/n/?] (y): y

Retrieving package aaa_base-11.2-43.46.1.x86_64 (1/1), 148.0 KiB (319.0 KiB unpacked)
Retrieving delta: ./rpm/x86_64/aaa_base-11.2-43.45.1_43.46.1.x86_64.delta.rpm, 93.0 KiB
Retrieving: aaa_base-11.2-43.45.1_43.46.1.x86_64.delta.rpm [done (8.9 KiB/s)]
Applying delta: ./aaa_base-11.2-43.45.1_43.46.1.x86_64.delta.rpm [done]
Installing: aaa_base-11.2-43.46.1 [done]
Additional rpm output:
insserv: warning: script 'K01bilogix' missing LSB tags and overrides
insserv: warning: script 'bilogix' missing LSB tags and overrides
Updating etc/sysconfig/language...
Updating etc/sysconfig/backup...
Updating etc/sysconfig/boot...
Updating etc/sysconfig/kernel...
Updating etc/sysconfig/suseconfig...
Updating etc/sysconfig/clock...
Updating etc/sysconfig/proxy...
Updating etc/sysconfig/windowmanager...
Updating etc/sysconfig/sysctl...
Updating etc/sysconfig/cron...
Updating etc/sysconfig/news...
Updating etc/sysconfig/shutdown...
Updating etc/passwd...unchanged
Updating etc/group...unchanged
Updating etc/shadow...unchanged
insserv: warning: script 'K01bilogix' missing LSB tags and overrides
insserv: warning: script 'bilogix' missing LSB tags and overrides

There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs.

mozart:/etc/samba #

Para verificar os pacotes de atualizacao no repositorio registrado, verifique com o comando abaixo:

mozart:/etc/samba # zypper list-updates
Loading repository data...
Reading installed packages...
S | Repository           | Name                                | Current Version | Available Version | Arch
--+----------------------+-------------------------------------+-----------------+-------------------+-------
v | openSUSE-11.2-Update | aria2                               | 1.5.2-2.3.1     | 1.9.3-0.1.1       | x86_64
v | openSUSE-11.2-Update | autofs                             | 5.0.4-6.1       | 5.0.4-6.2.1       | x86_64
v | openSUSE-11.2-Update | bash                               | 4.0-18.3        | 4.0-18.4.1        | x86_64
v | openSUSE-11.2-Update | bash-doc                         | 4.0-18.3        | 4.0-18.4.1        | x86_64
v | openSUSE-11.2-Update | bzip2                               | 1.0.5-36.6      | 1.0.5-36.7.1      | x86_64
v | openSUSE-11.2-Update | cifs-mount                       | 3.4.2-1.1.3.1   | 3.4.3-3.6.1       | x86_64
v | openSUSE-11.2-Update | cpio                                | 2.10-4.2        | 2.10-4.3.1        | x86_64
v | openSUSE-11.2-Update | cron                                | 4.1-195.196.1   | 4.1-195.197.1     | x86_64
v | openSUSE-11.2-Update | cups                                | 1.3.11-4.1      | 1.3.11-4.5.1      | x86_64
v | openSUSE-11.2-Update | cups-client                       | 1.3.11-4.1      | 1.3.11-4.5.1      | x86_64
v | openSUSE-11.2-Update | cups-libs                          | 1.3.11-4.1      | 1.3.11-4.5.1      | x86_64
v | openSUSE-11.2-Update | desktop-translations           | 11.2-11.13.1    | 11.2-11.16.1      | noarch
v | openSUSE-11.2-Update | device-mapper                   | 1.02.31-11.2    | 1.02.31-11.3.1    | x86_64
v | openSUSE-11.2-Update | dhcpcd                             | 3.2.3-47.2      | 3.2.3-47.4.1      | x86_64
v | openSUSE-11.2-Update | ethtool                             | 6-79.2          | 6-79.3.1          | x86_64
v | openSUSE-11.2-Update | findutils                            | 4.4.0-46.2      | 4.4.0-46.3.1      | x86_64
v | openSUSE-11.2-Update | freetype2                          | 2.3.9-2.2       | 2.3.9-2.4.1       | x86_64

onstat–b (Mostra informações do buffer em uso)

2010-11-23T11:59:00.001-02:00

Use a opção onstat -b para exibir informações do buffers que estão em uso, incluindo o número total de páginas residentes na área de buffer.

Sintaxe:

informix@isis:~> onstat –b

O número máximo de buffers disponíveis especificado no parâmetro de configuração BUFFERPOOL do ONCONFIG.

O comando onstat -b também fornece informações resumidas dos número de buffers modificados, o número total de páginas residentes na área de buffer, o numero total de buffer disponível, o numero total de hash buckets disponíveis e o tamanho do buffer em bytes (tamanho da pagina).

informix@isis:~> onstat -b

IBM Informix Dynamic Server Version 11.50.FC6WE -- On-Line -- Up 14 days 06:16:07 -- 303184 Kbytes

Buffers
address userthread flgs pagenum memaddr nslots pgflgs xflgs owner waitlist

Buffer pool page size: 2048
1 modified, 50000 total, 65536 hash buckets, 2048 buffer size

informix@isis:~>

Nota: Informações geradas pelo onstat –b são paginas sendo modificadas por uma thread. Não confundir com paginas usadas.

O tamanho da pagina é a menor unidade de I/O no sistema e determinada no momento da transferência.

Atualmente, o campo userthread é sempre 0.

O numero de hash buckets é a menor potencia de dois no buffers.

Buffer hash buckets aponta para o buffer headers. Cada buffer header contem um ponteiro para um pagina no buffer que mantem informações sobre o status de paginas lidas e escritas para a pagina de buffer. Haverá um cabeçalho de buffer para cada reserva na área de buffer.

As chamadas são feitas para determinar a validade das informações contidas na página do buffer para cada I/O executado.

O número de páginas modificadas se torna zero quando o buffer pool é liberado com um checkpoint ou quando as paginas são limpadas.

Cada uma das páginas dentro do buffer pool pode ser exibida ao executar o comando onstat –g dmp com o valor memaddr e o pagesize ( exemplo onstat-g dmp 0xa088000 2048).

Não confundir o bloqueio de uma página da área de buffer com o bloqueio de uma página de banco de dados.

Páginas dentro da área de buffer será fechada e liberada como páginas (de qualquer tipo) que são lidas do disco e colocada no buffer.

Profissionais Windows x Linha de Comando

2010-09-22T14:47:00.001-03:00

Interessante esse tema, para ser sincero nem acho que nem tenho condições de estar escrevendo algum artigo para Windows, pois não conheço quase nada, porem tenho vários colegas de profissão que são profissionais em Windows e trabalham com o Mesmo, só que dar uma ênfase aqui, estou falando de profissionais que trabalham com Servidores Windows.

Pois bem… não é difícil deduzir que sou um profissional especializado no Mundo Unix, HP-UX, Linux, AIX, etc, trabalho com consultoria, a maioria sendo cliente Totvs principalmente aplicado ao sistema Logix, e 99% das consultoria que faço é baseado em sistemas Unix, aconteceu que esses dias um cliente que tem a base em Windows Server me contatou para fazer um serviço em Banco de Dados Informix.

Bom aceitei o desafio a principio somente auxiliando o responsável pelo sistema, e o auxilio foi no sentido de ajudar a criar uma instancia, dbspaces, chunks, etc,… até ai tudo bem, mas ai me deparei com um problema interessante, para entendermos melhor o problema vou explicar como faço no Unix para resolver isso.

Quando se cria a instancia no informix o IDS já cria os logical logs dentro do rootdbs, então geralmente, não sendo uma regra, por questão de organização até e performance a gente cria um dbspace e um chunk somente para o logical log:

# onspaces –a –d llog –p /dblog/llog.000 –o 0 –s 1000106

e no windows não é diferente:

# onspaces –a –d llog –p C:\IFMXDATA\tst\llog.000 –o 0 –s 1000212

muito bem, depois a gente da uma organizada em tudo isso, primeiro criando mais 3 arquivos de logs para o dbspace llog:

# onparams –a –d llog

e para o Windows o mesmo procedimento

depois de criado os 3 logs, então movemos o ponto do logical log e do check point ate os logs que foram criados.

# onmode –l

# onmode –c

muito bem, movidos os ponteiros, entra aqui uma brincadeira em shell script que utilizo muito para simplificar as tarefas, nesse caso para remover os logs do rootdbs

# for i in `seq 6`
do
onparams –d –l $i –y
done

esse comando simplesmente remove os 6 primeiros logical logs que estão no rootdbs, simplifica não…

pois bem…

depois comento isso para o windows,

feito isso no linux, o normal é a gente encher agora o chunk criado para os logs de logs, o comando ja passei acima , porem já pensou um chunk de 500.000 paginas, sendo que cada logical log tem o tamanho de 5000 paginas, a gente teria que executar o comando 100 vezes. é ai que entra a linha de comando novamente:

um exemplo bem simples e rápido

while true
do
onparams –a –d llog
done;

na era que começar a dar a mensagem na console de que o chunk esta cheio, simplesmente aperte o ctrl-c para cancelar a execução do script…

um exemplo mais elaborado

x=1
while [ $x != 0 ]
do
onparams –a –d llog
x=`onstat –d |grep tstlog | awk ‘{print $6}’`
done

esse script já é mais elaborado, na hora que a coluna do onstat free chegar a 0 quer dizer que ja encheu os logs, então o valor do x vai retornar 0 ao while fazendo que o mesmo aborte o código.

magico não , isso é o mundo linux.

Porem retornando ao tema Windows, no atendimento a esse cliente, fiquei pensando e agora como vamos encher o log…

uma maneira seria fazer na unha, seta para cima e enter… ate encher o log ,mas o Windows não? tem como automatizar a tarefa… ? postei em alguns blog essa duvida, e no máximo o que me responderam foi , cria um arquivo .bat e insira um monte de vez o comando e depois rode o arquivo de lote, sinceramente acho que foi a pior resposta que ouvi até hoje, porem continuei minha pesquisa no google por dias, e não consegui achar a solução desse problema, e também consultei alguns especialistas em plataforma Microsoft.

ontem instalando um servidor windows para teste, fiquei ainda pensando … caramba será que não tem maneira de automatizar isso mesmo?

foi ai que para minha surpresa resolvi digitar um for la no prompt do windows, pode parecer engraçado, mas o windows tem um for, me desculpem os usuários de windows que conhecem, pois eu nao conhecia, e resolvi ler o help do FOR e para minha surpresa, resolvi o primeiro problema…..

sim removi os 6 primeiros logs no windows com o comando FOR olhem só….

FOR /L %i IN (1,1,6) DO onparams –d –l %i –y

magico também, risos.

ai tinha o segundo problema que na verdade já tinha resolvido o segundo o com o primeiro ficando assim:

FOR /L %i IN (1,1,97) DO onparams –a –l llog

problema resolvido, o windows server até que foi interessante nesse caso, resolver um problema via prompt, confesso que para mim foi novidade sim, porem conhecimento adquirido.

Mas gostaria de destacar a não resolução desse problema pelos profissionais do Windows, eles mesmos não conhecem isso, so sabem mexer em mouse? mau costume……

abraços a todos e qualquer duvida estou a disposição.

Códigos de retorno do utilitário onstat

2010-09-21T12:04:00.001-03:00

O utilitário onstat exibe um conjunto de códigos de retorno quando você executa o utilitário.

Valor	Descrição
-1	Inicialização GLS local falhou ou IDS não anexou a memória compartilhada
0	Modo de Inicialização
1	Quiescent mode
2	Recovery mode
3	Backup mode
4	Shutdown mode
5	Online mode
6	Abort mode
7	User mode
255	Off-Line mode

onstat – : Status do Servidor

2010-09-06T14:40:00.001-03:00

Todas as saídas onstat inclui um cabeçalho. O comando onstat - exibe apenas o cabeçalho, devolvendo valores que indica o modo do servidor. A primeira parte da saída identifica a versão do Server, a segunda parte identifica o status do server. O status do servidor Informix pode assumir um dos seguintes valores:

Initialization
Shutting Down
Quiescent
OnLine
Fast Recovery
Abort
Archive Backup
Unknown
Read-Only

Adicionalmente, o status do servidor pode ser acompanhada de informações secundárias. O valor (PRIM) ou (SEC) será exibido para os sistemas em sistemas de replicação de dados. (CKPT REQ) aparecerá caso haja necessidade; (CKPT INP) aparecerá se um ponto de verificação está em andamento; e (LONGTX) aparecerá caso esteja tendo um ROLL BACK sendo executado.

E na parte final das informações são fornecidas o tempo que o servidor esta no ar, seguido pelo tamanho total dos segmentos da shared memory (resident + virtual) utilizado pelo servidor em Kbytes. Se o servidor é impedido de realizar qualquer trabalho, a razão é adicionado ao final da linha de status. As possíveis razões para um sistema de bloqueio são:

CKPT Checkpoint
LONGTX Long Transaction
ARCHIVE Archive Requested Block
MEDIA_FAILURE DBSpace being marked down
HANG_SYSTEM Server Requested Block
DBS_DROP DBSpace is being dropped
DDR DDR Synchronization
LBU Prevent Log Backups

Sintaxe:

isis:~ # onstat -

(Version--Mode (Type)--(Checkpnt)--Up Uptime--Sh_mem Kbytes)

IBM Informix Dynamic Server Version 11.50.FC6WE -- On-Line -- Up 19 days 03:08:27 -- 1310184 Kbytes

Version:
Nome e a versão do produto

Mode:
É o modo atual

Type:
Se o servidor de banco usa HDR, indica se o servidor é primario ou secundario.
Se o servidor não esta envolvido com HDR, então este campo não contem nada. Se o server é primario então será mostrado o valor P e se for um servidor secundario será exibido o valor S.

Checkpnt:
Se um flag Checkpnt é definido, poderá então ser mostrado mais 2 valores
(CKPT REQ) - Indica que um segmento de usuário solicitou um checkpoint
(CKPT INP) – Indica que um checkpoint esta em progresso. Durante o checkpoint, o acesso é limitado somente para leitura. O Servidor de Banco de Dados não pode escrever ou atualizar dados até que o checkpoint termine.

Uptime:
Indica o tempo que o Servidor de Banco de dados esta rodando.
Se a hora do sistema é alterado manualmente para uma data posterior da inicialização do banco de dados, o tempo de atividade não estará disponível. Nesta situação será exibido essa mensagem: Uptime Unavailable.

Sh_mem:
È o tamanho do banco de dados na Shared Memory, mostrado em kilobytes

onstat -d: Comando que mostra informações sobre o chunk

2010-09-03T14:08:00.001-03:00

Use o comando onstat-d para mostrar informações sobre os chunks de cada espaço de armazenamento.

O comando onstat –d fornece uma saída em duas partes. A primeira parte identifica todos os dbspaces numa instancia; a segunda parte identifica todos os chunks associados aos dbspaces da primeira parte.

Sintaxe:

onstat –d

Usando onstat-d com blobspaces

Se você usar o comando onstat-d em uma instância com chunks blobspace, o servidor de banco de dados exibira a seguinte mensagem:

NOTE: For BLOB chunks, the number of free pages shown is out of date. Run ‘onstat -d update' for current stats.

Para obter estatísticas dos chunks blobspaces atualizadas, digite o comando onstat –d update. O utilitário onstat atualiza a shared memory com uma contagem exata de páginas livres para cada chunk blobspace.

Waiting for server to update BLOB chunk statistics ...

Exemplo do comando onstat –d:

IBM Informix Dynamic Server Version 11.50.FC6WE -- On-Line -- Up 14 days 04:47:06 -- 1310184 Kbytes

Dbspaces

address	number	flags	fchunk	nchunks	pgsize	flags	owner	name
4c4cc028	1	0x70001	1	1	2048	N B	informix	rootdbs
4d53e9d0	2	0x70001	2	1	2048	N B	informix	plog
4d53eb68	3	0x42001	3	1	2048	N TB	informix	tmp1_tst
4d53ed00	4	0x42001	4	1	2048	N TB	informix	tmp2_tst
4d540028	5	0x42001	5	1	2048	N TB	informix	tmp3_tst
4d5401c0	6	0x60001	6	1	2048	N B	informix	logicallog
4d540358	7	0x60001	7	1	2048	N B	informix	crm_tst
4d5404f0	8	0x60001	8	4	2048	N B	informix	logix_tst

8 active, 2047 maximum

Chunks address	chunk/dbs	offset	size	free	bpages	flags	pathname
4c4cc1c0	1 1	0	150000	110158		P0-B-	/dbtst/dbroots/rootdbs
4d540688	2 2	0	500053	0		P0-B-	/tstlog/pyslog/plog
4d540878	3 3	0	250053	249950		P0-B-	/tsttmp/tmp1_tst
4d540a68	4 4	0	250053	249950		P0-B-	/tsttmp/tmp2_tst
4d540c58	5 5	0	250053	249950		P0-B-	/tsttmp/tmp3_tst
4d541028	6 6	0	1500053	0		P0-B-	/tstlog/logicallog/llog
4d541218	7 7	0	1000053	699914		P0-B-	/dbtst/crm/crm.01
4d541408	8 8	0	2000053	116		P0-B-	/dbtst/logix/tst.01
4d5415f8	9 8	0	2000003	90		P0-B-	/dbtst/logix/tst.02
4d5417e8	10 8	0	2000003	542310		P0-B-	/dbtst/logix/tst.03
4d5419d8	11 8	0	2000003	2000000		P0-B-	/dbtst/logix/tst.04

11 active, 32766 maximum

NOTE: The values in the “size” and “free” columns for DBspace chunks are
displayed interms of “pgsizes” of the DBspace to which they belong.

Expand chunk capacity mode: always

Descrição dos campos do DBspaces

address
É o endereço do dbspace na shared memory.

number
Número de identificação único do dbspace atribuído na criação.

flags
Valores hexadecimal usado para descrever cada dbspaces. Cada flag individual descreve o status do dbspace usando os seguintes valores hexadecimais:

Valor da Flag	Descrição
0x00000000	Mirror não habilitado e dbspace não espelhado
0x00000001	Mirror habilitado e dbspace não espelhado
0x00000002	Mirror habilitado e dbspace espelhado
0x00000004	Mirror do chunk desabilitado
0x00000008	Mirror Recente
0x00000010	Blobspace
0x00000020	Blobspace em mídias removíveis
0x00000040	Blobspace em mídias óticas
0x00000080	Blobspace dropado
0x00000100	Blobspace é ótico STAGEBLOB
0x00000200	DBspace esta sendo recuperado
0x00000400	DBspace totalmente recuperado
0x00000800	Logical Log esta sendo recuperado
0x00001000	Uma tabela na dbspace esta sendo dropada
0x00002000	DBspace temporário
0x00004000	Blobspace esta sendo backupeado
0x00008000	Sbspace
0x00010000	Physical ou logical log alterado
0x00020000	Dbspace ou chunk tables alterado
0x00040000	Dbspace ou blobspace contem large chunk
0x00080000	Chunk nesse dbspace foi renomeado
0x00100000	DBspace temporários utilizados apenas em discos compartilhados em outros servidores.É um dos dbspaces listados no parâmetro ONCONFIG SDS_TEMPDBS.
0x00200000	DBspace temporários utilizados apenas em discos compartilhados em outros servidores. É um dos dbspaces listados no parâmetro ONCONFIG DBSPACETEMP.
0x00400000	O DBspace foi backapeado.

fchunk
É o numero de identificação do primeiro chunk da dbspace

nchunk
É o numero de chunk existente na dbspace

pgsize
É o tamanho da pagina do dbspace em bytes

flags
Usa letras em cada posição para descrever cada dbspace

Posição 1:

Flag	Descrição
M	Mirror
N	Não Mirror

Posição 2:

Flag	Descrição
X	Mirror criado recente
P	physical recuperado aguardando pela recuperação do Logical Log
L	Logical esta sendo recuperado
R	Sendo recuperado
D	Down

Posição 3:

Flag	Descrição
B	Blobspace
S	Sbspace
T	DBspace temporária
U	SBspace temporária
W	DBspace temporário no server primário (Esta flag só é mostrada no server secundário)

Posição 4:

Flag	Descrição
B	O Dbspace tem chunks maiores que 2GB

Owner
Proprietário do DBspace

Name
Nome do DBspace

Na linha a seguir da lista dos dbspaces:
active: Numero de dbspaces sendo utilizando no momento pela instancia incluindo o rootdbs
Maximum: refere-se ao numero máximo de DBspaces que a instância suporta.

Descrição dos campos dos Chunks

address
É o endereço do chunk

chunk/dbs
É o numero do chunk associado ao numero do dbspace

offset
É o numero do offset do Chunk criado

size
Tamanho do total do chunk, esse numero é em paginas.

free
O número de páginas livres no chunk.
Para um blobspace, indica o números de paginas livres aproximado

bpages
Tamanho do total do chunk em blobpages.

flags
Prove informações de status dos chunks.

Posição 1:

Flag	Descrição
P	Primário
M	Mirror

Posição 2:

Flag	Descrição
N	Renomeado e requer inicialização ou inconsistente
O	Online
D	Down
X	Mirror criado recentemente
I	Inconsistente

Posição 3:

Flag	Descrição
-	DBspace
B	Blobspace
S	Smart Blobspace

Posição 4:

Flag	Descrição
B	O chunk tem suporte acima de 2GB

Posição 5:

Flag	Descrição
-	Não utiliza direct I/O ou os I/O concorrentes estão em cooked
C	No AIX ®, usando I/O concorrendo em cooked
D	Direto I/O

pathname
é o caminho dos chunks nos dispositivos físicos.

Na linha abaixo das visualizações dos chunks:
active: Numero de chunk sendo utilizando no momento pela instancia incluindo o rootdbs
Maximum: refere-se ao numero máximo de chunks a instância suporta.

dbhome	Local onde se encontra os arquivos de controle, por exemplo (blacklist ou whitelist);
logdir	Local onde serão armazenados os arquivos de logs.
dest	Definição das categorias. Nessas categorias você pode definir os arquivos arquivos com domínios, urls e expressões regulares.
acl	Definições de bloqueios. Em nosso exemplo somente a acl default foi definida. Você pode definir mais que uma acl. A categoria porno que definimos em dest é bloqueada pela expressão !porno. Temos que adicionar o identificador all depois dos blocklist ou os usuários não conseguirão navegar. A diretiva redirect é mandatória, o squid mostrará um html avisando sobre o aviso do bloqueio.