November 1, 2001 at 10:51 am
I have some users who have requested that we provide a linked server connection from our development server to our production one. My initial thought was no way. I like to keep production separate and this would be a violation of that rule. But I thought I would throw the question out here for discussion, what would be the pros and cons of allowing a read-only connection for developers to be able to see into production from the dev server?
November 1, 2001 at 11:05 am
Depends how much you trust the developers. It is easy to crash a server or deadlock running transactions even with a read only connection (and you would have to be careful that you don't make a mistake and give update access ever).
Better to keep a copy of the production server somewhere for them to look at and refresh it from the backups daily.
Cursors never.
DTS - only when needed and never to control.
November 1, 2001 at 11:20 am
I agree with Nigel. In our company we have a test system which is created once a week from the backups of the test system. Considered replication, but don't want the extra load on the production server, and as backups are run twice a day, it has no issues for production.
Paul Ibison
email: Paul.Ibison@btinternet.com
Paul Ibison
Paul.Ibison@replicationanswers.com
November 1, 2001 at 11:25 am
One more in agreement with Nigel. Have an identical setup to what he described for the very reason that you don't know what type of read only querying is going to be done and I don't want the call when the production server gets buried.
The other nice side of this is that you don't have to worry about the trust relationship / permissions ever entering into the context of the discussion.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
November 1, 2001 at 12:11 pm
Ab-so-lute-leeee agree. NO WAY should developers be working with product, except as read-only to look for data.
Steve Jones
November 1, 2001 at 4:50 pm
A good thing about restoring the backup automatically is that you can run dbcc checks on it to find out if anything is dubious without impacting the live server.
Cursors never.
DTS - only when needed and never to control.
November 2, 2001 at 11:05 am
Generally we don't allow dev to prod linked servers even in the read-only case. However, we do have one significant exception and I am not proud of it. There is a history and a rationale, but that does not make it right. This particular resource system is key to any project that needs information about people, so it is heavily used.
I will get the chance in the next 60 days to make that particular project refresh their information to Test on a regular basis. Then I will get to crawl through numerous DEV boxes and get them to change their links from prod to test.
All this history should tell you that if you can hold the line then do. Otherwise, you may have to come back later and do an even bigger clean up job!
November 2, 2001 at 4:04 pm
I would agree that a copy of the data is better, but sometimes not practical. I think the read only linked server is not bad, but maybe unworkable depending on how your logins are set up. Probably better to give them a dev login to any db where they need read access.
Andy
November 5, 2001 at 10:32 am
I think that this has to do more with how much administration you want to handle. On our test system, we have linked servers to production. We often have several developers working on the same data, stored procs, tables, etc.. at the same time, If I were to refresh from production I would end up pissing off a lot of developer's. So, if someone wants to refresh information from production they can do it without me being involved. It is their test environment, and if they ruin it for another developer it's not my issue. They all know this, so they tend to watch each others back. I figure if they want it bad enough they could use an application ID to connect to get the information through access or the likes. I then have my time to look into server optimazation and other issues.
Tom
November 5, 2001 at 1:03 pm
I think you need 3 environments at a min. Prod, dev and a QA/staging area. Refresh QA and test before moving changes to production. Reffresh dev rarely and be sure everyone saves their items.
everyone should know what changes they have made on dev so things can be moved to production easily.
Steve Jones
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply