Are there issues when using RAW dbspaces on IDS 11
A DBA wanted RAW dbspaces for IDS 11.5 on SLES running under VMware ESX, but his sysadmins objected, claiming ESX host tools might misuse unformatted raw devices, that raw space wouldn't fit their VM backup strategy, that the performance gain was trivial, and that a journaled filesystem was safer. Respondents (Jonathon Wyza, Art Kagel, Fernando Nunes) said ESX doesn't care about raw devices, OS-level backups of chunks are useless anyway (use ontape/onbar or external backup mode), raw gives roughly 10-20% better I/O, and filesystem journaling is redundant with Informix's own logging and hurts performance (plus warnings about VM I/O overhead, EXT4 write-back and RAID5). Links to IBM 'Chat with the Labs' virtualization material were also given. The poster used the arguments in his meeting; the remaining open question was whether Linux tools like YaST inside the VM could interfere with raw logical volumes, which is left unanswered.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
HELP! Here is another angle to the recent questions, and explanations by Art, et. al, regarding using RAW instead of COOKED dbspaces on IDS 11.5 running on Linux. For reasons cited by Art and the others, I (the DBA) wish to use RAW dbspaces when I move my instances to Linux (SUSE 11 SLES) Virtual Machines on an ESX Server running VMWare. But my Sys Admins here are refusing to allow RAW spaces and citing all kinds of vague, generalized reasons why, such as: 1) the "host administration utilities" will not fly right with Raw Spaces but will not be specific about what would go wrong. In general, my sense is that they feel that the Management Console and Tools for the ESX host might see the Raw Dbspace and, because it does not contain not a formatted filesystem, allocate it to something on the box. 2) using raw space will not allow the VMs containing the IDS dbspaces to be backed up or fit into their backup strategy and backup utility. They cannot seem to understand that a normal backup utility would not know how to deal with the dbspaces even if they were Cooked. 3) that the "little bit" of performance that they claim I might get with Raw will not pay back for the increased Sys Admin overhead. 4) that they will use a Journaled File System (along with Cooked dbspaces) because it is more robust, fault-tolerant, comes back up quicker after a crash, etc. Can anybody provide me with any concrete information/experience that is related to the above points, particularly (1) . Does anyone know if raw dbspaces can cause problems in a Virtual Machine on a VMWare ESX Server. If you have some info and have time to send it soon, that would be appreciated because I am about to do battle over this with our Sys Admins. Thanks much in advance, Jim Cramer Database Administrator and Applications Developer III University of Iowa College of Engineering Engineering Computer Systems Support 1256 SC Iowa City, Iowa 52245 (319)-335-5757 jim-cramer@uiowa.edu jcramer@engineering.uiowa.edu http://css.engineering.uiowa.edu http://www.engineering.uiowa.edu http://www.uiowa.edu
1) That makes 0 sense. Although you will be using raw spaces, the drives
themselves are allocated by the host for the client to use in any way it sees
fit, just have them allocate the space on drive creation instead of when it
needs it (just so you have sequential sectors on the discs). Raw spaces will
work fine in a virtual environment.
2) Backing it up using their utility is silly. Use ontap or onbar.
3) Little bit? try at least 20% increase. And what sys admin overhead are they
talking about?
4) JFS is exactly why you DON"T want cooked files. look at the thread about
performance issue with ZFS on this board just this week to see a nice long
explanation by Art about this.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
Dont document the problem, fix it.
Atli Björgvin Oddsson
________________________________________
From: ids-bounces@iiug.org [ids-bounces@iiug.org] on behalf of Jim Cramer
[jim-cramer@uiowa.edu]
Sent: Tuesday, July 27, 2010 3:14 PM
To: ids@iiug.org
Subject: Are there issues when using RAW dbspaces on ID.... [20662]
HELP!
Here is another angle to the recent questions, and explanations
by Art, et. al, regarding using RAW instead of COOKED dbspaces
on IDS 11.5 running on Linux.
For reasons cited by Art and the others, I (the DBA) wish to use
RAW dbspaces when I move my instances to Linux (SUSE 11 SLES)
Virtual Machines on an ESX Server running VMWare.
But my Sys Admins here are refusing to allow RAW spaces and citing
all kinds of vague, generalized reasons why, such as:
1) the "host administration utilities" will not fly right
with Raw Spaces but will not be specific about what would
go wrong. In general, my sense is that they feel that
the Management Console and Tools for the ESX host might
see the Raw Dbspace and, because it does not contain not a formatted
filesystem, allocate it to something on the box.
2) using raw space will not allow the VMs containing the IDS
dbspaces to be backed up or fit into their backup strategy
and backup utility.
They cannot seem to understand that a normal backup utility
would not know how to deal with the dbspaces even if they
were Cooked.
3) that the "little bit" of performance that they claim I might
get with Raw will not pay back for the increased Sys Admin
overhead.
4) that they will use a Journaled File System (along with Cooked
dbspaces) because it is more robust, fault-tolerant, comes
back up quicker after a crash, etc.
Can anybody provide me with any concrete information/experience
that is related to the above points, particularly (1) .
Does anyone know if raw dbspaces can cause problems in a Virtual
Machine on a VMWare ESX Server.
If you have some info and have time to send it soon, that would
be appreciated because I am about to do battle over this with
our Sys Admins.
Thanks much in advance,
Jim Cramer
Database Administrator and
Applications Developer III
University of Iowa
College of Engineering
Engineering Computer Systems Support
1256 SC
Iowa City, Iowa 52245
(319)-335-5757
jim-cramer@uiowa.edu
jcramer@engineering.uiowa.edu
http://css.engineering.uiowa.edu
http://www.engineering.uiowa.edu
http://www.uiowa.edu
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Hello, there´s a good material on Chat with the labs, talking about virtualization, hope it helps you... https://www.ibm.com/developerworks/wikis/display/ifmxchatwithlab/Home Best regards. Em 27/07/2010 15:14, Jim Cramer escreveu: > HELP! > > Here is another angle to the recent questions, and explanations > by Art, et. al, regarding using RAW instead of COOKED dbspaces > on IDS 11.5 running on Linux. > > For reasons cited by Art and the others, I (the DBA) wish to use > RAW dbspaces when I move my instances to Linux (SUSE 11 SLES) > Virtual Machines on an ESX Server running VMWare. > > But my Sys Admins here are refusing to allow RAW spaces and citing > all kinds of vague, generalized reasons why, such as: > > 1) the "host administration utilities" will not fly right > with Raw Spaces but will not be specific about what would > go wrong. In general, my sense is that they feel that > the Management Console and Tools for the ESX host might > see the Raw Dbspace and, because it does not contain not a formatted > filesystem, allocate it to something on the box. > > 2) using raw space will not allow the VMs containing the IDS > dbspaces to be backed up or fit into their backup strategy > and backup utility. > > They cannot seem to understand that a normal backup utility > would not know how to deal with the dbspaces even if they > were Cooked. > > 3) that the "little bit" of performance that they claim I might > get with Raw will not pay back for the increased Sys Admin > overhead. > > 4) that they will use a Journaled File System (along with Cooked > dbspaces) because it is more robust, fault-tolerant, comes > back up quicker after a crash, etc. > > Can anybody provide me with any concrete information/experience > that is related to the above points, particularly (1) . > > Does anyone know if raw dbspaces can cause problems in a Virtual > Machine on a VMWare ESX Server. > > If you have some info and have time to send it soon, that would > be appreciated because I am about to do battle over this with > our Sys Admins. > > Thanks much in advance, > > Jim Cramer > Database Administrator and > Applications Developer III > University of Iowa > College of Engineering > Engineering Computer Systems Support > 1256 SC > Iowa City, Iowa 52245 > (319)-335-5757 > jim-cramer@uiowa.edu > jcramer@engineering.uiowa.edu > http://css.engineering.uiowa.edu > http://www.engineering.uiowa.edu > http://www.uiowa.edu > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Alexandre Marini Tecnologia da Informação - DBA msn: alexandre_marini@hotmail.com SEFAZ-MS / SGI-UGSR / Sistemas IBM-Informix Cert-Info-Mgmt_color <Cert-Info-Mgmt_color.jpg> IBM Informix Dynamic Server Certified Professional V10 / V11
YOW! Cooked spaces, Journaled filesystems (bet they want to use EXT4 to
boot), AND VM images. You've got the triple crown there Jim! Lord God in
Heaven, tell me they're not also saddling you with RAID5, RAID6, or RAIDZ on
top of all that!
1) ESX doesn't care about RAW spaces AFAIK and VMs and RAW disk work about
as well as VMs and any other form of storage, which is to say VERY BADLY!
My testing for a major developer of highly embedded systems show that IO
under a VM performs 10x SLOWER than IO performance on the underlying
hardware/OS. I would seriously consider running your server on a commodity
Linux box instead.
2) You are correct, of course. Any backup of Informix chunks made at the
operating system level, especially if they are made, as seems to be the
intent of your SAs, at the level of the underlying host OS, will be
completely useless for restoring the database unless you put the engine into
external back up mode and block transactions for the duration of the
backup. Otherwise only an ontape or onbar backup will be usable to restore
the engine.
3) That "little bit" is 10-20% performance increase of RAW device versus
COOKED device, and an additional 5-10% for non-journaled filesystem chunks
versus COOKED devices. That is without O_DIRECT enabled, but the cuts the
cost down to about 5-10% RAW over COOKED and another 2-5% for filesystems,
which while it is MUCH better, is not trivial. Add to that the extra cost
of journaling (at least 5% but usually more like 15%) and the cost of doing
all of this on a VM versus raw hardware (about 90% in my testing).
4) The journaling, as I've already stated is redundant and therefore a
performance hit that buys you NOTHING! Informix's logical and physical
logging is FAR more efficient at recovering the database after a crash and
adding the filesystem recovery to that will only delay the beginning of the
engine's fast recovery mechanism.
5) Run! Run fast and run far. You do NOT want to be associated with this
system once it's rolled out.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Tue, Jul 27, 2010 at 3:14 PM, Jim Cramer <jim-cramer@uiowa.edu> wrote:
> HELP!
>
> Here is another angle to the recent questions, and explanations
> by Art, et. al, regarding using RAW instead of COOKED dbspaces
> on IDS 11.5 running on Linux.
>
> For reasons cited by Art and the others, I (the DBA) wish to use
> RAW dbspaces when I move my instances to Linux (SUSE 11 SLES)
> Virtual Machines on an ESX Server running VMWare.
>
> But my Sys Admins here are refusing to allow RAW spaces and citing
> all kinds of vague, generalized reasons why, such as:
>
> 1) the "host administration utilities" will not fly right
> with Raw Spaces but will not be specific about what would
> go wrong. In general, my sense is that they feel that
> the Management Console and Tools for the ESX host might
> see the Raw Dbspace and, because it does not contain not a formatted
> filesystem, allocate it to something on the box.
>
> 2) using raw space will not allow the VMs containing the IDS
> dbspaces to be backed up or fit into their backup strategy
> and backup utility.
>
> They cannot seem to understand that a normal backup utility
> would not know how to deal with the dbspaces even if they
> were Cooked.
>
> 3) that the "little bit" of performance that they claim I might
> get with Raw will not pay back for the increased Sys Admin
> overhead.
>
> 4) that they will use a Journaled File System (along with Cooked
> dbspaces) because it is more robust, fault-tolerant, comes
> back up quicker after a crash, etc.
>
> Can anybody provide me with any concrete information/experience
> that is related to the above points, particularly (1) .
>
> Does anyone know if raw dbspaces can cause problems in a Virtual
> Machine on a VMWare ESX Server.
>
> If you have some info and have time to send it soon, that would
> be appreciated because I am about to do battle over this with
> our Sys Admins.
>
> Thanks much in advance,
>
> Jim Cramer
> Database Administrator and
> Applications Developer III
> University of Iowa
> College of Engineering
> Engineering Computer Systems Support
> 1256 SC
> Iowa City, Iowa 52245
> (319)-335-5757
> jim-cramer@uiowa.edu
> jcramer@engineering.uiowa.edu
> http://css.engineering.uiowa.edu
> http://www.engineering.uiowa.edu
> http://www.uiowa.edu
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--0016e659f7fea2c12b048c659cf6
I think nobody explains it better than Art, but I'd like to stress out two
points:
1- Every sysadmin talks about the advantages of journaling, but it's amazing
how these people forget about reality. Let's start with this Wikipedia
article:
http://en.wikipedia.org/wiki/Journaling_file_system
They split the journaling system into two: Physical and Logical. The first
logs all blocks (data blocks also) and the second only file metadata.
Let's dig into this: Physical has a lot of performance impact (which is
obvious) and it's ABSOLUTELY useless for databases, since the databases MUST
do this.
The logical journaling only stores metadata changes. PLEASE, can anybody ask
the sysadmin what kind of metadata is changes in a filesystem where only
Informix chunks are stored?! We don't (currently at least) change the size
of chunks...
2- The backup argument is alarming. And it does because this is not sysadmin
task or responsability, and the DBA must make sure this is his
responsability. Surely no one is thinking about doing filesystem backups of
database chunks with a live database...
Regards.
On Tue, Jul 27, 2010 at 10:59 PM, Art Kagel <art.kagel@gmail.com> wrote:
> YOW! Cooked spaces, Journaled filesystems (bet they want to use EXT4 to
> boot), AND VM images. You've got the triple crown there Jim! Lord God in
> Heaven, tell me they're not also saddling you with RAID5, RAID6, or RAIDZ
> on
> top of all that!
>
> 1) ESX doesn't care about RAW spaces AFAIK and VMs and RAW disk work about
> as well as VMs and any other form of storage, which is to say VERY BADLY!
> My testing for a major developer of highly embedded systems show that IO
> under a VM performs 10x SLOWER than IO performance on the underlying
> hardware/OS. I would seriously consider running your server on a commodity
> Linux box instead.
>
> 2) You are correct, of course. Any backup of Informix chunks made at the
> operating system level, especially if they are made, as seems to be the
> intent of your SAs, at the level of the underlying host OS, will be
> completely useless for restoring the database unless you put the engine
> into
> external back up mode and block transactions for the duration of the
> backup. Otherwise only an ontape or onbar backup will be usable to restore
> the engine.
>
> 3) That "little bit" is 10-20% performance increase of RAW device versus
> COOKED device, and an additional 5-10% for non-journaled filesystem chunks
> versus COOKED devices. That is without O_DIRECT enabled, but the cuts the
> cost down to about 5-10% RAW over COOKED and another 2-5% for filesystems,
> which while it is MUCH better, is not trivial. Add to that the extra cost
> of journaling (at least 5% but usually more like 15%) and the cost of doing
> all of this on a VM versus raw hardware (about 90% in my testing).
>
> 4) The journaling, as I've already stated is redundant and therefore a
> performance hit that buys you NOTHING! Informix's logical and physical
> logging is FAR more efficient at recovering the database after a crash and
> adding the filesystem recovery to that will only delay the beginning of the
> engine's fast recovery mechanism.
>
> 5) Run! Run fast and run far. You do NOT want to be associated with this
> system once it's rolled out.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or
> by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Tue, Jul 27, 2010 at 3:14 PM, Jim Cramer <jim-cramer@uiowa.edu> wrote:
>
> > HELP!
> >
> > Here is another angle to the recent questions, and explanations
> > by Art, et. al, regarding using RAW instead of COOKED dbspaces
> > on IDS 11.5 running on Linux.
> >
> > For reasons cited by Art and the others, I (the DBA) wish to use
> > RAW dbspaces when I move my instances to Linux (SUSE 11 SLES)
> > Virtual Machines on an ESX Server running VMWare.
> >
> > But my Sys Admins here are refusing to allow RAW spaces and citing
> > all kinds of vague, generalized reasons why, such as:
> >
> > 1) the "host administration utilities" will not fly right
> > with Raw Spaces but will not be specific about what would
> > go wrong. In general, my sense is that they feel that
> > the Management Console and Tools for the ESX host might
> > see the Raw Dbspace and, because it does not contain not a formatted
> > filesystem, allocate it to something on the box.
> >
> > 2) using raw space will not allow the VMs containing the IDS
> > dbspaces to be backed up or fit into their backup strategy
> > and backup utility.
> >
> > They cannot seem to understand that a normal backup utility
> > would not know how to deal with the dbspaces even if they
> > were Cooked.
> >
> > 3) that the "little bit" of performance that they claim I might
> > get with Raw will not pay back for the increased Sys Admin
> > overhead.
> >
> > 4) that they will use a Journaled File System (along with Cooked
> > dbspaces) because it is more robust, fault-tolerant, comes
> > back up quicker after a crash, etc.
> >
> > Can anybody provide me with any concrete information/experience
> > that is related to the above points, particularly (1) .
> >
> > Does anyone know if raw dbspaces can cause problems in a Virtual
> > Machine on a VMWare ESX Server.
> >
> > If you have some info and have time to send it soon, that would
> > be appreciated because I am about to do battle over this with
> > our Sys Admins.
> >
> > Thanks much in advance,
> >
> > Jim Cramer
> > Database Administrator and
> > Applications Developer III
> > University of Iowa
> > College of Engineering
> > Engineering Computer Systems Support
> > 1256 SC
> > Iowa City, Iowa 52245
> > (319)-335-5757
> > jim-cramer@uiowa.edu
> > jcramer@engineering.uiowa.edu
> > http://css.engineering.uiowa.edu
> > http://www.engineering.uiowa.edu
> > http://www.uiowa.edu
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --0016e659f7fea2c12b048c659cf6
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--0016364585e4393f9a048c6e4358
My last comments on journaling. On meta-data change journaling: - This (logical metadata only journaling) is the method used by EXT3, EXT4, and ZFS - All three use block relocation instead of physical block journaling. This means that on write a block is always written to a new location rather than overwriting the existing block on disk. A properly designed JFS (Journaled File System) will commit the new version of the disk block before updating the metadata or the logical journal (that's the problem with EXT4 - and EXT3 with write-back enabled they write the metadata first, then the journal entry before actually committing the physical change to disk). Once the write and journal are completed the FS metadata is updated. This means that on a crash there are three possibilities: - The new block version was partially or completely written but the journal entry was not written. - The new block version and journal entry were written and committed. - The new block version, journal, and metadata were written and committed. In the first case, after recovery, the file remains unchanged. In the second case, after recovery, the FS makes the missing metadata entries and the file is modified during recovery and the original block version is freed for reuse. In the third case all was well before the crash and the original version of the block was released for reuse. The problem with EXT4 (and EXT3 with write-back enabled) is that the application (meaning in this case Informix) thinks everything is hunky dory since the FS acknowledged the change as committed. However, immediately after the acknowledgement the physically modified block is still ONLY in cache and only the metadata and journal entry have been saved to disk. At this point if there is a crash, the file is actually unrecoverable! The metadata and the journal entry say the block has been moved to a new location and rewritten, but the new location has garbage in it from some previous block. This one made Linus Torvalds absolutely livid and he tore the EXT4 designers a new one over the design. Last I heard you could not disable the write-back behavior of EXT4 - Linus was pushing to have that fixed, but I don't know if it ever was. EXT3 in default mode and ZFS at least are safe, but the problem with them is just the fact of the block relocations. There is the performance problem of rewriting a whole block every time the database changes a single page within the block and so negating much of the gains of caching and there is the bigger problem that the file is no longer even as contiguous as a non-journaled filesystem would have it be. Standard UNIX filesystems allocate blocks of contiguous space and try to leave free space that is contiguous with those allocated blocks unused when allocating space for other files so that as a file grows it remains mostly contiguous in multi-block chunks. This fragments the free space in an FS making it difficult to write vvery large files (like Informix chunks) that are contiguous, but if you keep the chunks on an FS that's dedicated to Informix chunks that's not a real problem (at least currently) since Informix does not currently extend existing chunks over time. JFS's break that rule keeping the contiguous bits of a file the same as the block level. Even if a chunk were allocated as contiguous initially, over time the JFS will cause the file to become fragmented. If you make the FS block size smaller to alleviate the costs of multiple block rewrites, you make the file fragmentation worse. These problems don't affect filesystems and normal files as much as databases because the nature of the IO to files is different than IO to databases. When you write to a flat file, you write mostly sequentially, your rarely rewrite a portion of the file (unless you rewrite the entire file) and you never sync the file to disk before you close the file. That means that the cache will coalesce all writes until an entire block has been written out before the FS and OS cause a flush and sync of the cache to disk. That means that the FS has the ability to try to keep the rewritten blocks contiguous by allocating the replacement blocks contiguously. Essentially the file is relocated whole if it is rewritten. Databases don't work that way. Informix writes every block to a COOKED device or file either under O_SYNC or O_DIRECT control both of which force the single write (and Informix only ever writes a single page or eight contiguous pages at a time) to be physically written and committed before the write() call returns. That means that the coalescing features of the FS and OS cache management are bypassed in favor of data safety. That means that if the engine performs what it thinks is a sequential scan, it is actually performing a random read of the file swinging the read/write heads back and forth across the disk. If the physical structure is shared with other applications (can you say massive SAN?) that will also be competing with those other applications for head positioning. In normal sequential scanning (ie RAW or COOKED device or non-JFS files) the read ahead reduces the performance impact of this head contention somewhat. In a JFS, it cannot help at all. So I guess I have to change my mantra: NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Jul 28, 2010 at 4:18 AM, Fernando Nunes <domusonline@gmail.com>wrote: > I think nobody explains it better than Art, but I'd like to stress out two > points: > > 1- Every sysadmin talks about the advantages of journaling, but it's > amazing > how these people forget about reality. Let's start with this Wikipedia > article: > http://en.wikipedia.org/wiki/Journaling_file_system > They split the journaling system into two: Physical and Logical. The first > logs all blocks (data blocks also) and the second only file metadata. > Let's dig into this: Physical has a lot of performance impact (which is > obvious) and it's ABSOLUTELY useless for databases, since the databases > MUST > do this. > The logical journaling only stores metadata changes. PLEASE, can anybody > ask > the sysadmin what kind of metadata is changes in a filesystem where only > Informix chunks are stored?! We don't (curr
Jonathon,
Thank you very much for the fast response and the
below info.
At 2 pm I had to do battle with the Sys Admins here
and your information, as well as what Art has been
saying all last week (and previous to that) about
Raw db chunks and issues, helped me argue my
case.
As far as what I said and was worried about in issue (1)
goes, either I misunderstand what was rattled off
to me this morning in a hurry about that or they have
changed their tune.
After talking to them, I was pretty sure that the admins,
or perhaps just one of them, were claiming that there
could be issues with the ESX server management/system software/
utilities affecting the raw db chunks in the VMs that
my Informix instances are in. You are right, that makes
0 sense. I thought so too at the time, but perhaps
I misunderstood. Because now they are saying that
their concern is that Linux system management stuff,
such as YAST, within the VMs that my Informix instances
are in could mess with my raw logical volumes used
as Informix chunks. They said that they have to configure
some things inside the VMs so that they do not do that.
I have no Linux Sys Admin experience, just HP-UX.
If you are aware of anything that is part of Linux
that might be a consideration when I use raw logical
volumes, please let me know if you get a chance.
Thanks again for your help!
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Tuesday, July 27, 2010 2:23 PM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20663]
1) That makes 0 sense. Although you will be using raw spaces, the drives
themselves are allocated by the host for the client to use in any way it
sees
fit, just have them allocate the space on drive creation instead of when it
needs it (just so you have sequential sectors on the discs). Raw spaces will
work fine in a virtual environment.
2) Backing it up using their utility is silly. Use ontap or onbar.
3) Little bit? try at least 20% increase. And what sys admin overhead are
they
talking about?
4) JFS is exactly why you DON"T want cooked files. look at the thread about
performance issue with ZFS on this board just this week to see a nice long
explanation by Art about this.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
Dont document the problem, fix it.
Atli Björgvin Oddsson
________________________________________
From: ids-bounces@iiug.org [ids-bounces@iiug.org] on behalf of Jim Cramer
[jim-cramer@uiowa.edu]
Sent: Tuesday, July 27, 2010 3:14 PM
To: ids@iiug.org
Subject: Are there issues when using RAW dbspaces on ID.... [20662]
HELP!
Here is another angle to the recent questions, and explanations
by Art, et. al, regarding using RAW instead of COOKED dbspaces
on IDS 11.5 running on Linux.
For reasons cited by Art and the others, I (the DBA) wish to use
RAW dbspaces when I move my instances to Linux (SUSE 11 SLES)
Virtual Machines on an ESX Server running VMWare.
But my Sys Admins here are refusing to allow RAW spaces and citing
all kinds of vague, generalized reasons why, such as:
1) the "host administration utilities" will not fly right
with Raw Spaces but will not be specific about what would
go wrong. In general, my sense is that they feel that
the Management Console and Tools for the ESX host might
see the Raw Dbspace and, because it does not contain not a formatted
filesystem, allocate it to something on the box.
2) using raw space will not allow the VMs containing the IDS
dbspaces to be backed up or fit into their backup strategy
and backup utility.
They cannot seem to understand that a normal backup utility
would not know how to deal with the dbspaces even if they
were Cooked.
3) that the "little bit" of performance that they claim I might
get with Raw will not pay back for the increased Sys Admin
overhead.
4) that they will use a Journaled File System (along with Cooked
dbspaces) because it is more robust, fault-tolerant, comes
back up quicker after a crash, etc.
Can anybody provide me with any concrete information/experience
that is related to the above points, particularly (1) .
Does anyone know if raw dbspaces can cause problems in a Virtual
Machine on a VMWare ESX Server.
If you have some info and have time to send it soon, that would
be appreciated because I am about to do battle over this with
our Sys Admins.
Thanks much in advance,
Jim Cramer
Database Administrator and
Applications Developer III
University of Iowa
College of Engineering
Engineering Computer Systems Support
1256 SC
Iowa City, Iowa 52245
(319)-335-5757
jim-cramer@uiowa.edu
jcramer@engineering.uiowa.edu
http://css.engineering.uiowa.edu
http://www.engineering.uiowa.edu
http://www.uiowa.edu
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
Alexandre, Thanks for the excellent index to the chats with the Informix labs series. Yes, there is some very good material, it looks like, regarding virtualization, as well as other 11.5 topics that will help me with my transition from IDS 10 to 11.5 Thanks again, Jim -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Alexandre Marini Sent: Tuesday, July 27, 2010 2:31 PM To: ids@iiug.org Subject: Re: Are there issues when using RAW dbspaces o.... [20664] Hello, there´s a good material on Chat with the labs, talking about virtualization, hope it helps you... https://www.ibm.com/developerworks/wikis/display/ifmxchatwithlab/Home Best regards. Em 27/07/2010 15:14, Jim Cramer escreveu: > HELP! > > Here is another angle to the recent questions, and explanations > by Art, et. al, regarding using RAW instead of COOKED dbspaces > on IDS 11.5 running on Linux. > > For reasons cited by Art and the others, I (the DBA) wish to use > RAW dbspaces when I move my instances to Linux (SUSE 11 SLES) > Virtual Machines on an ESX Server running VMWare. > > But my Sys Admins here are refusing to allow RAW spaces and citing > all kinds of vague, generalized reasons why, such as: > > 1) the "host administration utilities" will not fly right > with Raw Spaces but will not be specific about what would > go wrong. In general, my sense is that they feel that > the Management Console and Tools for the ESX host might > see the Raw Dbspace and, because it does not contain not a formatted > filesystem, allocate it to something on the box. > > 2) using raw space will not allow the VMs containing the IDS > dbspaces to be backed up or fit into their backup strategy > and backup utility. > > They cannot seem to understand that a normal backup utility > would not know how to deal with the dbspaces even if they > were Cooked. > > 3) that the "little bit" of performance that they claim I might > get with Raw will not pay back for the increased Sys Admin > overhead. > > 4) that they will use a Journaled File System (along with Cooked > dbspaces) because it is more robust, fault-tolerant, comes > back up quicker after a crash, etc. > > Can anybody provide me with any concrete information/experience > that is related to the above points, particularly (1) . > > Does anyone know if raw dbspaces can cause problems in a Virtual > Machine on a VMWare ESX Server. > > If you have some info and have time to send it soon, that would > be appreciated because I am about to do battle over this with > our Sys Admins. > > Thanks much in advance, > > Jim Cramer > Database Administrator and > Applications Developer III > University of Iowa > College of Engineering > Engineering Computer Systems Support > 1256 SC > Iowa City, Iowa 52245 > (319)-335-5757 > jim-cramer@uiowa.edu > jcramer@engineering.uiowa.edu > http://css.engineering.uiowa.edu > http://www.engineering.uiowa.edu > http://www.uiowa.edu > > > **************************************************************************** *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Alexandre Marini Tecnologia da Informação - DBA msn: alexandre_marini@hotmail.com SEFAZ-MS / SGI-UGSR / Sistemas IBM-Informix Cert-Info-Mgmt_color <Cert-Info-Mgmt_color.jpg> IBM Informix Dynamic Server Certified Professional V10 / V11 **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.
There is a problem with the way that linux handles logical volumes with
informix. But it is easily fixable. By default the major/minor numbers for the
logical volume devices are assigned dynamically at boot. Because of this your
chunks could move, but informix wouldn't know where they went. You can set the
volumes to have static device numbers to fix that problem. Again, they don't
have to do ANYTHING.....
By and by the command would be something like this:
lvchange -M --major # --minor # "/dev/mapper/lg-lgname-lv-lvname"
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Wednesday, July 28, 2010 11:15 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20673]
Jonathon,
Thank you very much for the fast response and the below info.
At 2 pm I had to do battle with the Sys Admins here and your information, as
well as what Art has been saying all last week (and previous to that) about
Raw db chunks and issues, helped me argue my case.
As far as what I said and was worried about in issue (1) goes, either I
misunderstand what was rattled off to me this morning in a hurry about that or
they have changed their tune.
After talking to them, I was pretty sure that the admins, or perhaps just one
of them, were claiming that there could be issues with the ESX server
management/system software/ utilities affecting the raw db chunks in the VMs
that my Informix instances are in. You are right, that makes
0 sense. I thought so too at the time, but perhaps I misunderstood. Because
now they are saying that their concern is that Linux system management stuff,
such as YAST, within the VMs that my Informix instances are in could mess with
my raw logical volumes used as Informix chunks. They said that they have to
configure some things inside the VMs so that they do not do that.
I have no Linux Sys Admin experience, just HP-UX.
If you are aware of anything that is part of Linux that might be a
consideration when I use raw logical volumes, please let me know if you get a
chance.
Thanks again for your help!
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Tuesday, July 27, 2010 2:23 PM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20663]
1) That makes 0 sense. Although you will be using raw spaces, the drives
themselves are allocated by the host for the client to use in any way it sees
fit, just have them allocate the space on drive creation instead of when it
needs it (just so you have sequential sectors on the discs). Raw spaces will
work fine in a virtual environment.
2) Backing it up using their utility is silly. Use ontap or onbar.
3) Little bit? try at least 20% increase. And what sys admin overhead are they
talking about?
4) JFS is exactly why you DON"T want cooked files. look at the thread about
performance issue with ZFS on this board just this week to see a nice long
explanation by Art about this.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
________________________________________
From: ids-bounces@iiug.org [ids-bounces@iiug.org] on behalf of Jim Cramer
[jim-cramer@uiowa.edu]
Sent: Tuesday, July 27, 2010 3:14 PM
To: ids@iiug.org
Subject: Are there issues when using RAW dbspaces on ID.... [20662]
HELP!
Here is another angle to the recent questions, and explanations by Art, et.
al, regarding using RAW instead of COOKED dbspaces on IDS 11.5 running on
Linux.
For reasons cited by Art and the others, I (the DBA) wish to use RAW dbspaces
when I move my instances to Linux (SUSE 11 SLES) Virtual Machines on an ESX
Server running VMWare.
But my Sys Admins here are refusing to allow RAW spaces and citing all kinds
of vague, generalized reasons why, such as:
1) the "host administration utilities" will not fly right with Raw Spaces but
will not be specific about what would go wrong. In general, my sense is that
they feel that the Management Console and Tools for the ESX host might see the
Raw Dbspace and, because it does not contain not a formatted filesystem,
allocate it to something on the box.
2) using raw space will not allow the VMs containing the IDS dbspaces to be
backed up or fit into their backup strategy and backup utility.
They cannot seem to understand that a normal backup utility would not know how
to deal with the dbspaces even if they were Cooked.
3) that the "little bit" of performance that they claim I might get with Raw
will not pay back for the increased Sys Admin overhead.
4) that they will use a Journaled File System (along with Cooked
dbspaces) because it is more robust, fault-tolerant, comes back up quicker
after a crash, etc.
Can anybody provide me with any concrete information/experience that is
related to the above points, particularly (1) .
Does anyone know if raw dbspaces can cause problems in a Virtual Machine on a
VMWare ESX Server.
If you have some info and have time to send it soon, that would be appreciated
because I am about to do battle over this with our Sys Admins.
Thanks much in advance,
Jim Cramer
Database Administrator and
Applications Developer III
University of Iowa
College of Engineering
Engineering Computer Systems Support
1256 SC
Iowa City, Iowa 52245
(319)-335-5757
jim-cramer@uiowa.edu
jcramer@engineering.uiowa.edu
http://css.engineering.uiowa.edu
http://www.engineering.uiowa.edu
http://www.uiowa.edu
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Fernando,
Thanks for the advice and the reference on journaling.
I had my meeting with our Sys Admins yesterday and
brought along quite a bit of supporting material,
gathered from IIUG ids listserv, from responses to my
post to the list, from a call to Informix Support that
I placed, and other sources that I researched.
I convinced them to see the light about using Raw
db chunks and using a Logical Volume Manager to
partition them.
The only other info that I am looking for now is
about anything in the Linux SUSE 11 SLES system
and utilities that might have an issue with or
cause problems on a raw logical volume.
The Sys Admins tune changed over the course of the
day. At first I think that I was told that
they were concerned about management tool that is part
of what comes with the ESX Server to administer/create
the VMWare virtual hosts that my Informix instances
will run in. So, I included this concern in my
original post yesterday and, as Jonathan replied,
it makes 0 sense.
Perhaps I misunderstood them at first...
Later their concern changed to possibly something that comes
with the Linux SLES 11, running in the VM, causing a problem
with my raw db chunks. They mentioned some auto configuration
feature, that I believe is in the YAST management tool,
seeing the raw space, even though I would have it in a Logical
Volume, and try to use it. They said that they can configure
that feature to leave my space alone.
But is anyone has had any problems with Linux SLES interfering
with Raw db chunks, I would appreciate if you would post them.
Thanks to everyone for their help and fast response.
Jim Cramer
University of Iowa
College of Engineering
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Fernando Nunes
Sent: Wednesday, July 28, 2010 3:19 AM
To: ids@iiug.org
Subject: Re: Are there issues when using RAW dbspaces o.... [20666]
I think nobody explains it better than Art, but I'd like to stress out two
points:
1- Every sysadmin talks about the advantages of journaling, but it's amazing
how these people forget about reality. Let's start with this Wikipedia
article:
http://en.wikipedia.org/wiki/Journaling_file_system
They split the journaling system into two: Physical and Logical. The first
logs all blocks (data blocks also) and the second only file metadata.
Let's dig into this: Physical has a lot of performance impact (which is
obvious) and it's ABSOLUTELY useless for databases, since the databases MUST
do this.
The logical journaling only stores metadata changes. PLEASE, can anybody ask
the sysadmin what kind of metadata is changes in a filesystem where only
Informix chunks are stored?! We don't (currently at least) change the size
of chunks...
2- The backup argument is alarming. And it does because this is not sysadmin
task or responsability, and the DBA must make sure this is his
responsability. Surely no one is thinking about doing filesystem backups of
database chunks with a live database...
Regards.
On Tue, Jul 27, 2010 at 10:59 PM, Art Kagel <art.kagel@gmail.com> wrote:
> YOW! Cooked spaces, Journaled filesystems (bet they want to use EXT4 to
> boot), AND VM images. You've got the triple crown there Jim! Lord God in
> Heaven, tell me they're not also saddling you with RAID5, RAID6, or RAIDZ
> on
> top of all that!
>
> 1) ESX doesn't care about RAW spaces AFAIK and VMs and RAW disk work about
> as well as VMs and any other form of storage, which is to say VERY BADLY!
> My testing for a major developer of highly embedded systems show that IO
> under a VM performs 10x SLOWER than IO performance on the underlying
> hardware/OS. I would seriously consider running your server on a commodity
> Linux box instead.
>
> 2) You are correct, of course. Any backup of Informix chunks made at the
> operating system level, especially if they are made, as seems to be the
> intent of your SAs, at the level of the underlying host OS, will be
> completely useless for restoring the database unless you put the engine
> into
> external back up mode and block transactions for the duration of the
> backup. Otherwise only an ontape or onbar backup will be usable to restore
> the engine.
>
> 3) That "little bit" is 10-20% performance increase of RAW device versus
> COOKED device, and an additional 5-10% for non-journaled filesystem chunks
> versus COOKED devices. That is without O_DIRECT enabled, but the cuts the
> cost down to about 5-10% RAW over COOKED and another 2-5% for filesystems,
> which while it is MUCH better, is not trivial. Add to that the extra cost
> of journaling (at least 5% but usually more like 15%) and the cost of
doing
> all of this on a VM versus raw hardware (about 90% in my testing).
>
> 4) The journaling, as I've already stated is redundant and therefore a
> performance hit that buys you NOTHING! Informix's logical and physical
> logging is FAR more efficient at recovering the database after a crash and
> adding the filesystem recovery to that will only delay the beginning of
the
> engine's fast recovery mechanism.
>
> 5) Run! Run fast and run far. You do NOT want to be associated with this
> system once it's rolled out.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or
> by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Tue, Jul 27, 2010 at 3:14 PM, Jim Cramer <jim-cramer@uiowa.edu> wrote:
>
> > HELP!
> >
> > Here is another angle to the recent questions, and explanations
> > by Art, et. al, regarding using RAW instead of COOKED dbspaces
> > on IDS 11.5 running on Linux.
> >
> > For reasons cited by Art and the others, I (the DBA) wish to use
> > RAW dbspaces when I move my instances to Linux (SUSE 11 SLES)
> > Virtual Machines on an ESX Server running VMWare.
> >
> > But my Sys Admins here are refusing to allow RAW spaces and citing
> > all kinds of vague, generalized reasons why, such as:
> >
> > 1) the "host administration utilities" will not fly right
> > with Raw Spaces but will not be specific about what would
> > go wrong. In general, my sense is that they feel that
> > the Management Console and Tools for the ESX host might
> > see the Raw Dbspace and, because it does not contain not a formatted
> > filesystem, allocate it to something on the box.
> >
> > 2) using raw space will not allow the VMs containing the IDS
> > dbspaces to be backed up or fit into their backup strategy
> > and backup utility.
> >
> > They cannot seem to understand that a normal backup utility
> > would not know how to deal with the dbspaces even if they
> > were Cooked.
> >
> > 3) that
Art, Incredible, and useful information for now and for the future. Luckily I have convinced everyone involved here into the wisdom of going with Raw db chunks. One Sys Admin did mention a new angle that I had not mentioned previously. I don't know if you do much with IDS in VMWare instances, but we will have ours on an ESX Server. The Admin's concern, which regards scenarios of power failure or failure of some sort with the ESX Server, is loss of data and/or data integrity due to the buffering that takes place between the VM, containing my dbspaces, and the physical ESX Server host. Any info on this? Thanks again for your help, Jim -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Wednesday, July 28, 2010 7:49 AM To: ids@iiug.org Subject: Re: Are there issues when using RAW dbspaces o.... [20668] My last comments on journaling. On meta-data change journaling: - This (logical metadata only journaling) is the method used by EXT3, EXT4, and ZFS - All three use block relocation instead of physical block journaling. This means that on write a block is always written to a new location rather than overwriting the existing block on disk. A properly designed JFS (Journaled File System) will commit the new version of the disk block before updating the metadata or the logical journal (that's the problem with EXT4 - and EXT3 with write-back enabled they write the metadata first, then the journal entry before actually committing the physical change to disk). Once the write and journal are completed the FS metadata is updated. This means that on a crash there are three possibilities: - The new block version was partially or completely written but the journal entry was not written. - The new block version and journal entry were written and committed. - The new block version, journal, and metadata were written and committed. In the first case, after recovery, the file remains unchanged. In the second case, after recovery, the FS makes the missing metadata entries and the file is modified during recovery and the original block version is freed for reuse. In the third case all was well before the crash and the original version of the block was released for reuse. The problem with EXT4 (and EXT3 with write-back enabled) is that the application (meaning in this case Informix) thinks everything is hunky dory since the FS acknowledged the change as committed. However, immediately after the acknowledgement the physically modified block is still ONLY in cache and only the metadata and journal entry have been saved to disk. At this point if there is a crash, the file is actually unrecoverable! The metadata and the journal entry say the block has been moved to a new location and rewritten, but the new location has garbage in it from some previous block. This one made Linus Torvalds absolutely livid and he tore the EXT4 designers a new one over the design. Last I heard you could not disable the write-back behavior of EXT4 - Linus was pushing to have that fixed, but I don't know if it ever was. EXT3 in default mode and ZFS at least are safe, but the problem with them is just the fact of the block relocations. There is the performance problem of rewriting a whole block every time the database changes a single page within the block and so negating much of the gains of caching and there is the bigger problem that the file is no longer even as contiguous as a non-journaled filesystem would have it be. Standard UNIX filesystems allocate blocks of contiguous space and try to leave free space that is contiguous with those allocated blocks unused when allocating space for other files so that as a file grows it remains mostly contiguous in multi-block chunks. This fragments the free space in an FS making it difficult to write vvery large files (like Informix chunks) that are contiguous, but if you keep the chunks on an FS that's dedicated to Informix chunks that's not a real problem (at least currently) since Informix does not currently extend existing chunks over time. JFS's break that rule keeping the contiguous bits of a file the same as the block level. Even if a chunk were allocated as contiguous initially, over time the JFS will cause the file to become fragmented. If you make the FS block size smaller to alleviate the costs of multiple block rewrites, you make the file fragmentation worse. These problems don't affect filesystems and normal files as much as databases because the nature of the IO to files is different than IO to databases. When you write to a flat file, you write mostly sequentially, your rarely rewrite a portion of the file (unless you rewrite the entire file) and you never sync the file to disk before you close the file. That means that the cache will coalesce all writes until an entire block has been written out before the FS and OS cause a flush and sync of the cache to disk. That means that the FS has the ability to try to keep the rewritten blocks contiguous by allocating the replacement blocks contiguously. Essentially the file is relocated whole if it is rewritten. Databases don't work that way. Informix writes every block to a COOKED device or file either under O_SYNC or O_DIRECT control both of which force the single write (and Informix only ever writes a single page or eight contiguous pages at a time) to be physically written and committed before the write() call returns. That means that the coalescing features of the FS and OS cache management are bypassed in favor of data safety. That means that if the engine performs what it thinks is a sequential scan, it is actually performing a random read of the file swinging the read/write heads back and forth across the disk. If the physical structure is shared with other applications (can you say massive SAN?) that will also be competing with those other applications for head positioning. In normal sequential scanning (ie RAW or COOKED device or non-JFS files) the read ahead reduces the performance impact of this head contention somewhat. In a JFS, it cannot help at all. So I guess I have to change my mantra: NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! NO JFS, NO RAID5!!! Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity
Jonathon,
Thanks again for your continuing information and assistance.
Wow, I am glad that you warned me about this issue, or I
might have got off to a seriously bad start.
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Wednesday, July 28, 2010 10:21 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20675]
There is a problem with the way that linux handles logical volumes with
informix. But it is easily fixable. By default the major/minor numbers for
the
logical volume devices are assigned dynamically at boot. Because of this
your
chunks could move, but informix wouldn't know where they went. You can set
the
volumes to have static device numbers to fix that problem. Again, they don't
have to do ANYTHING.....
By and by the command would be something like this:
lvchange -M --major # --minor # "/dev/mapper/lg-lgname-lv-lvname"
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Wednesday, July 28, 2010 11:15 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20673]
Jonathon,
Thank you very much for the fast response and the below info.
At 2 pm I had to do battle with the Sys Admins here and your information, as
well as what Art has been saying all last week (and previous to that) about
Raw db chunks and issues, helped me argue my case.
As far as what I said and was worried about in issue (1) goes, either I
misunderstand what was rattled off to me this morning in a hurry about that
or
they have changed their tune.
After talking to them, I was pretty sure that the admins, or perhaps just
one
of them, were claiming that there could be issues with the ESX server
management/system software/ utilities affecting the raw db chunks in the VMs
that my Informix instances are in. You are right, that makes
0 sense. I thought so too at the time, but perhaps I misunderstood. Because
now they are saying that their concern is that Linux system management
stuff,
such as YAST, within the VMs that my Informix instances are in could mess
with
my raw logical volumes used as Informix chunks. They said that they have to
configure some things inside the VMs so that they do not do that.
I have no Linux Sys Admin experience, just HP-UX.
If you are aware of anything that is part of Linux that might be a
consideration when I use raw logical volumes, please let me know if you get
a
chance.
Thanks again for your help!
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Tuesday, July 27, 2010 2:23 PM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20663]
1) That makes 0 sense. Although you will be using raw spaces, the drives
themselves are allocated by the host for the client to use in any way it
sees
fit, just have them allocate the space on drive creation instead of when it
needs it (just so you have sequential sectors on the discs). Raw spaces will
work fine in a virtual environment.
2) Backing it up using their utility is silly. Use ontap or onbar.
3) Little bit? try at least 20% increase. And what sys admin overhead are
they
talking about?
4) JFS is exactly why you DON"T want cooked files. look at the thread about
performance issue with ZFS on this board just this week to see a nice long
explanation by Art about this.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
________________________________________
From: ids-bounces@iiug.org [ids-bounces@iiug.org] on behalf of Jim Cramer
[jim-cramer@uiowa.edu]
Sent: Tuesday, July 27, 2010 3:14 PM
To: ids@iiug.org
Subject: Are there issues when using RAW dbspaces on ID.... [20662]
HELP!
Here is another angle to the recent questions, and explanations by Art, et.
al, regarding using RAW instead of COOKED dbspaces on IDS 11.5 running on
Linux.
For reasons cited by Art and the others, I (the DBA) wish to use RAW
dbspaces
when I move my instances to Linux (SUSE 11 SLES) Virtual Machines on an ESX
Server running VMWare.
But my Sys Admins here are refusing to allow RAW spaces and citing all kinds
of vague, generalized reasons why, such as:
1) the "host administration utilities" will not fly right with Raw Spaces
but
will not be specific about what would go wrong. In general, my sense is that
they feel that the Management Console and Tools for the ESX host might see
the
Raw Dbspace and, because it does not contain not a formatted filesystem,
allocate it to something on the box.
2) using raw space will not allow the VMs containing the IDS dbspaces to be
backed up or fit into their backup strategy and backup utility.
They cannot seem to understand that a normal backup utility would not know
how
to deal with the dbspaces even if they were Cooked.
3) that the "little bit" of performance that they claim I might get with Raw
will not pay back for the increased Sys Admin overhead.
4) that they will use a Journaled File System (along with Cooked
dbspaces) because it is more robust, fault-tolerant, comes back up quicker
after a crash, etc.
Can anybody provide me with any concrete information/experience that is
related to the above points, particularly (1) .
Does anyone know if raw dbspaces can cause problems in a Virtual Machine on
a
VMWare ESX Server.
If you have some info and have time to send it soon, that would be
appreciated
because I am about to do battle over this with our Sys Admins.
Thanks much in advance,
Jim Cramer
Database Administrator and
Applications Developer III
University of Iowa
College of Engineering
Engineering Computer Systems Support
1256 SC
Iowa City, Iowa 52245
(319)-335-5757
jim-cramer@uiowa.edu
jcramer@engineering.uiowa.edu
http://css.engineering.uiowa.edu
http://www.engineering.uiowa.edu
http://www.uiowa.edu
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
**********************************************************
Maybe your sysadmins are frightened that they'd forget they were there! I recently had a hardware engineer that noticed that /home was getting a bit full and offered to add 'one of those unused partitions you've got all over the place'... > To: ids@iiug.org > From: jim-cramer@uiowa.edu > Subject: Are there issues when using RAW dbspaces on ID.... [20662] > Date: Tue, 27 Jul 2010 15:14:05 -0400 > > HELP! > > Here is another angle to the recent questions, and explanations > by Art, et. al, regarding using RAW instead of COOKED dbspaces > on IDS 11.5 running on Linux. > > For reasons cited by Art and the others, I (the DBA) wish to use > RAW dbspaces when I move my instances to Linux (SUSE 11 SLES) > Virtual Machines on an ESX Server running VMWare. > > But my Sys Admins here are refusing to allow RAW spaces and citing > all kinds of vague, generalized reasons why, such as: > > 1) the "host administration utilities" will not fly right > with Raw Spaces but will not be specific about what would > go wrong. In general, my sense is that they feel that > the Management Console and Tools for the ESX host might > see the Raw Dbspace and, because it does not contain not a formatted > filesystem, allocate it to something on the box. > > 2) using raw space will not allow the VMs containing the IDS > dbspaces to be backed up or fit into their backup strategy > and backup utility. > > They cannot seem to understand that a normal backup utility > would not know how to deal with the dbspaces even if they > were Cooked. > > 3) that the "little bit" of performance that they claim I might > get with Raw will not pay back for the increased Sys Admin > overhead. > > 4) that they will use a Journaled File System (along with Cooked > dbspaces) because it is more robust, fault-tolerant, comes > back up quicker after a crash, etc. > > Can anybody provide me with any concrete information/experience > that is related to the above points, particularly (1) . > > Does anyone know if raw dbspaces can cause problems in a Virtual > Machine on a VMWare ESX Server. > > If you have some info and have time to send it soon, that would > be appreciated because I am about to do battle over this with > our Sys Admins. > > Thanks much in advance, > > Jim Cramer > Database Administrator and > Applications Developer III > University of Iowa > College of Engineering > Engineering Computer Systems Support > 1256 SC > Iowa City, Iowa 52245 > (319)-335-5757 > jim-cramer@uiowa.edu > jcramer@engineering.uiowa.edu > http://css.engineering.uiowa.edu > http://www.engineering.uiowa.edu > http://www.uiowa.edu > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
ESX has to be setup to pass along IO sync operations to the host OS for filesystems. For RAW devices, it should not even be a concern, but check with VMWare support. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Jul 28, 2010 at 11:40 AM, jim-cramer@uiowa.edu <jim-cramer@uiowa.edu > wrote: > Art, > > Incredible, and useful information for now and for the future. > > Luckily I have convinced everyone involved here into the > wisdom of going with Raw db chunks. > > One Sys Admin did mention a new angle that I had not mentioned > previously. > > I don't know if you do much with IDS in VMWare instances, but > we will have ours on an ESX Server. The Admin's concern, > which regards scenarios of power failure or failure of some > sort with the ESX Server, is loss of data and/or data > integrity due to the buffering that takes place between the VM, containing > my dbspaces, and the physical ESX Server host. > > Any info on this? > > Thanks again for your help, > > Jim > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Wednesday, July 28, 2010 7:49 AM > To: ids@iiug.org > Subject: Re: Are there issues when using RAW dbspaces o.... [20668] > > My last comments on journaling. On meta-data change journaling: > > - This (logical metadata only journaling) is the method used by EXT3, > > EXT4, and ZFS > > - All three use block relocation instead of physical block journaling. > > This means that on write a block is always written to a new location rather > > than overwriting the existing block on disk. A properly designed JFS > > (Journaled File System) will commit the new version of the disk block > before > > updating the metadata or the logical journal (that's the problem with EXT4 > - > > and EXT3 with write-back enabled they write the metadata first, then the > > journal entry before actually committing the physical change to disk). Once > > the write and journal are completed the FS metadata is updated. This means > > that on a crash there are three possibilities: > > - The new block version was partially or completely written but the > > journal entry was not written. > > - The new block version and journal entry were written and committed. > > - The new block version, journal, and metadata were written and > > committed. > > In the first case, after recovery, the file remains unchanged. In the > second case, after recovery, the FS makes the missing metadata entries and > the file is modified during recovery and the original block version is > freed > > for reuse. In the third case all was well before the crash and the original > version of the block was released for reuse. > > The problem with EXT4 (and EXT3 with write-back enabled) is that the > application (meaning in this case Informix) thinks everything is hunky dory > since the FS acknowledged the change as committed. However, immediately > after the acknowledgement the physically modified block is still ONLY in > cache and only the metadata and journal entry have been saved to disk. At > this point if there is a crash, the file is actually unrecoverable! The > metadata and the journal entry say the block has been moved to a new > location and rewritten, but the new location has garbage in it from some > previous block. This one made Linus Torvalds absolutely livid and he tore > the EXT4 designers a new one over the design. Last I heard you could not > disable the write-back behavior of EXT4 - Linus was pushing to have that > fixed, but I don't know if it ever was. > > EXT3 in default mode and ZFS at least are safe, but the problem with them > is > > just the fact of the block relocations. There is the performance problem of > rewriting a whole block every time the database changes a single page > within > > the block and so negating much of the gains of caching and there is the > bigger problem that the file is no longer even as contiguous as a > non-journaled filesystem would have it be. Standard UNIX filesystems > allocate blocks of contiguous space and try to leave free space that is > contiguous with those allocated blocks unused when allocating space for > other files so that as a file grows it remains mostly contiguous in > multi-block chunks. This fragments the free space in an FS making it > difficult to write vvery large files (like Informix chunks) that are > contiguous, but if you keep the chunks on an FS that's dedicated to > Informix > > chunks that's not a real problem (at least currently) since Informix does > not currently extend existing chunks over time. JFS's break that rule > keeping the contiguous bits of a file the same as the block level. Even if > a chunk were allocated as contiguous initially, over time the JFS will > cause > > the file to become fragmented. If you make the FS block size smaller to > alleviate the costs of multiple block rewrites, you make the file > fragmentation worse. > > These problems don't affect filesystems and normal files as much as > databases because the nature of the IO to files is different than IO to > databases. When you write to a flat file, you write mostly sequentially, > your rarely rewrite a portion of the file (unless you rewrite the entire > file) and you never sync the file to disk before you close the file. That > means that the cache will coalesce all writes until an entire block has > been > > written out before the FS and OS cause a flush and sync of the cache to > disk. That means that the FS has the ability to try to keep the rewritten > blocks contiguous by allocating the replacement blocks contiguously. > Essentially the file is relocated whole if it is rewritten. > > Databases don't work that way. Informix writes every block to a COOKED > device or file either under O_SYNC or O_DIRECT control both of which force > the single write (and Informix only ever writes a single page or eight > contiguous pages at a time) to be physically written and committed before > the write() call returns. That means that the coalescing features of the FS > and OS cache management are bypassed in favor of data safety. That means > that if the engine performs what it thinks is a sequential scan, it is > actually performing a random read of the file swinging the read/write heads > back and forth across the disk. If the physical structure is shared with > other applications (can you say massive SAN?) that will also be competing > with those other applications for head positioning. In normal sequential > scanning (ie RAW or COOKED device or non-JFS files) the read ahead reduces > the performance impact of this head contention somewhat. In a JFS,
Hi again Jonathon,
It is my understanding that SUSE Linux comes with more than
1 Logical Volume Manager.
If this is the case, can you tell me which one the concern that
you mention below applies to?
Also, one of our Sys Admins told me that at least one of the LVMs
on Linux has a built-in mechanism that I could take advantage of
to avoid the pitfall that you mention. The mechanism apparently
involves a couple levels of symbolic links for each device file.
He says that the system will dynamically change the lowest level
link for a device file at times, but that it will also update
a higher level link, whose name/path never changes, for the same device
to reflect the change in the underlying link. In other words,
if I used the highest level link for a device file in my creation
of a db chunk, the pitfall you mention would be avoided.
I don't know if this mechanism that he told me about applied to
all Logical Volume Managers provide with SUSE and will check with
him on that.
In the mean time, it would be useful if you could tell me the name
of the LVM that you know the situation you described happens with.
Thanks,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Wednesday, July 28, 2010 10:21 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20675]
There is a problem with the way that linux handles logical volumes with
informix. But it is easily fixable. By default the major/minor numbers for
the
logical volume devices are assigned dynamically at boot. Because of this
your
chunks could move, but informix wouldn't know where they went. You can set
the
volumes to have static device numbers to fix that problem. Again, they
don't
have to do ANYTHING.....
By and by the command would be something like this:
lvchange -M --major # --minor # "/dev/mapper/lg-lgname-lv-lvname"
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Wednesday, July 28, 2010 11:15 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20673]
Jonathon,
Thank you very much for the fast response and the below info.
At 2 pm I had to do battle with the Sys Admins here and your information,
as
well as what Art has been saying all last week (and previous to that)
about
Raw db chunks and issues, helped me argue my case.
As far as what I said and was worried about in issue (1) goes, either I
misunderstand what was rattled off to me this morning in a hurry about
that or
they have changed their tune.
After talking to them, I was pretty sure that the admins, or perhaps just
one
of them, were claiming that there could be issues with the ESX server
management/system software/ utilities affecting the raw db chunks in the
VMs
that my Informix instances are in. You are right, that makes
0 sense. I thought so too at the time, but perhaps I misunderstood.
Because
now they are saying that their concern is that Linux system management
stuff,
such as YAST, within the VMs that my Informix instances are in could mess
with
my raw logical volumes used as Informix chunks. They said that they have
to
configure some things inside the VMs so that they do not do that.
I have no Linux Sys Admin experience, just HP-UX.
If you are aware of anything that is part of Linux that might be a
consideration when I use raw logical volumes, please let me know if you
get a
chance.
Thanks again for your help!
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Wyza,
Jonathon
Sent: Tuesday, July 27, 2010 2:23 PM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20663]
1) That makes 0 sense. Although you will be using raw spaces, the drives
themselves are allocated by the host for the client to use in any way it
sees
fit, just have them allocate the space on drive creation instead of when
it
needs it (just so you have sequential sectors on the discs). Raw spaces
will
work fine in a virtual environment.
2) Backing it up using their utility is silly. Use ontap or onbar.
3) Little bit? try at least 20% increase. And what sys admin overhead are
they
talking about?
4) JFS is exactly why you DON"T want cooked files. look at the thread
about
performance issue with ZFS on this board just this week to see a nice long
explanation by Art about this.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
________________________________________
From: ids-bounces@iiug.org [ids-bounces@iiug.org] on behalf of Jim Cramer
[jim-cramer@uiowa.edu]
Sent: Tuesday, July 27, 2010 3:14 PM
To: ids@iiug.org
Subject: Are there issues when using RAW dbspaces on ID.... [20662]
HELP!
Here is another angle to the recent questions, and explanations by Art,
et.
al, regarding using RAW instead of COOKED dbspaces on IDS 11.5 running on
Linux.
For reasons cited by Art and the others, I (the DBA) wish to use RAW
dbspaces
when I move my instances to Linux (SUSE 11 SLES) Virtual Machines on an
ESX
Server running VMWare.
But my Sys Admins here are refusing to allow RAW spaces and citing all
kinds
of vague, generalized reasons why, such as:
1) the "host administration utilities" will not fly right with Raw Spaces
but
will not be specific about what would go wrong. In general, my sense is
that
they feel that the Management Console and Tools for the ESX host might see
the
Raw Dbspace and, because it does not contain not a formatted filesystem,
allocate it to something on the box.
2) using raw space will not allow the VMs containing the IDS dbspaces to
be
backed up or fit into their backup strategy and backup utility.
They cannot seem to understand that a normal backup utility would not know
how
to deal with the dbspaces even if they were Cooked.
3) that the "little bit" of performance that they claim I might get with
Raw
will not pay back for the increased Sys Admin overhead.
4) that they will use a Journaled File System (along with Cooked
dbspaces) because it is more robust, fault-tolerant, comes back up quicker
after a crash, etc.
Can anybody provide me with any concrete information/experience that is
related to the above points, particularly (1) .
Does anyone know if raw dbspa
I was unaware there was more than 1 lv manager in SLES 11. I just used the one
in YaST2 under System->partitioner (which contains both a LVM and a standard
disc partitioner).
In my case I didn't use sym links for my chunks I used mknod to create nodes
to the device files, so I can't comment on if that will work or not. (this was
the recommendation of our software provider).
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Thursday, July 29, 2010 9:55 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20685]
Hi again Jonathon,
It is my understanding that SUSE Linux comes with more than
1 Logical Volume Manager.
If this is the case, can you tell me which one the concern that you mention
below applies to?
Also, one of our Sys Admins told me that at least one of the LVMs on Linux has
a built-in mechanism that I could take advantage of to avoid the pitfall that
you mention. The mechanism apparently involves a couple levels of symbolic
links for each device file.
He says that the system will dynamically change the lowest level link for a
device file at times, but that it will also update a higher level link, whose
name/path never changes, for the same device to reflect the change in the
underlying link. In other words, if I used the highest level link for a device
file in my creation of a db chunk, the pitfall you mention would be avoided.
I don't know if this mechanism that he told me about applied to all Logical
Volume Managers provide with SUSE and will check with him on that.
In the mean time, it would be useful if you could tell me the name of the LVM
that you know the situation you described happens with.
Thanks,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Wednesday, July 28, 2010 10:21 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20675]
There is a problem with the way that linux handles logical volumes with
informix. But it is easily fixable. By default the major/minor numbers for the
logical volume devices are assigned dynamically at boot. Because of this your
chunks could move, but informix wouldn't know where they went. You can set the
volumes to have static device numbers to fix that problem. Again, they don't
have to do ANYTHING.....
By and by the command would be something like this:
lvchange -M --major # --minor # "/dev/mapper/lg-lgname-lv-lvname"
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Wednesday, July 28, 2010 11:15 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20673]
Jonathon,
Thank you very much for the fast response and the below info.
At 2 pm I had to do battle with the Sys Admins here and your information, as
well as what Art has been saying all last week (and previous to that) about
Raw db chunks and issues, helped me argue my case.
As far as what I said and was worried about in issue (1) goes, either I
misunderstand what was rattled off to me this morning in a hurry about that or
they have changed their tune.
After talking to them, I was pretty sure that the admins, or perhaps just one
of them, were claiming that there could be issues with the ESX server
management/system software/ utilities affecting the raw db chunks in the VMs
that my Informix instances are in. You are right, that makes
0 sense. I thought so too at the time, but perhaps I misunderstood.
Because
now they are saying that their concern is that Linux system management stuff,
such as YAST, within the VMs that my Informix instances are in could mess with
my raw logical volumes used as Informix chunks. They said that they have to
configure some things inside the VMs so that they do not do that.
I have no Linux Sys Admin experience, just HP-UX.
If you are aware of anything that is part of Linux that might be a
consideration when I use raw logical volumes, please let me know if you get a
chance.
Thanks again for your help!
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Tuesday, July 27, 2010 2:23 PM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20663]
1) That makes 0 sense. Although you will be using raw spaces, the drives
themselves are allocated by the host for the client to use in any way it sees
fit, just have them allocate the space on drive creation instead of when it
needs it (just so you have sequential sectors on the discs). Raw spaces will
work fine in a virtual environment.
2) Backing it up using their utility is silly. Use ontap or onbar.
3) Little bit? try at least 20% increase. And what sys admin overhead are they
talking about?
4) JFS is exactly why you DON"T want cooked files. look at the thread about
performance issue with ZFS on this board just this week to see a nice long
explanation by Art about this.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
________________________________________
From: ids-bounces@iiug.org [ids-bounces@iiug.org] on behalf of Jim Cramer
[jim-cramer@uiowa.edu]
Sent: Tuesday, July 27, 2010 3:14 PM
To: ids@iiug.org
Subject: Are there issues when using RAW dbspaces on ID.... [20662]
HELP!
Here is another angle to the recent questions, and explanations by Art, et.
al, regarding using RAW instead of COOKED dbspaces on IDS 11.5 running on
Linux.
For reasons cited by Art and the others, I (the DBA) wish to use RAW dbspaces
when I move my instances to Linux (SUSE 11 SLES) Virtual Machines on an ESX
Server running VMWare.
But my Sys Admins here are refusing to allow RAW spaces and citing all kinds
of vague, generalized reasons why, such as:
1) the "host administration utilities" will not fly right with Raw Spaces but
will not be specific about what would go wrong. In general, my sense is that
they feel that the Management Console and Tools for the ESX host might see the
Raw Dbspace and, because it d
Thanks for the clarification Jonathon.
I was told there was more than 1 LVM, in SLES 11, but
I have also been told some other things by our Sys
Admins that have turned out to be way wrong, as you
all have seen in this thread. Strange, because the
person who told me uses YAST2 also...
Oh well, I will check out your info below personally as soon as
they give me the SLES 11 VM.
Thanks again,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Thursday, July 29, 2010 9:34 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20687]
I was unaware there was more than 1 lv manager in SLES 11. I just used the
one
in YaST2 under System->partitioner (which contains both a LVM and a standard
disc partitioner).
In my case I didn't use sym links for my chunks I used mknod to create nodes
to the device files, so I can't comment on if that will work or not. (this
was
the recommendation of our software provider).
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Thursday, July 29, 2010 9:55 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20685]
Hi again Jonathon,
It is my understanding that SUSE Linux comes with more than
1 Logical Volume Manager.
If this is the case, can you tell me which one the concern that you mention
below applies to?
Also, one of our Sys Admins told me that at least one of the LVMs on Linux
has
a built-in mechanism that I could take advantage of to avoid the pitfall
that
you mention. The mechanism apparently involves a couple levels of symbolic
links for each device file.
He says that the system will dynamically change the lowest level link for a
device file at times, but that it will also update a higher level link,
whose
name/path never changes, for the same device to reflect the change in the
underlying link. In other words, if I used the highest level link for a
device
file in my creation of a db chunk, the pitfall you mention would be avoided.
I don't know if this mechanism that he told me about applied to all Logical
Volume Managers provide with SUSE and will check with him on that.
In the mean time, it would be useful if you could tell me the name of the
LVM
that you know the situation you described happens with.
Thanks,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Wednesday, July 28, 2010 10:21 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20675]
There is a problem with the way that linux handles logical volumes with
informix. But it is easily fixable. By default the major/minor numbers for
the
logical volume devices are assigned dynamically at boot. Because of this
your
chunks could move, but informix wouldn't know where they went. You can set
the
volumes to have static device numbers to fix that problem. Again, they don't
have to do ANYTHING.....
By and by the command would be something like this:
lvchange -M --major # --minor # "/dev/mapper/lg-lgname-lv-lvname"
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Wednesday, July 28, 2010 11:15 AM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20673]
Jonathon,
Thank you very much for the fast response and the below info.
At 2 pm I had to do battle with the Sys Admins here and your information, as
well as what Art has been saying all last week (and previous to that) about
Raw db chunks and issues, helped me argue my case.
As far as what I said and was worried about in issue (1) goes, either I
misunderstand what was rattled off to me this morning in a hurry about that
or
they have changed their tune.
After talking to them, I was pretty sure that the admins, or perhaps just
one
of them, were claiming that there could be issues with the ESX server
management/system software/ utilities affecting the raw db chunks in the VMs
that my Informix instances are in. You are right, that makes
0 sense. I thought so too at the time, but perhaps I misunderstood.
Because
now they are saying that their concern is that Linux system management
stuff,
such as YAST, within the VMs that my Informix instances are in could mess
with
my raw logical volumes used as Informix chunks. They said that they have to
configure some things inside the VMs so that they do not do that.
I have no Linux Sys Admin experience, just HP-UX.
If you are aware of anything that is part of Linux that might be a
consideration when I use raw logical volumes, please let me know if you get
a
chance.
Thanks again for your help!
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Tuesday, July 27, 2010 2:23 PM
To: ids@iiug.org
Subject: RE: Are there issues when using RAW dbspaces o.... [20663]
1) That makes 0 sense. Although you will be using raw spaces, the drives
themselves are allocated by the host for the client to use in any way it
sees
fit, just have them allocate the space on drive creation instead of when it
needs it (just so you have sequential sectors on the discs). Raw spaces will
work fine in a virtual environment.
2) Backing it up using their utility is silly. Use ontap or onbar.
3) Little bit? try at least 20% increase. And what sys admin overhead are
they
talking about?
4) JFS is exactly why you DON"T want cooked files. look at the thread about
performance issue with ZFS on this board just this week to see a nice long
explanation by Art about this.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-257-3381
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
==============================
SLES 11x64 & IDS 11.50.FC6
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
________________________________________
From: ids-bounces@iiug.org [ids-bounces@iiug.org] on behalf of Jim Cramer
[jim-cramer@uiowa.edu]
Sent: Tuesday, July 27, 2010 3:14 PM
To: ids@iiug.org
Subject: Are there issues when usin