Movimentando Lob Segments
Olá Pessoal.
Quando cria se uma tabela utilizando datatype XMLTYPE é criado um segmento do tipo lob.
Em um reorg por exemplo pode ser necessário movimenta-lo, para isso siga os passos abaixo.
PS: Esta mto objetivo pois estou com pressa… 
– Encontrando lob segments
SQL> SELECT SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME FROM DBA_EXTENTS WHERE SEGMENT_TYPE=’LOBSEGMENT’
2 AND TABLESPACE_NAME = ‘TSDCC’;
SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME
—————————— —————— ——————————
SYS_LOB0000270286C00004$$ LOBSEGMENT TSDCC
SYS_LOB0000270286C00004$$ LOBSEGMENT TSDCC
SYS_LOB0000270286C00004$$ LOBSEGMENT TSDCC
SYS_LOB0000270286C00004$$ LOBSEGMENT TSDCC
SYS_LOB0000270286C00004$$ LOBSEGMENT TSDCC
Para mover o lob precisamos das seguintes informações:
column table_name format a30
column column_name format a30
column segment_name format a30
SQL> SELECT OWNER, TABLE_NAME,COLUMN_NAME,SEGMENT_NAME FROM DBA_LOBS
2 WHERE TABLESPACE_NAME = ‘TSDCC’ ;
OWNER TABLE_NAME COLUMN_NAME SEGMENT_NAME
—————————— —————————— —————————— ——————————
BMFAUT TTSPMLQ_XML MSG_XML SYS_LOB0000120908C00004$$
BMFAUT TXMLMSGTV2 DS_DADO SYS_LOB0000120911C00007$$
BMFAUT TXMLMSGV2 DS_MSG SYS_LOB0000120917C00004$$
BMFAUT TXMLMSG_GERA DS_MSG SYS_LOB0000120920C00004$$
BMFCM TTSPMLQ_XML MSG_XML SYS_LOB0000120939C00004$$
A sintaxe para movimentar lob é ‘ALTER TABLE <TABLE_NAME> MOVE LOB <LOB_NAME> STORE AS <SEGMENT_NAME> TABLESPACE <TABLESPACE_NAME>;
Abaixo esta um sql dinamico para criar o script de movimentação.
– Cria script para movimentar lobs
SELECT ‘ALTER TABLE ‘ || OWNER || ‘.’ || TABLE_NAME || ‘ MOVE LOB (‘ || COLUMN_NAME || ‘) STORE AS ‘ || SEGMENT_NAME || ‘ TABLESPACE TSDCC2;’
FROM DBA_LOBS
WHERE TABLESPACE_NAME = ‘TSDCC’;
ALTER TABLE BMFAUT.TTSPMLQ_XML MOVE LOB (MSG_XML) STORE AS SYS_LOB0000120908C00004$$ TABLESPACE TSDCC2;
É isso.
Abs.
Henrique
Pra que serve cada script de relatórios AWR ?
Pessoal,
Esse post rápido irá descrever qual o proposito de cada scritpt awr localizado no $ORACLE_HOME/rdbms/admin .
– Relatorio para ambientes Single Instance
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
–Relatorio para ambientes RAC
@$ORACLE_HOME/rdbms/admin/awrgrpt.sql
–Relatorio para instancias especificas do RAC
@$ORACLE_HOME/rdbms/admin/awrgrpti.sql
–Para um sql especifico
@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql
– Para um sql especifico, em uma instancia especifica
@$ORACLE_HOME/rdbms/admin/awrsqrpi.sql
– Gerar relatorio com comparação de dois periodos distintos
@$ORACLE_HOME/rdbms/admin/awrddrpt.sql
– Gerar relatorio com comparação de dois periodos, usando todos instancias disponiveis no ambiente RAC.
@$ORACLE_HOME/rdbms/admin/awrgdrpt.sql
– Gerar relatorio com comparacao de dois periodos para uma instancia especifica do RAC
@$ORACLE_HOME/rdbms/admin/awrddrpi.sql
Vlws!
Commit;
Henrique
Otimizadores – CBO – E parametros de Tunning em poucas frases.
Pessoal,
Muito tempo sem postar nada :/ … Más vamos a um post rápido porém util.
Estou trabalhando em um projeto de performance, é legal pois mexo desde de bancos pequenos 4Gb até RAC´s em 4 nodes com TB.. abaixo esta uns parametros que tenho levado em consideração e trazem um belo resultado.
Vejam uma breve descrição sobre os otimizadores utilizados de forma mais comuns, e parametros relacionas ao CBO, espero que seja útil.
OTIMIZADORES
FIRST_ROWS, favorece acesso ao index, é usado quando existe a necessidade de retornar as primeiras linhas de forma rápida mesmo que isso gere mais I/O que um full table scan.
O otimizador FIRST_ROWS, geralmente é utilizado em sistema de transações ONLINE onde o usuário final precisa da primeira pagina de informação o mais rápido possivel.
ALL_ROWS, esse otimizador favorece full table scans, principalmente quando existe a necessidade de reduzir os recursos do servidor. Esse otimizador normalmente é utilizado durante processos batch e para DW, onde o objetivo e reduzir o consumo de recursos do servidor.
PARAMETROS DE AJUDA AO CBO
optimizer_index_cost_adj, é um parametro muito importante para o CBO, pois é ele que determina a propensão que o CBO terá de escolher acesso a index ao invés de FULL TABLE SCAN. Quanto menor o valor, mais chances o CBO terá de escolher acesso ao dado via Index. Esse parametro pode trazer (no meu caso traz efetivamente) grandes ganhos de performance em bancos OLTP. abaixo esta um script que ajuda a mensurar o valor do parametro (coluna c5).
select
a.average_wait c1,
b.average_wait c2,
a.total_waits /(a.total_waits + b.total_waits)*100 c3,
b.total_waits /(a.total_waits + b.total_waits)*100 c4,
(b.average_wait / a.average_wait)*100 c5
from
v$system_event a,
v$system_event b
where
a.event = ‘db file scattered read’
and
b.event = ‘db file sequential read’;
OPTIMIZER_INDEX_CACHING, esse parametro que diz ao CBO como seu index esta armazendo dentro do buffer cache.
O valor para o parametro optimizer_index_caching afeta o CBO em suas decisoes para operações de join ( nested loops) ou fazer um full table scan.
Abraço.
Henrique
Commit
/
Estimando crescimento da tablespace SYSAUX – Retenção do AWR.
Olá Pessoal.
Precisa aumentar a retenção do AWR ? Em quanto a tablespace SYSAUX será acrescida por causa dessa alteração ?
A Oracle disponibiliza um script que faz esse calculo pra você, chama-se utlsyxsz.sql e esta localizado dentro de $ORACLE_HOME/rdbms/admin , abaixo esta o out de um teste que fiz na minha VM, repare que ele faz a pergunta e já te da a resposta com a média do sistema, fácil não ?
Se precisar de um resumão do AWR, como retenção, intervalo de coleta, espaço ocupado e etc, use o script awrinfo.sql que esta no mesmo diretório.
**** SQLPlus *****
SQL> @utlsyxsz.sql
This script estimates the space required for the SYSAUX tablespace.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Specify the Report File Name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is utlsyxsz.txt. To use this name,
press <return> to continue, otherwise enter an alternative.
Enter value for report_name: x
Using the report name x
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SYSAUX Size Estimation Report
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Estimated at
12:13:26 on Sep 28, 2010 ( Tuesday ) in Timezone -03:00
DB_NAME HOST_PLATFORM INST STARTUP_TIME PAR
———– —————————————- —– —————– —
* CERT localhost.localdomain – Linux IA (32-bit 1 12:12:29 (09/28) N)
~~~~~~~~~~~~~~~~~~~~
Current SYSAUX usage
~~~~~~~~~~~~~~~~~~~~
| Total SYSAUX size: 74.0 MB
|
| Total size of SM/AWR 43.3 MB ( 58.4% of SYSAUX )
| Total size of SM/OPTSTAT 2.9 MB ( 3.9% of SYSAUX )
| Total size of LOGMNR 5.9 MB ( 8.0% of SYSAUX )
| Total size of SM/ADVISOR 5.3 MB ( 7.1% of SYSAUX )
| Total size of SM/OTHER 4.8 MB ( 6.4% of SYSAUX )
| Total size of EM_MONITORING_USER 1.6 MB ( 2.1% of SYSAUX )
| Total size of LOGSTDBY 0.9 MB ( 1.2% of SYSAUX )
| Total size of XSOQHIST 0.8 MB ( 1.0% of SYSAUX )
| Total size of AO 0.8 MB ( 1.0% of SYSAUX )
| Total size of STREAMS 0.5 MB ( 0.7% of SYSAUX )
| Total size of JOB_SCHEDULER 0.4 MB ( 0.5% of SYSAUX )
| Total size of TSM 0.3 MB ( 0.3% of SYSAUX )
| Total size of Others 6.9 MB ( 9.3% of SYSAUX )
|
~~~~~~~~~~~~~~~~~~~~
AWR Space Estimation
~~~~~~~~~~~~~~~~~~~~
| To estimate the size of the Automatic Workload Repository (AWR)
| in SYSAUX, we need the following values:
|
| – Interval Setting (minutes)
| – Retention Setting (days)
| – Number of Instances
| – Average Number of Active Sessions
| – Number of Datafiles
|
| For ‘Interval Setting’,
| Press <return> to use the current value: 60.0 minutes
| otherwise enter an alternative
|
Enter value for interval: 60
** Value for ‘Interval Setting’: 60
|
| For ‘Retention Setting’,
| Press <return> to use the current value: 7.00 days
| otherwise enter an alternative
|
Enter value for retention: 7
** Value for ‘Retention Setting’: 7
|
| For ‘Number of Instances’,
| Press <return> to use the current value: 1.00
| otherwise enter an alternative
|
Enter value for num_instances: 1
** Value for ‘Number of Instances’: 1
|
| For ‘Average Number of Active Sessions’,
| Press <return> to use the current value: 0.15
| otherwise enter an alternative
|
Enter value for active_sessions: 20
** Value for ‘Average Number of Active Sessions’: 20
| ***************************************************
| Estimated size of AWR: 380.8 MB
|
| The AWR estimate was computed using
| the following values:
|
| Interval - 60 minutes
| Retention - 7.00 days
| Num Instances - 1
| Active Sessions - 20.00
| Datafiles - 26
| ***************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Optimizer Stat History Space Estimation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| To estimate the size of the Optimizer Statistics History
| we need the following values:
|
| – Number of Tables in the Database
| – Number of Partitions in the Database
| – Statistics Retention Period (days)
| – DML Activity in the Database (level)
|
| For ‘Number of Tables’,
| Press <return> to use the current value: 1,781.0
| otherwise enter an alternative <a positive integer>
|
Enter value for number_of_tables: 1780
** Value for ‘Number of Tables’: 1780
|
| For ‘Number of Partitions’,
| Press <return> to use the current value: 0.00
| otherwise enter an alternative <a positive integer>
|
Enter value for number_of_partitions:
** Value for ‘Number of Partitions’: 0
|
| For ‘Statistics Retention’,
| Press <return> to use the current value: 31.0 days
| otherwise enter an alternative <a positive integer>
|
Enter value for stats_retention: 31
** Value for ‘Statistics Retention’: 31
|
| For ‘DML Activity’,
| Press <return> to use the current value: 2 <medium>
| otherwise enter an alternative <1=low, 2=medium, 3=high>
|
Enter value for dml_activity: 20
** Value for ‘DML Activity’: 20
| ***************************************************
| Estimated size of Stats history 72.6 MB
|
| The space for Optimizer Statistics history was
| estimated using the following values:
|
| Tables - 1,780
| Indexes - 1,883
| Columns - 26,052
| Partitions - 0
| Indexes on Partitions - 0
| Columns in Partitions - 0
| Stats Retention in Days - 31
| Level of DML Activity - Medium
| ***************************************************
~~~~~~~~~~~~~~~~~~~~~~
Estimated SYSAUX usage
~~~~~~~~~~~~~~~~~~~~~~
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Estimated size of AWR: 380.8 MB
|
| The AWR estimate was computed using
| the following values:
|
| Interval - 60 minutes
| Retention - 7.00 days
| Num Instances - 1
| Active Sessions - 20.00
| Datafiles - 26
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Estimated size of Stats history 72.6 MB
|
| The space for Optimizer Statistics history was
| estimated using the following values:
|
| Tables - 1,780
| Indexes - 1,883
| Columns - 26,052
| Partitions - 0
| Indexes on Partitions - 0
| Columns in Partitions - 0
| Stats Retention in Days - 31
| Level of DML Activity - Medium
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| For all the other components, the estimate
| is equal to the current space usage of
| the component.
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
| ***************************************************
| Summary of SYSAUX Space Estimation
| ***************************************************
| Est size of LOGMNR 5.9 MB
| Est size of SM/ADVISOR 5.3 MB
| Est size of SM/OTHER 4.8 MB
| Est size of EM_MONITORING_USER 1.6 MB
| Est size of LOGSTDBY 0.9 MB
| Est size of XSOQHIST 0.8 MB
| Est size of AO 0.8 MB
| Est size of STREAMS 0.5 MB
| Est size of JOB_SCHEDULER 0.4 MB
| Est size of TSM 0.3 MB
| Est size of Others 6.9 MB
| Est size of SM/AWR 380.8 MB
| Est size of SM/OPTSTAT 72.6 MB
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Total Estimated SYSAUX size: 481.3 MB
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ***************************************************
End of Report
Abraço,
Henrique
Commit
/
Adicionando disco em Diskgroup ASM – Linux.
Pessoal,
Este post na verdade não é bem um artigo, é só um rascunho.. porque eu mesmo esqueço as vezes a sequencia correta dos passos para adicionar um disco para o asm, então vou colocar aqui, assim já sei onde vou procurar.
Os passos do artigo se resumem em adiconar o disco no ASMLIB ( se não souber o que é ASMLIB, dá um procurada é importante) e depois no diskgroup do ASM.
Mãos a obra.
Primeiro veja se o disco já pertence ao Oracle , para isso faça um querydisk.
- querydisk
[oracle@acsprod mpath (acnxp0)]$ sudo /usr/sbin/oracleasm querydisk /dev/mpath/mpath18p1
Device “/dev/mpath/mpath18p1″ is not marked as an ASM disk
Veja que o Asmlib respondeu que o disco não pertence a ele, então vamos criar o disco no Asmlib.
– criando o disk
[oracle@acsprod mpath (acnxp0)]$ sudo /usr/sbin/oracleasm createdisk DSK013 /dev/mpath/mpath18p1
Writing disk header: done
Instantiating disk: done
Agora vamos listar os discos para ver ser foi criado “certinho”
– liste os discos
sudo /usr/sbin/oracleasm listdisks
DSK000
DSK001
DSK002
DSK003
DSK004
DSK005
DSK006
DSK008
DSK009
DSK010
DSK011
DSK012
DSK013
Opa, legal o disco DSK013 esta lá, agora vamos adiciona-lo ao Diskgroup no ASM .
Para isso configure as variaveis da sua instancia ASM e se conecte nela.
– veja o status dos discos e tamanho na visao v$asm_disk
set line 180
col path for a30
select name, mount_status, header_status, mode_status, label, path, total_mb, free_mb from v$asm_disk
order by label, path
/
– valida o tamanho / espacos dos diskgroups
SQL> select name, total_mb, free_mb from v$asm_diskgroup;
NAME TOTAL_MB FREE_MB
—————————— ———- ———-
NXARC 71672 71616
NXDAT 645040 4886
– adicion disco a um diskgroup
SQL> alter diskgroup nxdat add disk ‘ORCL:DSK012′ name DSK012;
Diskgroup altered.
SQL> alter diskgroup nxdat add disk ‘ORCL:DSK013′ name DSK013;
Diskgroup altered.
SQL> SQL> alter diskgroup nxdat add disk ‘ORCL:DSK014′ name DSK014;
Diskgroup altered.
– Verifica o novo tamanho do diskgroup.
SQL>
SQL> select name, total_mb, free_mb from v$asm_diskgroup;
0
NAME TOTAL_MB FREE_MB
—————————— ———- ———-
NXARC 71672 71616
NXDAT 860056 219896
Pronto o disco foi adicionado no Diskgroup.
Espero ter ajudado..
Abraço,
Henrique
commit
/
PS: Caso sua instância ASM seja 11g, você deve ser conectar com o privilegio de SYSASM e não SYSDBA com nas versões anteriores.es.
Recover de bloco com Block Media Recover – RMAN
Olá,
Amigos, um tempo sem post.. muito trabalho, fim de ano, projetos atrasados…. enfim.. vamos lá.
Quando menos se espera , você pode precisar BMR ou Block Media Recover, essa funcionalidade do RMAN que faz recuperação apenas do bloco corrompido tem salvo minha “vida” nos últimos 3 dias, isso porque a três noites seguidas que sou acordado pelo time de monitoraçao com erros no backup de 3 bases que tem datafiles no mesmo filesystem.
O problema é daqueles que nós DBA´s nunca queremos corrupção, por sorte esse ambiente tem o RMAN configurado perfeitamente com a Library de fitas, o que facilita muito meu trabalho, afinal faz o recover apenas do que realmente é necessário.
Bom vamos ao que interessa.
Primeiramente o erro – Se estiver usando o rman para backup não se desespere…rsrs
Hex dump of Absolute File 24, Block 116222 in trace file /oracle/9.2.0/admin/wb5ip0/udump/wb5ip01_ora_9888.trc
***
Corrupt block relative dba: 0x0601c5fe (file 24, block 116222)
Fractured block found during backing up datafile
Data in bad block -
type: 0 format: 0 rdba: 0×00000000
last change scn: 0×0000.00000000 seq: 0×0 flg: 0×00
consistency value in tail: 0xc51d0601
check value in block header: 0×0, block checksum disabled
spare1: 0×0, spare2: 0×0, spare3: 0×0
***
1 – Na mensagem temos informações valiosas, o id do datafile (24) e o bloco corrompido, com a query abaixo é possivel descobrir qual o segmento que esta nesse bloco, ou se por sorte ele esta vazio. Se o segmento for index por exemplo, não muito grande, pode se fazer um rebuild e já amenizar o problema.
SELECT SEGMENT_NAME, SEGMENT_TYPE FROM DBA_EXTENTS
WHERE FILE_ID = 24 AND 116222 BETWEEN BLOCK_ID AND
BLOCK_ID + BLOCKS – 1;
Uma alternativa bem legal também, é fazer resize do datafile (se possivel) até o bloco corrompido, isso vai eliminar o problema, e depois faz outro resize para o tamanho normal.
PS: Lembrando que o RMAN irá mostrar um erro sempre que for fazer backup, caso exista blocos corrompidos, então precisa realmente arrumar o “trem”.
2 – No meu caso o bloco estava vazio, então decidi utilizar o Block Media Recover, para isso, primeiro é necessário rodar um comando de verificação na base. Esse comando irá procurar por blocos corrompidos e em encontrando irá popular a view v$backup_corruption.
– Comando de verificação – Aloquei varios canais, más pode ser feito so o comando backup validate…
run {
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
allocate channel d5 type disk;
backup validate check logical database;
}
Quando o comando terminar, faça uma query na v$backup_corruption e veja o resultado.
SQL> select file#, block#, marked_corrupt, corruption_type
2 from v$backup_corruption;
FILE# BLOCK# MAR CORRUPTIO
———- ———- — ———
24 116222 YES FRACTURED
27 378708 YES FRACTURED
28 256001 YES FRACTURED
24 116222 YES FRACTURED
28 256001 YES FRACTURED
24 116222 YES FRACTURED
28 256003 YES FRACTURED
28 256005 YES FRACTURED
27 378708 YES FRACTURED
28 256001 YES FRACTURED
24 116222 YES FRACTURED
27 378708 YES FRACTURED
24 116222 YES FRACTURED
O retorno foi drastico, várias corrupções, vamos a correção.
No RMAN, mande o comando :
run {
ALLOCATE CHANNEL c1 TYPE ‘sbt_tape’
PARMS ‘ENV=(TDPO_OPTFILE=/oracle/9.2.0/tsm/tdpo_acvdp0.opt)’;
blockrecover corruption list;
RELEASE CHANNEl c1;
}
Uma explicação rápida sobre o bloco de comando acima:
ALLOCATE CHANNEL c1 TYPE ‘sbt_tape’ à alocando um canal do tipo fita
PARMS ‘ENV=(TDPO_OPTFILE=/oracle/9.2.0/tsm/tdpo_acvdp0.opt)’ – Passando path do driver da fita.
blockrecover corruption list à Ira fazer recover de toda a lista de blocos contidas na v$backup_corruption, uma alternative seria passer penas o file e bloco corrompido, nesse caso ficaria assim blockrecover datafile 24 block 116222;.
RELEASE CHANNEL C1 – Libera o canal de fita alocado no primeiro comando.
Durante a execução do comando, o rman irá pesquisar por um backup válido do bloco, e de forma sequencial aplicar os archives necessários para que o bloco fique consistente com o restante do banco.
– Saída do comando.
Starting blockrecover at 10-12-2010 05:25:32
channel c1: restoring block(s)
channel c1: specifying block(s) to restore from backup set
restoring blocks of datafile 00024
channel c1: restored block(s) from backup piece 1
piece handle=gslv3gfi_1_1 tag=TAG20101209T031551 params=NULL
channel c1: restored block(s) from backup piece 2
piece handle=gslv3gfi_2_1 tag=TAG20101209T031551 params=NULL
channel c1: restored block(s) from backup piece 3
piece handle=gslv3gfi_3_1 tag=TAG20101209T031551 params=NULL
channel c1: block restore complete
– Aplicando archives
archive log thread 1 sequence 90379 is already on disk as file /oradata/arch01/wb5ip0/wb5ip01_0000090379.arc
channel c1: starting archive log restore to default destination
channel c1: restoring archive log
archive log thread=1 sequence=90312
channel c1: restored backup piece 1
piece handle=gulv3h74_1_1 tag=TAG20101209T034748 params=NULL
channel c1: restore complete
channel c1: restore complete
Finished blockrecover at 10-12-2010 05:38:20
Após a finalização, faça um dbverify somente para garantir que não existem mais blocos corrompidos..
É isso galera.
Abraço,
Henrique
Commit
/
Validar sintaxe de script rman
Olá,
Precisa ter certeza de que seu script de backup / restore esta correto ? Não pode executa-lo ?
Utilize o comando checksyntax, veja como é simples.
Criei um arquivo de exemplo simples.
[oracle@localhost ~]$ vi bkp_online.sql
run {
backup as compressed backupset database include current controlfile plus archivelog;
}
Entre no rman com a opção checksyntax.
[oracle@localhost ~]$ rman checksyntax
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Sep 24 09:46:31 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN>
Para fazer o teste “chame” o script.
RMAN> @bkp_online.sql
RMAN> run {
2> backup as compressed backupset database include current controlfile plus archivelog delete all input;
3> }
The cmdfile has no syntax errors
RMAN> **end-of-file**
Se receber a mensagem “The cmdfile has no syntax errors”, fique tranquilo tudo esta perfeito.
Abraço,
Henrique
Commit
/
