From: C'est Pierre (cestpierre_at_gmail.com)
Date: Fri Oct 13 2006 - 12:05:27 CEST
Message-ID: <5485940d0610130305s2cf24a4fg448540f0e8b7811d@mail.gmail.com> Date: Fri, 13 Oct 2006 11:05:27 +0100 From: "C'est Pierre" <cestpierre@gmail.com> Subject: Re: [suse-sles-e] Re: [suse-oracle] Re: [suse-sles-e] Re: [suse-oracle] Raw Devices
Thanks to all who replied to my questions!
Our dba decided to go with LVM until ASM is more "stable", he says.
Thanks to all!
Pierre
On 10/11/06, Didier Boiteux <dboiteux@novell.com> wrote:
> Pierre,
>
> The SLES9 kernel included in SP3 was indeed 2.6.5-7.244 on 12th Dec 2005.
> (See http://www.novell.com/products/server9/packages.html
> or from the INDEX.gz on the SP3 CD)
>
> Many news kernel patches have appeared since then.
> Here is a useful link to find easily all the rpm patches (like for the
> kernel):
>
> - For the "core" packages:
> For x86_64: -> for the kernel ones
> https://you.novell.com/update/x86_64/update/SUSE-CORE/9/rpm/x86_64/
> - For the specific SLES
> For x86_64:
> https://you.novell.com/update/x86_64/update/SUSE-SLES/9/rpm/x86_64/
>
> YouŽll find the 2.6.5-7.257 there.
> (In case you wonder, the difference between the core and SLEs pacakges comes
> from the United Linux experience so that the core packages would be shared by
> all United Linux distributions...)
>
>
> You can also look at the Patch Support DataBase (PSDB) at
> http://support.novell.com/linux/psdb/byproduct.html
> and look for SLEs9 x86_64, and then search for "kernel", but it is slightly
> longer...
>
> For example, at present, the latest is 2.6.5-7.282 (patch-11193).
>
>
> -+-
> Didier
>
>
> On Tuesday 10 October 2006 12:09, C'est Pierre wrote:
> > Hello all!
> >
> > Sorry for the late reply, but I had a few other tasks to solve in between.
> > We're going to try the lvm + raw approach. Any issues?
> >
> > In case of failure, we'll resort to OCFSv2. I've been to Oracle's OCFS
> > page and they say we require SLES 9 SP3's kernel 2.6.5-7.257. However,
> > my SP3 iso, downloaded from Novell's website, has these files:
> >
> > ./x86_64/update/SUSE-CORE/9/rpm/x86_64/kernel-source-2.6.5-7.244.x86_64.rpm
> > ./x86_64/update/SUSE-CORE/9/rpm/x86_64/kernel-syms-2.6.5-7.244.x86_64.rpm
> > ./x86_64/update/SUSE-CORE/9/rpm/x86_64/kernel-default-2.6.5-7.244.x86_64.rp
> >m ./x86_64/update/SUSE-CORE/9/rpm/x86_64/kernel-smp-2.6.5-7.244.x86_64.rpm
> >
> > Any ideas?
> >
> > Thanks,
> > Pierre
> >
> > On 10/9/06, Alexei_Roudnev <Alexei_Roudnev@exigengroup.com> wrote:
> > > I think, that your DBA tried to do a bad thing - change disk size on SAN
> > > system and then resize ASM device., It don';t work because Linux don't
> > > see new size if disk is mounted by any way.
> > >
> > > You should not
> > > - use ASMLib, it is a piece of garbage.
> > > - don't try to resize disk when ASM device is full.
> > >
> > > You should, instead, ADD new disk into the group, when previous one is
> > > filled in (and system will redistribute ASM files), OR add new
> > > ASM disk group and assign new datafile into the tablespace.
> > >
> > > OCFSv2 is a controvercial thing - it is fine when it work, buit it adds
> > > an element of instability. I;d better use NFS for backups, but we are
> > > runnimng OCFSv2 in the lab for low-performance file systems (archive logs
> > > and backups) and it works fine (if we have not infrastructure failures).
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "C'est Pierre" <cestpierre@gmail.com>
> > > To: "Fabrizio Magni" <fabrizio.magni@gmail.com>
> > > Cc: <suse-oracle@suse.com>; <suse-sles-e@suse.com>
> > > Sent: Monday, October 09, 2006 8:41 AM
> > > Subject: [suse-sles-e] Re: [suse-oracle] Raw Devices
> > >
> > > > Hi Fabrizio,
> > > >
> > > > We skipped the option of using ASMLib on this cluster. Our dba said it
> > > > had a limitation (or bug) when a tablespace (or was it raw device?)
> > > > filled up, they couldn't extend the size anymore. This is a migration
> > > > database, so they'll need lots more space than we already have in the
> > > > long run.
> > > >
> > > > We're using RAC and raw devices only, from what he said. An
> > > > alternative in mind is OCFS.
> > > >
> > > > Any thoughts?
> > > >
> > > >
> > > > Thanks,
> > > > Pierre
> > > >
> > > > On 10/9/06, Fabrizio Magni <fabrizio.magni@gmail.com> wrote:
> > > > > Hi Pierre,
> > > > > just personal curiosity: what's the advantage to have 47 partition on
> > >
> > > the
> > >
> > > > > same disk?
> > > > > If you are still using the ASM then you can simply use a single
> > >
> > > partition
> > >
> > > > > (or device).
> > > > > Tablespaces are already divided inside that device optimizing the
> > > > > space usage.
> > > > >
> > > > > Regards
> > > > > Fabrizio
> > > > >
> > > > > On 10/9/06, C'est Pierre <cestpierre@gmail.com> wrote:
> > > > > > Hello all,
> > > > > >
> > > > > > First, I am sys-administrator, not a DBA, so excuse me if I am no
> > > > > > precise with some tech. aspects of Oracle.
> > > > > >
> > > > > > I am in the process of installing a new RAC cluster. Our previous
> > > > > > one, went smoothly, but we used ASMLib, which we aren't using now.
> > > > > > Problem: I created 47 partitions on a scsi disk presented to the
> > > > > > server thru a fibre channel card. These are sda1 thru sda47.
> > > > > > However, only the 15 first (except one, which is the extended one -
> > > > > > sda4) are usable.
> > > > > >
> > > > > > I wrote the /etc/raw, mapping sda's to raw's just as the dba
> > > > > > sugested for organizational purposes (they aren't sequential, e.g
> > > > > > raw51 maps to sda28).
> > > > > >
> > > > > > I then made this line of bash to create all device nods that
> > > > > > weren't there (and even those that were...just in case):
> > > > > >
> > > > > > for i in `seq -f %g 1 47`; do echo mknod sda$i b 8 $i ; done
> > > > > >
> > > > > > Problem: I can't access past sda16, I get this error:
> > > > > >
> > > > > > dd: opening `/dev/sda16': No such device or address
> > > > > >
> > > > > > when I look at dmesg and /proc/partitions, I only get to see the
> > > > > > first 15 partitions there (or 16, if you count with 'sda')
> > > > > >
> > > > > > sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11
> > > > > > sda12 sda13 sda14 sda15 >
> > > > > >
> > > > > > I've googled for this problem and it seems there's a limitation on
> > > > > > scsi disks of 16 partitions per device. Is this true? if so, what
> > > > > > is the solution for this problem? how can I make 47 raw partitions?
> > > > > >
> > > > > > I can still ask our storage administrator to divide this disk into
> > > > > > several disks and then we will group partitions 16 partitions on
> > > > > > each, but this isn't a good solution. Another alternative solution
> > > > > > which our dba presented, was adding ocfs 2 support and make it
> > > > > > dance with the devil by the pale moonlight ;-)
> > > > > >
> > > > > > Let me know your thoughts and especially solutions!!
> > > > > >
> > > > > > Also, your thoughts on ocfs or not as a side note would be
> > > > > > apreciated.
> > > > > >
> > > > > > Thank you
> > > > > >
> > > > > > Pierre
> > > > > >
> > > > > > P.S: I'm not french but I love french bread! ;)
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, email: suse-oracle-unsubscribe@suse.com
> > > > > > For additional commands, email: suse-oracle-help@suse.com
> > > > > > Please see http://www.suse.com/oracle/ before posting
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
> > > > For additional commands, e-mail: suse-sles-e-help@suse.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
> For additional commands, e-mail: suse-sles-e-help@suse.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Fri Oct 13 2006 - 12:05:55 CEST