Estamos migrando uma aplicação de Oracle para SQL Server. O fornecedor é responsável pela maioria dos esforços de migração, mas há uma parte desenvolvida internamente com a qual estou tendo problemas.
A aplicação antiga no Oracle tem um procedimento que coleta dados específicos e, em seguida, outro procedimento insere esses dados em uma tabela de teste em nosso sistema de receita (um servidor Oracle diferente). Este é um procedimento Oracle por meio de um Oracle Public Database Link.
No SQL Server, estou tentando reescrever esse processo usando os servidores vinculados do SQL Server. Criei a conexão do Linked Server com o sistema de receita e ele pode se conectar por meio desse link.
No SQL*Plus, posso emitir esta instrução como esse usuário:
select * from rs.rs_myapp;
E obtenho resultados. (rs é o usuário do sistema de receita, não o usuário com o qual me conecto. A tabela rs_MyApp é a tabela de teste para nossos dados em seu sistema.)
Mas se eu tentar fazer isso no SQL Server:
select * from [rstest-Link]..rs.rs_myapp
Recebo esta mensagem:
Msg 7314, nível 16, estado 1, linha 50 O provedor OLE DB "OraOLEDB.Oracle" para o servidor vinculado "rstest-Link" não contém a tabela ""rs".."rs_myapp"". A tabela não existe ou o usuário atual não tem permissões nessa tabela.
Eu posso fazer isso, no entanto:
select * from openquery([rstest-Link], 'select count(*) from rs.rs_myapp')
E isso traz resultados de volta, mostrando que o link funciona.
No entanto, não consigo concluir o procedimento do SQL Server, devido a esse erro 7314. O procedimento é bem básico, tem exatamente uma linha de código:
Insert Into [rstest-Link]..rs.rs_myapp (ACCOUNT_NUMBER, FROM_DATE, TO_DATE,
Data1, Data2, SAMPLE_DATE, Content1, Content2)
select ACCOUNT_NUMBER, FROM_DATE, TO_DATE, MyData1, MyData2, SAMPLE_DATE, MyContent1, MyContent2
FROM dbo.RS_INTERFACE;
Mas sem resolver o erro 7314, não há como criar o procedimento.
Então, como eu faço isso? Vou ter que usar um cursor e emitir algum tipo de código para cada linha, como:
INSERT OPENQUERY ([rstest-Link], 'SELECT ... FROM ...')
VALUES ('...');
A Oracle usa um catálogo que diferencia maiúsculas de minúsculas e oculta esse fato feio de você convertendo silenciosamente identificadores sem aspas para todas as letras maiúsculas, tanto em DDL quanto em DML.
O nome da sua tabela é, na verdade, RS.RS_MYAPP, e o SQL Server pode estar enviando o identificador para o Oracle como "rs".."rs_myapp", o que falharia no Oracle.
Então tente
selecione * de [rstest-Link]..RS.RS_MYAPP
Primeiro: vou tentar responder a pergunta em si: Quando você faz referência às tabelas ORACLE diretamente,
[LinkedServerName]..[Schema].[Table]
é esse o método que você está usando?Em caso afirmativo, certifique-se de que o usuário que está efetuando login por meio do Linked Server esteja configurado no lado ORACLE para usar RPC Out. (através das configurações do servidor vinculado)
^^Editar: Ignore o acima. David acertou em sua resposta.
Agora alguns pensamentos:
Eu tenho trabalhado com SQL Server --> ORACLE via servidor vinculado há alguns anos, e posso dizer com certeza que por pura facilidade de uso e estabilidade, escrevendo a consulta em ORACLE SQL / PL/SQL e usando OPENQUERY( ) funcionou muito melhor para mim do que usar as tabelas do servidor vinculado e escrever a consulta em T-SQL.
Por quê?
1) Bem, quando você escreve no ORACLE SQL e o passa pelo
OPENQUERY
, é o mecanismo ORACLE que está fazendo o trabalho pesado, e o SQL Server não está tendo que lutar pelo otimizador do Oracle. O SQL Server apenas aguarda a conclusão da consulta e aceita os resultados.2) Você pode otimizar a consulta no lado do ORACLE e apenas usá-la no lado do SQL Server quando terminar. O otimizador do SQL Server apenas me diz 100% - Consulta remota e deixa por isso mesmo.
3) Problemas (com permissões, otimização, etc.) são muito mais fáceis de diagnosticar se você não precisar filtrar o T-SQL.
4) Você ainda pode manipular os resultados usando T-SQL quando eles são retornados (na instrução SELECT externa. Isso significa que você pode usar AMBAS as funções Oracle E T-SQL Native para processar sua consulta
TRUNC
. acessível.SUBSTR
INSTR
CHARDINDEX
Eu só era bem versado em T-SQL quando comecei a usá-lo para consultar o ORACLE, e deixe-me dizer a você, assim que aprendi PL/SQL, comecei a usá-lo em
OPENQUERY
instruções no SQL Server. O conceito de separação de funções vale para estes também. Eles são muito mais felizes quando não estão lutando.