Does anyone know of a good way to transfer SQL Server database to Oracle db,
(structure and data)?

Thanks

Alex


----- Original Message -----
From: "Robertson-Ravo, Neil (RX)" <[EMAIL PROTECTED]>
To: "SQL" <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 2:35 PM
Subject: RE: Data storage best practice


>
> Yep, but you would be suprised.  I am working on app here (3rd party)
which
> has probably not only the worst codebase I have ever seen, but also the
> worst Database design......the simple things like indexes have been left
> out..
>
> n
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 21 January 2003 14:31
> To: SQL
> Subject: RE: Data storage best practice
>
>
> All of these should be done in the design phase, prior to production, for
> that very reason.  Index design is the final phase in database design, not
> the first phase of troubleshooting.
> "Whenever I hear the word culture, I reach for my revolver."
> -- Hermann Goring
>
>
>
>
> "Robertson-Ravo, Neil (RX)" <[EMAIL PROTECTED]>
> 01/21/2003 08:37 AM
> Please respond to sql
>
>
>         To:     SQL <[EMAIL PROTECTED]>
>         cc:
>         Subject:        RE: Data storage best practice
>
>
> note : you will have a problem when you want to create a clustered index
> on
> an already populated table.... you have to copy the data out, truncate,
> create clustered index and then copy the date back in.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 21 January 2003 13:24
> To: SQL
> Subject: RE: Data storage best practice
>
>
> For anyone else that might find it useful, I was taught to create my
> indices this way:
>
> 1.  Declare primary key constraints.  In some DBMS's, the primary key
> constraint is automatically created as a clustered, unique index.  In SQL
> Server, you can choose whether to make it clustered or not.  Regardless,
> your primary key column(s) are always indexed.
> 2.  Declare unique indices on alternate keys.
> 3.  Declare clustered indices on tables for whose columns you will have a
> large number of rows and where you can clearly define the columns as
> having a wide range of queries.
> 4.  Declare non-clustered indices on tables where you have non-key columns
>
> that will be part of ad hoc joins.
> 5.  Test and tune your index scheme by populating the dB with test data of
>
> the appropriate scale, starting a trace, and then running a battery of
> stress tests against the dB.  Microsoft's index tuning wizard can help in
> this process, but cannot substitute for raw benchmarking.
>
> If you put it off long enough, it might go away.
> -- Unknown
>
>
>
> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=6
Subscription: 
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=6
Signup for the Fusion Authority news alert and keep up with the latest news in 
ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm

                        

Reply via email to