LOCKS DE TABELAS – ORACLE

Publicado: junho 26, 2014 em ORACLE
Tags:, ,

Abaixo segue um procedimento via SQL legal para quando ocorre lock de tabelas no ORACLE…

Primeiro, rodar este SQL para identificar quem é o “tranca-rua” =]

SELECT l.session_id||','||v.serial# sid_serial,
 l.ORACLE_USERNAME ora_user,
 l.OS_USER_NAME,
 o.object_name, 
 o.object_type, 
 DECODE(l.locked_mode,
 0, 'None',
 1, 'Null',
 2, 'Row-S (SS)',
 3, 'Row-X (SX)',
 4, 'Share',
 5, 'S/Row-X (SSX)',
 6, 'Exclusive', 
 TO_CHAR(l.locked_mode)
 ) lock_mode,
 o.status,  
 to_char(o.last_ddl_time,'dd.mm.yy') last_ddl
FROM dba_objects o, gv$locked_object l, v$session v
WHERE o.object_id = l.object_id
 and l.SESSION_ID=v.sid
order by 2,3;

Após, identificada a seção, rodar o comando abaixo para matar o processo…

SQL> ALTER SYSTEM KILL SESSION 'sid,serial#';>

Ou também, para agilizar…

SQL> ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;

Também é possível Desconectar a sessão do usuário, com os comandos abaixo, lembrando que o IMMEDIATE é mais ágil.

SQL> ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' POST_TRANSACTION;
SQL> ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE;

O Select abaixo também mostra algumas informações de locks de tabelas, legal observar a coluna BLOCK que mostra se aquela seção está bloqueando alguém (BLOCK > 0)

select     p.spid,
 s.username,
 s.osuser,
 s.machine,
 s.sid,
 p.program,
 l.lmode,
 l.block
 from     v$session s,
 v$process p,
 v$lock l
 where    s.paddr = p.addr
 and    l.sid = s.sid
 and     s.username is not null

E era isso!

Hoje me deparei com um problema… (que novidade… hehehhe)

Ao executar o check and update statistics o sistema apresentava os erros abaixo para todas as tabelas que necessitavam ser atualizadas:

BR0301E SQL error -20003 at location stats_ind_collect-3, SQL statement:

‘BEGIN DBMS_STATS.GATHER_INDEX_STATS (OWNNAME => ‘”SAPDEV”‘, INDNAME => ‘”ZTBPP008~0″‘, ESTIMATE_PERCENT => 1, DEGREE => NULL, NO_INVALIDATE => FALSE); END;’

ORA-20003: Specified bug number (5099019) does not exist

ORA-06512: at “SYS.DBMS_STATS”, line 11351

ORA-06512: at “SYS.DBMS_STATS”, line 11375

ORA-06512: at line 1

BR0886E Checking/collecting statistics failed for index SAPDEV.ZTBPP008~0

Após muita pesquisa, efetuei o relink dos binários do Oracle, como era recomendado em notas da SAP mas o problema continuou, consegui solucionar após rodar os 3 scripts abaixo:

  • SQL> @?/rdbms/admin/dbmsstat.sql
  • SQL> @?/rdbms/admin/prvtstas.plb
  • SQL> @?/rdbms/admin/prvtstat.plb

Ai tudo voltou ao normal!

Abraço!

Hoje estava com um grande problema, não conseguia de forma alguma completar um SQL para inserir valores com Data/Hora em um banco do SQL Server, ai depois de várias pesquisas consegui entender mais ou menos como as coisas funcionam no SQL Server 2008, segue abaixo, espero que aproveitem!

Antes do SQL Server 2008, o SQL Server apenas dava suporte a dois tipos de dados relacionados a data e a hora: DATETIME e SMALLDATETIME, os mesmo trabalham com data e hora em conjunto, com o surgimento do SQL Server 2008 temos os tipos de dados: DATE e TIME separados, DATETIME2 que tem um intervalo de dados maior e uma precisão melhor que DATETIME e DATETIMEOFFSET, este ultimo tem um componente de fuso horário. Veja abaixo com mais detalhes uma tabela informativa dos tipos de dados de data e hora:

