Re: Samba and 10g - and NT
- From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
- To: niall.litchfield@xxxxxxxxx
- Date: Mon, 22 Nov 2004 20:26:45 +0100
Howard,
This was the discussion during the tech forum session, wasn't it? Sorry
for not responding earlier, I was at a customer's site today.
First let's try to reconstruct the path you're following right now, and
define some constants to refer to during the rest of this thread:
The original database (I say: D1) is running on NT, with instance,
executables and data sitting nicely together on NT.
You created a second database, named D2 for now. The instance of D2 runs
on NT, the database resides on a Linux box, using CIFS (Samba) for the
connectivity.
The final database (let's call it D3) will have it's instance on Linux,
as well as the datafiles.
You want to export D2. Purpose is importing the exportfile in D3.
D1 is 9.2.0.4
D3 will probably be 10.2.0.3
What version is D2? Did you upgrade D1 to 10 on NT? Or is it just a
9.2.0.4 copy on NT?
If it's 10g you don't need the export. You can transport the
tablespaces. If it's 9i you don't need the copy. You can export from D1.
BTW, I don't know whether accessing databasefiles through CIFS (and the
Samba implementation of it) is actually supposed to work. It's a long
time ago I created a database on some Windows platform, and I never had
database files accessed through a share. Maybe it is supported, but it
is not unlikely that you have to take care of some special Samba
configuration settings to run this. I'm not surprised if this causes
your export to fail.
During the discussion we came up with some possible scenarios, IIRC:
1.
Upgrade D1 from 9i to 10g, on the NT box
Create a D3 (10g) on Linux
Use the 10g capabilities for cross platform transportable tablespaces to
import the (upgraded) D1 tablespaces to D3
2.
Create D3 on Linux (10g)
Export D1, eventually in several parts. You can export the 'static' data
(lookup tables, historical data) with some fine-grained export scripts,
using the proper where clauses, and import this in D3
Finally, during some downtime, you export the rest of the data from D1,
and import this in D3
This scenario requires no D2.
Where does this theoretical model meet your actual situation? If we
know, we might be able to help you further.
Best regards,
Carel-Jan Engel
===
If you think education is expensive, try ignorance. (Derek Bok)
===
On Mon, 2004-11-22 at 17:45, Niall Litchfield wrote:
> On Mon, 22 Nov 2004 15:47:28 +0100, Eric Buddelmeijer
> <eric.buddelmeijer@xxxxxxxxxx> wrote:
> > The reason 10g came into play probably is because that is the version that
> > supports OS transportability without export/import. Staying with 9.2 means
> > IMHO the downtime to do the export/import.
>
> I think that was why we ended up heading off in that direction.
>
> I'm a bit intrigued though - because IIRC exp was dying on the NT box
> anyway, I'm beginning to wonder about the integrity of the existing
> database files, given this (maybe wayward) recollection and the
> corrupt blocks you are getting doing it this way.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
