Manual layout of Sol10 - Solaris
This is a discussion on Manual layout of Sol10 - Solaris ; Still I need advice or right and specific figures of manual layout of
160 GB HardDrive ,and that layout is suitable ofr future installs.
Please give me number for each slice to not be forced to reinstall
Sol10 again . ...
-
Manual layout of Sol10
Still I need advice or right and specific figures of manual layout of
160 GB HardDrive ,and that layout is suitable ofr future installs.
Please give me number for each slice to not be forced to reinstall
Sol10 again . And , if there is an installer can handle that problem
pls give me URL of downloading it .
Thanks in advance
-
Re: Manual layout of Sol10
In comp.unix.solaris ehabaziz2001@gmail.com wrote:
> Still I need advice or right and specific figures of manual layout of
> 160 GB HardDrive ,and that layout is suitable ofr future installs.
> Please give me number for each slice to not be forced to reinstall
> Sol10 again . And , if there is an installer can handle that problem
> pls give me URL of downloading it .
> Thanks in advance
Well in the thread you started previously, there was a great long discussion
about this matter. If you read through that, you should discover that the
only real answer is, "it depends." It depends on what the machine will be
used for, how much data will be on it, whether user directories are on this
machine locally or automounted from somewhere else, on how much extra
software you intend to install, and also on your personal philosophy of disk
space allocation.
How would you LIKE to lay it out? If you present something, people can
critique it, and let you know if you're going down a wrong path.
Colin
-
Re: Manual layout of Sol10
Let say for Oracle application ?
-
Re: Manual layout of Sol10
s0 / what ever the minimum is +1gb
s1 swap usually double your internal memory
s3 /var 2gb
s4 /oracle ever how much you feel you will need for application
s5 /data anything that is left from the drive
s6 empty slice, same size as your root to allow for live
upgrade
s7 /export/home probably only need about 20gb
This would allow you lots of options
Group, feel free to critique this.
I don't usually put /var and /export/home seperate, but in his case, it
might be best.
wrote in message
news:1143984401.164244.292540@u72g2000cwu.googlegr oups.com...
> Let say for Oracle application ?
>
-
Re: Manual layout of Sol10
In comp.unix.solaris ehabaziz2001@gmail.com wrote:
> Let say for Oracle application ?
And what is your hardware?
When you say "Oracle Application," do you mean a database-backed application,
or Oracle itself (which would make this a database box)?
There's no way I would put a database on an OS disk in anything other than
a playground for myself. Also, Oracle makes some very strict demands on what
is required for swap space, so my thought would be:
/ s0 20GB
s1 Whatever Oracle recommends
overlap s2 (whole disk)
/var s3 10GB
metadb s7 >24MB (massive overkill)
....and if home directories are going to be on the local disk,
/export/home s4 (remaining disk less 20GB)
Then put Oracle on an external disk.
-
Re: Manual layout of Sol10
Colin B. wrote:
> In comp.unix.solaris ehabaziz2001@gmail.com wrote:
>
>>Let say for Oracle application ?
>
>
> And what is your hardware?
>
> When you say "Oracle Application," do you mean a database-backed application,
> or Oracle itself (which would make this a database box)?
>
> There's no way I would put a database on an OS disk in anything other than
> a playground for myself. Also, Oracle makes some very strict demands on what
> is required for swap space, so my thought would be:
>
> / s0 20GB
> s1 Whatever Oracle recommends
> overlap s2 (whole disk)
> /var s3 10GB
> metadb s7 >24MB (massive overkill)
>
> ...and if home directories are going to be on the local disk,
> /export/home s4 (remaining disk less 20GB)
>
> Then put Oracle on an external disk.
>
Shouldn't the Oracle executables be put in /opt?
The database itself should normally be spread over five or more
spindles. Don't put both a table and its indices on the same drive and
put redo logs on a disk by themselves.
Oracle makes some very specific recommendations for allocating disk
space. If you need to ask, find those recommendations and obey them as
if they were holy writ! You can break the rules if the data base is
small, simple, and performance is not terribly important but, if that is
the case, why are you using Oracle?
-
Re: Manual layout of Sol10
In comp.unix.solaris Richard B. Gilbert wrote:
> Colin B. wrote:
>> In comp.unix.solaris ehabaziz2001@gmail.com wrote:
>>
>>>Let say for Oracle application ?
>>
>>
>> And what is your hardware?
>>
>> When you say "Oracle Application," do you mean a database-backed application,
>> or Oracle itself (which would make this a database box)?
>>
>> There's no way I would put a database on an OS disk in anything other than
>> a playground for myself. Also, Oracle makes some very strict demands on what
>> is required for swap space, so my thought would be:
>>
>> / s0 20GB
>> s1 Whatever Oracle recommends
>> overlap s2 (whole disk)
>> /var s3 10GB
>> metadb s7 >24MB (massive overkill)
>>
>> ...and if home directories are going to be on the local disk,
>> /export/home s4 (remaining disk less 20GB)
>>
>> Then put Oracle on an external disk.
>>
>
> Shouldn't the Oracle executables be put in /opt?
Depends on the particulars of the site. Our Oracle binaries are in their
own directory, but on local disk at any rate.
> The database itself should normally be spread over five or more
> spindles. Don't put both a table and its indices on the same drive and
> put redo logs on a disk by themselves.
>
> Oracle makes some very specific recommendations for allocating disk
> space. If you need to ask, find those recommendations and obey them as
> if they were holy writ! You can break the rules if the data base is
> small, simple, and performance is not terribly important but, if that is
> the case, why are you using Oracle?
Agreed. There are certain situations where breaking the rules makes clear
sense, but you REALLY need to know what you're doing, if you don't want to
mess things up.