Web Development

Ask something
Discussion Locked

Oracle Unix Questions

0 helpful
5 replies

by maria.olivero

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I have two large unix boxes running oracle, one in production and one for development. The application is a couple of million lines of C that commicates with another couple hundred thousand lines of PL/SQL (three schemas and about 50 packages in each).
1) Can anyone recommend a version control solution for the PL/SQL code? (Even Oracle's source control system wants to export the source to flat files and then control those - I would like to aviod that if possible.)
2) How can I keep the data set on the development box in sync with production? An export is going to include the packages and I don't want ongoing development work to be overwritten.
Thanks,
Maria

5 replies

by jaqui

1) I use cvs, though going to look at subversion soon.

2) set both servers to talk to each other and sync the data.

personally, unless the production server is really slwo due to volume, I would just use one server.
using the client apps for production and development tools for development wouldn't conflict on same server and db. ( as long as the development isn't altering the data. for the you need a test server, which you can export as needed using development tools from a combined server, no loss of data. )

by jaqui

cvs is a flat file rather than integrated into oracle, so it's not really what you want.
subvrsion is also.

rcs, as next poster mentions is also flat file, with no support for multiple users, so may not work for you even if you do choose to go flat file.

since your development server needs to be able to alter the testing db, the best way to keep the development db in sync with the production db would be to run a script on it that would back the production db up into it.
( development server as read only client to production server. )

this process is essentially copying the db, structure and data into a new db.

the benefit of duplication means you can just erase the development data and not loose anything.
assuming that the scripts are being stored separately rather than in the database containing the data to be used.
ie:
dbserver
db1 scripts
db2 data
same on both servers.
or, my personal choice:
dbserver1
db1 procuction scripts
db2 production data
db3 development scripts
db4 development data ( copy of production data )

dbserver2
backup of production scripts / data
backup of development scripts
server2 running a script daily ( at worst )hourly ( at best ) to back the production data so that there is a reduced risk of downtime.
server2 running a constant script testing for server1 function.
server1 goes down server2 kicks in automatically so downtime is measured in seconds. with only an hours lost data to really worry about.

by jaqui

you could also use the client software to send the data to both servers whenever updating the production server

this would mean if it goes down and you have used my preffered config, you only lose minutes of data at worst.

the only time you need to keep development and production completely separate as servers is when the production server is being hit with 10,000 transactions a minute
any less and it can serve both without signifcant loss of performance.
and a net gai in function with the backup ready to roll instantly.

by j.lupo

1) I have used unix RCS and some proprietary stuff. Primarily because we wanted to control branching from baseline for version releases and such.

2) I think was answered by the previous poster.

by john_miller_portland

I will answer on your second question. You can use selective extract / unload of Oracle data into flat csv files from source database. Then use sqlloader to load data into target database.
If you have large database or willing to automate the process you may want to look into product like Fastreader from wisdomforce http://www.wisdomforce.com
fastreader is a high performance Oracle data extract and load software which creates input for loader and also provide with fast compression on the fly.

This discussion is closed to new replies.