Tipos de dados Armazenamento (Bytes) Intervalo de datas Precisão Formato de entrada recomendado e exemplo
DATETIME 8 10 de janeiro de 1753 a 31 de dezembro de 9999 3 1/3 milissegundos ‘AAAAMMDD hh:mm:ss.nnn’ ‘20090212 13:30:15.123’
SMALLDATETIME 4 10 de janeiro de 1990 a 6 de junho de 1979 1 minuto ‘AAAAMMDD hh:mm’ ‘20090212 12:30’
DATE 3 10 de janeiro de 0001 a 31 de dezembro de 9999 1 dia ‘AAAA-MM-DD’
TIME 3 a 5 100 nanossegundos ‘hh:mm:ss.nnnnnnn’ ’12:30:15:1234567’
DATETIME2 6 a 8 10 de janeiro 0001 a 31 de dezembro 9999 100 nanossegundos ‘AAAA-MM-DD hh:mm:ss.nnnnnnn’ ‘2009-02-12 12:30:15.1234567’
DATETIMEOFFSET 8 a 10 10 de janeiro de 0001 a 31 de dezembro de 9999 100 nanossegundos ‘YYY-MM-DD hh:mm:ss.nnnnnnn [+|-] hh:mm’ ‘2009-02-12 12:30:15.1234567 +02:00’

Sobre os requisitos de armazenamento dos últimos três tipos de dados na tabela acima:

TIME, DATETIME2 e DATETIMEOFFSET dependem da precisão que você escolher, ou seja, uma precisão com um número inteiro no intervalo de 0 a 7 que representa a precisão em fração de segundo.

Exemplo:

TIME(0): significa 0 de precisão em fração de segundo, ou seja, um segundo de precisão.
TIME(3): significa uma precisão de um milissegundo.
TIME(7): significa uma precisão de 100 nanossegundos.

Funções de data e hora

Primeiramente vamos mostrar as funções que retornam data e hora atuais, veja a tabela abaixo:

Função Tipo retornado Descrição Nova no SQL Server 2008
GETDATE DATETIME Data e hora atuais Não
CURRENT_TIMESTAMP DATETIME A mesma GETDATE, porem, ANSI Não
GETUTCDATE DATETIME Data e hora atuais em UTC Não
SYSDATETIME DATETIME2 Data e hora atuais Sim
SYSUTDATETIME DATETIME2 Data e hora atuais em UTC Sim
SYSDATETIMEOFFSET DATETIMEOFFSET Data e hora atuais incluindo fuso horário Sim

Veja o código abaixo demonstrando o uso das funções de data e hora atuais:

SELECTGETDATE() AS [GETDATE]SELECTCURRENT_TIMESTAMP() AS [CURRENT_TIMESTAMP]

SELECT

GETUTCDATE() AS [GETUTCDATE]

SELECT

SYSDATETIME() AS [SYSDATETIME]

SELECT

SYSUTCDATETIME() AS [SYSUTCDATETIME]

SELECT

SYSDATETIMEOFFSET() AS [SYSDATETIMEOFFSET]

Também temos a parte de formatação para exibição de data… segue abaixo

 

