Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Copy Tables from Development Server to Production Server

Status
Not open for further replies.

oracle8

MIS
Sep 30, 2000
69
PH
Hi!

Please give me the best idea on the following :

1. How to copy Tables from production to development server.

2. Will the Table constraints, triggers, indexes and privileges be copied together with that table being copy from development to production server? If Yes, How. If No, what is your best advice.

Thank you very much

Rommel

 
I know this is not really the answer to your question, but even after someone helps you copy these over, I suggest that you save a copy of the SQL that was used to create these tables, indexes, etc.

The company I work for has a fairly large Oracle database application and wanted to create a copy of it on a fail over server. I was tasked to recreate this database, from scratch, by doing describes, queries on the Oracle system tables, etc. It was not fun. Another instance that I manage, I have all the scripts that were used to create every table, every index, etc. If it ever crashes, I can recreate the structure in no time.

Just a suggestion...


Terry M. Hoey
th3856@txmail.sbc.com

Ever notice that by the time that you realize that you ran a truncate script on the wrong instance, it is too late to stop it?
 
Recommend you export the tables, triggers, etc from the production db and import them into your development db. Explicit details are found in the Server Utilities manual.
 
i hesitate to tell you this terry -- but you can get [tt]exp[/tt] to give you a textfile containing a database creation script...
Mike
michael.j.lacey@ntlworld.com
 
Thanks for the info Mike. Next time I have to do something like that, I will look at the export tool.

Don't hesitate to tell me anything, I am still learning. But, they also didn't like me getting too close to that server. Paranoid bunch that they are. It might be because that system is where I got my "bye line" from. Took it down for 6 hours... Not a good thing.

Terry M. Hoey
th3856@txmail.sbc.com

Ever notice that by the time that you realize that you ran a truncate script on the wrong instance, it is too late to stop it?
 
Thanks guys for those excellent ideas.

Can you still give me an idea on what will happen if i copy tables to a different tablespace? Do table triggers, indexes, etc. be copied also?

Thanks again
 
Terry,

I only hesitated to tell you because of all the time you've already invested doing it a slower way -- when someone tells *me* something like that my desk ends up with some more dents in it (from my head <wry smile>)

The truncate script thing -- not done *that* one, (yet, that is) but did once run a restore script on a live server, when I had intended to run a backup script....... So the associated 'sick' feeling is a sort of famliar one.
Mike
michael.j.lacey@ntlworld.com
 
Well, just because I did it the hard way once, doesn't mean I have to do it again that way. And with as often as we move offices, I get a new desk to add dents to all the time.

I once found a web page that had &quot;true DBA tragedy&quot; stories. Looking through them, there were several I said I would never do. I don't think truncating tables on the Production server was listed. No one would do that...
<s>

Terry M. Hoey
th3856@txmail.sbc.com

Ever notice that by the time that you realize that you ran a truncate script on the wrong instance, it is too late to stop it?
 
What th3856 said in thr firts place about having an object creation script is the safest and most practical solution. I assure that this the method mostly used by DBAs. The data can always be imported.

Regards
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top