[oracle_br] RE: Restore sem um datafile
Tudo jóia ?? Então, basicamente é o que eu falei : TODA e QUALQUER linha numa tabela Oracle, como nós sabemos, é identificada por um ROWID, e um ROWID é composto pelo id do datafile + bloco +slot aonde a linha reside, sim ??? Então, basta vc colocar uma condição no ROWID especificando para não acessar o datafile e/ou os blocos corrompidos, okdoc ??? Nada muito complicado, a nota metalink "Extract rows from a CORRUPT table creating ROWID from DBA_EXTENTS" (Doc ID 422547.1) dá um scriptzinho-exemplo... E é Óbvio, antes de mostrar o meu exemplo, observo que : a. eu suponho aqui que o datafile ** inteiro ** foi perdido : claro que se na verdade foram só uns poucos blocos que corromperam, vc facilmente poderia usar a DBMS_REPAIR para 'marcar' no dicionário de dados os blocos corruptos , que serão pulados nos próximos selects, veja a nota "Extracting Data from a Corrupt Table using DBMS_REPAIR or Event 10231" (Doc ID 33405.1) b. ululantemente óbvio que Índices vc simplesmente reconstrói/recria, views materiualizadas vc faz refresh, etc c. eu estou exemplificando aqui com o caso mais simples, de uma tabela heap comum e normal, sem datatypes não-escalares, nem nada : claro que na vida real vc pode ter CLUSTER TABLEs, aonde o mesmo bloco pode conter linhas de múltiplos segmentos, vc pode ter LOBs (que no caso de LOBs não-inline residem em extents de LOB), pode ter Partições A nota "Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g" (Doc ID 28814.1) te guiará para esses casos mais complexos... => Isso posto, vamos ao teste : primeiro, vamos criar uma tabela espalhada por múltiplos datafiles ... SQL> create tablespace TS_TESTE_CORRUPT datafile '/home/oracle/app/oracle/oradata/orcl/ts_teste_corrupt01.dbf' size 10m autoextend on; Tablespace created. SQL> create table TB_CORRUPT tablespace TS_TESTE_CORRUPT as (select * from dba_objects where 1=2) ; Table created. SQL> insert /*+ APPEND */ into TB_CORRUPT (select * from dba_objects); 74926 rows created. SQL> commit; Commit complete. SQL> alter database datafile '/home/oracle/app/oracle/oradata/orcl/ts_teste_corrupt01.dbf' autoextend off; Database altered. SQL> alter tablespace TS_TESTE_CORRUPT add datafile '/home/oracle/app/oracle/oradata/orcl/ts_teste_corrupt02.dbf' size 10m autoextend on; Tablespace altered. SQL> insert /*+ APPEND */ into TB_CORRUPT (select * from dba_objects); 74926 rows created. SQL> commit; Commit complete. => maravilha, vamos acessar todos os blocos dos dois datafiles : SQL> select count(*) from TB_CORRUPT; COUNT(*) -- 149852 => espia a nossa amiga DBA_EXTENTS : SQL> desc dba_extents Name Null? Type -- OWNER VARCHAR2(30) SEGMENT_NAME VARCHAR2(81) PARTITION_NAME VARCHAR2(30) SEGMENT_TYPE VARCHAR2(18) TABLESPACE_NAME VARCHAR2(30) EXTENT_ID NUMBER FILE_ID NUMBER BLOCK_ID NUMBER BYTES NUMBER BLOCKS NUMBER RELATIVE_FNO NUMBER => veja lá que tenho extents nos dois datafiles : SQL> select file_id, RELATIVE_FNO, sum(blocks) from dba_extents where tablespace_name='TS_TESTE_CORRUPT' group by file_id, RELATIVE_FNO; FILE_ID RELATIVE_FNO SUM(BLOCKS) -- --- 881024 771152 SQL> select file_id, file_name from dba_data_files where file_id in (7,8); FILE_ID -- FILE_NAME - 7 /home/oracle/app/oracle/oradata/orcl/ts_teste_corrupt01.dbf 8 /home/oracle/app/oracle/oradata/orcl/ts_teste_corrupt02.dbf ==> okdoc ?? Agora vou corromper/perder um dos datafiles : SQL> !cp /dev/null /home/oracle/app/oracle/oradata/orcl/ts_teste_corrupt02.dbf => ululantemente óbviamente, AINDA tenho no dicionário extents marcados como pertencentes ao arquivo apagado, quando tentar acesssar a tabela inteira, o dicionário aponta para esses extents, na hora de os ler recebo erro : SQ
Re: [oracle_br] RE: Restore sem um datafile
Ve na DBA_EXTENTS pelo file_id, ou file#, não lembro agora do datafile corrompido, ai ve todos os objetos dessa tablespace que não pertençam a este datafile. Em 19 de dezembro de 2013 17:29, escreveu: > > > Chiappa, como remover os "dados/segmentos/extents que estavam nesse > arquivo perdido" ? Não entendi como faria isso. > > -- *Fabrício Pedroso Jorge.* Administrador de Banco de Dados Oracle 11g Certified SQL Expert Oracle 11g Certified Associate Oracle 11g Certified Professional Linux Professional Institute Certified Level I (LPIC-I) ITIL V3 Foudations certificacaodb.com.br *Resumo Profissional:* http://br.linkedin.com/in/fabriciojorge *Contatos:* + 55 91 88991116 skype: fabricio.pedroso.jorge fpjb...@gmail.com
[oracle_br] RE: Restore sem um datafile
Chiappa, como remover os "dados/segmentos/extents que estavam nesse arquivo perdido" ? Não entendi como faria isso.
RES: RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Ederson, Muito estranho então. RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/d01/backup/prod/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 5 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/prod/BKP_%d_%t_%s.rman' MAXPIECESIZE 10 G; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/d01/backup/prod/snapcf_prod.f'; Estava acompanhando, e quando o primeiro arquivo *.rman atingiu 10G, ele simplesmente sumiu. Acabei subescrevendo o arquivo de log, coloquei para gerar novamente o backup full, com essa nova alteração que voce passou levou 3 horas, fiquei impressionado. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de ederson200...@yahoo.com.br Enviada em: quarta-feira, 18 de dezembro de 2013 10:12 Para: oracle_br@yahoogrupos.com.br Assunto: RE: RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN Edinilson, O destino dos backups, vc confere e configura com SHOW ALL e se não esver correto, basta rodar: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/d01/backup/%F'; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/%U' MAXPIECESIZE 10 G; Neste diretório (/d01/backup), devem permanecer os arquivos ao fim do backup, senão eles foram removidos por outro processo. Inclusive, vc pode monitorar os arquivos sendo "escritos" durante a execução do rman da outra janela, abrindo outra sessão TTY ou putty e fazendo: $ cd /d01/backup $ watch -d ls -lt Verifica o conteúdo do arquivo gerado na linha (confira o nome q vc colocou): rman target=/ log=/home/oracle/bkp03_rman.log << EOF Qualquer coisa, coloca o conteúdo do arquivo no corpo da mensagem. []'s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] RE: Restore sem um datafile
A gente só espera que o pessoalzinho aí tenha aprendido a lição, que a perda dos dados que estavam no datafile corrompido/perdido sirva de lição pra turma... Bom, sobre o procedimento : supondo sempre que a instância em questão já consegue enxergar/acessar os diskgroups em questão, se os tamanhos envolvidos permitirem, uma outra opção seria se fazer a transferência dos datafiles (afora os da tablespace SYSTEM) online - simplesmente pede-se um ALTER TABLESPACE nnn OFFLINE, copia via RMAN o datafile para o ASM via copy datafile '/pathcompleto/nomedodatafile.dbf' to '+DGEMQUESTÃO, e depois voltar a tablespace online e remover o datafile no filesystem - iirc o copy do RMAN já atualiza o dicionário e o controlfile, não é necessário se fazer manualmente um ALTER DATABASE RENAME DATAFILE ... Isso para cada tablespace Depois o que se faria é uma SALVAGEM dos dados que estão nessa tablespace manca, criando-se uma nova tablespace no ASM e fazendo-se exp/imp ou INSERT /*+ APPEND */ dos dados para a nova tablespace mas com um WHERE que evite acesso aos dados que estavam no datafile perdido, e finalmente o DROP dessa tablespace corrupta. O procedimento acima em tese teria a vantagem de ter menos tempo de indisponibilidade total (só para mover para o ASM os datafiles da tablespace SYSTEM é que vc vai ficar indisponível) , mas é Claro que certamente vc pode fazer com um backup as copy já apontando para o ASM, sim Eu olhei bem por cima os comandos, rapidamente, mas a sintaxe e a ordem parecem estar corretas, sim []s Chiappa ===> OBS : Só lembro que, NECESSARIAMENTE, quando vc removeu o datafile X corrompido do controlfile, ele AINDA vai estar referenciado no DICIONÁRIO - veja que não é só no controlfile que há referências aos datafiles, lembre-se que na DBA_SEGMENTS certamente ainda vão haver segmentos apontando para o FILE_ID tal do datafile inexistente, na DBA_EXTENTS idem, ** Vão haver ROWIDs ** que apontam para um extent e um bloco que estavam nesse datafile sumido OU SEJA, não basta só "remover" o datafile sumido do controlfile, vc TEM que remover os dados/segmentos/extents que estavam nesse arquivo perdido, yep ??
[oracle_br] Restore sem um datafile
Pessoal, tenho a seguinte situação:
Oracle 11.2.0.3 single instance + ASM (grid-infra)
RedRat 6.4
Tenho 3 bases nesse servidor, 2 estão no ASM e 1 em filesystem.
Nessa que esta em filesystem, tenho um datafile todo corrompido, o mesmo ja
esta até em outra incarnação e claro offline. A tablespace desse datafile tem
outros varios datafiles. Quando a usuário tenta acessar os dados que estão
nesse datafile, explode o erro. (Show de horror, já peguei esse ambiente assim).
Minha tarefa é: migrar essa instancia para o ASM porem sem levar o datafile
corrompido.
obs: não temos backup desse datafile, e os novos backups estão com skip offline.
Estou pensando nesses passos:
1) alter database create crontrolfile to trace;
2) apagar do controlfile o datafile.
3)baixar o banco;
4)startup nomount;
5)recriar o controlfile;
6)alter database open;
Agora migrar:
1)alter system set control_files='' scope=spfile;
2)alter system set db_create_file_dest='' scope=spfile;
3)shut immeidate
4)startup nomoun
5)rman target /
6)restore controlfile from '';
7)alter database mount;
8) backup as copy database format '';
9)switch database to copy;
10)alter database open;
Mover a TEMP e redos
1)alter tablespace temp add tempfile size 500M
2)alter database tempfile '/temp01.dbf' drop including datafiles
Com isso ficará apenas o datafile criado no ASM para a TEMP
3)criar novos grupos de redos
alter database add logfile group 4 ('','2') size xxM;
alter database add logfile group 5 ('','2') size xxM;
alter system switch logfile;
dropar os antigos.
Pronto!!
O que vcs acham desse processo, ta certo?
Re: [oracle_br] Criação automática de índices
Roberto Sem problema, imagina! Só fiquei curioso caso existisse uma forma de fazer isso... Obrigado! [ ] André Em 19 de dezembro de 2013 14:35, Roberto Warstat escreveu: > > > André, > > Me desculpe, mas cometi um erro ao responder a tua pergunta. > Quando estava fazendo os testes dessa criação de índices, achei que havia > criado uma FK com a claúsula USING INDEX, mas na realidade foi uma UK. Por > isso a minha resposta errônea. > > Abraço, > Roberto > > > Em 19 de dezembro de 2013 09:55, Andre Santos > escreveu: > > >> >> Roberto >> >> Por favor, pode passar um exemplo de USING INDEX (...) com FK? >> >> [ ] >> >> André >> >> >> >> Em 18 de dezembro de 2013 19:56, Roberto Warstat >> escreveu: >> >> >>> >>> André, >>> >>> A sintaxe "USING INDEX (..)" pode ser utilizada para FK também. >>> >>> Abraços, >>> Roberto Warstat >>> >>> Em 18/12/2013 13:59, Andre Santos escreveu: >>> >>> >>> Pessoal >>> >>> Só um comentário... a sintaxe "USING INDEX (...)", só é válida para >>> UNIQUE ou PRIMARY KEY, correto? >>> Nunca vi esse uso com FK (ou qualquer outro tipo de constraint). >>> >>> Roberto, para Foreign Keys, se for desejado, o índice deve ser criado >>> separadamente (comando CREATE INDEX). >>> >>> Eu geralmente crio, mas antes avalio se já existe algum índice que >>> atenda: ou seja, cujas primeiras colunas da chave do índice coincidam com a >>> FK. >>> Se já existir, não é necessário criar um outro só para a FK. >>> >>> [ ]'s >>> >>> André Santos >>> >>> >>> >>> Em 18 de dezembro de 2013 14:36, escreveu: >>> Bom… para não haver confusão. Segue um resumo. Roberto, O Oracle NÃO CRIA um índice em FK (Foreign Key) quando se cria o seu modelo físico no banco de dados, OK! O índice é criado AUTOMATICAMENTE somente quando se trata de uma PK (Primary Key) ou UK (Unique), conforme o Fabio Prado comentou. Esse é o padrão do Oracle 6 até 12c e ponto! Porém, a observação do Ederson também está 100% correta nos dois pontos que ele citou. Primeiro, geralmente se cria ÍNDICES em FK para evitar LOCKS, retirar CONTENÇÃO e fornecer acesso rápido aos dados quando se tem algum predicado na sua instrução SQL, WHERE coluna = ‘alguma coisa’;, isso é padrão SQL92, SQL2003, ANSI-SQL.. então.. tb disponível desde Oracle 8i… MAS, você deve mencionar EXPLICITAMENTE a utilização do índice em sua FK. Segundo, a criação desse índice é feito a parte em outras instruções SQL, não sendo implícita do banco de dados! Assim se resume melhor todas as explicações, que foram 100% corretas. E tente matar esse mito na sua empresa, pq quem falou isso, não sabe que está agilizando uma instrução SQL e praticamente matando o banco de dados. Abraços, Rodrigo Almeida Em 18/12/2013, à(s) 11:22, ederson200...@yahoo.com.br escreveu: Correção: No texto onde se lê: --> Criar o indice em bairro.cli_cod_bairro, pode agilizar as pesquisas em cima de um "where cli_cod_bairro =", mas não é obrigatório. O correto é: --> Criar o indice em CLIENTE.cli_cod_bairro, pode agilizar as pesquisas em cima de um "where cli_cod_bairro =", mas não é obrigatório. Meu multitask está falhando hj. >>> >>> >> > >
Re: [oracle_br] Criação automática de índices
André, Me desculpe, mas cometi um erro ao responder a tua pergunta. Quando estava fazendo os testes dessa criação de índices, achei que havia criado uma FK com a claúsula USING INDEX, mas na realidade foi uma UK. Por isso a minha resposta errônea. Abraço, Roberto Em 19 de dezembro de 2013 09:55, Andre Santos escreveu: > > > Roberto > > Por favor, pode passar um exemplo de USING INDEX (...) com FK? > > [ ] > > André > > > > Em 18 de dezembro de 2013 19:56, Roberto Warstat > escreveu: > > >> >> André, >> >> A sintaxe "USING INDEX (..)" pode ser utilizada para FK também. >> >> Abraços, >> Roberto Warstat >> >> Em 18/12/2013 13:59, Andre Santos escreveu: >> >> >> Pessoal >> >> Só um comentário... a sintaxe "USING INDEX (...)", só é válida para >> UNIQUE ou PRIMARY KEY, correto? >> Nunca vi esse uso com FK (ou qualquer outro tipo de constraint). >> >> Roberto, para Foreign Keys, se for desejado, o índice deve ser criado >> separadamente (comando CREATE INDEX). >> >> Eu geralmente crio, mas antes avalio se já existe algum índice que >> atenda: ou seja, cujas primeiras colunas da chave do índice coincidam com a >> FK. >> Se já existir, não é necessário criar um outro só para a FK. >> >> [ ]'s >> >> André Santos >> >> >> >> Em 18 de dezembro de 2013 14:36, escreveu: >> >>> >>> >>> Bom… para não haver confusão. >>> >>> Segue um resumo. >>> >>> >>> Roberto, >>> >>> O Oracle NÃO CRIA um índice em FK (Foreign Key) quando se cria o seu >>> modelo físico no banco de dados, OK! O índice é criado AUTOMATICAMENTE >>> somente quando se trata de uma PK (Primary Key) ou UK (Unique), conforme o >>> Fabio Prado comentou. Esse é o padrão do Oracle 6 até 12c e ponto! >>> >>> Porém, a observação do Ederson também está 100% correta nos dois >>> pontos que ele citou. >>> >>> Primeiro, geralmente se cria ÍNDICES em FK para evitar LOCKS, retirar >>> CONTENÇÃO e fornecer acesso rápido aos dados quando se tem algum predicado >>> na sua instrução SQL, WHERE coluna = ‘alguma coisa’;, isso é padrão SQL92, >>> SQL2003, ANSI-SQL.. então.. tb disponível desde Oracle 8i… MAS, você deve >>> mencionar EXPLICITAMENTE a utilização do índice em sua FK. >>> >>> Segundo, a criação desse índice é feito a parte em outras instruções >>> SQL, não sendo implícita do banco de dados! >>> >>> Assim se resume melhor todas as explicações, que foram 100% corretas. >>> >>> E tente matar esse mito na sua empresa, pq quem falou isso, não sabe >>> que está agilizando uma instrução SQL e praticamente matando o banco de >>> dados. >>> >>> Abraços, >>> Rodrigo Almeida >>> >>> >>> Em 18/12/2013, à(s) 11:22, ederson200...@yahoo.com.br escreveu: >>> >>>Correção: >>> >>> No texto onde se lê: >>> >>> --> Criar o indice em bairro.cli_cod_bairro, pode agilizar as pesquisas >>> em cima de um "where cli_cod_bairro =", mas não é obrigatório. >>> >>> >>> O correto é: >>> >>> --> Criar o indice em CLIENTE.cli_cod_bairro, pode agilizar as pesquisas >>> em cima de um "where cli_cod_bairro =", mas não é obrigatório. >>> >>> Meu multitask está falhando hj. >>> >>> >>> >> >> > >
Re: [oracle_br] RE: Interromper o fluxo na Procedure
Obrigado... Em Quinta-feira, 19 de Dezembro de 2013 11:58, "jlchia...@yahoo.com.br" escreveu: tente um RETURN : BEGIN comandos ... -- vou fazer o DDL Begin execute immediate comando ddl Exception when others then ... logo o erro de alguma forma return; End; ... continua o processamento ... return; END; -- fim da rotina []s Chiappa
[oracle_br] RE: Interromper o fluxo na Procedure
tente um RETURN : BEGIN comandos ... -- vou fazer o DDL Begin execute immediate comando ddl Exception when others then ... logo o erro de alguma forma return; End; ... continua o processamento ... return; END; -- fim da rotina []s Chiappa
Re: [oracle_br] Interromper o fluxo na Procedure
Creio que você deva usar o RAISE_APPLICATION_ERROR http://www.java2s.com/Tutorial/Oracle/0480__PL-SQL-Programming/AcompleteexampleusingRAISEAPPLICATIONERROR.htm Em 19 de dezembro de 2013 11:53, Jales Jose Moraes escreveu: > > > Bom tarde! > > > Pessoal vou incluir no meu PL um execute immediate para truncar uma tabela. > Como faço no bloco do Exception para que caso o truncate falhar, eu possa > interroper a PL? > > > -- *Fabrício Pedroso Jorge.* Administrador de Banco de Dados Oracle 11g Certified SQL Expert Oracle 11g Certified Associate Oracle 11g Certified Professional Linux Professional Institute Certified Level I (LPIC-I) ITIL V3 Foudations certificacaodb.com.br *Resumo Profissional:* http://br.linkedin.com/in/fabriciojorge *Contatos:* + 55 91 88991116 skype: fabricio.pedroso.jorge fpjb...@gmail.com
[oracle_br] Interromper o fluxo na Procedure
Bom tarde! Pessoal vou incluir no meu PL um execute immediate para truncar uma tabela. Como faço no bloco do Exception para que caso o truncate falhar, eu possa interroper a PL?
Re: [oracle_br] Criação automática de índices
Roberto Por favor, pode passar um exemplo de USING INDEX (...) com FK? [ ] André Em 18 de dezembro de 2013 19:56, Roberto Warstat escreveu: > > > André, > > A sintaxe "USING INDEX (..)" pode ser utilizada para FK também. > > Abraços, > Roberto Warstat > > Em 18/12/2013 13:59, Andre Santos escreveu: > > > Pessoal > > Só um comentário... a sintaxe "USING INDEX (...)", só é válida para > UNIQUE ou PRIMARY KEY, correto? > Nunca vi esse uso com FK (ou qualquer outro tipo de constraint). > > Roberto, para Foreign Keys, se for desejado, o índice deve ser criado > separadamente (comando CREATE INDEX). > > Eu geralmente crio, mas antes avalio se já existe algum índice que atenda: > ou seja, cujas primeiras colunas da chave do índice coincidam com a FK. > Se já existir, não é necessário criar um outro só para a FK. > > [ ]'s > > André Santos > > > > Em 18 de dezembro de 2013 14:36, escreveu: > >> >> >> Bom… para não haver confusão. >> >> Segue um resumo. >> >> >> Roberto, >> >> O Oracle NÃO CRIA um índice em FK (Foreign Key) quando se cria o seu >> modelo físico no banco de dados, OK! O índice é criado AUTOMATICAMENTE >> somente quando se trata de uma PK (Primary Key) ou UK (Unique), conforme o >> Fabio Prado comentou. Esse é o padrão do Oracle 6 até 12c e ponto! >> >> Porém, a observação do Ederson também está 100% correta nos dois pontos >> que ele citou. >> >> Primeiro, geralmente se cria ÍNDICES em FK para evitar LOCKS, retirar >> CONTENÇÃO e fornecer acesso rápido aos dados quando se tem algum predicado >> na sua instrução SQL, WHERE coluna = ‘alguma coisa’;, isso é padrão SQL92, >> SQL2003, ANSI-SQL.. então.. tb disponível desde Oracle 8i… MAS, você deve >> mencionar EXPLICITAMENTE a utilização do índice em sua FK. >> >> Segundo, a criação desse índice é feito a parte em outras instruções >> SQL, não sendo implícita do banco de dados! >> >> Assim se resume melhor todas as explicações, que foram 100% corretas. >> >> E tente matar esse mito na sua empresa, pq quem falou isso, não sabe >> que está agilizando uma instrução SQL e praticamente matando o banco de >> dados. >> >> Abraços, >> Rodrigo Almeida >> >> >> Em 18/12/2013, à(s) 11:22, ederson200...@yahoo.com.br escreveu: >> >>Correção: >> >> No texto onde se lê: >> >> --> Criar o indice em bairro.cli_cod_bairro, pode agilizar as pesquisas >> em cima de um "where cli_cod_bairro =", mas não é obrigatório. >> >> >> O correto é: >> >> --> Criar o indice em CLIENTE.cli_cod_bairro, pode agilizar as pesquisas >> em cima de um "where cli_cod_bairro =", mas não é obrigatório. >> >> Meu multitask está falhando hj. >> >> >> > > >
