Re: 10g new features (was: dc_used_extents ,dc_free_extents

Hi!

> Tanel,
> Thanks for sharing the presentation in the 10g features.
> I started looking at the slides and I have a question about the "cross
> platform transportable tablespaces" and the command you used.
> From what I gather in the command I can take a Unix based datafile and
> convert it to a "Microsoft Windows NT"
> format just by quoting the destination OS type and version? Then
> basically I have to copy the converted datafile to the new OS and
> recognize the datafile by the new OS to have to data available? How is
> this possible? the different OS's use different storage (fat's, inodes)
> unless it converts it into a common format like ASCII. Do you have to
> perform and "conversion" on the new OS when the file is copied over? For

No, contents of a file are just a sequence of bytes. No fats, no inodes. These are file system internal mechanisms to keep track about file chunks on a device. As I understand, convert tablespace does just little-endian to big-endian conversion (or vice versa) for appropriate datatypes, maybe something in the datafile header as well.

> query purposes why not use a DBLINK? I think it would be faster. I can
> understand some complicated actions and wanting to keep the data
> separate between platforms or if you wanted to migrate between
> platforms. Other than that reason I am finding it difficult to
> understand the full advantage for this feature.

You might be right, direct load inserts over dblinks can be quite fast and they don't require intermediate storage+disk IO capacity for transferring data. But within SAN environment you can just mount your device with converted file elsewhere, here we might have more benefit from transportable tablespaces. I depends on environment, which method will be faster for data transfer, I think. Also, 10g's data pump with it's direct read & load capabilities will change the picture.

>
> I think that the online segment shrink is a nice feature but as I
> understand the feature, it requires the use of RAW devices. Is this
> correct? The RAW device must have a portion of the disk allocated for
> the max size file before the shrink or else the disk could be clobbered
> by creating a file on the device.

No, the segment is shrunk within Oracle datafile, it doesn't matter on which storage layer they lie.

> No SQLPLUSW for windows? Is this because of a browser based access to
> the sqlplus function?

SQLPLUSW was quite crappy, I've never used it anyway, regular sqlplus on cmd.exe will do the job just fine.

Tanel.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tanel Poder
  INET: tanel.poder.003_at_mail.ee

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).