[SQL2008R2]Oracle Linked Server icm TNSnames op netwerkshare

[hellknight]

Even een korte situatieschets: de database voor ons ERP systeem draait op een Oracle-database, daarnaast
hebben we een MS SQL Server 2008R2 omgeving welke voor ETL/reporting/etc gebruikt wordt.
Vanuit deze SQL server omgeving zijn er 2 applicaties welke connectie met de Oracle db moeten maken:
- SQL Server Management Studio, middels een Linked Server (SSMS)
- SQL Server Business Intelligence Development Studio (BIDS)
Beidde maken gebruik van de "Oracle Provider for OLEDB"

Momenteel wordt er nog gebruik gemaakt van een lokale TNSNames.ora file op de SQL server. Er zijn momenteel wat infra-wijzigen gaande/gepland welke niet altijd tijdig naar ons team gecommuniceerd worden, waardoor het al eens is voorgekomen dat de test/acceptatie omgeving van de Oracle database opeens naar een andere (virtual) server verhuist was, waardoor wij geen verbinding meer konden maken.
Er is ook een TNSNames file welke door het ERP team beheert wordt, deze bevind zich op een netwerkshare. Deze wordt bij iedere infra-wijziging ge-update.

We willen dan ook de settings zo aanpassen dat de OLEDB connecties gebruik maken van deze centrale TNSNAMES, ipv de lokale.

Ondertussen heb ik het half werkend: BIDS maakt gebruik van de centrale TNSNAMES file.
SSMS lijkt echter niet van plan mee te werken - zowel de bestaande linked server, als eventueel nieuw aangemaakte linked servers, naar de Oracle DB blijven de locale TNSNAMES gebruiken.

Wat heb ik gedaan:
- Environment variabele TNS_ADMIN aangemaakt, welke naar de directory op de share verwijst waar de TNSNAMES zich bevindt.
- TNS_ADMIN key in het register aangemaakt, met als waarde de directory op de share waar de TNSNAMES zich bevindt.

in command promt geven zowel

code:

echo %TNS_ADMIN%

als

code:

TNSPING /?

de juiste directory op de share als output.
Hier loop ik echter vast - ik heb geen idee wat ik nog kan aanpassen om te zorgen dat de linked server in SSMS gebruik gaat maken van de centrale TNSNAMES.

Heeft er iemand enig idee hoe ik dit kan oplossen?

[demokert]

Hoi Hellknight,

Het probleem is dus dat jullie niet tijdig op de hoogte worden gebracht als een server verhuisd.
Ik ben van mening dat je het dan niet op een "ingewikkelde" manier moet oplossen maar het voor altijd gemakkelijk moet maken.

Ik zou voorstellen om van die server een alias te maken en deze in je linkedserver te gebruiken. Op deze manier hoef je enkel het DNS record aan te (laten) passen en heb je er verder geen omkijken meer naar.

[hellknight]

Je hebt (deels) een punt, maar de vraag blijft staan ;-)
Zolang we met een lokale TNSnames werken, zal er altijd iemand van ons team handmatig op iedere server (DEV, ACC en PROD) de TNSnames moeten aanpassen wanneer er iets veranderd. De policy is dan ook dat er, om te verbinden met de ERP databases, gebruik wordt gemaakt van de centrale TNSnames file.

Als er enkel een server verhuist, is dit geen issue - er wordt reeds gebruik gemaakt van een alias. Wanneer de databases ZELF echter verhuizen naar een andere server, zoals onlangs gebeurd is, helpt dit niet.

[demokert]

Alias per database? Het is niet DE oplossing maar vergemakkelijkt wellicht wel een hoop.

[ Voor 64% gewijzigd door demokert op 22-05-2013 16:02 ]

[Remco]

Je kan je tnsnames toch simpelweg op het netwerk zetten? Dat hebben wij hier ook zo gedaan. Alle clients maken gebruik van de centrale tnsnames.ora. Een wijziging maken is dan relatief simpel gedaan.
Niet goed gelezen....

[ Voor 7% gewijzigd door Remco op 22-05-2013 17:39 ]

[hellknight]

demokert schreef op woensdag 22 mei 2013 @ 16:01:
Alias per database? Het is niet DE oplossing maar vergemakkelijkt wellicht wel een hoop.

Ik begrijp even niet hoe dit de zaken makkelijker kan maken. Zover ik weet kun je enkel DNS entries op naam of IP van een computer (server/client) maken, en niet voor zaken, zoals een database, welke op een machine aanwezig zijn. Daar is, in het geval van Oracle, de TNSNAMES voor.

[demokert]

Ik zat al te wachten op die vraag en had hem eigenlijk al gelijk moeten toelichten.
Het klopt dat je die enkel op IP of computernamen toe kan wijzen. Bij het bedrijf waar ik werk wil men dat we per database een alias maken (dus eigenlijk voor die machine) Dit maakt het migreren van die database een stuk makkelijker zodat enkel de DNS voor die database hoeft worden aangepast. Op deze manier hoeft men niet in config files te duiken etc.

Maar ik begrijp je probleem helaas zit ik voornamelijk in SQL Server en (te) weinig in Oracle. Mocht je er alsnog uitkomen post hier je oplossing aub.

[hellknight]

Mocht ik een oplossing vinden, dan zal ik die zeker hier melden. Toch alvast bedankt voor het meedenken.

Het probleem lijkt echt in SQL Server te zitten, in de werking van de Linked Server, of de samenwerking tussen deze en de Oracle OLEDB provider - aan de oracle-kant staat alles goed, TNSADMIN variabele, etc, kloppen. Ook Visual Studio (BIDS) werkt goed(deze kijkt netjes naar de netwerk TNSNAMES).
Alleen de Linked Server, welke we voor de handmatige checks, etc, gebruiken, vertikt het...

[demokert]

Wij hebben zelf amper Oracle > SQL Server integratie, dit gebeurt in een enkel geval bij ons. Die maakt overigens nog gebruik van een verouderde provider zonder problemen overigens. Heb je al eens overwogen een topic te maken op de MSDN fora of te zoeken, wellicht heeft iemand ooit eerder het probleem ervaren.

[hellknight]

Ik wilde het eerst even hier op Tweakers proberen, maar ik ga inderdaad maar eens een topic op MSDN maken.

[hellknight]

Topic op MSDN heeft ook weinig geholpen, maar het lijkt erop dat we zelf een oplossing gevonden hebben:

Het bleek dat naast te Linked Server. ook de SQL Server Agent packages, welke we gebruiken om de BIDS packages scheduled te laten draaien, zich niets van de TNS_ADMIN variabele aantrekken, en enkel met een lokale TNSNames werken.

Ik ben toen op het idee gekomen om de lokale ..\network\admin directory te vervangen door een symlink naar de admin directory op de share, waar de juiste TNSNames in staat.
Voorlopige conclusie: het werkt. TNSPING kan de database niet resolven, maar de Linked Server functioneert, en packages handmatig vanuit BIDS draaien ook. Enkel de SQL Server Agent packages moet ik nog testen op de ACC omgeving, daar we deze op DEV niet gebruiken.

Niet de meest nette oplossing misschien, maar het lijkt te werken

Update: Helaas, SQL Server Agent is nog eigenwijzer dan de Linked Server - het werkt niet - hij kan de TNS entry niet resolven.

[ Voor 7% gewijzigd door hellknight op 09-07-2013 15:59 ]