Standard Date Formats
Date Format Standard SQL Statement Sample Output
Mon DD YYYY 1 HH:MIAM (or PM) Default SELECT CONVERT(VARCHAR(20), GETDATE(), 100) Jan 1 2005 1:29PM 1
MM/DD/YY USA SELECT CONVERT(VARCHAR(8), GETDATE(), 1) AS [MM/DD/YY] 11/23/98
MM/DD/YYYY USA SELECT CONVERT(VARCHAR(10), GETDATE(), 101) AS [MM/DD/YYYY] 11/23/1998
YY.MM.DD ANSI SELECT CONVERT(VARCHAR(8), GETDATE(), 2) AS [YY.MM.DD] 72.01.01
YYYY.MM.DD ANSI SELECT CONVERT(VARCHAR(10), GETDATE(), 102) AS [YYYY.MM.DD] 1972.01.01
DD/MM/YY British/French SELECT CONVERT(VARCHAR(8), GETDATE(), 3) AS [DD/MM/YY] 19/02/72
DD/MM/YYYY British/French SELECT CONVERT(VARCHAR(10), GETDATE(), 103) AS [DD/MM/YYYY] 19/02/1972
DD.MM.YY German SELECT CONVERT(VARCHAR(8), GETDATE(), 4) AS [DD.MM.YY] 25.12.05
DD.MM.YYYY German SELECT CONVERT(VARCHAR(10), GETDATE(), 104) AS [DD.MM.YYYY] 25.12.2005
DD-MM-YY Italian SELECT CONVERT(VARCHAR(8), GETDATE(), 5) AS [DD-MM-YY] 24-01-98
DD-MM-YYYY Italian SELECT CONVERT(VARCHAR(10), GETDATE(), 105) AS [DD-MM-YYYY] 24-01-1998
DD Mon YY 1 SELECT CONVERT(VARCHAR(9), GETDATE(), 6) AS [DD MON YY] 04 Jul 06 1
DD Mon YYYY 1 SELECT CONVERT(VARCHAR(11), GETDATE(), 106) AS [DD MON YYYY] 04 Jul 2006 1
Mon DD, YY 1 SELECT CONVERT(VARCHAR(10), GETDATE(), 7) AS [Mon DD, YY] Jan 24, 98 1
Mon DD, YYYY 1 SELECT CONVERT(VARCHAR(12), GETDATE(), 107) AS [Mon DD, YYYY] Jan 24, 1998 1
HH:MM:SS SELECT CONVERT(VARCHAR(8), GETDATE(), 108) 03:24:53
Mon DD YYYY HH:MI:SS:MMMAM (or PM) 1 Default + milliseconds SELECT CONVERT(VARCHAR(26), GETDATE(), 109) Apr 28 2006 12:32:29:253PM 1
MM-DD-YY USA SELECT CONVERT(VARCHAR(8), GETDATE(), 10) AS [MM-DD-YY] 01-01-06
MM-DD-YYYY USA SELECT CONVERT(VARCHAR(10), GETDATE(), 110) AS [MM-DD-YYYY] 01-01-2006
YY/MM/DD SELECT CONVERT(VARCHAR(8), GETDATE(), 11) AS [YY/MM/DD] 98/11/23
YYYY/MM/DD SELECT CONVERT(VARCHAR(10), GETDATE(), 111) AS [YYYY/MM/DD] 1998/11/23
YYMMDD ISO SELECT CONVERT(VARCHAR(6), GETDATE(), 12) AS [YYMMDD] 980124
YYYYMMDD ISO SELECT CONVERT(VARCHAR(8), GETDATE(), 112) AS [YYYYMMDD] 19980124
DD Mon YYYY HH:MM:SS:MMM(24h) 1 Europe default + milliseconds SELECT CONVERT(VARCHAR(24), GETDATE(), 113) 28 Apr 2006 00:34:55:190 1
HH:MI:SS:MMM(24H) SELECT CONVERT(VARCHAR(12), GETDATE(), 114) AS [HH:MI:SS:MMM(24H)] 11:34:23:013
YYYY-MM-DD HH:MI:SS(24h) ODBC Canonical SELECT CONVERT(VARCHAR(19), GETDATE(), 120) 1972-01-01 13:42:24
YYYY-MM-DD HH:MI:SS.MMM(24h) ODBC Canonical (with milliseconds) SELECT CONVERT(VARCHAR(23), GETDATE(), 121) 1972-02-19 06:35:24.489
YYYY-MM-DDTHH:MM:SS:MMM ISO8601 SELECT CONVERT(VARCHAR(23), GETDATE(), 126) 1998-11-23T11:25:43:250
DD Mon YYYY HH:MI:SS:MMMAM 1 Kuwaiti SELECT CONVERT(VARCHAR(26), GETDATE(), 130) 28 Apr 2006 12:39:32:429AM 1
DD/MM/YYYY HH:MI:SS:MMMAM Kuwaiti SELECT CONVERT(VARCHAR(25), GETDATE(), 131) 28/04/2006 12:39:32:429AM

 

