[oracle_br] Re: Dúvida select
Maravilha, Gerson : fico contente de ter sido útil e ter conseguido ajudar a te esclarecer as suas dúvidas Eu não tenho previsão de ministrar treinamento por enquanto, mas não deixe de usar as muitas e boas refs que vc recebeu nesta thread, e as dúvidas que forem pintando na medida do possível a gente tenta esclarecer... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "gersonlima276" escreveu > > > Boa tarde Chiappa e todos do grupo, > > Com esta explicação entendi com certeza esta query, muito obrigado Chiappa > pela aula, muito bem explicado, agora sim entendi, aliás como faço para ter > mais aulas com você? rsrsrrsrs(tô brincando). Muito obrigado a todos pela > atenção, abraços a todos. > > Gerson Lima. > > > --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" > escreveu > > > > Verdade verdadeiríssima, Miltão... > > > > Gerson, quando eu dava treinamentos de SQL eu sempre usava como técnica > > didática a esquematização dos comandos, ie, tentava "quebrar" em diversas > > sub-partes lógicas, sempre achei que é interessante para aprendizado, E > > colocando em linhas separadas cada sub-parte, cada seção No caso de um > > JOIN, o esqueletão seria : > > > > SELECT colunasqueeuqueroexibirvindasdetodasastabelas > >FROM listadastabelasaseremjuntadas > >condiçõesdechaveentreastabelas > > > > vamos pensar nas duas primeiras linhas/seções que são mais fáceis de > > entender - recheando de carne o esqueleto/substiuindo pelo seu exemplo, > > chegaríamos em : > > > > SELECT cd_paciente, nm_paciente, ds_endereco, cd_etnia, nm_etnia > > FROM paciente, etnia > > > > ==> OU SEJA, eu olhei a tua lista de colunas de cada tabela e as > > copiei/colei no esqueleto, separadas por vírgulas, sim ?? NADA mais que > > isso... > > > > Continuando, nem sempre é obrigatório mas é uma Excelente prática vc > > INDICAR no comando de qual tabela vem cada coluna, e a sintaxe para isso é > > separar o nome da tabela da respectiva coluna por um ponto, tipo : > > > > SELECT paciente.cd_paciente, paciente.nm_paciente, paciente.ds_endereco, > > etnia.cd_etnia, etnia.nm_etnia > > FROM paciente, etnia > > > > => legal ?? Porém, apesar de funcionar/ser aceita, essa opção de vc > > colocar o nome completo da tabela na frente de cada coluna faz vc digitar > > DEMAIS, é trabalhosa Então a outra opção aceita e muito mais usada é vc > > dar um APELIDO para cada tabela na linha do FROM, e colocar na frente de > > cada coluna o APELIDO correspondente - vamos dar os apelidos de A e de B > > para cada tabela ?? Aí ficaria assim : > > > > SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia > > FROM paciente A, etnia B > > > > > > => até aqui, tranquilo ?? Tá vendo como o comando está se formando ??? > > Acompanhou até aqui ?? > > > > Para finalizar, vamos colocar a linha/seção que indica a CONDIÇÃO em que > > os dados devem ser juntados/lidos em cada tabela : a idéia é, vc NÂO QUER > > que para cada linha de cada paciente apareçam TODAS as etnias, vc quer > > APENAS a descrição da etnia correntemente sendo lida para o paciente atual > > , e (imagino, pelo jeitão das suas tabelas) que a informação, a > > Identificação da etnia corrente está na coluna CD_ETNIA, então é ESSA a > > chave, a condição a ser observada : indicando isso, o executor de SQLs do > > banco de dados já sabe que quando vc estiver lendo um paciente com, > > digamos, CD_ETNIA=1, é a descrição da etnia 1, aquela aonde CD_ETNIA é > > igual a 1 na tabela de etnia que virá... Depois, continuando a execução do > > comando SQL, quando o banco de dados vc ler um paciente com CD_ETNIA=2, é a > > descrição da tabela etnia aonde CD_ETNIA=2 que será trazida OU SEJA, o > > que vc quer é trazer da tabela etnia a descrição da etnia que seja IGUAL, > > que tenha o mesmo código, que a etnia do paciente sendo lido, sim > > Há duas maneiras de vc indicar isso, uma é indicar com uma cláusula WHERE > > o que que tem que ser igual nas duas tabelas para a ligação entre elas : > > > > SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia > > FROM paciente A, etnia B > > WHERE A.cd_etnia = B.cd_etnia; > > > > > > ==>> PRONTO !!! Executa isso e vc vai ter a sua resposta, sim ?? Muito > > difícil, ou deu pra acompanhar ??? > > > > Esta forma que eu mostrei acima, aonde vc só indica o que que tem que ser > > igual nas duas tabelas, é a forma originalmente usada no dialeto SQL do > > banco de dados Oracle > > Há uma segunda forma, que é vc indicar a operação de join além de indicar > > a coluna-chave, ficaria tipo : > > > > SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia > > FROM paciente A join etnia B > > ON (A.cd_etnia = B.cd_etnia); > > > > ==> legal ??? Eu gosto mais da (e uso mais a) primeira forma , mas ambas > > funcionam, use aquela que gostar mais Espero que
[oracle_br] Re: Dúvida select
Boa tarde Chiappa e todos do grupo, Com esta explicação entendi com certeza esta query, muito obrigado Chiappa pela aula, muito bem explicado, agora sim entendi, aliás como faço para ter mais aulas com você? rsrsrrsrs(tô brincando). Muito obrigado a todos pela atenção, abraços a todos. Gerson Lima. --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" escreveu > > Verdade verdadeiríssima, Miltão... > > Gerson, quando eu dava treinamentos de SQL eu sempre usava como técnica > didática a esquematização dos comandos, ie, tentava "quebrar" em diversas > sub-partes lógicas, sempre achei que é interessante para aprendizado, E > colocando em linhas separadas cada sub-parte, cada seção No caso de um > JOIN, o esqueletão seria : > > SELECT colunasqueeuqueroexibirvindasdetodasastabelas >FROM listadastabelasaseremjuntadas >condiçõesdechaveentreastabelas > > vamos pensar nas duas primeiras linhas/seções que são mais fáceis de > entender - recheando de carne o esqueleto/substiuindo pelo seu exemplo, > chegaríamos em : > > SELECT cd_paciente, nm_paciente, ds_endereco, cd_etnia, nm_etnia > FROM paciente, etnia > > ==> OU SEJA, eu olhei a tua lista de colunas de cada tabela e as copiei/colei > no esqueleto, separadas por vírgulas, sim ?? NADA mais que isso... > > Continuando, nem sempre é obrigatório mas é uma Excelente prática vc INDICAR > no comando de qual tabela vem cada coluna, e a sintaxe para isso é separar o > nome da tabela da respectiva coluna por um ponto, tipo : > > SELECT paciente.cd_paciente, paciente.nm_paciente, paciente.ds_endereco, > etnia.cd_etnia, etnia.nm_etnia > FROM paciente, etnia > > => legal ?? Porém, apesar de funcionar/ser aceita, essa opção de vc colocar > o nome completo da tabela na frente de cada coluna faz vc digitar DEMAIS, é > trabalhosa Então a outra opção aceita e muito mais usada é vc dar um > APELIDO para cada tabela na linha do FROM, e colocar na frente de cada coluna > o APELIDO correspondente - vamos dar os apelidos de A e de B para cada tabela > ?? Aí ficaria assim : > > SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia > FROM paciente A, etnia B > > > => até aqui, tranquilo ?? Tá vendo como o comando está se formando ??? > Acompanhou até aqui ?? > > Para finalizar, vamos colocar a linha/seção que indica a CONDIÇÃO em que os > dados devem ser juntados/lidos em cada tabela : a idéia é, vc NÂO QUER que > para cada linha de cada paciente apareçam TODAS as etnias, vc quer APENAS a > descrição da etnia correntemente sendo lida para o paciente atual , e > (imagino, pelo jeitão das suas tabelas) que a informação, a Identificação da > etnia corrente está na coluna CD_ETNIA, então é ESSA a chave, a condição a > ser observada : indicando isso, o executor de SQLs do banco de dados já sabe > que quando vc estiver lendo um paciente com, digamos, CD_ETNIA=1, é a > descrição da etnia 1, aquela aonde CD_ETNIA é igual a 1 na tabela de etnia > que virá... Depois, continuando a execução do comando SQL, quando o banco de > dados vc ler um paciente com CD_ETNIA=2, é a descrição da tabela etnia aonde > CD_ETNIA=2 que será trazida OU SEJA, o que vc quer é trazer da tabela > etnia a descrição da etnia que seja IGUAL, que tenha o mesmo código, que a > etnia do paciente sendo lido, sim > Há duas maneiras de vc indicar isso, uma é indicar com uma cláusula WHERE o > que que tem que ser igual nas duas tabelas para a ligação entre elas : > > SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia > FROM paciente A, etnia B > WHERE A.cd_etnia = B.cd_etnia; > > > ==>> PRONTO !!! Executa isso e vc vai ter a sua resposta, sim ?? Muito > difícil, ou deu pra acompanhar ??? > > Esta forma que eu mostrei acima, aonde vc só indica o que que tem que ser > igual nas duas tabelas, é a forma originalmente usada no dialeto SQL do banco > de dados Oracle > Há uma segunda forma, que é vc indicar a operação de join além de indicar a > coluna-chave, ficaria tipo : > > SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia > FROM paciente A join etnia B > ON (A.cd_etnia = B.cd_etnia); > > ==> legal ??? Eu gosto mais da (e uso mais a) primeira forma , mas ambas > funcionam, use aquela que gostar mais Espero que vc tenha captado a > essência da coisa, e qquer dúvida, não hesite em nos mandar um copy/paste > COMPLETO do que vc está tentando e das msgs que recebeu, BEM COMO uma > descrição e uma explicação do que queria, que a gente discute em cima ... > > []s > >Chiappa > > OBS IMPORTANTE : que fique Claro, o que mostrei acima é o caso mais simples > de JOIN, em que sempre há uma linha de dados na tabela B para cada linha > correspondente na tabela A, o chamado EQUI-JOIN - claro que há casos aonde > isso não é verdadeiro, aí vc tem que usar OUTROS tipos de joins... Dá um look > em http://dwhlaureat
[oracle_br] Re: Migração de banco entre plataformas diferentes
Pois é, Ederson : como eu citei na minha resposta, Se Fosse migração entre plataformas diferentes mas com o mesmo endian-type/same endianness, aonde a Ordem De gravação dos bytes em memória ou disco é a mesma, aí realmente usaríamos o CONVERT, que em si é bem rápido, já que há muito pouco a fazer nos datafiles em sim, que são os maiores componentes num banco de dados Oracle normalmente - no máximo provavelmente vai haver alguns poucos ajustes no cabeçalho do datafile, coisinhas do tipo Os blocos de dados dos usuários já estariam gravados numa sequência legível para a plataforma-destino, não sendo passíveis de alteração alguma... No caso do colega, porém, ele QUER/PRECISA migrar para uma nova plataforma com uma ordem de gravação de bytes DIFERENTE da original, então essa opção de CONVERTER uma cópia de datafiles simplesmente via RMAN tá fora Daniel, antes de responder a sua dúvida, só confirmando : vc Entendeu que para vc fazer transport de tablespaces vc ** TEM ** que colocar a tablespace a trasportar em read-only (que Implica em indisponibilidade para gravação/alteração/inclusão de dados enquanto isso), ** E ** que além disso os objetos TEM que ser auto-contidos na tablespace em transporte (ie, eventuais segmentos logicamente necessários para cada objeto, como LOB Segments, por exemplo) Precisam estar gravados nessa mesma tablespace em transporte, okdoc ?? Senão vc NÃo Vai poder fazer o transporte, yep ?? Isso tudo está Explícito na nota metalink recomendada (a "Migration Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1]) e nos links dela ASSIM SENDO, torna-se a frisar : SE vc tiver alguma chance de estabelecer, temporariamente que seja, só para a migração, uma rede de alta-performance e dedicada entre os dois servers, a opção de DATAGUARD ou similares com envio de dados pela rede ** É ** a preferida, por não ter exigências físicas sobre as tablespaces e poder ser feita totalmente online, sem indisponibilidade Muito bem, isso posto a sua resposta : primeiro, veja que "criação de instância" é algo meio impreciso, pois INSTÂNCIA não é algo físico, que vc cria e que fica armazenado em disco - conceitualmente, uma INSTÂNCIA é o resultado dos binários Oracle sendo carregados para a memória e lendo os arquivos/pré-requisitos, como os initfiles, variáveis de ambiente, etc, yep ??? Fosse Windows o SO vc ainda precisaria criar algo a mais que seria o SERVIÇO WINDOWS que serve de "muleta", mas sendo (como é) unix-like o seu ambiente, cabou : tenha os BINÁRIOS instalados no servidor-destino com o MESMO EXATO release e os MESMO patches que no server origem E use os mesmos valores de init e variáveis/etc no server destino que vc VAI ser capaz de startar uma instância IDÊNTICA , sim sim ??? Para se provar isso, na tua máquina unix-like que possua binários Oracle crie um initfile, set as variáveis de ORACLE_HOME, ORACLE_SID e PATH e manda um startup nomount que vc vai ver que a instãncia VAI ser inicializada pelos binários SEM que vc tenha que "criar" nada via assistente ou seja o que for , sim ??? É Claro, porém, que a instância sozinha não serve de muito, vc TEM que ter um database para a instância abrir, aqui DATABASE sendo definido como o conjunto de datafiles+controlfiles+demaisarqsnecessários, né ?? Que fique claro, com transport de tablespaces vc vai estar adicionando tablespaces de usuário em um database QUE JÁ EXISTE, vc NÃO * vai clonar/copiar/trazer o database do server origem Assim, para que vc crie no server destino um database o mais idêntico possível ao que eiste no server origem, o procedimento seria : 1. instale no servidor destino os binários do RDBMS Oracle com o mesmo exato release (11.2.0.2, iirc da sua mensagem) existente no servidor origem 2. aplique nesses binários do server destino os MESMOS TODOS patches que estão aplicados na origem 3. use no server destino o assistente de criação de banco de dados (que já cria os pré-reqs para vc poder subir uma instância) para criar um database com o MESMO NOME e com as MESMAS exatas propriedades (tal como characterset, linguagem, ordenação, MESMAS features que foram usadas na origem, etc, etc), e os mesmos parãmetros de inicialização sempre aonde possível (podem haver alterações por hardwares diferentes entre origem e destino, ou devido à requisitos do SO), não esquecendo de quando o Assistente perguntar a identificação de instância vc informa o mesmo ID usado na origem 4. suba essa instância cujos pre-reqs o Assistente já te criou e com ela abra o database 5. transporte uma a uma as tablespaces não-internas/de usuários que vc quer trazer do banco-origem : é basicamente confirmar via DBMS própria que a tablespace é transportável no banco-origem, colocar no banco-origem a tablespace em read-only, copiar os datafiles da tablespace a partir da origem para o destino (via FTP, copy, RMAN, o que quiser/tiver), copiar os metadados
[oracle_br] Re: Dúvida select
Verdade verdadeiríssima, Miltão... Gerson, quando eu dava treinamentos de SQL eu sempre usava como técnica didática a esquematização dos comandos, ie, tentava "quebrar" em diversas sub-partes lógicas, sempre achei que é interessante para aprendizado, E colocando em linhas separadas cada sub-parte, cada seção No caso de um JOIN, o esqueletão seria : SELECT colunasqueeuqueroexibirvindasdetodasastabelas FROM listadastabelasaseremjuntadas condiçõesdechaveentreastabelas vamos pensar nas duas primeiras linhas/seções que são mais fáceis de entender - recheando de carne o esqueleto/substiuindo pelo seu exemplo, chegaríamos em : SELECT cd_paciente, nm_paciente, ds_endereco, cd_etnia, nm_etnia FROM paciente, etnia ==> OU SEJA, eu olhei a tua lista de colunas de cada tabela e as copiei/colei no esqueleto, separadas por vírgulas, sim ?? NADA mais que isso... Continuando, nem sempre é obrigatório mas é uma Excelente prática vc INDICAR no comando de qual tabela vem cada coluna, e a sintaxe para isso é separar o nome da tabela da respectiva coluna por um ponto, tipo : SELECT paciente.cd_paciente, paciente.nm_paciente, paciente.ds_endereco, etnia.cd_etnia, etnia.nm_etnia FROM paciente, etnia => legal ?? Porém, apesar de funcionar/ser aceita, essa opção de vc colocar o nome completo da tabela na frente de cada coluna faz vc digitar DEMAIS, é trabalhosa Então a outra opção aceita e muito mais usada é vc dar um APELIDO para cada tabela na linha do FROM, e colocar na frente de cada coluna o APELIDO correspondente - vamos dar os apelidos de A e de B para cada tabela ?? Aí ficaria assim : SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia FROM paciente A, etnia B => até aqui, tranquilo ?? Tá vendo como o comando está se formando ??? Acompanhou até aqui ?? Para finalizar, vamos colocar a linha/seção que indica a CONDIÇÃO em que os dados devem ser juntados/lidos em cada tabela : a idéia é, vc NÂO QUER que para cada linha de cada paciente apareçam TODAS as etnias, vc quer APENAS a descrição da etnia correntemente sendo lida para o paciente atual , e (imagino, pelo jeitão das suas tabelas) que a informação, a Identificação da etnia corrente está na coluna CD_ETNIA, então é ESSA a chave, a condição a ser observada : indicando isso, o executor de SQLs do banco de dados já sabe que quando vc estiver lendo um paciente com, digamos, CD_ETNIA=1, é a descrição da etnia 1, aquela aonde CD_ETNIA é igual a 1 na tabela de etnia que virá... Depois, continuando a execução do comando SQL, quando o banco de dados vc ler um paciente com CD_ETNIA=2, é a descrição da tabela etnia aonde CD_ETNIA=2 que será trazida OU SEJA, o que vc quer é trazer da tabela etnia a descrição da etnia que seja IGUAL, que tenha o mesmo código, que a etnia do paciente sendo lido, sim Há duas maneiras de vc indicar isso, uma é indicar com uma cláusula WHERE o que que tem que ser igual nas duas tabelas para a ligação entre elas : SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia FROM paciente A, etnia B WHERE A.cd_etnia = B.cd_etnia; ==>> PRONTO !!! Executa isso e vc vai ter a sua resposta, sim ?? Muito difícil, ou deu pra acompanhar ??? Esta forma que eu mostrei acima, aonde vc só indica o que que tem que ser igual nas duas tabelas, é a forma originalmente usada no dialeto SQL do banco de dados Oracle Há uma segunda forma, que é vc indicar a operação de join além de indicar a coluna-chave, ficaria tipo : SELECT A.cd_paciente, A.nm_paciente, A.ds_endereco, B.cd_etnia, B.nm_etnia FROM paciente A join etnia B ON (A.cd_etnia = B.cd_etnia); ==> legal ??? Eu gosto mais da (e uso mais a) primeira forma , mas ambas funcionam, use aquela que gostar mais Espero que vc tenha captado a essência da coisa, e qquer dúvida, não hesite em nos mandar um copy/paste COMPLETO do que vc está tentando e das msgs que recebeu, BEM COMO uma descrição e uma explicação do que queria, que a gente discute em cima ... []s Chiappa OBS IMPORTANTE : que fique Claro, o que mostrei acima é o caso mais simples de JOIN, em que sempre há uma linha de dados na tabela B para cada linha correspondente na tabela A, o chamado EQUI-JOIN - claro que há casos aonde isso não é verdadeiro, aí vc tem que usar OUTROS tipos de joins... Dá um look em http://dwhlaureate.blogspot.com.br/2012/08/joins-in-oracle.html , por exemplo, para um overview dos diversos tipos de joins --- Em oracle_br@yahoogrupos.com.br, "Milton Bastos Henriquis Jr." escreveu > > Sem problema Gerson, estamos aqui pra ajudar > > Nesse caso vc precisa COPIAR e COLAR tudo que vc está fazendo. > Se nao deu certo, cole aqui pra gente o comando que vc usou e o erro que vc > recebeu, senão fica difícil a gente adivinhar! > > > > > 2013/7/12 gersonlima276 > > > ** > > > > > > > > Ola Milton, > > eu li, mas quando faço aqui não da certo e eu nã
Re: [oracle_br] Re: Migração de banco entre plataformas diferentes
Daniel.. Da uma olhada no meu blog que no passado eu fiz um post sobre migração de solaris para linux. Enviado por Samsung Mobile Mensagem original De : Daniel Mello Data: Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: Migração de banco entre plataformas diferentes Muito obrigado pelas respostas de todos. Realmente um ponto que não destaquei é que nesta migração em específico teremos um bom tempo de indisponibilidade aceitável pelo cliente, ou seja, acredito que a forma mais simples seja realmente o "Cross-Platform Transportable Tablespaces". Terei que ensaiar um pouco essa migração, pois realmente é algo totalmente novo. Um ponto que não ficou bem claro na documentação é em relação à criação da instância e database, vocês já usaram esse recurso? Att Daniel. De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 11 de Julho de 2013 18:00 Assunto: [oracle_br] Re: Migração de banco entre plataformas diferentes Joinha, Miltão ? Bem, primeiro sobre o tamanho, não sei se eu chamaria hoje em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até decente em termos de gigabyte x obamas) em coisinhas tipo aqui : http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode ser montada em RAID-0 cfrme http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports Anyway, no caso específico de migração que estamos discutindo, o busílis é que esta é uma migração cross-endianness - fosse uma migração para outro SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para um disk device do tipo e restore+convert na outra ponta Nessa situação aí sim realmente uma das opções com a menor indisponibilidade seria sim enviar os dados via rede de modo consistente e com banco disponível (por DG, por GG, por um software de terceiros que seja capaz de processar logs Oracle como é o caso do shareplex, por um software residente na máquina-destino que leia via rede os dados da origem e os insira no banco-destino de maneira consistente no tempo, via flashback ou quetais - existem diversos no mercado -, etc) , mas a NECESSIDADE aí é, Óbvio, uma rede de alta-performance ligando os dois servidores Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a tua infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e de alta-performance entre os dois servers (não dá pra pensar em usar a rede Pública comum da Empresa, normalmente) aí pode ficar inviável usar tecnologias de transferência via rede, e nesses casos Tranquilamente pode ser mais economicamente viável ao invés de upgradear a rede se investir num disco externo rápido Infelizmente,sendo (como é) cross-endianness, a opção aí nesse cenário aonde a rede não é confiável e performática seria muito certamente partir para Cross-Platform Transportable Tablespaces , que implica em colocar cada tablespace em read-only e portanto é menos disponível . Para vc ter um overview das opções, dá um look na nota metalink "Migration Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1] que vc acha links para as principais opções todas ... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani escreveu > > Meu caro, > > Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele referencia. > Na minha opinião, a melhor forma para migrar VLDBs é com Dataguard e > tecnologias similares (Goldengate/Shareplex), mesmo assim ainda prefiro o DG. > > Onde o seu downtime é mínimo. > > http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf > > > Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento de > Oracle do brasil, faça sua inscrição em www.guob.com.br. > > > Atenciosamente, > Rodrigo Mufalani > rodrigo@... > www.mufalani.com.br > > > > > > On 11/07/2013, at 16:27, Daniel Mello wrote: > > > Boa tarde. > > > > Assim como um pergunta respondida de nosso amigo Victor, tenho uma migração > > entre plataformas, mas no meu caso muda o Endian_Format " BIG >> Little", a > > mudança será de um Solaris Sparc para Solaris x86-64. A versão do oracle é > > a 11.2.0.2. > > Alguém já fez esse tipo de conversão? > > Conhecem o melhor método? > > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a princípio. > > > > Obrigado. > > Daniel. > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
Re: [oracle_br] Re: Dúvida select
Sem problema Gerson, estamos aqui pra ajudar Nesse caso vc precisa COPIAR e COLAR tudo que vc está fazendo. Se nao deu certo, cole aqui pra gente o comando que vc usou e o erro que vc recebeu, senão fica difícil a gente adivinhar! 2013/7/12 gersonlima276 > ** > > > > Ola Milton, > eu li, mas quando faço aqui não da certo e eu não entendo direito a > estrura desta query, desculpa ficar perguntando algo tão simples para > vocês, mas não sei aonde estou errando. > > > --- Em oracle_br@yahoogrupos.com.br, "Milton Bastos Henriquis Jr." > escreveu > > > > Gerson, vc já tinha perguntado isso em outro e-mail e nós já tínhamos > > respondido, com o código prontinho pra vc... > > Vc chegou a ler? > > > > > > > > 2013/7/12 gersonlima276 > > > > > ** > > > > > > > > > > Bom dia a todos, > > > > > > eu estou lendo algumas apostila para aprender sql e junto fazendo > alguns > > > exercício para entender melhor, mas ainda não entendi sobre inner > join, eu > > > dei um select aqui na empresa em duas tabela e esta assim: > > > > > > select * from paciente > > > > > > cd_paciente (21213) > > > nm_paciente (Amaral Rodrigues) > > > ds_endereço (Rua Jacu Pessego) > > > cd_etnia (2) > > > > > > select * from etnia > > > > > > cd_etnia (2) > > > nm_etnia (AMANAYE) > > > > > > eu estou fazendo um select para trazer a descrição da etnia(AMANAYE) > > > > > > perdoe a minha ignorância mas alguém pode me explicar com faço? > > > > > > Um grande abraço a todos vocês. > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, Fabio Prado escreveu > > > > > > > > > Gerson, > > > > > > > > (e) e (p) são apelidos das tabelas > > > > > > > > é uma boa prática atribuir apelidos curtos para as tabelas e > referenciar > > > os > > > > nomes das colunas com o apelido na frente > > > > > > > > O exemplo que vc passou está incompleto. O correto seria como está > > > escrito > > > > abaixo: > > > > > > > > select e.name. p.valor as pagamento > > > > from empregados as e > > > > left join pagamentos p > > > > ... > > > > > > > > Aconselho vc a fazer um curso de SQL básico. Veja o do link abaixo > (não > > > sei > > > > se é bom, mas é gratuito): > > > > > > > > > > > > http://www.softblue.com.br/site/curso/id/3/CURSO+SQL+COMPLETO+BASICO+AO+AVANCADO+ON+LINE+BD03 > > > > > > > > []s > > > > > > > > Fábio Prado > > > > www.fabioprado.net > > > > > > > > > > > > > > > > > > > > 2013/7/11 gersonlima276 > > > > > > > > > > > > ** > > > > > > > > > > > > > > > Ola mestre do Oracle, > > > > > > > > > > tira uma dúvida, no select abaixo eu preciso saber sobre o > significa a > > > > > letra (e)(p) na frente do name e do valor, como entender isto? > > > > > > > > > > select e.name. p.valor as pagamento > > > > > from empregados as left join pagamentos > > > > > > > > > > obrigado senhores!!! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Fábio Prado > > > > www.fabioprado.net > > > > "Compartilhando conhecimentos e treinando profissionais em Bancos de > > > Dados > > > > Oracle" > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: Dúvida select
Gerson, olha mais outro link de apostila grátis de sql básico: http://www.portalgsti.com.br/2013/05/apostila-sql-disponivel-para-download.html Se estiver difícil de entender, faça um curso ou compre um livro. O livro "Aprendendo SQL" da Editora Novatec é excelente, eu já li e recomendo a qq um q queira iniciar seus estudos em SQL. []s Fábio Prado www.fabioprado.net Em 12 de julho de 2013 12:16, gersonlima276 escreveu: > ** > > > > Ola Milton, > eu li, mas quando faço aqui não da certo e eu não entendo direito a > estrura desta query, desculpa ficar perguntando algo tão simples para > vocês, mas não sei aonde estou errando. > > --- Em oracle_br@yahoogrupos.com.br, "Milton Bastos Henriquis Jr." > escreveu > > > > Gerson, vc já tinha perguntado isso em outro e-mail e nós já tínhamos > > respondido, com o código prontinho pra vc... > > Vc chegou a ler? > > > > > > > > 2013/7/12 gersonlima276 > > > > > ** > > > > > > > > > Bom dia a todos, > > > > > > eu estou lendo algumas apostila para aprender sql e junto fazendo > alguns > > > exercício para entender melhor, mas ainda não entendi sobre inner > join, eu > > > dei um select aqui na empresa em duas tabela e esta assim: > > > > > > select * from paciente > > > > > > cd_paciente (21213) > > > nm_paciente (Amaral Rodrigues) > > > ds_endereço (Rua Jacu Pessego) > > > cd_etnia (2) > > > > > > select * from etnia > > > > > > cd_etnia (2) > > > nm_etnia (AMANAYE) > > > > > > eu estou fazendo um select para trazer a descrição da etnia(AMANAYE) > > > > > > perdoe a minha ignorância mas alguém pode me explicar com faço? > > > > > > Um grande abraço a todos vocês. > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, Fabio Prado escreveu > > > > > > > > Gerson, > > > > > > > > (e) e (p) são apelidos das tabelas > > > > > > > > é uma boa prática atribuir apelidos curtos para as tabelas e > referenciar > > > os > > > > nomes das colunas com o apelido na frente > > > > > > > > O exemplo que vc passou está incompleto. O correto seria como está > > > escrito > > > > abaixo: > > > > > > > > select e.name. p.valor as pagamento > > > > from empregados as e > > > > left join pagamentos p > > > > ... > > > > > > > > Aconselho vc a fazer um curso de SQL básico. Veja o do link abaixo > (não > > > sei > > > > se é bom, mas é gratuito): > > > > > > > > > > > > http://www.softblue.com.br/site/curso/id/3/CURSO+SQL+COMPLETO+BASICO+AO+AVANCADO+ON+LINE+BD03 > > > > > > > > []s > > > > > > > > Fábio Prado > > > > www.fabioprado.net > > > > > > > > > > > > > > > > > > > > 2013/7/11 gersonlima276 > > > > > > > > > > > > ** > > > > > > > > > > > > > > > Ola mestre do Oracle, > > > > > > > > > > tira uma dúvida, no select abaixo eu preciso saber sobre o > significa a > > > > > letra (e)(p) na frente do name e do valor, como entender isto? > > > > > > > > > > select e.name. p.valor as pagamento > > > > > from empregados as left join pagamentos > > > > > > > > > > obrigado senhores!!! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Fábio Prado > > > > www.fabioprado.net > > > > "Compartilhando conhecimentos e treinando profissionais em Bancos de > > > Dados > > > > Oracle" > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > -- Fábio Prado www.fabioprado.net "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle" [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Dúvida select
Colega, complementando para quem mais interessar : => em pt, além do citado em se googlando um pouco vc também acha vários outros cursos introdutórios (tanto completos quanto demonstração parcial), e também apostilas e tutoriais, como por exemplo : http://www.juliobattisti.com.br/tutoriais/almirrivas/oracle003.asp http://www.iped.com.br/programacao-e-desenvolvimento/curso/oracle http://www.apostilaz.com.br/programacao/apostila-oracle.html http://www.scriptbrasil.com.br/apostilas/bd/oracle/ http://www.consulting.com.br/edsonalmeidajunior/admin/downloads/admbancoora.pdf http://www.oficinadanet.com.br/apostilas/detalhe/162/apostila_de_oracle => em Inglês a oferta é Ainda Maior, se vc tiver ao menos o chamado "inglês técnico", como por exemplo : http://www.pickatutorial.com/tutorials/oracle_1.htm http://www.iselfschooling.com/Free_Oracle_Training/01_Basics/01_SQL/lesson01.html http://www.miraclewisdom.com/oracle_database.htm http://www.skillbuilders.com/Oracle/Oracle-Consulting-Training.cfm?tab=free-retired-tutorials https://www.oraclecoach.com/free-oracle-video-training http://www.e-learningcenter.com/oracle.htm http://www.softwaretrainingtutorials.com/oracle-choice.php http://oracledbazerotopro.com/ http://www.techtutorials.net/tutorials/databases/oracle.html => A Documentação Oracle é imprescindível (pra vc saber o que o RDBMS Oracle faz e o que ele não faz, o que vc pode usar nele e como usar, etc), está TODINHA online em http://tahiti.oracle.com/ e é de grátis também : eu Recomendo vc começar com os Conceitos básicos de database em geral e do RDBMS Oracle em particular, os principais dos quais vc encontra no manual de Concepts... Não é didática o objetivo da Documentação (ela existe como referência e guia de uso, bem como lista de conteúdo e sintaxes), então vc VAI precisar também de outras fontes, mas não cometa o ERRO de desconsiderar a Documentação... => Porém, CEDO ou TARDE - e aposto que mais CEDO que tarde - vc *** VAI *** ter que botar a mão no bolso e investir em bons livros de iniciantes (dá uma pesquisada em msgs anteriores aqui no Grupo mesmo que andamos discutindo/recomendando alguns títulos), e em algum eventual Treinamento, aonde vc possa tirar dúvidas e receber guias/best practices e sugestões do Instrutor. É de se discutir se é melhor fazer o Curso depois de ter ralado com livros e materiais da web ou se é melhor fazer ambos mais ou menos simultaneamente, MAS que vc vai precisar de todas as fontes, ah isso vai... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "gersonlima276" escreveu > > Valeu pela dica do curso, estou precisando e muito, um grande abraço!! > > > --- Em oracle_br@yahoogrupos.com.br, Fabio Prado escreveu > > > > Gerson, > > > > (e) e (p) são apelidos das tabelas > > > > é uma boa prática atribuir apelidos curtos para as tabelas e referenciar os > > nomes das colunas com o apelido na frente > > > > O exemplo que vc passou está incompleto. O correto seria como está escrito > > abaixo: > > > > select e.name. p.valor as pagamento > > from empregados as e > > left join pagamentos p > > ... > > > > Aconselho vc a fazer um curso de SQL básico. Veja o do link abaixo (não sei > > se é bom, mas é gratuito): > > > > http://www.softblue.com.br/site/curso/id/3/CURSO+SQL+COMPLETO+BASICO+AO+AVANCADO+ON+LINE+BD03 > > > > []s > > > > Fábio Prado > > www.fabioprado.net > > > > > > > > > > 2013/7/11 gersonlima276 > > > > > ** > > > > > > > > > Ola mestre do Oracle, > > > > > > tira uma dúvida, no select abaixo eu preciso saber sobre o significa a > > > letra (e)(p) na frente do name e do valor, como entender isto? > > > > > > select e.name. p.valor as pagamento > > > from empregados as left join pagamentos > > > > > > obrigado senhores!!! > > > > > > > > > > > > > > > > > -- > > Fábio Prado > > www.fabioprado.net > > "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados > > Oracle" > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
[oracle_br] Re: Dúvida select
Ola Milton, eu li, mas quando faço aqui não da certo e eu não entendo direito a estrura desta query, desculpa ficar perguntando algo tão simples para vocês, mas não sei aonde estou errando. --- Em oracle_br@yahoogrupos.com.br, "Milton Bastos Henriquis Jr." escreveu > > Gerson, vc já tinha perguntado isso em outro e-mail e nós já tínhamos > respondido, com o código prontinho pra vc... > Vc chegou a ler? > > > > 2013/7/12 gersonlima276 > > > ** > > > > > > Bom dia a todos, > > > > eu estou lendo algumas apostila para aprender sql e junto fazendo alguns > > exercício para entender melhor, mas ainda não entendi sobre inner join, eu > > dei um select aqui na empresa em duas tabela e esta assim: > > > > select * from paciente > > > > cd_paciente (21213) > > nm_paciente (Amaral Rodrigues) > > ds_endereço (Rua Jacu Pessego) > > cd_etnia (2) > > > > select * from etnia > > > > cd_etnia (2) > > nm_etnia (AMANAYE) > > > > eu estou fazendo um select para trazer a descrição da etnia(AMANAYE) > > > > perdoe a minha ignorância mas alguém pode me explicar com faço? > > > > Um grande abraço a todos vocês. > > > > > > --- Em oracle_br@yahoogrupos.com.br, Fabio Prado escreveu > > > > > > Gerson, > > > > > > (e) e (p) são apelidos das tabelas > > > > > > é uma boa prática atribuir apelidos curtos para as tabelas e referenciar > > os > > > nomes das colunas com o apelido na frente > > > > > > O exemplo que vc passou está incompleto. O correto seria como está > > escrito > > > abaixo: > > > > > > select e.name. p.valor as pagamento > > > from empregados as e > > > left join pagamentos p > > > ... > > > > > > Aconselho vc a fazer um curso de SQL básico. Veja o do link abaixo (não > > sei > > > se é bom, mas é gratuito): > > > > > > > > http://www.softblue.com.br/site/curso/id/3/CURSO+SQL+COMPLETO+BASICO+AO+AVANCADO+ON+LINE+BD03 > > > > > > []s > > > > > > Fábio Prado > > > www.fabioprado.net > > > > > > > > > > > > > > > 2013/7/11 gersonlima276 > > > > > > > > > ** > > > > > > > > > > > > Ola mestre do Oracle, > > > > > > > > tira uma dúvida, no select abaixo eu preciso saber sobre o significa a > > > > letra (e)(p) na frente do name e do valor, como entender isto? > > > > > > > > select e.name. p.valor as pagamento > > > > from empregados as left join pagamentos > > > > > > > > obrigado senhores!!! > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Fábio Prado > > > www.fabioprado.net > > > "Compartilhando conhecimentos e treinando profissionais em Bancos de > > Dados > > > Oracle" > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
Re: [oracle_br] Re: Dúvida select
Gerson, vc já tinha perguntado isso em outro e-mail e nós já tínhamos respondido, com o código prontinho pra vc... Vc chegou a ler? 2013/7/12 gersonlima276 > ** > > > Bom dia a todos, > > eu estou lendo algumas apostila para aprender sql e junto fazendo alguns > exercício para entender melhor, mas ainda não entendi sobre inner join, eu > dei um select aqui na empresa em duas tabela e esta assim: > > select * from paciente > > cd_paciente (21213) > nm_paciente (Amaral Rodrigues) > ds_endereço (Rua Jacu Pessego) > cd_etnia (2) > > select * from etnia > > cd_etnia (2) > nm_etnia (AMANAYE) > > eu estou fazendo um select para trazer a descrição da etnia(AMANAYE) > > perdoe a minha ignorância mas alguém pode me explicar com faço? > > Um grande abraço a todos vocês. > > > --- Em oracle_br@yahoogrupos.com.br, Fabio Prado escreveu > > > > Gerson, > > > > (e) e (p) são apelidos das tabelas > > > > é uma boa prática atribuir apelidos curtos para as tabelas e referenciar > os > > nomes das colunas com o apelido na frente > > > > O exemplo que vc passou está incompleto. O correto seria como está > escrito > > abaixo: > > > > select e.name. p.valor as pagamento > > from empregados as e > > left join pagamentos p > > ... > > > > Aconselho vc a fazer um curso de SQL básico. Veja o do link abaixo (não > sei > > se é bom, mas é gratuito): > > > > > http://www.softblue.com.br/site/curso/id/3/CURSO+SQL+COMPLETO+BASICO+AO+AVANCADO+ON+LINE+BD03 > > > > []s > > > > Fábio Prado > > www.fabioprado.net > > > > > > > > > > 2013/7/11 gersonlima276 > > > > > > ** > > > > > > > > > Ola mestre do Oracle, > > > > > > tira uma dúvida, no select abaixo eu preciso saber sobre o significa a > > > letra (e)(p) na frente do name e do valor, como entender isto? > > > > > > select e.name. p.valor as pagamento > > > from empregados as left join pagamentos > > > > > > obrigado senhores!!! > > > > > > > > > > > > > > > > > -- > > Fábio Prado > > www.fabioprado.net > > "Compartilhando conhecimentos e treinando profissionais em Bancos de > Dados > > Oracle" > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Migração de banco entre plataformas diferentes
huahuhahua - tá certo, era do Mufalani... Sorry pela citação do nome em vão... :) []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Milton Bastos Henriquis Jr." escreveu > > Tudo jóia Chiappa, e vc? > O e-mail não era meu não... rs > > Abraço! > > http://certificacaobd.com.br > > > > 2013/7/11 J. Laurindo Chiappa > > > ** > > > > > > Joinha, Miltão ? Bem, primeiro sobre o tamanho, não sei se eu chamaria > > hoje em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até > > decente em termos de gigabyte x obamas) em coisinhas tipo aqui : > > http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode > > ser montada em RAID-0 cfrme > > http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports > > Anyway, no caso específico de migração que estamos discutindo, o busílis é > > que esta é uma migração cross-endianness - fosse uma migração para outro > > SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para > > um disk device do tipo e restore+convert na outra ponta > > Nessa situação aí sim realmente uma das opções com a menor > > indisponibilidade seria sim enviar os dados via rede de modo consistente e > > com banco disponível (por DG, por GG, por um software de terceiros que seja > > capaz de processar logs Oracle como é o caso do shareplex, por um software > > residente na máquina-destino que leia via rede os dados da origem e os > > insira no banco-destino de maneira consistente no tempo, via flashback ou > > quetais - existem diversos no mercado -, etc) , mas a NECESSIDADE aí é, > > Óbvio, uma rede de alta-performance ligando os dois servidores > > Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a > > tua infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e > > de alta-performance entre os dois servers (não dá pra pensar em usar a rede > > Pública comum da Empresa, normalmente) aí pode ficar inviável usar > > tecnologias de transferência via rede, e nesses casos Tranquilamente pode > > ser mais economicamente viável ao invés de upgradear a rede se investir num > > disco externo rápido Infelizmente,sendo (como é) cross-endianness, a > > opção aí nesse cenário aonde a rede não é confiável e performática seria > > muito certamente partir para Cross-Platform Transportable Tablespaces , que > > implica em colocar cada tablespace em read-only e portanto é menos > > disponível . > > > > Para vc ter um overview das opções, dá um look na nota metalink "Migration > > Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1] > > que vc acha links para as principais opções todas ... > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani > > escreveu > > > > > > > > Meu caro, > > > > > > Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele > > referencia. Na minha opinião, a melhor forma para migrar VLDBs é com > > Dataguard e tecnologias similares (Goldengate/Shareplex), mesmo assim ainda > > prefiro o DG. > > > > > > Onde o seu downtime é mínimo. > > > > > > > > http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf > > > > > > > > > Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento > > de Oracle do brasil, faça sua inscrição em www.guob.com.br. > > > > > > > > > Atenciosamente, > > > Rodrigo Mufalani > > > rodrigo@ > > > www.mufalani.com.br > > > > > > > > > > > > > > > > > > > > On 11/07/2013, at 16:27, Daniel Mello wrote: > > > > > > > Boa tarde. > > > > > > > > Assim como um pergunta respondida de nosso amigo Victor, tenho uma > > migração entre plataformas, mas no meu caso muda o Endian_Format " BIG >> > > Little", a mudança será de um Solaris Sparc para Solaris x86-64. A versão > > do oracle é a 11.2.0.2. > > > > Alguém já fez esse tipo de conversão? > > > > Conhecem o melhor método? > > > > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a > > princípio. > > > > > > > > Obrigado. > > > > Daniel. > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
Re: [oracle_br] Re: Migração de banco entre plataformas diferentes
Tudo jóia Chiappa, e vc? O e-mail não era meu não... rs Abraço! http://certificacaobd.com.br 2013/7/11 J. Laurindo Chiappa > ** > > > Joinha, Miltão ? Bem, primeiro sobre o tamanho, não sei se eu chamaria > hoje em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até > decente em termos de gigabyte x obamas) em coisinhas tipo aqui : > http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode > ser montada em RAID-0 cfrme > http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports > Anyway, no caso específico de migração que estamos discutindo, o busílis é > que esta é uma migração cross-endianness - fosse uma migração para outro > SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para > um disk device do tipo e restore+convert na outra ponta > Nessa situação aí sim realmente uma das opções com a menor > indisponibilidade seria sim enviar os dados via rede de modo consistente e > com banco disponível (por DG, por GG, por um software de terceiros que seja > capaz de processar logs Oracle como é o caso do shareplex, por um software > residente na máquina-destino que leia via rede os dados da origem e os > insira no banco-destino de maneira consistente no tempo, via flashback ou > quetais - existem diversos no mercado -, etc) , mas a NECESSIDADE aí é, > Óbvio, uma rede de alta-performance ligando os dois servidores > Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a > tua infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e > de alta-performance entre os dois servers (não dá pra pensar em usar a rede > Pública comum da Empresa, normalmente) aí pode ficar inviável usar > tecnologias de transferência via rede, e nesses casos Tranquilamente pode > ser mais economicamente viável ao invés de upgradear a rede se investir num > disco externo rápido Infelizmente,sendo (como é) cross-endianness, a > opção aí nesse cenário aonde a rede não é confiável e performática seria > muito certamente partir para Cross-Platform Transportable Tablespaces , que > implica em colocar cada tablespace em read-only e portanto é menos > disponível . > > Para vc ter um overview das opções, dá um look na nota metalink "Migration > Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1] > que vc acha links para as principais opções todas ... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani > escreveu > > > > > Meu caro, > > > > Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele > referencia. Na minha opinião, a melhor forma para migrar VLDBs é com > Dataguard e tecnologias similares (Goldengate/Shareplex), mesmo assim ainda > prefiro o DG. > > > > Onde o seu downtime é mínimo. > > > > > http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf > > > > > > Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento > de Oracle do brasil, faça sua inscrição em www.guob.com.br. > > > > > > Atenciosamente, > > Rodrigo Mufalani > > rodrigo@... > > www.mufalani.com.br > > > > > > > > > > > > > On 11/07/2013, at 16:27, Daniel Mello wrote: > > > > > Boa tarde. > > > > > > Assim como um pergunta respondida de nosso amigo Victor, tenho uma > migração entre plataformas, mas no meu caso muda o Endian_Format " BIG >> > Little", a mudança será de um Solaris Sparc para Solaris x86-64. A versão > do oracle é a 11.2.0.2. > > > Alguém já fez esse tipo de conversão? > > > Conhecem o melhor método? > > > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a > princípio. > > > > > > Obrigado. > > > Daniel. > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está suje
[oracle_br] free sga.. tem coisa errada ai ?
Bom dia senhores.. que acha disso? Ontem o colega Mufalani comentou em um thread sobre o problema que um outro colega que estava enfrentando com o backup, talvez por um possivel problemas de alocacao de memoriafui lendo aquilo para acompanhar e resolvi de curiosidade olhar o meu *v$sgainfo;* Que me chama atenção é que ta zerado... Eu acho que isso tá mal configurado.. a linha Free sga memory sempre informa 0 o servidor tem 12 gb no total e 8 gb estaria alocado para o Oracle.. pior que ninguém ate agora reclamou de performance SQL> select * from v$sgainfo; NAME BYTES RES -- --- Fixed SGA Size 2272320 No Redo Buffers9699328 No Buffer Cache Size4496293888 Yes Shared Pool Size 3976200192 Yes Large Pool Size16777216 Yes Java Pool Size 33554432 Yes Streams Pool Size 16777216 Yes Shared IO Pool Size 0 Yes Granule Size 16777216 No Maximum SGA Size 8551575552 No Startup overhead in Shared Pool 149299768 No NAME BYTES RES -- --- Free SGA Memory Available 0 esse acima o valor da sga max foi setado manualmente... e tem um outro servidor que tá no automatico, default do Oracle 11g (11.2.0.4 ambos), ainda nem começou a ser configurado pra entrar em producao... SQL> select * from v$sgainfo; NAME BYTES RES -- --- Fixed SGA Size 2263328 No Redo Buffers9707520 No Buffer Cache Size3573547008 Yes Shared Pool Size 1174405120 Yes Large Pool Size16777216 Yes Java Pool Size 16777216 Yes Streams Pool Size 16777216 Yes Shared IO Pool Size 0 Yes Granule Size 16777216 No Maximum SGA Size 4810256384 No Startup overhead in Shared Pool 157244256 No NAME BYTES RES -- --- Free SGA Memory Available 0 [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Migração de banco entre plataformas diferentes
Bom dia a todos, Sobre este cenário, gostaria de compartilhar um link. Peço licença ao mestre Portilho que postou o case de sucesso no blog da Nerv. http://nervinformatica.com.br/blog/2012/05/10/revisao-do-rman-convert-database-migracao-entre-linux-e-solaris-de-6tb-com-downtime-de-30-minutos/ Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit --- Em oracle_br@yahoogrupos.com.br, Daniel Mello escreveu > > Muito obrigado pelas respostas de todos. > Realmente um ponto que não destaquei é que nesta migração em específico > teremos um bom tempo de indisponibilidade aceitável pelo cliente, ou seja, > acredito que a forma mais simples seja realmente o "Cross-Platform > Transportable Tablespaces". Terei que ensaiar um pouco essa migração, pois > realmente é algo totalmente novo. Um ponto que não ficou bem claro na > documentação é em relação à criação da instância e database, vocês já usaram > esse recurso? > > Att > Daniel. > > > > > De: J. Laurindo Chiappa > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quinta-feira, 11 de Julho de 2013 18:00 > Assunto: [oracle_br] Re: Migração de banco entre plataformas diferentes > > > Joinha, Miltão ? Bem, primeiro sobre o tamanho, não sei se eu chamaria > hoje em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até > decente em termos de gigabyte x obamas) em coisinhas tipo aqui : > http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode ser > montada em RAID-0 cfrme > http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports > > Anyway, no caso específico de migração que estamos discutindo, o busílis é > que esta é uma migração cross-endianness - fosse uma migração para outro > SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para um > disk device do tipo e restore+convert na outra ponta > Nessa situação aí sim realmente uma das opções com a menor > indisponibilidade seria sim enviar os dados via rede de modo consistente e > com banco disponível (por DG, por GG, por um software de terceiros que seja > capaz de processar logs Oracle como é o caso do shareplex, por um software > residente na máquina-destino que leia via rede os dados da origem e os insira > no banco-destino de maneira consistente no tempo, via flashback ou quetais - > existem diversos no mercado -, etc) , mas a NECESSIDADE aí é, Óbvio, uma rede > de alta-performance ligando os dois servidores > Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a > tua infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e de > alta-performance entre os dois servers (não dá pra pensar em usar a rede > Pública comum da Empresa, normalmente) aí pode ficar inviável usar > tecnologias de transferência via rede, e nesses casos Tranquilamente pode ser > mais economicamente viável ao invés de upgradear a rede se investir num disco > externo rápido Infelizmente,sendo (como é) cross-endianness, a opção aí > nesse cenário aonde a rede não é confiável e performática seria muito > certamente partir para Cross-Platform Transportable Tablespaces , que implica > em colocar cada tablespace em read-only e portanto é menos disponível . > > Para vc ter um overview das opções, dá um look na nota metalink > "Migration Of An Oracle Database Across OS Platforms (Generic Platform)" [ID > 733205.1] que vc acha links para as principais opções todas ... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani escreveu > > > > Meu caro, > > > > Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele referencia. > > Na minha opinião, a melhor forma para migrar VLDBs é com Dataguard e > > tecnologias similares (Goldengate/Shareplex), mesmo assim ainda prefiro o > > DG. > > > > Onde o seu downtime é mínimo. > > > > http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf > > > > > > Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento de > > Oracle do brasil, faça sua inscrição em www.guob.com.br. > > > > > > Atenciosamente, > > Rodrigo Mufalani > > rodrigo@ > > www.mufalani.com.br > > > > > > > > > > > > On 11/07/2013, at 16:27, Daniel Mello wrote: > > > > > Boa tarde. > > > > > > Assim como um pergunta respondida de nosso amigo Victor, tenho uma > > > migração entre plataformas, mas no meu caso muda o Endian_Format " BIG >> > > > Little", a mudança será de um Solaris Sparc para Solaris x86-64. A versão > > > do oracle é a 11.2.0.2. > > > Alguém já fez esse tipo de conversão? > > > Conhecem o melhor método? > > > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a > > > princípio. > > > > > > Obrigado. > > > Daniel. > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
Re: [oracle_br] Re: Migração de banco entre plataformas diferentes
Muito obrigado pelas respostas de todos. Realmente um ponto que não destaquei é que nesta migração em específico teremos um bom tempo de indisponibilidade aceitável pelo cliente, ou seja, acredito que a forma mais simples seja realmente o "Cross-Platform Transportable Tablespaces". Terei que ensaiar um pouco essa migração, pois realmente é algo totalmente novo. Um ponto que não ficou bem claro na documentação é em relação à criação da instância e database, vocês já usaram esse recurso? Att Daniel. De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 11 de Julho de 2013 18:00 Assunto: [oracle_br] Re: Migração de banco entre plataformas diferentes Joinha, Miltão ? Bem, primeiro sobre o tamanho, não sei se eu chamaria hoje em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até decente em termos de gigabyte x obamas) em coisinhas tipo aqui : http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode ser montada em RAID-0 cfrme http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports Anyway, no caso específico de migração que estamos discutindo, o busílis é que esta é uma migração cross-endianness - fosse uma migração para outro SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para um disk device do tipo e restore+convert na outra ponta Nessa situação aí sim realmente uma das opções com a menor indisponibilidade seria sim enviar os dados via rede de modo consistente e com banco disponível (por DG, por GG, por um software de terceiros que seja capaz de processar logs Oracle como é o caso do shareplex, por um software residente na máquina-destino que leia via rede os dados da origem e os insira no banco-destino de maneira consistente no tempo, via flashback ou quetais - existem diversos no mercado -, etc) , mas a NECESSIDADE aí é, Óbvio, uma rede de alta-performance ligando os dois servidores Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a tua infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e de alta-performance entre os dois servers (não dá pra pensar em usar a rede Pública comum da Empresa, normalmente) aí pode ficar inviável usar tecnologias de transferência via rede, e nesses casos Tranquilamente pode ser mais economicamente viável ao invés de upgradear a rede se investir num disco externo rápido Infelizmente,sendo (como é) cross-endianness, a opção aí nesse cenário aonde a rede não é confiável e performática seria muito certamente partir para Cross-Platform Transportable Tablespaces , que implica em colocar cada tablespace em read-only e portanto é menos disponível . Para vc ter um overview das opções, dá um look na nota metalink "Migration Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1] que vc acha links para as principais opções todas ... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani escreveu > > Meu caro, > > Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele referencia. > Na minha opinião, a melhor forma para migrar VLDBs é com Dataguard e > tecnologias similares (Goldengate/Shareplex), mesmo assim ainda prefiro o DG. > > Onde o seu downtime é mínimo. > > http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf > > > Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento de > Oracle do brasil, faça sua inscrição em www.guob.com.br. > > > Atenciosamente, > Rodrigo Mufalani > rodrigo@... > www.mufalani.com.br > > > > > > On 11/07/2013, at 16:27, Daniel Mello wrote: > > > Boa tarde. > > > > Assim como um pergunta respondida de nosso amigo Victor, tenho uma migração > > entre plataformas, mas no meu caso muda o Endian_Format " BIG >> Little", a > > mudança será de um Solaris Sparc para Solaris x86-64. A versão do oracle é > > a 11.2.0.2. > > Alguém já fez esse tipo de conversão? > > Conhecem o melhor método? > > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a princípio. > > > > Obrigado. > > Daniel. > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ES
[oracle_br] Re: Dúvida select
Bom dia a todos, eu estou lendo algumas apostila para aprender sql e junto fazendo alguns exercício para entender melhor, mas ainda não entendi sobre inner join, eu dei um select aqui na empresa em duas tabela e esta assim: select * from paciente cd_paciente (21213) nm_paciente (Amaral Rodrigues) ds_endereço (Rua Jacu Pessego) cd_etnia (2) select * from etnia cd_etnia (2) nm_etnia (AMANAYE) eu estou fazendo um select para trazer a descrição da etnia(AMANAYE) perdoe a minha ignorância mas alguém pode me explicar com faço? Um grande abraço a todos vocês. --- Em oracle_br@yahoogrupos.com.br, Fabio Prado escreveu > > Gerson, > > (e) e (p) são apelidos das tabelas > > é uma boa prática atribuir apelidos curtos para as tabelas e referenciar os > nomes das colunas com o apelido na frente > > O exemplo que vc passou está incompleto. O correto seria como está escrito > abaixo: > > select e.name. p.valor as pagamento > from empregados as e > left join pagamentos p > ... > > Aconselho vc a fazer um curso de SQL básico. Veja o do link abaixo (não sei > se é bom, mas é gratuito): > > http://www.softblue.com.br/site/curso/id/3/CURSO+SQL+COMPLETO+BASICO+AO+AVANCADO+ON+LINE+BD03 > > []s > > Fábio Prado > www.fabioprado.net > > > > > 2013/7/11 gersonlima276 > > > ** > > > > > > Ola mestre do Oracle, > > > > tira uma dúvida, no select abaixo eu preciso saber sobre o significa a > > letra (e)(p) na frente do name e do valor, como entender isto? > > > > select e.name. p.valor as pagamento > > from empregados as left join pagamentos > > > > obrigado senhores!!! > > > > > > > > > > -- > Fábio Prado > www.fabioprado.net > "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados > Oracle" > > > [As partes desta mensagem que não continham texto foram removidas] >
