none
Linked-Server para um Servidor que já tem o Linked-Server criado RRS feed

  • Pergunta

  • Pessoal

         Estou em um  projeto onde já temos um linked-Server criado para um Servidor 172.10.0.105 que está vindo do Servidor 172.10.0.114, só que agora estou precisando em criar um novo linked-Server para o Servidor 172.10.0.105, só que como pelo IP vai dar problema que já existe estamos pensando em criar o novo linked-Server pelo nome no caso MchServerPonto, existiria alguma outra maneira de criar por IP mais de uma vez no mesmo Servidor de origem ?

    sexta-feira, 6 de dezembro de 2019 19:08

Respostas

  • Deleted
    • Marcado como Resposta neibala quarta-feira, 11 de dezembro de 2019 12:50
    segunda-feira, 9 de dezembro de 2019 22:26
  • Neibala,

    Aproveitando ainda este post, veja no link abaixo uma abordagem interessante sobre as diferenças entre ODBC e OLEDB:

    https://social.msdn.microsoft.com/Forums/pt-BR/85116c21-b848-48ed-9a12-4a74f94dfeb3/oledb-x-ado-x-odbc-para-o-programador-qual-a-diferena

    Já este outro do Stack Overflow, extraiu um trecho da documentação oficial Microsoft, bem interessante:

    "

    A documentação da Microsoft diz bem o que é. Vou só resumir.

    São componentes para dar acesso (leitura) a dados vindos de uma determinada fonte, provavelmente um banco de dados. Existem operações comuns que estes provedores devem fornecer. O ADO.NET os trata de forma abstrata e os provedores os implementa de forma concreta de acordo com as especificidades da fonte de dados.

    A ideia é que o acesso à qualquer fonte de dados seja feita de forma transparente. Que pareça que tudo vem de algo comum, que não seja necessário entender o funcionamento específico da fonte. isto simplifica inclusive a troca de uma fonte por outra.

    Estes provedores funcionam como se fossem os drivers ODBC e OleDB mas implementam uma forma mais adequada para o .NET.

    Se você entende como o dbf funciona, talvez entenda o que sejam os RDD (Replaceable Data Drivers). É basicamente a mesma coisa.

    Alguns provedores definidos pela Microsoft podem ser achados aqui. Qualquer um pode definir seus próprios provedores. Há empresas especializadas nisto e alguns banco de dados do mercado fornecem provedores para o ADO.NET. Exemplos.

    OleDB - Como se vê os próprios drivers ODBC e OleDB são provedores do ADO.Net.

    O provedor OleDB apenas pode acessar fontes de dados que conseguem se comunicar com esta tecnologia. A própria Microsoft está abandonando seu suporte em alguns dos seus produtos.

    ODBC - O ODBC é uma forma mais universal de acesso a fontes de dados.

    Ambos devem ser evitados porque é uma camada a mais, tem um custo de processamento extra, embora o OleDB evita um pouco isto. Provedores mais específicos para um banco de dados ou outra fonte sempre é mais vantajoso. A implementação deles são mais eficientes por conhecerem como acessar os dados da melhor forma. Usa-se provedores mais genéricos, como os dois exemplos citados, quando não existe um provedor mais específico.

    As definições formais podem ser obtidas no links acima."

    Neste mesmo link, você vai encontrar outras definições e considerações sobre o ODBC e OLEDB que se assemelha ao que destaquei no outro post:

    "Rogers Corrêa

    Provedor é algo que te ajuda, que fornece algo no caso uma conexão.

    OLE DB e ODBC são APIs que permitem o acesso a uma gama de fontes de dados.

    • (ODBC), é um padrão internacional para manipular dados relacionais usando a sintaxe de consulta SQL em diferentes fontes de dados. ODBC tem a vantagem de ser um padrão internacional que permite manipular uma grande variedade de fontes de dados relacionais através de diversos Drivers de ODBC da Microsoft e terceiros de fornecedores. A principal desvantagem do ODBC é que é limitado a relacional, sintaxe SQL com base em dados. 

    • OLE DB é a interface de baixo nível estratégico da Microsoft para dados em toda a organização. OLE DB é uma especificação aberta desenvolvida para proporcionar o sucesso do ODBC, fornecendo um padrão aberto para acessar todos os tipos de dados. OLE DB não impõe nenhuma limitação específica na sintaxe da consulta ou a estrutura dos dados expostos como ele pode ser recuperado em formato tabular. Um provedor de dados OLE DB é análogo a um Driver de ODBC, expondo uma fonte de dados para um OLE DB consumidor, como ADO. Uma variedade cada vez maior de dados provedores do OLE DB sendo disponibilizados por fornecedores de Microsoft e de terceiros. O primeiro provedor de dados OLE DB, provedor Microsoft OLE DB para Drivers ODBC, permite que você exponha a qualquer fonte de dados ODBC para um consumidor de OLE DB."

    Vale uma análise e entendimento da forma de uso e acesso, mas ambos são justamente formas de se possibilitar acesso ao SQL Server de maneiras distintas e específicas.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    segunda-feira, 9 de dezembro de 2019 23:07