Extended Date Formats
Date Format SQL Statement Sample Output
YY-MM-DD
SELECT SUBSTRING(CONVERT(VARCHAR(10), GETDATE(), 120), 3, 8) AS [YY-MM-DD]
SELECT REPLACE(CONVERT(VARCHAR(8), GETDATE(), 11), ‘/’, ‘-‘) AS [YY-MM-DD]
99-01-24
YYYY-MM-DD
SELECT CONVERT(VARCHAR(10), GETDATE(), 120) AS [YYYY-MM-DD]
SELECT REPLACE(CONVERT(VARCHAR(10), GETDATE(), 111), ‘/’, ‘-‘) AS [YYYY-MM-DD]
1999-01-24
MM/YY SELECT RIGHT(CONVERT(VARCHAR(8), GETDATE(), 3), 5) AS [MM/YY] SELECT SUBSTRING(CONVERT(VARCHAR(8), GETDATE(), 3), 4, 5) AS [MM/YY] 08/99
MM/YYYY SELECT RIGHT(CONVERT(VARCHAR(10), GETDATE(), 103), 7) AS [MM/YYYY] 12/2005
YY/MM SELECT CONVERT(VARCHAR(5), GETDATE(), 11) AS [YY/MM] 99/08
YYYY/MM SELECT CONVERT(VARCHAR(7), GETDATE(), 111) AS [YYYY/MM] 2005/12
Month DD, YYYY 1 SELECT DATENAME(MM, GETDATE()) + RIGHT(CONVERT(VARCHAR(12), GETDATE(), 107), 9) AS [Month DD, YYYY] July 04, 2006 1
Mon YYYY 1 SELECT SUBSTRING(CONVERT(VARCHAR(11), GETDATE(), 113), 4, 8) AS [Mon YYYY] Apr 2006 1
Month YYYY 1 SELECT DATENAME(MM, GETDATE()) + ‘ ‘ + CAST(YEAR(GETDATE()) AS VARCHAR(4)) AS [Month YYYY] February 2006 1
DD Month 1 SELECT CAST(DAY(GETDATE()) AS VARCHAR(2)) + ‘ ‘ + DATENAME(MM, GETDATE()) AS [DD Month] 11 September 1
Month DD 1 SELECT DATENAME(MM, GETDATE()) + ‘ ‘ + CAST(DAY(GETDATE()) AS VARCHAR(2)) AS [Month DD] September 11 1
DD Month YY 1 SELECT CAST(DAY(GETDATE()) AS VARCHAR(2)) + ‘ ‘ + DATENAME(MM, GETDATE()) + ‘ ‘ + RIGHT(CAST(YEAR(GETDATE()) AS VARCHAR(4)), 2) AS [DD Month YY] 19 February 72 1
DD Month YYYY 1 SELECT CAST(DAY(GETDATE()) AS VARCHAR(2)) + ‘ ‘ + DATENAME(MM, GETDATE()) + ‘ ‘ + CAST(YEAR(GETDATE()) AS VARCHAR(4)) AS [DD Month YYYY] 11 September 2002 1
MM-YY SELECT RIGHT(CONVERT(VARCHAR(8), GETDATE(), 5), 5) AS [MM-YY] SELECT SUBSTRING(CONVERT(VARCHAR(8), GETDATE(), 5), 4, 5) AS [MM-YY] 12/92
MM-YYYY SELECT RIGHT(CONVERT(VARCHAR(10), GETDATE(), 105), 7) AS [MM-YYYY] 05-2006
YY-MM SELECT RIGHT(CONVERT(VARCHAR(7), GETDATE(), 120), 5) AS [YY-MM] SELECT SUBSTRING(CONVERT(VARCHAR(10), GETDATE(), 120), 3, 5) AS [YY-MM] 92/12
YYYY-MM SELECT CONVERT(VARCHAR(7), GETDATE(), 120) AS [YYYY-MM] 2006-05
MMDDYY SELECT REPLACE(CONVERT(VARCHAR(10), GETDATE(), 1), ‘/’, ”) AS [MMDDYY] 122506
MMDDYYYY SELECT REPLACE(CONVERT(VARCHAR(10), GETDATE(), 101), ‘/’, ”) AS [MMDDYYYY] 12252006
DDMMYY SELECT REPLACE(CONVERT(VARCHAR(10), GETDATE(), 3), ‘/’, ”) AS [DDMMYY] 240702
DDMMYYYY SELECT REPLACE(CONVERT(VARCHAR(10), GETDATE(), 103), ‘/’, ”) AS [DDMMYYYY] 24072002
Mon-YY 1 SELECT REPLACE(RIGHT(CONVERT(VARCHAR(9), GETDATE(), 6), 6), ‘ ‘, ‘-‘) AS [Mon-YY] Sep-02 1
Mon-YYYY 1 SELECT REPLACE(RIGHT(CONVERT(VARCHAR(11), GETDATE(), 106), 8), ‘ ‘, ‘-‘) AS [Mon-YYYY] Sep-2002 1
DD-Mon-YY 1 SELECT REPLACE(CONVERT(VARCHAR(9), GETDATE(), 6), ‘ ‘, ‘-‘) AS [DD-Mon-YY] 25-Dec-05 1
DD-Mon-YYYY 1 SELECT REPLACE(CONVERT(VARCHAR(11), GETDATE(), 106), ‘ ‘, ‘-‘) AS [DD-Mon-YYYY] 25-Dec-2005 1

 

