Wendy Smoak wrote: > Stevenson, Charles wrote: > > The issue is this: the path to the index is hardcoded in the > > header of a > > data file. So if one uses OS-level, UV-unaware methods of > > moving files > > around, the wrong files point to the wrong indexes.
> Does UniData not suffer from this problem? We copy files > around all the > time and have not seen this behaviour. No, UniData does not have this problem because UniData does not store a path to the index file in the header of the data portion. On OPEN, UniData looks for correctly named index files (X_file for static files and idx00n for dynamic files) in the SAME directory as the data portion it has just opened. If indexes exist with the right names they are assumed to correspond to the data and are used, if they are not there then no indexes are used. HENDERSON MICHAEL MR wrote: > Glenn Herbert wrote: > [snip] > > > The way I really hoped would be implemented was to have the index > > files exist within the file subdirectory, i.e. all files with > > indexes would be similar in structure to Type30, but have a .index > > subdirectory within them. So, from then on, the indexes would be > > "tied" to the main data file. > > But then you wouldn't have the opportunity to put your data files and > their indexes on different spindles / channels / file systems to > maximise throughput by spreading I/O. > [ I know it's been a feature of Oracle since about release 8 that you > could separate 'tablespaces' from 'indexspaces' for exactly > that reason. > Wonder how they avoid the moving-file problem? ;-) ] Mike, Oracle avoids the file moving problem by not supporting it through non-Oracle aware mechanisms. You can't simply take a file which corresponds to all or part of an Oracle tablespace and relocate it. Rather, you can, but Oracle won't function afterwards. If you want to move a file from one place to another you have to use ALTER TABLESPACE or ALTER DATABASE commands. If you want to change the tablespace that is used for a particular table or its indexes then you need to use ALTER TABLE or ALTER INDEX. Moving on from this, you are right that the approach Glenn suggested above and the one taken by UniData precludes separating the indexes from the data (except via use of symbolic links at the OS level and I wouldn't recommend that). It is interesting to trawl through comp.databases.oracle.server or its archives looking for references to this commonly taught practise. Basically, real Oracle DBAs seem to firmly believe that separating indexes form data causes more harm than good as far as performance is concerned. Cheers, Ken ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
