Hopefully you followed the advice from the previous section and didn't create a database.
For most people, I can probably outline the process in a couple of words: "Run 'dbassist'." Unless this is the first time you've ever run Oracle, none of the questions should really phase you.
For completeness, I'll document what I did but I'd best say what I was aiming for first. Bottom line: this is neither a production system nor a 'serious' (i.e., several people, full time) development box. I installed 8i to play around and see what was new or different from 8 and older versions.
This means that when 'dbassist' offered an easy option I took it. And
when it suggested using a different disk, or at least a different
partition, I declined. My
/home/oracle. All the data files and software are in there,
all on one partition.
cd $ORACLE_HOME/dbsYou now need to edit a file called "init<SID>.ora" ("initdev1.ora" in my case). About half-way down the file is a commented out line looking something like this:
# rollback_segments = (r01, r02, r03, r04)Uncomment this line (remove the hash), save the file and you're done.
MANAGER'. (It seems to be conventional to put Oracle passwords in uppercase. In fact passwords are not case sensitive.) I recommend you change it straight away by typing
passwordat the SQL*Plus prompt. (For people expecting an
ALTER USERcommand, this is new to the version of SQL*Plus supplied with 8i.) The other password that you need to know is the one for SYS. It defaults to '
CHANGE_ON_INSTALL' and you should do exactly what it says!
sqlplus system/<password>). Then type:
@?/sqlplus/admin/pupbld.sqlThe question-mark is an alias for the
edso you do!). Open
$ORACLE_HOME/sqlplus/admin/glogin.sqlin your favourite editor and add
define_editor=<editor name>to the end.
And that's it. You should now have an operational database that you can log into using SQL*Plus.
Yes and no. If you're just playing around, building a database for yourself to learn the new features of 8i, then 'yes.' The database the above instructions will build is complete and will work fine.
However, if you know anything about Oracle, you will quickly realise that the default configuration is appallingly bad. If you're making a serious, production system I recommend you use the "Custom" option.
Even for my toy system I did some tweaking. I increased the sizes of most of the table-spaces and changed them so that they didn't grow automatically (I hate software when it tries to be too clever).
No and it will work fine if you don't, but I don't recommend putting all your files on the same disk nevertheless.
Spreading the files over a number of disks, even it's just the data files on one and the rollback segments on another, will have a significant performance advantage. Read an Oracle DBA book if you need further information.
Caused by several zero-length files in the initial installation. Following the patch procedure will fix this problem.
To cut a long story short, your
$ORACLE_SID is probably set
incorrectly or not at all. Make sure it's set to the same value you
gave 'dbassist' and that it's value is exported (i.e.,
ORACLE_SID in any Bourne compatible shell).
This is a very common error, and there are a number of different things that cause it.
Firstly you'll want to make sure that you're not creating a Shared Server configuration (sometimes known as MTS). Create a database using Dedicated Server and convert it later.
If that's not it, check your
NLS_LANG environment variable. The
easiest option is to unset it. If you really want to use it, make sure
that you have it exactly right. Make sure you don't transpose any '1's
(one's) for 'l's (the twelfth letter of the alphabet)!
'dbassist' won't let you create a datafile bigger than 1Gb. I believe this to be a bug as Linux has no problem with files up to 2Gb.
Note that does not limit the size of your database to 1Gb or less. A database is made up of many table-spaces which can be made up of many data-files. Talk to your friendly DBA for more information.
Recent versions of the Linux kernel allow applications to directly access the disks. Oracle is able to use this facility and can (sometimes) increase its performance.
Technically the answer is 'yes,' you can use raw files. But realistically the answer is 'no.' The performance improvement you'll get probably isn't worth the administrative overhead.