Bom , era isso, em algumas horas é bem útil uma dica assim!! Abraço!!

Sabemos que no dia-a-dia, sempre estamos sujeitos a falhas, então por mais experiente que seja o Basis, ABAP ou qualquer pessoa que esteja utilizando o SAP, sempre que possível, crie barreiras para os erros!!

O STMS (Transporte de Requests) quando configurado em sistemas SAP para a transição de requests entre ambientes vem com o botão padrão para transporte de todas as requests da fila, o “CAMINHÃO GRANDE” como dizem meus colegas… esse caminhão é um PERIGO, pois quando executado, transporta tudo que está na fila da STMS para o ambiente aonde se está logado, imaginem isso no PRD…. é só arrumar a malhinha e ir embora né… hehehehe

Bom, para remover o botão de transporte de todas as requests é simples, primeiro veja a imagem do botão que falo abaixo:

Ele está dentro da fila de transporte de algum sistema, como DEV, QAS…

Para remove-lo:

  • Entre no sistema CONTROLADOR DE DOMINIO, no meu caso o DEV 000
  • No menu, clique em síntese de sistemas
  • Escolha o sistema que deseja remover e clique 2x
  • Entre na guia Ferramenta Transporte
  • Adicione a linha NO_IMPORT_ALL = 1
  • Veja como fica:

Salve tudo e teste se o botão sumiu nesse sistema,

Repita os passos para os outros sistemas que você transporta requests….

Agora durma sossegado!!

 

ESTATÍSTICAS ORACLE / SAP

Publicado: março 4, 2013 em ORACLE, SAP BASIS
Tags:, ,

A atualização das estatísticas das tabelas do SAP semanal executando, via Shell Script no Unix, o comando -> brconnect -u / -c -f stats -t all

O log deste comando aparece na DB13.

Recomendação:

É interessante rodar ao menos 1 vez a atualização das estatísticas para todas as tabelas do sistema com o comando: brconnect -u / -c -f stats -t all -f collect

Procedimento a ser estabelecido para todos os sistemas com Banco Oracle.

  1. Agendar execução semanal da atualização das estatísticas das tabelas (Usar DB13, isto é a sugestão da SAP):
    brconnect -u / -c -f stats -t all
  2. Executar periodicamente (Scheduler mensal, apesar da SAP sugerir a cada 3 meses) o procedimento para fixar estatisticas em tabelas especiais do SAP. Sempre obter a última versão dos scripts antes de executá-los.
    . Executar script statistics10.txt para fixar estatísticas (Nota 1020260)
    . Executar script dbstatc10.sql para atualizar tabela DBSTATC com as exceções a regra geral de otimização do BRCONNECT (Nota 403704)
  3. Executar periodicamente a atualização das estatísticas das tabelas do dicionário de dados do Oracle e estatísticas sobre o ambiente (hardware) a cada 2 ou 4 meses ou após upgrade de hardware ou aplicação de patches do Oracle (Nota 838725)
    . Parametro STATISTICS_LEVEL = TYPICAL – Dá uma olhada neste parâmetro

. stats_change_threshold = 50% => Após o limite deste parâmetro ser atingido a estatística será coletada.

. Desativar estatisticas automaticas do Oracle

SQL>EXECUTE DBMS_SCHEDULER.DISABLE(‘GATHER_STATS_JOB’)
brconnect -u / -c -f stats -t oradict_stats
brconnect -u / -c -f stats -t system_stats

Notas a serem verificadas

  • Nota 588668 – FAQ: Database Statistics
  • Nota 838725 – Oracle database 10g: New database statistics
  • Nota 1020260 – Delivering Oracle statistics
  • Nota 403704 – BRCONNECT – Enhanced functions for Oracle DBA
  • Nota 106047 DB21: Customizing the DBSTATC
  • Nota 122718 CBO: tables with special processing

As estatísticas da DB13 não são completas e não pegam todas as tabelas do Oracle.

Sugiro você rodar um full update statisticas utilizando o dbms_stat e em seguida, uma atualização de estatísticas da DB13 As estatísticas que o SAP não usa ele “limpa” dos controles internos do oracle de estatísticas e as que você atualizou serão