Todas as Respostas

  • Neibala,

    Não tenho certeza, mas talvez poderia ser uma possibilidade criar inicialmente um Alias através da ferramenta SQL Server Configuration Manager justamente no servidor que vai ser feito a criação do Linked Server, no qual esta Alias apontaria justamente para o IP mas você iria utilizar o nome no Linked Server.

    Veja se estes links te ajudam:

    https://social.msdn.microsoft.com/Forums/sqlserver/en-US/83e06567-9ac3-48f9-bfd5-e02ee2000671/adding-a-linked-server-with-alias

    https://jackworthen.com/2017/03/23/creating-and-configuring-an-alias-in-sql-server/

    https://www.sqlshack.com/how-to-create-and-configure-a-linked-server-in-sql-server-management-studio/

    Uma outra possibilidade que poderiamos pensar seria através das configurações ODBC:

    https://www.sqlshack.com/how-to-configure-a-linked-server-using-the-odbc-driver/

    https://social.msdn.microsoft.com/forums/sqlserver/en-US/daa86ac4-d759-44d3-a12f-4b580ab02a0b/sql-server-alias-configuration


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    sexta-feira, 6 de dezembro de 2019 19:30
  • Deleted
    sábado, 7 de dezembro de 2019 00:11
  •    José Diz, a minha maior preocupação seria quantos linked-Server poderia ter de um mesmo Servidor, ligado a mesma instância de origem, exemplo tendo como base a seguinte estrutura :

     Servidor de origem Servidor 172.10.0.105 (SvrPontoProd) instância sqlPontoProd

     Neste caso eu poderia ter o meu linked-Server de 2 maneiras apenas ou teria outras, onde o acesso seria pelo IP ou pelo nome da máquina ou teria outras maneiras ?

      Exemplo :

    1) 172.10.0.115\sqlPontoProd
    2) SvrPontoProd\sqlPontoProd

    segunda-feira, 9 de dezembro de 2019 11:44
  • Deleted
    segunda-feira, 9 de dezembro de 2019 13:15
  •    José Diz, a minha maior preocupação seria quantos linked-Server poderia ter de um mesmo Servidor, ligado a mesma instância de origem, exemplo tendo como base a seguinte estrutura :

     Servidor de origem Servidor 172.10.0.105 (SvrPontoProd) instância sqlPontoProd

     Neste caso eu poderia ter o meu linked-Server de 2 maneiras apenas ou teria outras, onde o acesso seria pelo IP ou pelo nome da máquina ou teria outras maneiras ?

      Exemplo :

    1) 172.10.0.115\sqlPontoProd
    2) SvrPontoProd\sqlPontoProd

    Neibala,

    Tecnicamente não existe um limite de linkeds servers que podem ser feito entre a mesma origem e destino, o que você tem que se atentar é justamente a forma de configuração, ou seja, especificar nomes únicas e exclusivos mesmo que seja entre as mesmas fontes, mas de forma diferente.

    O exemplo do José Diz apresenta justamente essa possibilidade.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    segunda-feira, 9 de dezembro de 2019 16:40
  •  José Diz / Junior Galvão

      A forma pela quais vocês comentarão realmente deu certo, só que fiquei na dúvida na questão da performance, pois antes a criação do linked-Server está conforme abaixo :

    1) EXEC master.dbo.sp_addlinkedserver @server = N'172.10.0.105', @srvproduct=N'SQL Server'

    já está nova

    2) EXEC master.dbo.sp_addlinkedserver @server = N'SERVER_0_105', @srvproduct=N'', @provider= N'SQLNCLI', @datasrc= N'172.10.0.105';

    Nesses 2 casos será utilizado o  Microsoft OLE DB Provider for SQL Server ou :

    1) @srvproduct=N'SQL Server' acessa o SQL Server ?

    2) @provider= N'SQLNCLI' acesso o SQL Server Native Client 11 ?

    3) Ou seria de outra maneira ?

    E estava verificando a questão de ter mais de um linked-Server @provider= N'SQLNCLI', só que fiquei com uma dúvida do que li na documentação da Microsoft, na questão de ter mais de um linked-Server, poderia esclarecer melhor está informação do site da Microsoft, conforme abaixo ?

    https://docs.microsoft.com/pt-br/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15
    O Microsoft OLE DB Provider para SQL Server (SQLOLEDB) anterior e o provedor SQL Server Native Client OLE DB (SQLNCLI) permanecem preteridos e não é recomendável usar nenhum dos dois para um novo trabalho de desenvolvimento.

    segunda-feira, 9 de dezembro de 2019 18:41
  •  José Diz / Junior Galvão

      A forma pela quais vocês comentarão realmente deu certo, só que fiquei na dúvida na questão da performance, pois antes a criação do linked-Server está conforme abaixo :

    1) EXEC master.dbo.sp_addlinkedserver @server = N'172.10.0.105', @srvproduct=N'SQL Server'

    já está nova

    2) EXEC master.dbo.sp_addlinkedserver @server = N'SERVER_0_105', @srvproduct=N'', @provider= N'SQLNCLI', @datasrc= N'172.10.0.105';

    Nesses 2 casos será utilizado o  Microsoft OLE DB Provider for SQL Server ou :

    1) @srvproduct=N'SQL Server' acessa o SQL Server ?

    2) @provider= N'SQLNCLI' acesso o SQL Server Native Client 11 ?

    3) Ou seria de outra maneira ?

    E estava verificando a questão de ter mais de um linked-Server @provider= N'SQLNCLI', só que fiquei com uma dúvida do que li na documentação da Microsoft, na questão de ter mais de um linked-Server, poderia esclarecer melhor está informação do site da Microsoft, conforme abaixo ?

    https://docs.microsoft.com/pt-br/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15
    O Microsoft OLE DB Provider para SQL Server (SQLOLEDB) anterior e o provedor SQL Server Native Client OLE DB (SQLNCLI) permanecem preteridos e não é recomendável usar nenhum dos dois para um novo trabalho de desenvolvimento.

    Neibala,

    Performance, você se refere a acessar por IP ou por nome se existe diferença?


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    segunda-feira, 9 de dezembro de 2019 20:00
  • Deleted
    segunda-feira, 9 de dezembro de 2019 21:09
  •  José Diz / Junior Galvão

      A forma pela quais vocês comentarão realmente deu certo, só que fiquei na dúvida na questão da performance, pois antes a criação do linked-Server está conforme abaixo :

    1) EXEC master.dbo.sp_addlinkedserver @server = N'172.10.0.105', @srvproduct=N'SQL Server'

    já está nova

    2) EXEC master.dbo.sp_addlinkedserver @server = N'SERVER_0_105', @srvproduct=N'', @provider= N'SQLNCLI', @datasrc= N'172.10.0.105';

    Nesses 2 casos será utilizado o  Microsoft OLE DB Provider for SQL Server ou :

    1) @srvproduct=N'SQL Server' acessa o SQL Server ?

    2) @provider= N'SQLNCLI' acesso o SQL Server Native Client 11 ?

    3) Ou seria de outra maneira ?

    E estava verificando a questão de ter mais de um linked-Server @provider= N'SQLNCLI', só que fiquei com uma dúvida do que li na documentação da Microsoft, na questão de ter mais de um linked-Server, poderia esclarecer melhor está informação do site da Microsoft, conforme abaixo ?

    https://docs.microsoft.com/pt-br/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15
    O Microsoft OLE DB Provider para SQL Server (SQLOLEDB) anterior e o provedor SQL Server Native Client OLE DB (SQLNCLI) permanecem preteridos e não é recomendável usar nenhum dos dois para um novo trabalho de desenvolvimento.

    Neibala,

    Então, acessei a documentação, realmente este trecho esta destacando esta recomendação, mas verificando na minha máquina as configurações e providers ODBCs, neste momento tenho as edições 2017 e 2019 instaladas e os respectivos providers:


    A sua preocupação ao meu ver esta mais relacionada a continuidade e disponibilidade destes providers do que está mesmo questões de desempenho.

    Não é isso?


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    segunda-feira, 9 de dezembro de 2019 21:58
  • Deleted
    • Marcado como Resposta neibala quarta-feira, 11 de dezembro de 2019 12:50
    segunda-feira, 9 de dezembro de 2019 22:26
  • Neibala,

    Aproveitando ainda este post, veja no link abaixo uma abordagem interessante sobre as diferenças entre ODBC e OLEDB:

    https://social.msdn.microsoft.com/Forums/pt-BR/85116c21-b848-48ed-9a12-4a74f94dfeb3/oledb-x-ado-x-odbc-para-o-programador-qual-a-diferena

    Já este outro do Stack Overflow, extraiu um trecho da documentação oficial Microsoft, bem interessante:

    "

    A documentação da Microsoft diz bem o que é. Vou só resumir.

    São componentes para dar acesso (leitura) a dados vindos de uma determinada fonte, provavelmente um banco de dados. Existem operações comuns que estes provedores devem fornecer. O ADO.NET os trata de forma abstrata e os provedores os implementa de forma concreta de acordo com as especificidades da fonte de dados.

    A ideia é que o acesso à qualquer fonte de dados seja feita de forma transparente. Que pareça que tudo vem de algo comum, que não seja necessário entender o funcionamento específico da fonte. isto simplifica inclusive a troca de uma fonte por outra.

    Estes provedores funcionam como se fossem os drivers ODBC e OleDB mas implementam uma forma mais adequada para o .NET.

    Se você entende como o dbf funciona, talvez entenda o que sejam os RDD (Replaceable Data Drivers). É basicamente a mesma coisa.

    Alguns provedores definidos pela Microsoft podem ser achados aqui. Qualquer um pode definir seus próprios provedores. Há empresas especializadas nisto e alguns banco de dados do mercado fornecem provedores para o ADO.NET. Exemplos.

    OleDB - Como se vê os próprios drivers ODBC e OleDB são provedores do ADO.Net.

    O provedor OleDB apenas pode acessar fontes de dados que conseguem se comunicar com esta tecnologia. A própria Microsoft está abandonando seu suporte em alguns dos seus produtos.

    ODBC - O ODBC é uma forma mais universal de acesso a fontes de dados.

    Ambos devem ser evitados porque é uma camada a mais, tem um custo de processamento extra, embora o OleDB evita um pouco isto. Provedores mais específicos para um banco de dados ou outra fonte sempre é mais vantajoso. A implementação deles são mais eficientes por conhecerem como acessar os dados da melhor forma. Usa-se provedores mais genéricos, como os dois exemplos citados, quando não existe um provedor mais específico.

    As definições formais podem ser obtidas no links acima."

    Neste mesmo link, você vai encontrar outras definições e considerações sobre o ODBC e OLEDB que se assemelha ao que destaquei no outro post:

    "Rogers Corrêa

    Provedor é algo que te ajuda, que fornece algo no caso uma conexão.

    OLE DB e ODBC são APIs que permitem o acesso a uma gama de fontes de dados.

    • (ODBC), é um padrão internacional para manipular dados relacionais usando a sintaxe de consulta SQL em diferentes fontes de dados. ODBC tem a vantagem de ser um padrão internacional que permite manipular uma grande variedade de fontes de dados relacionais através de diversos Drivers de ODBC da Microsoft e terceiros de fornecedores. A principal desvantagem do ODBC é que é limitado a relacional, sintaxe SQL com base em dados. 

    • OLE DB é a interface de baixo nível estratégico da Microsoft para dados em toda a organização. OLE DB é uma especificação aberta desenvolvida para proporcionar o sucesso do ODBC, fornecendo um padrão aberto para acessar todos os tipos de dados. OLE DB não impõe nenhuma limitação específica na sintaxe da consulta ou a estrutura dos dados expostos como ele pode ser recuperado em formato tabular. Um provedor de dados OLE DB é análogo a um Driver de ODBC, expondo uma fonte de dados para um OLE DB consumidor, como ADO. Uma variedade cada vez maior de dados provedores do OLE DB sendo disponibilizados por fornecedores de Microsoft e de terceiros. O primeiro provedor de dados OLE DB, provedor Microsoft OLE DB para Drivers ODBC, permite que você exponha a qualquer fonte de dados ODBC para um consumidor de OLE DB."

    Vale uma análise e entendimento da forma de uso e acesso, mas ambos são justamente formas de se possibilitar acesso ao SQL Server de maneiras distintas e específicas.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    segunda-feira, 9 de dezembro de 2019 23:07
  •  Junior Galvão / José Diz

         Quero agradecer as várias fontes de informação que foram muito útil na questão de tirar algumas dúvidas que pode surgir vendo outros pontos de acesso também e estarei analisando novamente este assunto e validando se realmente está atendendo dentro das minhas expectativas.

    quarta-feira, 11 de dezembro de 2019 12:49
  •  Junior Galvão / José Diz

         Quero agradecer as várias fontes de informação que foram muito útil na questão de tirar algumas dúvidas que pode surgir vendo outros pontos de acesso também e estarei analisando novamente este assunto e validando se realmente está atendendo dentro das minhas expectativas.

    Neibala,

    Ok, perfeito, ficamos no aguardo, estamos aqui para ajudar e aprender sempre.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quarta-feira, 11 de dezembro de 2019 13:47