O banco de dados é composto por um (ou mais dependendo se existem dbspaces adicionais) arquivo que chamamos de arquivo do banco de dados extensão db e um arquivo de log de transação extensão log.
O arquivo do banco armazena todas as informações de todos os objetos do banco de dados (tabelas, índices, stored procedures, etc). Ele é dividido em pages de tamanho fixo (ao se criar o banco é informado seu tamanho e a única forma de se alterar é recriando o banco) e qualquer estrutura dentro do banco (cache, arquivo de log, checkpoint log, etc) é lida ou gravada individualmente definida por este tamanho de page.
O page size do banco de dados do Sispetro é de 4Kb. |
Um arquivo de log (também chamado de foward log) armazena todas as alterações realizadas no banco a partir do momento em que o mesmo foi criado. Ele serve basicamente como um elemento de segurança para falhas no banco de dados principal e como um instrumento imprescindível para realização de sincronização entre bancos.
É fundamental que o banco de dados de produção tenha um log de transações ativo e numa unidade de disco diferente da do banco principal pois isso irá permitir restaurar o banco no caso de uma pane do banco de dados principal além de torná-lo mais rápido (pois se o banco não tem log, é obrigado a escrever todas as suas transações a partir do COMMIT no banco principal o que leva a uma sobrecarga no mesmo).
Este arquivo de log pode ser visualizado a partir do aplicativo dbtran. Este aplicativo transforma o arquivo de log num arquivo de texto contendo todos os comandos e transações salvas nele.
dbtran scgwin.log # conteúdo jogado para scgwin.sql type scgwin.sql --CHECKPOINT-0000-0030248238-2012-01-10 00:04 --CHECKPOINT-0000-0030248264-2012-01-10 00:05 --CONNECT-1011-0030248290-DBA-2012-01-10 00:39 --BEGIN TRANSACTION-1011-0030248301 BEGIN TRANSACTION go --UPDATE-1011-0030249452 UPDATE DBA.Deposito SET Descricao='BASE DEMO' WHERE CodDep='1' go --COMMIT-1011-0030249473 COMMIT WORK go |
Para entender melhor como um dado é gravado e como as estruturas acima funcionam, segue uma descrição de como um dado é gravado no banco.
Vamos supor que nós iremos alterar um dado numa determinada tabela (UPDATE de A para B).
Note que, neste momento, o banco não possui o dado alterado (somente o cache e, como segurança, o Transaction Log). |
DBSRV12 @<nome arquivo parametro> # scgwin.par: # -c120M # -xNone # -nScgwin12 # scgwin.db |
SELECT descricao FROM DEPOSITO WHERE CODDEP='1' // pode ser qq código, somente memorize o código e descrição UPDATE DEPOSITO SET DESCRICAO = DESCRICAO + '1' WHERE CODDEP='1' // para acrescentar 1 ao final do campo descricao |
COMMIT |
dbtran scgwin.log // vai jogar o arquivo de log transcrito para scgwin.sql |
// jogar para o subdiretorio backup COPY SCGWIN.* BACKUP/SCGWIN.* |
DBSRV12 @<nome arquivo parametro> # scgwin.par: # -c120M # -xNone # -nScgwin12 # scgwin.db |
SELECT descricao FROM DEPOSITO WHERE CODDEP='1' // pode ser qq código, somente memorize o código e descrição // deve mostrar DESCRICAO ORIGINAL + '1' |
dbsrv12 -f scgwin.db |
É importante considerar algo que nem sempre nos atemos quando instalamos o banco de dados: que ele está no topo de uma estrutura ao qual não tem controle direto (ver estrutura abaixo). Assim, quando ele solicita que um dado seja gravado no disco, está usando uma chamada de função de um sistema operacional. Em última instância, o que o Banco deseja é ver o dado gravado no disco porém o responsável por este comando funcionar são os níveis abaixo e como eles interagem entre si.
Existe um documento da própria Sybase para analisar a influência de cada elo na cadeia da gravação de um dado e é importante que o administrador do banco de dados o leia. O nome do documento é SQL Anywhere I/O Requirements for Windows and Linux. Resumidamente, existem duas preocupações importantes com relação ao processo de gravação do banco: cache em cada nível da pilha (disco rígido, controladora e sistema de arquivos em Linux) e o tipo do sistema de arquivos em Linux (no Windows, como o sistema de arquivos é normalmente NTFS, não existe uma preocupação neste sentido como é o caso do Linux onde existem diversos tipos de sistemas de arquivos).
Sistema Operacional |
Sintoma |
Ação |
---|---|---|
Windows |
Falha para honrar FUA bit ou o comando de flush cache |
Testar performance com cache desligado (Device Manager, Propriedades Disk Drive, Tab Política, Desabilitar "Write Caching"), atualizar SO e drivers controladores |
Linux |
FS = ext2, ext3 ou ext4 sem cláusula de montagem Barrier=1, ext3 ou ext4 com versão do Kernel igual ou inferior a 2.6.32, xfs com cláusula de montagem /nobarrier, xfs com versão do Kernel igual ou inferior a 2.6.33, LVM com versão do Kernel igual ou inferior a 2.6.29 |
Desabilitar write cache usando sdparm ou hdparm conforme o documento |
Como foi dito anteriormente, um banco de dados é composto por pages (páginas) de um determinado tamanho (que pode variar de 1K, 2K, 4K, 8K, 16K, 32K - o Sispetro utiliza páginas de 4K). Estas páginas são utilizadas para salvar organizadamente tabelas, índices e até a estrutura do cache (em memória). Seu tamanho é definido no momento da criação do banco de dados e afeta desde o uso correto do cache até o desperdício de espaço em disco passando por velocidade de leitura de dados e outros aspectos do dia a dia do banco. Existem alguns fatores para se chegar ao tamanho correto da pagina porém o mais importante com relação à administração do banco é tentar deixar o arquivo do banco (.db) desfragmentado (o mais contíguo possível no sistema de arquivos).
Cada vez que o número de páginas livre fica próximo de acabar, o banco aumenta seu tamanho físico, aumentando seu número de páginas livres.
Nossa tarefa aqui é tentar antecipar isso aumentando o tamanho do arquivo .db e depois desfragmentando o disco de forma que o arquivo .db fique num espaço contíguo (ou o mais contíguo possível).
# -u -> pedir informacoes de todas as tabelas inclusive da de sistema # -c -> parametros de conexão # -q -> quiet (nao mostrar informações na tela) # -o -> jogar informações para um arquivo DBINFO -u -c "server=<nome servidor>;uid=DBA;pwd=<senha banco>" -q -o "<nome arquivo output>" |
ALTER DBSPACE SYSTEM ADD 120MB |
O ideal é criar um evento que rode à noite para fazer este trabalho de forma automática. |
Tipo |
Valor |
---|---|
Tamanho Banco |
13 arquivos (DB) por banco. Para cada arquivo, seu tamanho é determinado pelo Sistema Operacional (mais abaixo) |
Tamanho Arquivo (FAT 12) |
16 MB |
Tamanho Arquivo (FAT 16) |
2 GB |
Tamanho Arquivo (FAT 32) |
4 GB |
Tamanho Arquivo para NTFS, HP-UX 11.0 ou mais recentes, Solaris 2.6 ou mais recentes, Linux 2.4 ou mais recentes) |
512 GB for 2 KB pages |
Tamanho Arquivo (para todas as outras plataformas e sistemas de arquivos) |
2 GB |
Tamanho máximo cache (non-AWE cache) (Windows XP Home Edition, Windows XP Professional, Windows Server 2003 Web Edition, Windows Server 2003 Standard Edition, Windows Server 2008, Windows Server 2008 R2, Windows 7) |
1.8 GB |
Tamanho máximo cache (non-AWE cache) (Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, Windows Vista Ultimate, Windows Vista Enterprise, Windows Vista Business, Windows Vista Home Premium, Windows Vista Home Basic) |
2.7 GB |
Tamanho máximo cache (AWE cache) (Windows XP Home Edition, Windows XP Professional, Windows Server 2003 Web Edition, Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition ) 100% da memória disponível |
128 MB |
Tamanho máximo cache (Windows Mobile) |
Limitado ao tamanho de memória do dispositivo |
Tamanho máximo cache (Unix---Solaris, x86 Linux, IBM AIX, HP) |
2 GB para servidor 32-bits |
Tamanho máximo cache (Win 64) |
Limitado pelo tamanho da memória física nos servidores 64-bits |
Tamanho máximo cache (Itanium HP-UX) |
Limitado pelo tamanho da memória física nos servidores 64-bits |
Depois que é feita a migração para o Sybase 12 não será mais possível com o mesmo scgwin.db voltara para a versão do Sybase 7.
Caso seja necessário voltar para a versão anterior, disponibilizaremos um sugestão, para isso você precisara de uma versão do banco de dados nas duas versões.
Para que o procedimento seja feito é necessário que se faça o Unload do banco na versão do Sybase 7, da estrutura e dos dados.
Abra o programa scview.exe que poderá ser encontrado em "C:\Arquivos de programas\Sybase\Shared\Sybase Central 3.2\win32\scview.exe" e conecte no banco que está na versão 7 do Sybase.
Não digite o número 5, aumente as dependências com a setinha. |
Para que o procedimento seja feito é necessário que se faça o Unload do banco na versão do Sybase 12 da estrutura e dos dados.
Abra o programa Sybase Central 6.1.0 e escolha o ODBC do banco de dados na versão do Sybase 12.
dbunload \-v \-c "DSN=scgwin12" \-r "C:\dado12\reload.sql" \-ii "C:\dados12\unload" |
Nesta fase iremos trabalhar com os scripts gerados nas etapas anteriores.
Criaremos três scripts:
//------------------------------------------------- //-- Reload data //------------------------------------------------- |
A disponibilidade do banco deve ser calculada de forma que se tenha o melhor custo/benefício para o cliente. O primeiro passo é definir quanto tempo o cliente aguentaria sem o Sistema no ar. Isso pode variar de nem um minuto, alguns minutos, algumas horas ou muitas horas. É lógico que, em sã consciência, todo cliente iria preferir a primeira opção. Porém, o custo de se ter um servidor auxiliar, licença de uso de um outro Sybase, uma estrutura de rede redundante, todos os micros com no-break, Internet redundante enfim, ter todos os pontos que podem falhar duplicados pode não compensar comparando este cenário com um muito mais barato onde teríamos um servidor auxiliar destino dos backups e um funcionário para acioná-lo caso o servidor principal falhe.
Enfim, é questão de avaliação porém é necessário sempre simular o tempo de parada nos mais variados cenários para se chegar a uma decisão conjunta.
Por isso, iremos listar os mecanismos disponíveis de proteção e cada um poderá optar pelo cenário com melhor custo/benefício para a sua empresa.
Você deve avaliar o procedimento de backup particularmente em função de cinco variáveis:
É a forma mais simples de se ter uma cópia do banco de dados em segurança. Todos os dados são copiados para um outro local criando uma cópia idêntica do banco de dados num determinado ponto no tempo.
Podemos executar o backup tanto no servidor diretamente quanto de uma outra máquina qualquer.
dbbackup -c "SERVER=scgwin12;UID=DBA;PWD=mara97" "c:\backup" # opções # Host=192.168.0.1 # DBN=scgwin.db |
BACKUP DATABASE DIRECTORY 'C:\\backup'; |
Tanto o arquivo principal (.DB) quanto o arquivo de log de transações (.LOG) são copiados e necessários no caso de uma restauração. |
O backup incremental é um backup parcial somente do arquivo de transações (.LOG) obtido no momento em que é realizado o backup. É como se tirássemos uma foto do log no momento da execução do comando. É um backup bem mais rápido do que o backup full. É chamado incremental pois logo após a sua realização truncamos o arquivo de log original fazendo com que o log original tenha somente as transações a partir daquele momento (em que o mesmo fora truncado). Ele é utilizado num esquema de backups onde normalmente é realizado um backup full num primeiro passo e, em seguida, realizados backups incrementais num intervalo fixo de tempo (1h por exemplo). Assim, teríamos num plano de backup hipotético, um backup full programado para a meia-noite, outro para o meio-dia e backups incrementais de hora em hora (1:00am, 2:00am e assim por diante). Para se restaurar um banco de dados num esquema como este, precisaríamos ter o backup full e todos os backups incrementais até o ponto da falha.
Quando implementamos este tipo de esquema de backup, normalmente realizamos o truncamento do log já no primeiro backup full utilizando a cláusula -x no comando ou adicionando TRANSACTION LOG TRUNCATE |
dbbackup -c "SERVER=scgwin12;UID=DBA;PWD=mara97" -x -t "c:\backup" # opções # Host=192.168.0.1 # DBN=scgwin.db |
Aqui devemos tomar um cuidado adicional pois como devemos preservar todos os logs, não podemos simplesmente sobreescrever os logs anteriores. Caso o comando acima seja executado novamente, ele irá sobreescrever o log inutilizando todo o esquema planejado. Para tanto, devemos adicionar mais duas cláusulas importantes:
dbbackup -c "SERVER=scgwin12;UID=DBA;PWD=mara97" -x -t -r -n "c:\backup" # opções # Host=192.168.0.1 # DBN=scgwin.db |
BACKUP DATABASE DIRECTORY TRANSACTION LOG ONLY LOG TRANSACTION LOG RENAME MATCH 'C:\\backup'; |
O backup diferencial na realidade segue a mesma linha do backup incremental tendo como única diferença o fato de não truncarmos o log de transações logo após realizarmos o backup incremental.
Assim, a cópia do log de transações realizada contém não só as últimas alterações ocorridas desde o último backup do log de transações como também todas as transações desde que o log foi truncado (normalmente pelo último backup full). Para se restaurar um banco de dados num esquema como este, precisaríamos ter o backup full e somente o último arquivo de log copiado até o ponto da falha.
Quando implementamos este tipo de esquema de backup, normalmente realizamos o truncamento do log já no primeiro backup full utilizando a cláusula -x no comando ou adicionando TRANSACTION LOG TRUNCATE |
dbbackup -c "SERVER=scgwin12;UID=DBA;PWD=mara97" -t -y "c:\backup" # opções # Host=192.168.0.1 # DBN=scgwin.db # A clausula -y serve para que o comando não pergunte se deseja sobreescrever o arquivo pois o nome será o mesmo do arquivo de log já copiado anteriormente |
BACKUP DATABASE DIRECTORY TRANSACTION LOG ONLY LOG 'C:\\backup'; |
Importante: Em todos os comandos de backup acima (full, incremental ou diferencial), utilizando a cláusula *-s faz com que o comando de backup seja executado no servidor (como se estivéssemos executando o mesmo comando via ISQL). Isso, em testes que fiz, faz com que o tempo de backup seja reduzido em quase 150%. Lembre-se somente que o diretório de backup nestes casos deverão ser especificados a partir do servidor, isto é, o diretório "c:\backup" dos exemplos acima serão criados ou utilizados no servidor independente do computador onde está sendo executado o comando. |
O backup live é um tipo diferente de backup. Na realidade, é um procedimento que coloca no ar (num outro computador normalmente), um processo que irá espelhar o arquivo de log de transações.
Ele serve para que tenhamos sempre uma cópia atualizada do arquivo de transações atual num outro local para que possamos, num processo de restauração, recuperar os dados até o exato momento da falha. Caso este procedimento não seja executado, corremos o risco de, por exemplo, ter uma falha no disco rígido onde está o arquivo de log de transações e, neste caso, conseguiríamos recuperar os dados até o último backup deste arquivo de log de transações (já que não conseguiríamos aplicar o log de produção na última etapa de recuperação).
dbbackup -l scgwin.log -c "SERVER=scgwin12;UID=DBA;PWD=mara97" c:\backup |
Um procedimento fundamental para aumentar a segurança do procedimento de backup é testá-lo, isto é, saber se o arquivo principal do banco copiado através do backup full está integro. Isso pode ser feito de duas formas:
Importante: É fundamental entender que, sempre que executamos o dbValid sobre um backup, ele altera o banco de dados pois deve subir o banco para verificar as tabelas e, no procedimento de subir o banco, o checkpoint log é restaurado e o transaction log aplicado (mesmo que não aplicássemos o transaction log, o checkpoint log é restaurado) fazendo com que qualquer tentativa futura de se utilizar o banco junto com backups incrementais posteriormente se torne mal sucedida. Para usar o dbvalid portanto, devemos utilizá-lo sobre uma cópia do backup. |
Nunca tente executar o dbvalid num banco com outros usuários conectados e com permissão de alteração pois ele dará resultados espúrios. Sempre execute o dbvalid subindo o banco com a cláusula -r (read-only) porém atenção: logo após realizar um backup, é fundamental subir a cópia do backup sem a cláusula -r aplicando o log (com a cláusula -ad) e depois subindo o banco normalmente com a cláusula -r pois o banco necessita se alterar quando sobe pela primeira vez após a realização de um backup. |
Vamos juntar o que foi exposto até o momento e realizar através de comandos batch os seguintes procedimentos:
"%SQLANY12%\bin32\dbinit.exe" ddd12.db |
"%SQLANY12%\bin32\dbspawn.exe"^ -f "%SQLANY12%\bin32\dbsrv12.exe"^ -o dbsrv12_log_ddd12.txt^ -oe dbsrv12_log_fatal_ddd12.txt^ -os 10M^ -x tcpip^ -zl^ -zp^ -zt^ ddd12.db # -o: log do console do servidor vai para arquivo # -oe: erros fatais vão para outro arquivo de log # -x TCPIP: protocolo TCP/IP # -os: renomear log qdo tamanho arquivo atingir tamanho especificado # -zl: relembrar ultimo comando executado para cada conexão # -zp: relembrar plano da última query executada de cada conexão # -zt: monitorar tempo de execução de cada processamento de cada conexão |
"%SQLANY12%\bin32\dbisql.com"^ -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql"^ READ ENCODING Cp1252 04s_script_to_create_table_and_event.sql |
CREATE TABLE rapid ( pkey INTEGER NOT NULL DEFAULT AUTOINCREMENT PRIMARY KEY ); CREATE EVENT rapid_insert HANDLER BEGIN WHILE 1 = 1 LOOP INSERT rapid VALUES ( DEFAULT ); COMMIT; WAITFOR DELAY '00:00:00.1'; END LOOP; END; TRIGGER EVENT rapid_insert; |
REM ****************************************************************** REM Criar sub-diretorio backup\generation_temp MD backup CD backup RD /S /Q generation_temp MD generation_temp CD .. ECHO ********************************************^ *********************************************>>backup\generation_temp\dbbackup_log.txt ECHO ***** Iniciado backup full >>backup\generation_temp\dbbackup_log.txt SET ERRMSG= DATE /T >>backup\generation_temp\dbbackup_log.txt TIME /T >>backup\generation_temp\dbbackup_log.txt REM ****************************************************************** ECHO ***** Passo 1 Backup Full >>backup\generation_temp\dbbackup_log.txt "%SQLANY12%\bin32\dbbackup.exe"^ -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql"^ -o backup\generation_temp\dbbackup_log.txt^ -x^ backup\generation_temp IF ERRORLEVEL 1 SET ERRMSG=Passo 1 Backup Full falhou com ERRORLEVEL = %ERRORLEVEL% IF NOT "%ERRMSG%z" == "z" GOTO backup_failed REM ****************************************************************** ECHO ***** Passo 2 Aplicar log >>backup\generation_temp\dbbackup_log.txt CD backup\generation_temp MD validate XCOPY ddd12.db validate /V /Q /K CD ..\.. REM Note: O diretório da cláusula -ad é relativo ao folder contendo o bando de dados. "%SQLANY12%\bin32\dbsrv12.exe"^ -o backup\generation_temp\dbbackup_log.txt^ backup\generation_temp\validate\ddd12.db^ -ad "%CD%\backup\generation_temp" IF ERRORLEVEL 1 SET ERRMSG=Passo 2 Aplicar log falhou com ERRORLEVEL = %ERRORLEVEL% IF NOT "%ERRMSG%z" == "z" GOTO backup_failed REM ****************************************************************** ECHO ***** Passo 3 Iniciar cópia com cláusula read-only >>backup\generation_temp\dbbackup_log.txt "%SQLANY12%\bin32\dbspawn.exe"^ -f "%SQLANY12%\bin32\dbsrv12.exe"^ -n readonlycopy^ -o backup\dbsrv12_readonlycopy_log.txt^ -r^ backup\generation_temp\validate\ddd12.db IF ERRORLEVEL 1 SET ERRMSG=Passo 3 Iniciar banco cópia com cláusula read-onlyu falhou com ERRORLEVEL = %ERRORLEVEL% IF NOT "%ERRMSG%z" == "z" GOTO backup_failed REM ****************************************************************** ECHO ***** Passo 4 Validar >>backup\generation_temp\dbbackup_log.txt "%SQLANY12%\bin32\dbvalid.exe"^ -c "ENG=readonlycopy;DBN=ddd12;UID=dba;PWD=sql"^ -o backup\generation_temp\dbbackup_log.txt^ -q IF ERRORLEVEL 1 SET ERRMSG=Passo 4 Validar falhou com ERRORLEVEL = %ERRORLEVEL% REM ****************************************************************** ECHO ***** Passo 5 Parar cópia read-only >>backup\generation_temp\dbbackup_log.txt "%SQLANY12%\bin32\dbstop.exe"^ -c "ENG=readonlycopy;DBN=ddd12;UID=dba;PWD=sql"^ -y IF NOT "%ERRMSG%z" == "z" GOTO backup_failed REM ****************************************************************** ECHO ***** Passo 6 Mover arquivos >>backup\generation_temp\dbbackup_log.txt CD backup RD /S /Q generation1 RENAME generation2 generation1 RENAME generation3 generation2 RENAME generation4 generation3 RENAME generation5 generation4 RENAME generation6 generation5 RENAME generation7 generation6 RENAME generation8 generation7 RENAME generation9 generation8 RENAME generation10 generation9 RENAME generation_temp generation10 CD .. REM ****************************************************************** REM Backup OK DIR /S backup\generation10\*.* >>backup\generation10\dbbackup_log.txt ECHO ***** Backup full OK >>backup\generation10\dbbackup_log.txt DATE /T >>backup\generation10\dbbackup_log.txt TIME /T >>backup\generation10\dbbackup_log.txt GOTO end :backup_failed REM ****************************************************************** REM Backup falhou ECHO ***** Error: Backup full falhou... >>backup\generation_temp\dbbackup_log.txt ECHO ***** %ERRMSG% >>backup\generation_temp\dbbackup_log.txt DATE /T >>backup\generation_temp\dbbackup_log.txt TIME /T >>backup\generation_temp\dbbackup_log.txt GOTO end :end |
A cláusula -ad é uma das únicas cláusulas onde o diretório passado é relativo ao local onde está o banco de dados e não (como é o padrão normal do SQLAnywhere) o local onde o servidor (executável) está sendo executado ou o folder corrente. Assim, utiliza-se a variável %CD% (que retorna o diretório corrente) para se criar um caminho completo a partir da raiz. |
ECHO ********************************************^ *********************************************>>backup\generation10\dbbackup_log.txt ECHO ***** Backup incremental iniciado >>backup\generation10\dbbackup_log.txt SET ERRMSG= DATE /T >>backup\generation10\dbbackup_log.txt TIME /T >>backup\generation10\dbbackup_log.txt REM ****************************************************************** ECHO ***** Passo 1 Verificar backup full >>backup\generation10\dbbackup_log.txt IF EXIST "backup\generation10\ddd12.db" ( GOTO check_full_log_backup ) ELSE ( GOTO full_backup_is_missing ) :check_full_log_backup IF EXIST "backup\generation10\ddd12.log" ( GOTO full_backup_exists ) ELSE ( GOTO full_backup_is_missing ) :full_backup_is_missing SET ERRMSG=Passo 1 Verificar backup full falhou GOTO backup_failed :full_backup_exists REM ****************************************************************** ECHO ***** Passo 2 Backup Incremental >>backup\generation10\dbbackup_log.txt CD backup\generation10 MD logs CD ..\.. "%SQLANY12%\bin32\dbbackup.exe"^ -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql"^ -o backup\generation10\dbbackup_log.txt^ -n^ -t^ -x^ backup\generation10\logs IF ERRORLEVEL 1 SET ERRMSG=Passo 2 Backup Incremental falhou com ERRORLEVEL = %ERRORLEVEL% IF NOT "%ERRMSG%z" == "z" GOTO backup_failed REM ****************************************************************** ECHO ***** Passo 3 Aplicar log >>backup\generation10\dbbackup_log.txt REM Nota: O diretório da cláusula -ad é relativo ao diretório contendo o banco de dados. "%SQLANY12%\bin32\dbsrv12.exe"^ -o backup\generation10\dbbackup_log.txt^ backup\generation10\validate\ddd12.db^ -ad "%CD%\backup\generation10\logs" IF ERRORLEVEL 1 SET ERRMSG=Passo 3 Aplicar log falhou com ERRORLEVEL = %ERRORLEVEL% IF NOT "%ERRMSG%z" == "z" GOTO backup_failed REM ****************************************************************** REM Backup OK DIR /S backup\generation10\*.* >>backup\generation10\dbbackup_log.txt ECHO ***** Backup Incremental OK >>backup\generation10\dbbackup_log.txt DATE /T >>backup\generation10\dbbackup_log.txt TIME /T >>backup\generation10\dbbackup_log.txt GOTO end :backup_failed REM ****************************************************************** REM Backup falhou ECHO ***** Error: Backup Incremental falhou >>backup\generation10\dbbackup_log.txt ECHO ***** %ERRMSG% >>backup\generation10\dbbackup_log.txt DATE /T >>backup\generation10\dbbackup_log.txt TIME /T >>backup\generation10\dbbackup_log.txt GOTO end :end |
Opção: Repetir o último passo 10 vezes preservando o conteúdo de até 10 diretórios. |
"%SQLANY12%\bin32\dbisql.com"^ -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql"^ SELECT COUNT(*), MAX ( pkey ) FROM rapid PAUSE Nota: COUNT deve ser igual ao MAX |
"%SQLANY12%\bin32\dbstop.exe" -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql" -y PAUSE Esperar enquando o banco para e entao... ERASE /F ddd12.db REM Nota: O log de transacao não é apagado. |
ECHO ********************************************^ *********************************************>>backup\generation10\dbbackup_log.txt ECHO Iniciado Restore >>backup\generation10\dbbackup_log.txt DATE /T >>backup\generation10\dbbackup_log.txt TIME /T >>backup\generation10\dbbackup_log.txt COPY backup\generation1\ddd12.db REM Nota: A cláusula -o grava os dados do diagnostico do backup deste exemplo. REM Nota: O diretório da cláusula -ad é relativo ao diretório contendo o banco de dados. "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation1 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation1\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation2 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation2\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation3 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation3\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation4 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation4\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation5 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation5\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation6 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation6\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation7 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation7\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation8 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation8\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation9 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation9\logs "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation10 "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -ad backup\generation10\logs REM Usar a cláusula -a para aplicar o log mais recente. "%SQLANY12%\bin32\dbsrv12.exe" -o backup\generation10\dbbackup_log.txt ddd12.db -a ddd12.log REM ****************************************************************** REM Fim do Restore DATE /T >>backup\generation10\dbbackup_log.txt TIME /T >>backup\generation10\dbbackup_log.txt |
Este é um esquema que permite ao Sybase ter fail-over, isto é, troca automática de banco em caso de pane de um banco principal. É um conceito simples e com um esquema simples de execução porém com alcance em termos de segurança muito profundos:
Crédito para o site http://sqlanywhere.blogspot.com ao qual tomei por base os meus testes e esta demonstração. |
REM Criando os subdiretorios... MD arbiter MD server1 MD server2 PAUSE REM Copiando o banco e o log no subdiretorio server1... PAUSE CD server1 COPY "C:\Documents and Settings\All Users\Documentos\SQL Anywhere 12\Samples\demo.db" COPY "C:\Documents and Settings\All Users\Documentos\SQL Anywhere 12\Samples\demo.log" "%SQLANY12%\bin32\dblog.exe" -t demo.log demo.db CD .. PAUSE REM Preparando os bancos para uso... PAUSE "%SQLANY12%\bin32\dbspawn.exe" -f "%SQLANY12%\bin32\dbeng12.exe" -n temp server1\demo.db "%SQLANY12%\bin32\dbisql.com" -c "ENG=temp;DBN=demo;UID=dba;PWD=sql" READ additional_DDL.sql "%SQLANY12%\bin32\dbstop.exe" -y -c "ENG=temp;UID=dba;PWD=sql" PAUSE REM Copiando o banco preparado para o server2... PAUSE copy server1\demo.db server2 copy server1\demo.log server2 PAUSE PREPARACAO OK |
CREATE OR REPLACE FUNCTION which_database ( IN @verbosity VARCHAR ( 7 ) DEFAULT 'verbose' ) -- or 'concise' RETURNS LONG VARCHAR BEGIN IF @verbosity = 'concise' THEN RETURN STRING ( 'Connection Number / Name ', CONNECTION_PROPERTY ( 'Number' ), ' / ', CONNECTION_PROPERTY ( 'Name' ), ', Server ', PROPERTY ( 'Name' ), ', Database ', DB_PROPERTY ( 'Name' ), IF PROPERTY ( 'Name' ) <> PROPERTY ( 'ServerName' ) THEN IF DB_PROPERTY ( 'ReadOnly' ) = 'On' THEN ' (HA secondary)' ELSE ' (HA primary)' ENDIF ELSE '' ENDIF, ' on ', PROPERTY ( 'MachineName' ), ' at ', IF CONNECTION_PROPERTY ( 'CommLink' ) = 'TCPIP' THEN '' ELSE STRING ( CONNECTION_PROPERTY ( 'CommLink' ), ' ' ) ENDIF, IF CONNECTION_PROPERTY ( 'CommNetworkLink' ) = 'TCPIP' THEN PROPERTY ( 'TcpIpAddresses' ) ELSE CONNECTION_PROPERTY ( 'CommNetworkLink' ) ENDIF, ' using ', DB_PROPERTY ( 'File' ) ); ELSE RETURN STRING ( ' Connection number: ', CONNECTION_PROPERTY ( 'Number' ), '\x0d\x0a Connection name: CON=', CONNECTION_PROPERTY ( 'Name' ), '\x0d\x0a Server name: ENG=', PROPERTY ( 'Name' ), '\x0d\x0a Database name: DBN=', DB_PROPERTY ( 'Name' ), IF PROPERTY ( 'Name' ) <> PROPERTY ( 'ServerName' ) THEN STRING ( '\x0d\x0a Actual HA server name: ', PROPERTY ( 'ServerName' ), IF DB_PROPERTY ( 'ReadOnly' ) = 'On' THEN ' (read-only HA secondary)' ELSE ' (updatable HA primary)' ENDIF, '\x0d\x0a HA arbiter is: ', DB_PROPERTY ( 'ArbiterState' ), '\x0d\x0a HA partner is: ', DB_PROPERTY ( 'PartnerState' ), IF DB_PROPERTY ( 'PartnerState' ) = 'connected' THEN STRING ( ', ', DB_PROPERTY ( 'MirrorState' ) ) ELSE '' ENDIF ) ELSE '' ENDIF, '\x0d\x0a Machine name: ', PROPERTY ( 'MachineName' ), '\x0d\x0a Connection via: ', IF CONNECTION_PROPERTY ( 'CommLink' ) = 'TCPIP' THEN 'Network ' ELSE STRING ( CONNECTION_PROPERTY ( 'CommLink' ), ' ' ) ENDIF, CONNECTION_PROPERTY ( 'CommNetworkLink' ), IF CONNECTION_PROPERTY ( 'CommNetworkLink' ) = 'TCPIP' THEN STRING ( ' to ', PROPERTY ( 'TcpIpAddresses' ) ) ELSE '' ENDIF, '\x0d\x0a Database file: ', DB_PROPERTY ( 'File' ) ); END IF; END; -- FUNCTION which_database |
REM Iniciando os servidores... "%SQLANY12%\bin32\dbspawn.exe" -f "%SQLANY12%\bin32\dbsrv12.exe" @arbiterconfig.txt "%SQLANY12%\bin32\dbspawn.exe" -f "%SQLANY12%\bin32\dbsrv12.exe" @server1config.txt "%SQLANY12%\bin32\dbspawn.exe" -f "%SQLANY12%\bin32\dbsrv12.exe" @server2config.txt PAUSE TUDO OK |
-n arbiter -o arbiter\arbiterlog.txt -su sql -x tcpip(port=55500) -xa auth=dJCnj8nUx3Lijoa8;dbn=demo -xf arbiter\arbiterstate.txt #-su sql: para executar dbstop no utility_db (banco de dados fantasma). #-xa <senha>: senha para todos os bancos participantes do esquema (todos devem ter a mesma senha). #-fx: designar um arquivo texto de controle do estado do banco (read-only). # dbn=demo (deve ser igual ao nome do banco de dados utilizado pelo servidor primario e secundário) |
# server options -n server1 -o server1\server1log.txt -su sql -x tcpip(port=55501;dobroadcast=no) -xf server1\server1state.txt # dobroadcast=no é usado somente para garantir que ele não irá responder a outros broadcasts ou participar de outros esquemas HAs # database options server1\demo.db -sm secondarydemo -sn primarydemo -xp partner=(eng=server2;links=tcpip(host=localhost;port=55502;timeout=1)); mode=sync;auth=dJCnj8nUx3Lijoa8;arbiter=(eng=arbiter;links=tcpip(host=localhost;port=55500;timeout=1)) #-sm: nome logico da engine para quando se quiser conectar no banco secundário (read-only). #-sn: nome logico da engine para quando se quiser conectar no banco primário. # Os nomes são lógicos pois eles decidirão o papel de cada um no esquema conforme a disponibilidade de cada banco. #-xp: *partner:* para se designar o parceiro (na configuração do banco primário é o secundário e vice-versa), # *mode*=synch para só liberar a transação no servidor primário quando o secundário receber # e aplicar a transação de forma síncrona, *auth*= deve ser igual para todos os bancos do esquema HA, # *arbiter:*= designar quem irá ser o árbitro do esquema. |
# server options -n server2 -o server2\server2log.txt -su sql -x tcpip(port=55502;dobroadcast=no) -xf server2\server2state.txt # database options server2\demo.db -sm secondarydemo -sn primarydemo -xp partner=(eng=server1;links=tcpip(host=localhost;port=55501;timeout=1)); mode=sync;auth=dJCnj8nUx3Lijoa8;arbiter=(eng=arbiter;links=tcpip(host=localhost;port=55500;timeout=1)) |
SETLOCAL SET MORE=DBN=demo;UID=dba;PWD=sql;LINKS=TCPIP(HOST=localhost:55501,localhost:55502;DOBROADCAST=NONE) "%SQLANY12%\bin32\dbisql.com" -c "ENG=primarydemo;CON=Conexao1;%MORE%" PAUSE Aguardar conexao para continuar.... "%SQLANY12%\bin32\dbisql.com" -c "ENG=secondarydemo;CON=Conexao2;%MORE%" PAUSE Tudo OK |
A regra final para que o esquema de HA funcione e os usuários tenham conexão com um banco é que existam pelo menos dois servidores ativos e se comunicando no esquema. Pode ser o servidor primário e o secundário, o servidor primário e o árbitro ou o servidor secundário e o árbitro porém devem existir dois servidores e que um enxergue o outro, isto é, seja possível uma comunicação entre eles. |
O correto monitoramento do banco faz com que possamos antecipar algum problema de lentidão ou melhorar a performance do mesmo a partir de certos parâmetros do servidor, do banco ou da conexão.
Assim, é importante primeiro conhecermos alguns parâmetros importantes e, em seguida, vermos como podemos monitorá-los.
Abaixo, segue um exemplo da criação de uma stored procedure que irá (ao ser consumida através de um SELECT * FROM V_SHOW_COUNTERS depois de ter sido criada) mostrar todos os contadores numéricos tanto do servidor quanto do banco de dados.
CREATE VIEW v_Show_Counters AS SELECT CAST( STRING ( '1.Servidor ', PROPERTY( 'Name' ) ) as VARCHAR(200) ) AS nome_propriedade, Propname AS nome, Value AS Valor, PropDescription AS Descricao FROM sa_eng_properties() WHERE ISNUMERIC( valor ) = 1 UNION ALL SELECT CAST( STRING ( '2.Banco Dados ', DB_NAME( Number) ) as VARCHAR(200) ) AS nome_propriedade, Propname AS nome, Value AS Valor, PropDescription AS Descricao FROM sa_db_properties() WHERE ISNUMERIC( valor ) = 1 ORDER BY 1,2; SELECT * FROM V_SHOW_COUNTERS; |
Como se pode ver (tela abaixo), ao ser executada, a procedure retorna uma infinidade de parâmetros sobre o banco e o servidor inclusive com uma breve descrição de cada uma delas.
O importante nesta análise é estabelecer uma baseline, isto é, monitorar alguns parâmetros e estabelecer quais são os números que indicam que o servidor ou o banco está trabalhando normalmente. Isto só pode ser estabalecido pelo próprio administrador já que cada ambiente tem suas próprias configurações de hardware, rede e número de clientes. Esta baseline deve ser estabelecida ao longo do tempo de forma que a média seja o número mais apropriado para se levar em consideração pois teremos momentos de pico ou vale que não irão caracterizar o comportamento normal do servidor ou banco.
Porém, quais são os mais importantes ou os primeiros a serem analisados e monitorados?
Nome Propriedade |
Descrição |
Tipo |
Observações |
---|---|---|---|
ActiveReq (activeReq) |
Número de requisições que estão sendo processadas no momento |
Servidor |
|
MaxReq (multiprogramminglevel) |
Número máximo de requisições possíveis de serem processadas ao mesmo tempo |
Servidor |
Corresponde ao parâmetro -gn (MultiProgrammingLevel) cujo default é 20. Este número pode ser aumentado automaticamente pelo servidor conforme o número de requisições pendentes, processadores e memória disponíveis. O número máximo é obtido pelo parâmetro MaxMultiProgrammingLevel e um valor razoável é igual a 80. |
WaitingReq (unSchReq) |
Número de requisições esperando para serem processadas |
Servidor |
|
DiskReads |
Número de páginas lidas pelo servidor |
banco de dados |
Pode-se obter a velocidade de leitura de páginas do servidor se calcularmos a diferença entre este parâmetro neste momento e seu valor a 1 minuto atrás. |
DiskWrites |
Número de páginas gravadas pelo servidor |
banco de dados |
Pode-se obter a velocidade de gravação de páginas do servidor se calcularmos a diferença entre este parâmetro neste momento e seu valor a 1 minuto atrás. |
BytesIn (bytesReceived) |
Bytes recebidos pelo servidor |
servidor |
Pode-se obter a velocidade de recebimento de dados via rede local do servidor se calcularmos a diferença entre este parâmetro neste momento e seu valor a 1 minuto atrás. |
BytesOut (bytesSend) |
Bytes enviados ao servidor |
servidor |
Pode-se obter a velocidade de envio de dados via rede local do servidor se calcularmos a diferença entre este parâmetro neste momento e seu valor a 1 minuto atrás. |
CacheHits |
Número de páginas que foram supridas pelo cache e não por uma leitura do disco |
Banco |
Satisfação Cache = CacheHits/CacheRead |
CacheRead |
Número de páginas que foram pesquisadas no cache |
Banco |
Qualquer dado manipulado pelo banco é trazido ao cache primeiro e este parâmetro conta o número de acessos ao cache independente se a página originalmente estava lá ou não. |
CachePanics |
Número de tentativas mal sucedidas de se alocar uma página ao cache |
Banco |
Deve ser sempre 0 ou próximo de 0 |
Low Memory (QueryLowMemoryStrategy) |
Número de vezes que o servidor teve de alterar seu plano de query por memória (cache) baixa |
Banco |
|
ApproximateCPUTime |
Consumo de CPU aproximado por conexão |
conexão |
Utilizar sa_conn_properties('ApproximateCPUTime') |
SELECT Number AS connection_number, CONNECTION_PROPERTY ( 'Name', Number ) AS connection_name, CONNECTION_PROPERTY ( 'Userid', Number ) AS user_id, CAST ( Value AS NUMERIC ( 30, 2 ) ) AS approximate_cpu_time FROM sa_conn_properties() WHERE PropName = 'ApproximateCPUTime' ORDER BY approximate_cpu_time DESC; # connection_number connection_name user_id approximate_cpu_time # ================= ================ ========== ==================== # 33 SQL_DBC_5071260 LongRunner 97.20 # 35 SQL_DBC_3aa4a78 DBA 2.09 # 12 Sybase Central 1 DBA 1.09 # 37 SQL_DBC_504b0f0 LotsOfLocks 0.00 |
Existem algumas opções para o monitoramento destes parâmetros:
O banco "estar lento" pode representar uma série de pequenos problemas que, somados, podem fazer o banco ficar lento. Devemos lembrar que o banco roda em cima de um sistema operacional, que é executado em cima de um hardware e se comunica com outros computadores através de uma rede local portanto qualquer um destes pontos pode estar contribuindo para a percepção de lentidão. Outro ponto a se considerar é: lento em relação a que? É importante termos parâmetros para podermos comparar, por exemplo, o número de commits por segundo de um servidor para ver e comparar em dois momentos diferentes.
Mesmo isso pode não dar a noção exata do motivo da lentidão pois, como foi falado antes, existem outros fatores que não foram mencionados aqui que influenciam a performance sentida pelo usuário, portanto, é fundamental conhecer o seu ambiente. Todos os pontos que se interligam (rede, switch, servidor, etc) devem ser monitorados através de poucos porém confiáveis parâmetros de forma que a investigação sobre a lentidão seja bem sucedida (e inclusive investimentos possam ser realizados baseados na realidade dos números e não em achismos).
Isso leva tempo porém a mesma mecânica que fazemos com o banco deve ser ampliada para o servidor em si, para a rede local de forma a monitorar todos os pontos entre o usuário e o servidor.
Iremos demonstrar aqui como funciona uma outra ferramenta importante neste gerenciamento que é o tracing.
Ele permite capturar todos os comandos realizados pelo banco ordenando-os e analisando-os de forma que se tenha uma noção do que o servidor está fazendo. Estas informações podem, inclusive, serem transmitidas para outra pessoa analisar (setor de suporte, por exemplo).
Em seguida, vamos dar algumas dicas de otimização do banco.
dbinit.exe banco.db dbspawn.exe -f dbeng11.exe -o banco_msg.txt -oe banco_fatal.txt -x tcpip banco.db dbisql.com -c "ENG=banco;DBN=banco;UID=dba;PWD=sql |
dbspawn.exe -f dbeng11.exe -o banco_trace_msg.txt -oe banco_trace_fatal.txt -x tcpip banco_trace.db dbisql.com -c "ENG=tracing;DBN=tracing;UID=dba;PWD=sql" |
SELECT 'query 1', SYSTABCOL.domain_id, COUNT(*) FROM SYSTABCOL CROSS JOIN SYSTAB CROSS JOIN SYSGROUP GROUP BY SYSTABCOL.domain_id ORDER BY SYSTABCOL.domain_id; |
SELECT 'query 2', SYSTABCOL.domain_id, COUNT(*) FROM SYSTABCOL CROSS JOIN SYSTABCOL AS b CROSS JOIN SYSGROUP GROUP BY SYSTABCOL.domain_id ORDER BY SYSTABCOL.domain_id; |
UNLOAD SELECT sa_diagnostic_cursor.plan_xml FROM dbo.sa_diagnostic_cursor INNER JOIN dbo.sa_diagnostic_request ON sa_diagnostic_request.logging_session_id = sa_diagnostic_cursor.logging_session_id AND sa_diagnostic_request.cursor_id = sa_diagnostic_cursor.cursor_id WHERE sa_diagnostic_request.logging_session_id = <logging session id> AND sa_diagnostic_request.request_id = <request Id> TO 'c:\temp\<nome desejado>.saplan' DELIMITED BY '' ESCAPES OFF HEXADECIMAL OFF QUOTES OFF; |
SELECT DB_PROPERTY('DBFILEFRAGMENTS'); |
Alguns desfragmentadores trabalham melhor com arquivos criados do que com espaço livre, isto é, ao executar o desfragmentador antes de se criar o banco, o banco acaba fragmentado desnecessariamente. Assim, a ordem correta é criar o banco e depois desfragmentar o disco rígido. |
ALTER DBSPACE SYSTEM ADD 100MB; |
CALL sa_table_fragmentation; |
REORGANIZE TABLE <nome_tabela>; |
SELECT * FROM SA_INDEX_LEVELS() ORDER BY SA_INDEX_LEVELS.TABLENAME, SA_INDEX_LEVELS.INDEXNAME; |
REORGANIZE TABLE <nome_tabela> INDEX <nome_indice>; |
Um usuário pode estar com seu computador aparentemente travado e isto tem, obviamente, várias causas que podem estar ou não relacionadas ao banco de dados. Vamos assumir então que todas as outras causas (computador com defeito em algum de seus componentes, rede intermitente, problema no Sistema Operacional, lentidão no servidor causada por algum outro processo sendo executado, etc) foram analisadas e estão em ordem.
Devemos, então, formular algumas perguntas:
Podemos identificar se um usuário está ou não executando algo no servidor através de dois procedimentos (depende se o FoxHound está disponível ou não). Caso você não tenha o FoxHound, execute o comando abaixo.
select connection_property('ReqStatus', sci.Number) as ReqStatus, usu.usuario, sci.* from sa_conn_info() sci INNER JOIN usuarioConexaoBanco usu on (sci.number = usu.IdConexao) WHERE USUARIO = <NOME USUARIO INVESTIGADO> |
O resultado segue abaixo.
Note que, como não existe nenhuma informação nas informações vindas da conexão (pois todas se logam como DBA), o Sispetro registra, quando o usuário faz o login, na tabela UsuarioConexaoBanco o número da conexão (Number) juntamente com o nome do usuário sempre sobreescrevendo o último valor apresentado.
Podemos ver acima que o usuário Futura não está realizando nenhum trabalho no banco (pois a coluna ReqStatus está com o valor Idle e a coluna LastReqTime está com uma data/hora muito distante de quando foi executado o comando). Além disso, ele não está travado por nenhuma outra conexão (apareceria o número da conexão na coluna BlockedOn).
Uma outra alternativa é utilizar o FoxHound sendo que antes devemos pesquisar o número da conexão (ou números pois o Sispetro utiliza 2 conexões ativas).
Um outro SELECT interessante para se ter uma noção de quais usuários estão consumindo mais CPU do banco de forma rápida é o seguinte:
SELECT con.Number AS connection_number, CONNECTION_PROPERTY ( 'Name', Number ) AS connection_name, usu.usuario , CONNECTION_PROPERTY ( 'Userid', Number ) AS user_id, CAST ( Value AS NUMERIC ( 30, 2 ) ) AS approximate_cpu_time FROM sa_conn_properties() con INNER JOIN usuarioConexaoBanco usu ON ( con.NUmber = usu.IdConexao ) WHERE PropName = 'ApproximateCPUTime' ORDER BY approximate_cpu_time DESC; |
Para identificar que o usuário está travado por outro usuário, podemos recorrer ao script abaixo ou ao foxhound novamente.
SELECT NUMBER(*) AS #, Name, usu.usuario, UserId, Number, BlockedOn FROM sa_conn_info() as con INNER JOIN usuarioConexaoBanco usu ON ( con.Number = usu.IdConexao ) WHERE con.BlockedOn <> 0 OR EXISTS( SELECT * FROM sa_conn_info() as con2 WHERE con2.BlockedOn = con.BlockedOn ) ORDER BY BlockedOn, Name, UserId, number; |