Disclaimer: I'm coming at this as an Oracle DBA, working with our SQL Server DBA.
Ran across this yesterday, and it's not making any sense at all.
Server is running Win Server 2008; SQL Server 2008 R2. Several linked servers to Oracle databases on other hosts. Let's call this system STG08
Server has system environment variable TNS_ADMIN set to a local directory. This tell Oracle where to look for his network config files, sqlnet.ora and tnsnames.ora. We changed this to reference a shared folder on another host, using a unc (\\myserver\tnsadmin). After restarting sqlserver, it started using the new tnsnames.ora to resolve database names. Fine.
But now we open Management Studio on my desktop (or my SQL Server DBA's desktop), open the very same STG08, and test the same linked server, and get 'ORA-12154: TNS: could not resolve the connect identifier specified'. This means it could not locate the specified database name in tnsnames.ora. (Something I've written about extensively at edstevensdba.com) It seems to both of us that the link server is defined within SQL Server running on STG08, so the connection to the oracle database should originate from there. So why would it matter where Management Studio is run from? We've also seen evidence of these connections being cached, and that cached entry being replaced with newer information after restarting SQL Server (sometimes), after rebooting the entire machine (either the server or the desktop), and sometimes simply by the passing of time.
Outside of the SQL Server environment, on the same STG08 server, the oracle tools (tnsping and sqlplus) behave exactly as expected - that is, any change in tnsnames.ora - the file itself or a reference to which file to be used - is reflected immediately on the very next connection attempt.
So at this point we are both baffled as to what is going on an hoping someone can shed some light.