utilizadas por ele para gerar as novas seleções de tabelas a terem suas estatísticas atualizadas.

Este procedimento já foi aplicado em vários DBs e sempre funciona!

 

Hoje foi um dia daqueles aqui na empresa, estou a alguns dias buscando uma solução para um problema de performance em um banco de dados de nosso RH, é aquela velha situação, usuário grita de um lado, o outro escuta e grita também e tudo começa a virar uma bola de neve, mesmo sem muitas vezes nenhum deles ter razão, ai só resta ao DBA acompanhar um a um, para checar e comprovar (mais uma vez) que o problema não é o sistema/banco e sim o procedimento que o usuário está executando… aff, faz parte da vida… ehehhehe

Mas tudo isso sempre tem o lado positivo, estive pesquisando algumas coisas sobre performance e achei algumas coisas interessantes, as quais vou listar abaixo, é bom para quem está iniciando na área de banco de dados, é a configuração bem básica para fazer um banco funcionar de acordo…. espero que aproveitem….

Oracle

O ORACLE funciona com 3 estruturas principais, como qualquer outro banco de dados, estas são MEMÓRIA, ARMAZENAMENTO E PROCESSAMENTO, estes 3 itens tem que trabalhar de forma alinhada para que o desempenho do banco de dados seja satisfatório, ou melhor, “Supere as expectativas dos usuários”, pois é isso que eles sempre querem… =]

O primeiro aspecto que vamos falar é da MEMÓRIA

O Oracle e outros bancos de dados necessitam de muita memória (dependendo da aplicação é claro) para funcionar, digamos que “quanto mais melhor”.

As áreas de memória do ORACLE são divididas basicamente em SGA e PGA, SGA é compartilhada e PGA é privada.

A imagem abaixo mostra de forma simplificada o funcionamento da memória no banco de dados:

A memória para o banco de dados é importante, pois é aonde transitam todos os dados entre o CLIENTE <-> SERVIDOR, cada requisição que o usuário faz é processada pelo banco de dados, é feita leitura de arquivos físicos muitas vezes e enviados para a memória, aonde são ordenados e enviados para o usuário finalmente….

O gerenciamento de memória tem sido aprimorado nas ultimas versões do ORACLE, hoje na versão 11g temos os parâmetros abaixo de forma simplificada para serem ajustados, após explico cada um deles…

Vejam que temos um parâmetro chamado MEMORY_TARGET, hoje basta ajustar esse parâmetro no ORACLE que ele faz o resto, ajustando os valores necessários para a SGA e PGA, além de todas as “subdivisões” dentro destas.

Também é possível utilizar parametrizações especificas para a SGA e PGA, muitas vezes aplicações solicitam isso, por exemplo o SAP, ele passa uma série de configurações para a PGA e SGA, além dos componentes que existem dentro destas, impossibilitando o uso de parâmetros mais gerais como o MEMORY_TARGET. Quando um parâmetro interno da memória é especificado e também temos o MEMORY_TARGET ativo, o que acontece é que este parâmetro passa a valer para ser o mínimo de memória utilizado para tal componente, imagine por exemplo, termos a configuração abaixo:

MEMORY_TARGET = 2GB
DB_CACHE_SIZE = 500MB

A partir deste momento, o banco vai dimensionar a PGA e SGA automaticamente, desde que o DB_CACHE_SIZE que está dentro da PGA tenha no mínimo 500MB.

Os parâmetros tem a ordem básica abaixo representada

  • MEMORY_TARGET
    • SGA_TARGET (SGA_MAX_SIZE)
      • DB_CACHE_SIZE
      • JAVA_POOL_SIZE
      • LARGE_POOL_SIZE
      • SHARED_POOL_SIZE
      • LOG_BUFFER
      • STREAMS_POOL_SIZE
    • PGA_AGGREGATE_TARGET (_PGA_MAX_SIZE) (para funcionar tem que estar setado o parâmetro workarea_size_policy = auto)
      • BITMAP_MERGE_AREA_SIZE
      • CREATE_BITMAP_AREA_SIZE
      • HASH_AREA_SIZE
      • SORT_AREA_SIZE
      • WORKAREA_SIZE_POLICY

