Jamie,
Thanks for the idea. I need a bit more info if you have time..
1. What is the OS and Version that you are running IDS on?
2. And if Linux, is it the Open Edition or the Enterprise Edition?
3. If it is on Linux, is the OS using the "device mapper". You
can tell by looking in /dev for a directory called mapper.
If it is there, you should find the actual block device files
that the system's Logical Volume Manager created if you used
it to partition a disk.
If you did, then the device files are in /etc/mapper instead
of in /dev/VolGrpxx (where xx is the Volume Group Number that
the Logical Volumes were created from), and in this directory
are symbolic links, instead of the actual LV device files,
which point to the actual device files in /dev/mapper.
Again, does your system use this mapper functionality? It is important
for me to know in order to know whether I will be able to
get away with using the method that you use and have explained
below.
Please let me know the answers to these questions if you
have the time.
Thanks again,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Jamie
Gedye
Sent: Friday, June 17, 2011 12:16 PM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24078]
We use the same concept with creating sym links to the actual LVM devices.
The difference is that we create our own block devices that use the same
major,minor numbers as the LVM device and then point the sym links to the
ones we created.
For example:
LVM device:
brw-rw---- 1 root disk 253, 8 May 13 11:37 dm-8 (notice the major,minor is
253,8)
We have a directory called /ifxslices/blockdevices that has our created
devices. Use the mknod command to create the device.
brw-rw----. 1 informix informix 253, 8 Jun 17 07:33
/ifxslices/blockdevices/rootdbs (notice that the major,minor numbers are
the same as the LVM device, and the permissions/ownership are set the way
informix needs them to be).
Lastly, we create sym links to point to our block devices and use them in
the creation of the dbspaces.
lrwxrwxrwx. 1 informix informix 20 May 2 15:12 /ifxslices/rootdbs ->
blockdevices/rootdbs
This way there's in a script or anything that needs to be run on every
machine boot to make sure that the devices are setup the way you need them
to be. Just make sure to protect the directory that you put everything in
so that there's no chance to somebody removing them accidently.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Friday, June 17, 2011 9:57 AM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24077]
Hi Art,
Thanks for answering this and I understand.
I will figure out the details of this SuSE device file symbolic link
shuffling. Or, if anyone who happens to read this knows what to point the
Symbolic Links the DBA creates for the Informix Chunks at, please post it or
email me.
Again, I owe you major thanks Art for the information and clever way of
finding out which Informix Chunk# every device file had been assigned, in
the case that the Symbolic Links used to create the Chunks in Informix get
blown away and have to be recreated.
I could not have gotten anywhere without that info.
Much appreciated,
Jim Cramer
Univ of Iowa
jim-cramer@uiowa.edu
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: Friday, June 17, 2011 9:09 AM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24076]
>
> I haven't used SUSE with Informix myself. I use Ubuntu here at home
> but with simple files and DIRECT_IO just for simplicity of mgt. At
> ADTC out main servers are on Sun/Solaris and the training servers are
> SUSE but again just using simple files. When clients have systems for
> me to configure, I try not to get involved in the "how" of
> implementing the storage whenever I can. I haven't done serious SA
> work in 20 years or more so I try to stay out.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> 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 Fri, Jun 17, 2011 at 9:41 AM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Thanks again Art.
> >
> > I will check what you suggest.
> >
> > Regarding using IDS on Linux SuSE 11 SLES, have you setup IDS on
> > that OS?
> >
> > If you have, was the" device-mapper"
> > functionality turned on and the LVM for the system creating the
> > device files for the LVs in/ dev/mapper?
> >
> > If you have encountered this scenario, then did you point your
> > symbolic link for the chunks directly at the device files in.
> > /dev/mapper, or did you point your links at the links in
> > /dev/VolGrpxx, which, in turn, point to the device files in/
> > dev/mapper??
> >
> > Jim
> >
> > Connected by DROID on Verizon Wireless Connected by DROID on Verizon
> > Wireless
> >
> > -----Original message-----
> >
> > From: Art Kagel <art.kagel@gmail.com>
> > To: ids@iiug.org
> > Sent: Thu, Jun 16, 2011 23:03:59 GMT+00:00
> > Subject: Re: is there a way to find out the physical de.... [24068]
> >
> > Errno 2 is permissions (EPERM). Make sure that all of the low level
> chunk
> > devices are informix:informix with 0660 privileges and make sure
> > that
> the
> > links themselves are 777 (owner of the links doesn't really matter,
> but I
> > usually make them informix:informix also).
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > Blog: http://informix-myview.blogspot.com/
> >
> > 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> > wrote:
> >
> > > Hi Art,
> > >
> > > Well, no doubt about it, you are THE MAN! I *almost* have the
> server
> > > back up (see below). Good news and bad news.
> > >
> > > Thanks very much for the clever way of recreating lost symbolic
> links
> > > used originally to create chunks and pointing these links at the
> actual
> > > chunk device file paths/names. This method is based upon your
> expert
> > > knowledge
> > > of chunk storage internals.
> > >
> > > I used your method to get the chunk number for each chunk/block
> device
> > > file (using RAW chunks), looked for that number in the oncfg
> > > file's "Chunks" section, got the name of the symbolic link used to
> > > create the chunk from that line in the file, and created a script
> > > to
> recreate
> > > the symbolic links/pathnames that had been used in the onspaces
> commands
> > > that created the chunks.
> > >
> > > The server begins to start with the "oninit" command, but it
> ABORTS.
> > > According to the online.log file, it gets quite a ways through
> startup
> > > but finds something wrong, Errno 2 (missing file or directory?)
> > > with chunk 1, my rootdbs. I have included the tail end of the log
> file,
> > > starting just before the warning about chunk 1, continuing to the
> end.
> > >
> > > Any ideas? It seems like perhaps I made a mistake with the
> > > creation
> of
> > > the symbolic link for rootdbs, but it looks OK I think. The "ls -l"
> of it
> > > produces:
> > >
> > > lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> > > /dev/VolGrp01/vol01
> > >
> > > and the rootdbs link points to another link, and ls -l on that
> > > link
> > > produces:
> > >
> > > lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> > > /dev/mapper/VolGrp01-vol01
> > >
> > > and ls -l on the target of that link, the block device file for
> > > the
> LV
> > that
> > > I used to create Chunk 1 with, produces:
> > >
> > > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> > > /dev/mapper/VolGrp01-vol01
> > >
> > > The "ls -lL /dev/rootdbs" command produces:
> > >
> > > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
> > >
> > > I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from
> HPUX to
> > it.
> > > I
> > > do not really understand the "device-mapper" Linux functionality
> that is
> > > creating
> > > symbolic links instead of Logical Volume device files in the
> traditional
> > > directory
> > > created for the Volume Group that the LVs belong to, and pointing
> those
> > > links in
> > > the VG dir to /dev/mapper, where the device files for the LV
> actually
> > > reside.
> > >
> > > So, due to my lack of knowledge of mapper, the following might be
> the
> > > problem and
> > > I would appreciate your opinion on it.
> > >
> > > Originally I created the sym links in /dev to point straight at
> > > the
> > device
> > > file
> > > in /dev/mapper. For example, the rootdbs was created with:
> > >
> > > ln -s /dev/mapper/VolGrp01-vol01b /dev/rootdbs
> > >
> > > However, due to some discussions with our Linux Sys Admins here, I
> have
> > > recreated
> > > the links in /dev to point to the sym links in the /dev/vgxx dir,
> which
> > > then
> > > point
> > > to the actual device files that I have set the ownershiip and
> permissions
> > > on
> > >
> > > correctly.
> > >
> > > The rootdbs was created with the path /dev/rootdbs, and the "ls -
> lL" on
> > > that
> > > sym link/path
> > > shows the target of this double-linking to be:
> > >
> > > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
> > >
> > > which looks OK permissions and ownership-wise, but perhaps the
> double
> > > linking is the problem?
> > >
> > > What do you think? Sorry this is so long. Thanks for bearing with
> me.
> > >
> > > Jim
> > >
> > > 15:30:20 Event notification facility epoll enabled.
> > > 15:30:20 IBM Informix Dynamic Server Version 11.70.FC1GE Software
> Serial
> > > Number AAA#B000000
> > > 15:30:20 Warning: stat() failed for chunk file /dev/rootdbs
> > > 15:30:22 IBM Informix Dynamic Server Initialized -- Shared Memory
> > > Initialized.
> > >
> > > 15:30:22 Started 1 B-tree scanners.
> > > 15:30:22 B-tree scanner threshold set at 5000.
> > > 15:30:22 B-tree scanner range scan size set to -1.
> > > 15:30:22 B-tree scanner ALICE mode set to 6.
> > > 15:30:22 B-tree scanner index compression level set to med.
> > > 15:30:22 Physical Recovery Started at Page (2:131643).
> > > 15:30:23 Physical Recovery Complete: 8 Pages Examined, 8 Pages
> Restored.
> > > 15:30:23 Logical Recovery Started.
> > > 15:30:23 Dynamically allocated new virtual shared memory segment
> (size
> > > 8192KB)
> > > 15:30:23 Memory sizes:resident:192512 KB, virtual:253840 KB,
> > > SHMTOTAL:16777216 KB
> > > 15:30:23 10 recovery worker threads will be started.
> > > 15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1
> -->
> > > errno = 2
> > > 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> > > 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
> > >
> > > Thread(29, xchg_1.2, 502519a8, 3)
> > >
> > > File: rsbuff.c Line: 6302
> > > 15:30:23 Action: Please notify IBM Informix Technical Support.
> > > 15:30:23 stack trace for pid 12822 written to
> /opt/db/ids/tmp/af.40567de
> > > 15:30:23 See Also: /opt/db/ids/tmp/af.40567de
> > > 15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
> > > 15:30:23 Rollforward of log record failed. iserrno = 126
> > > 15:30:23 Log Record: log = 27, pos = 0x3ef8518, type =
> > OLDRSAM:HINSERT(40),
> > > trans = 26
> > > 15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
> > >
> > > Critical media failure.
> > > 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> > > 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
> > >
> > > Thread(29, xchg_1.2, 502519a8, 3)
> > >
> > > File: rsmirror.c Line: 1734
> > > 15:30:23 stack trace for pid 12822 written to
> /opt/db/ids/tmp/af.40567de
> > > 15:30:23 See Also: /opt/db/ids/tmp/af.40567de, shmem.40567de.0
> > > 15:30:28 Starting crash time check of:
> > > 15:30:28 1. memory block headers
> > > 15:30:28 2. stacks
> > > 15:30:28 Crash time checking found no problems
> > > 15:30:28 rsmirror.c, line 1734, thread 29, proc id 12822,
> > > INFORMIX-
> OnLine
> > > Must ABORT
> > >
> > > Critical media failure..
> > > 15:30:29 Fatal error in ADM VP at mt.c:14250
> > > 15:30:29 Unexpected virtual processor termination, pid = 12822,
> exit =
> > > 0x100
> > >
> > > 15:30:29 PANIC: Attempting to bring system down
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> Of
> > Art
> > > Kagel
> > > Sent: Thursday, June 16, 2011 1:34 PM
> > > To: ids@iiug.org
> > > Subject: Re: is there a way to find out the physical de....
> > > [24060]
> > >
> > > Unfortunately, no. Informix only stored the links you provide, it
> does
> > not
> > > follow the links to their core names at all, it depends on the OS
> to
> > > maintain and promote the links.
> > >
> > > HOWEVER, there is one way. Use dd piped to od -x to read the first
> few
> > > pages (so 2K each if you used the default pagesize or whatever the
> > pagesize
> > > of the dbspaces were) of each chunk's physical device. The first
> six
> > bytes
> > > of each page have the chunk number encoded. So on my server for
> chunk #1:
> > >
> > > $ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/rootdb.1.chunk
> bs=2k
> > > count=2|od -x
> > > 2+0 records in
> > > 2+0 records out
> > > 4096 bytes (4.1 kB) copied, 0.00441886 s, 927 kB/s 0000000 *0000
> > > 0000 0001* 9600 0003 1800 0130 06c0 0000020 0000 0000 0000 0000
> > > 4249 204d 6e49 6f66
> > >
> > > For chunk #6:
> > >
> > > $ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/tempdbs1.1.chunk
> bs=2k
> > > count=1|od -x
> > > 1+0 records in
> > > 1+0 records out
> > > 2048 bytes (2.0 kB) copied, 7.7661e-05 s, 26.4 MB/s 0000000 *0000
> > > 0000 0006* 492e 0000 1800 0018 07e4 0000020 0000 0000 0000 0000
> > > 0000 0000 0000 0000
> > >
> > > Armed with the chunk numbers you should be able to recreate the
> links.
> > >
> > > Art S. Kagel
> > > Advanced DataTools (www.advancedatatools.com)
> > > Blog: http://informix-myview.blogspot.com/
> > >
> > > 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 Thu, Jun 16, 2011 at 2:23 PM, jim-cramer@uiowa.edu
> > > wrote:
> > >
> > > > Help!
> > > >
> > > > 11.70.FC1 on Linux SUSE 11 SLES
> > > >
> > > > After setting up a 11.7 IDS instance and creating a bunch of
> > > > Logical Volumes, creating Symbolic Links in /dev that pointed to
> > > > the block device files that the LV Manager created, changing the
> > > > ownership and permission on these device files appropriately,
> > > > creating dbspaces from the chunks *using the Symbolic Link
> > > > pathnames* to the chunk device files, I found out that when the
> > > > Linux system was rebooted all of the Symbolic Links for my
> > > > Informix Chunks were deleted from /dev (and also that the
> > > > ownership and permissions for the chunk devices files had
> > > > reverted to my pre-configured state).
> > > >
> > > > I need to re-create the symbolic links for the chunks, in some
> > > > non-system directory I assume.
> > > >
> > > > The names of the symbolic links that I created indicated what
> > > > dbspace the each chunk belonged to. I have those link names
> in
> > > > my $INFORMIXDIR/etc/oncfg_servername.0 file as the pathname to
> > > > each Chunks.
> > > >
> > > > UNFORTUNATELY, the names that I gave the Logical Volumes, and
> > > > hence the names of the devices files created for the LVs/Chunks,
> > > > did not indicate which Chunk/DBSpace each was created for (i.e.:
> > > > I used a systematic pattern vol01, vol02, vol02,...)
> > > >
> > > > So, I need a way to find out the physical device file pathname
> > > > that each of the symbolic links had pointed to, so that I can
> > > > recreate the links correctly.
> > > >
> > > > OR
> > > >
> > > > since those links have been blown away by the OS and the
> > > > instance is down, is there a file somewhere where I would find this
info?
> > > >
> > > > Or
> > > >
> > > > is there an Informix Utility that can be run against a down
> instance
> > > > that would list out the chunks that had been created for that
> instance
> > > > along with the physical device file pathname for each?
> > > >
> > > > Any information or ideas would be appreciated.
> > > >
> > > > Thanks,
> > > >
> > > > Jim Cramer
> > > > Univ of Iowa
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> **********************************************************************
> *
> *****
> > > ***
> > > > Forum Note: Use "Reply" to post a response in the discussion
> forum.
> > > >
> > > >
> > >
> > > --bcaec5016349fe9e0304a5d882f3
> > >
> > >
> > >
> >
> **********************************************************************
> *
> *****
> > > ***
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> > >
> > >
> >
> >
> >
> **********************************************************************
> *
> ********
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --bcaec51a7e3ed80ad604a5dc379a
> >
> >
> >
> >
> **********************************************************************
> *
> ********
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
> **********************************************************************
> *
> ********
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --20cf3071c696c8a2d004a5e8ed25
>
>
> **********************************************************************
> *
> ********
> 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.