O mais simples é sempre deixar o banco gerenciar tudo, ajustando o MEMORY_TARGET e o resto é com ele…. só ajustar outros parâmetros quando ver que o bixo tá pegando, se tiver algum problema de performance ou for expressamente recomendado pelo sistema que está rodando sobre este banco.

Estas views mostram a utilização detalhada de cada item dentro da memória total alocada pelo parâmetro MEMORY_TARGET

· V$MEMORY_DYNAMIC_COMPONENTS – Visualiza os dados da MEMORY_SIZE, mostrando como está a distribuição de memória automática do banco de dados

· V$MEMORY_RESIZE_OPS – Esta mostra as ultimas alterações que o banco de dados efetuou na alocação de memória.

· V$SGA_DYNAMIC_FREE_MEMORY – Memória livre para alocação

Também podemos ver mais a fundo como está o funcionamento da SGA na view

· SELECT * FROM V$SGA

Temos alguns outros SELECTS abaixo que nos ajudam a TUNAR a SGA e PGA com seus respectivos componentes…

  • Este select mostra como está o uso dos buffers do banco, a coluna estd_physical_read_factor contém os valores que mudarão em percentual caso a memória (coluna size_for_estimate) seja ajustada.
    • Entendemos que neste caso precisamos ajustar o parâmetro BUFFER_CACHE, porém se ele não estiver setado, o ORACLE está administrando ele automaticamente, talvez seja necessário aumentar a memória como um todo na SGA_TARGET ou MEMORY_TARGET.
SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads FROM V$DB_CACHE_ADVICE WHERE name = 'DEFAULT' AND block_size = (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size') AND advice_status = 'ON'
  • Outro cara legal de checar é a situação da PGA, com o select abaixo
    • Ele mostra a situação, deve-se preocupar com o tamanho da SGA caso haja muitas entradas “multipass”
Select name, value from v$sysstat where name like ‘%workarea%’
  • Na PGA podemos checar também os acertos de cache, a ORACLE recomenda que este valor esteja acima de 95%
Select to_char(round(value,4),’999.99’) || ‘%’ “PGA Hit Ratio” From sys.v_$pgastat Where name = ‘cache hit percentage’; 

É possível impedir que os usuários conectem-se mais de uma vez concorrente no SAP.

Para isso, deve-se configurar o parâmetro (transação RZ10) login/disable_multi_gui_login com valor Y.

Para criar exceções (usuários que possam efetuar conexões múltiplas) deve-se configurar o parâmetro login/multi_login_users. O valor do parâmetro é o ID dos usuários, todos em maiúsculas, separados por vírgulas (com um máximo de 256 caracteres).

ERROS NO ORACLE

Publicado: julho 5, 2012 em ORACLE
Tags:,

Para descobrir o que significa o erro ORA-01017, por exemplo, conecte-se no sistema operacional com o usuário ora<SID>. Digite, na linha de comando, OERR ORA 01017. Você obterá a descrição do erro, forma de correção, etc.

Para ajustar a sintonia entre o SAP e o Oracle, verifique a nota 124361. Ela possui parâmetros para todas as versões de SAP (acima da 4) e Oracle.

É muito interessante ter noções de ORACLE, servidor… enfim, pois as configurações variam muito de uma máquina/SO para outra…

Por falhas no planejamento e utilização dos usuários, pode ser necessário desbloquear usuários sem conectar-se ao SAP (imagine que o único usuário com este privilégio esteja bloqueado). Para isso, acesse o banco de dados (no Oracle, por exemplo, execute o svrmgrl e digite connect internal) e execute o seguinte comando:

update sapr3.usr02 set uflag = 0 where mandt = <mandante> and bname = ‘<usuário>’

Caso a senha do usuário seja desconhecida, você pode apagar o usuário SAP* (assumindo que você não tenha a senha deste usuário também) e conectar-se com usuário SAP* e senha PASS. Para isso, o parâmetro de instância

login/no_automatic_user_sapstar tem que estar com o valor 0 na DEFAULT PROFILE – vide nota 68048.

Para apagar o usuário, acesse o banco de dados e execute o seguinte comando SQL:

delete from sapr3.usr02 where mandt = <mandante> and bname = ‘SAP*’

Não esqueça de dar um COMMIT depois de executar o SQL.

A melhor política de segurança é alterar a senha deste usuário para algo bem complexo, guardá-la em cofre na empresa e usar outro usuário (uma cópia deste). Dessa forma, este tipo de ação torna-se desnecessária.