dbimport : symbolic links to xxx.unl files
Jacques planned to upgrade IDS 9.21 to 9.40 on Solaris 8 and dbexport/dbimport a ~40GB database split across two filesystems. Art Kagel confirmed symbolic links to .unl files on the second filesystem work fine for dbimport, and that 'onmode -BC 1' (large chunks) is unrelated to the tools' large-file support. However, a test UNLOAD via isql still failed at exactly 2GB (error -852), though a 2.3GB file could be created manually, ruling out an OS/filesystem limit. Others suggested the HPL, or unloading to a named pipe fed into gzip (and reversing it for loading). The thread ends without the poster confirming a fix.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi guys, anyone has experience on this ?
I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an upgrade
to IDS 9.40 and afterwards a complete reorganisation of the databases.
First question :
In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and execute the
onmode -BC 1 command to allow big chunks. After that I suppose I can usedbexport to unload the data. (I will test to unload a table >2 Gb).
Second question :
I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and 1 x 21 Gb).
The database contains about 40 Gb, so during the dbexport I will move the
files already written to the second filesystem.
Now to do the dbimport, several files will be located on the second filesystem
instead of on the one indicated in the xxx.sql file
If I create symbolic links in the first filesystem, pointing to the xxx.unl
files located in the second filesystem, will dbimport work fine ?
Thanks for any replies.
Jacques Lapeire
Yes, that will work fine. The dbexport doesn't need the large chunk support
though, that's independent of the large file support in the tools, so you
can skip that step until later if you want to rebuild the instance with
larger chunks.
On Thu, May 22, 2008 at 7:59 AM, JACQUES LAPEIRE <
jacques.lapeire@siemens.com> wrote:
> Hi guys, anyone has experience on this ?
>
> I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an
> upgrade
> to IDS 9.40 and afterwards a complete reorganisation of the databases.
>
> First question :
>
> In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and execute
> the
> onmode -BC 1 command to allow big chunks. After that I suppose I can use> dbexport to unload the data. (I will test to unload a table >2 Gb).
>
> Second question :
>
> I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and 1 x 21
> Gb).
> The database contains about 40 Gb, so during the dbexport I will move the
> files already written to the second filesystem.
> Now to do the dbimport, several files will be located on the second
> filesystem
> instead of on the one indicated in the xxx.sql file
>
> If I create symbolic links in the first filesystem, pointing to the xxx.unl
> files located in the second filesystem, will dbimport work fine ?
>
> Thanks for any replies.
>
> Jacques Lapeire
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.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, Oninit, the IIUG, nor any other organization
with which I am associated either explicitely or implicitely. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
Thanks for your reply Art,
so to be sure I understand correctly :
- I do not need to give onmode -BC 1
- after the upgrade to 9.40 , dbexport will unload tables > 2 Gb
- the dbimport with symbolic links will work
Thx and best regards
Jacques
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Art Kagel
Sent: donderdag 22 mei 2008 14:40
To: ids@iiug.org
Subject: Re: dbimport : symbolic links to xxx.unl files [12182]
Yes, that will work fine. The dbexport doesn't need the large chunk
support
though, that's independent of the large file support in the tools, so
you
can skip that step until later if you want to rebuild the instance with
larger chunks.
On Thu, May 22, 2008 at 7:59 AM, JACQUES LAPEIRE <
jacques.lapeire@siemens.com> wrote:
> Hi guys, anyone has experience on this ?
>
> I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an
> upgrade
> to IDS 9.40 and afterwards a complete reorganisation of the databases.
>
> First question :
>
> In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and
execute
> the
> onmode -BC 1 command to allow big chunks. After that I suppose I canuse
> dbexport to unload the data. (I will test to unload a table >2 Gb).
>
> Second question :
>
> I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and 1
x 21
> Gb).
> The database contains about 40 Gb, so during the dbexport I will move
the
> files already written to the second filesystem.
> Now to do the dbimport, several files will be located on the second
> filesystem
> instead of on the one indicated in the xxx.sql file
>
> If I create symbolic links in the first filesystem, pointing to the
xxx.unl
> files located in the second filesystem, will dbimport work fine ?
>
> Thanks for any replies.
>
> Jacques Lapeire
>
>
>
>
************************************************************************
*******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.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, Oninit, the IIUG, nor any other
organization
with which I am associated either explicitely or implicitely. Neither do
those opinions reflect those of other individuals affiliated with any
entity
with which I am affiliated nor those of the entities themselves.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
Yes.
Art
On Thu, May 22, 2008 at 8:46 AM, Lapeire, Jacques <
jacques.lapeire@siemens.com> wrote:
> Thanks for your reply Art,
>
> so to be sure I understand correctly :
>
> - I do not need to give onmode -BC 1
> - after the upgrade to 9.40 , dbexport will unload tables > 2 Gb
> - the dbimport with symbolic links will work
>
> Thx and best regards
> Jacques
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: donderdag 22 mei 2008 14:40
> To: ids@iiug.org
> Subject: Re: dbimport : symbolic links to xxx.unl files [12182]
>
> Yes, that will work fine. The dbexport doesn't need the large chunk
> support
> though, that's independent of the large file support in the tools, so
> you
> can skip that step until later if you want to rebuild the instance with
> larger chunks.
>
> On Thu, May 22, 2008 at 7:59 AM, JACQUES LAPEIRE <
> jacques.lapeire@siemens.com> wrote:
>
> > Hi guys, anyone has experience on this ?
> >
> > I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an
> > upgrade
> > to IDS 9.40 and afterwards a complete reorganisation of the databases.
>
> >
> > First question :
> >
> > In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and
> execute
> > the
> > onmode -BC 1 command to allow big chunks. After that I suppose I can> use
> > dbexport to unload the data. (I will test to unload a table >2 Gb).
> >
> > Second question :
> >
> > I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and 1
> x 21
> > Gb).
> > The database contains about 40 Gb, so during the dbexport I will move
> the
> > files already written to the second filesystem.
> > Now to do the dbimport, several files will be located on the second
> > filesystem
> > instead of on the one indicated in the xxx.sql file
> >
> > If I create symbolic links in the first filesystem, pointing to the
> xxx.unl
> > files located in the second filesystem, will dbimport work fine ?
> >
> > Thanks for any replies.
> >
> > Jacques Lapeire
> >
> >
> >
> >
> ************************************************************************
> *******
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Art S. Kagel
> Oninit (www.oninit.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, Oninit, the IIUG, nor any other
> organization
> with which I am associated either explicitely or implicitely. Neither do
>
> those opinions reflect those of other individuals affiliated with any
> entity
> with which I am affiliated nor those of the entities themselves.
>
> ************************************************************************
> *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.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, Oninit, the IIUG, nor any other organization
with which I am associated either explicitely or implicitely. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
Hi Art,
sorry, but this time I have some doubts.
Yesterday evening I upgraded from 9.21 to 9.40 and did not yet give the
"onmode -BC 1" command.
admi:/var/adm >onstat -d
IBM Informix Dynamic Server Version 9.40.UC7 -- On-Line -- Up
13:35:04 -- 315392 Kbytes
. . . . . .. . . . . .
Expanded chunk capacity mode: disabled
As a test (before we start the reorganisaton in a couple of weeks) I
tried to unload a big table
with the following command :
isql apare - << OEF
unload to /unload1/cptmvt.unl select * from cptmvtOEF
The table contained 13 254 335 rows and after 7 383 874 rows the unload
failed.
Write failed. 7383874 rows unloaded (check ulimit or disk space).
1380: Write failed. rows unloaded (check ulimit or disk space).
See error -852.
Error in line 1
Near character position 30
As you can see below the size of the unload file is exactly the 2 Gb
limit, the filesystem is not full yet
and the ulimit command indicates unlimited for the file-size on
OS-level. (Solaris 8 on sparc)
So I think there must be a relationship anyway between the 'onmode -BC"
and the tools ?
I fear that the dbexport will not work either.
I think I will give the "onmode -BC 1" and try the unload again, or is
there something else I'm missing ?
Best regards,
Jacques Lapeire
admi:/var/adm >df -k /unload1
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t1d48s6 11531755 3809297 7607141 34% /unload1
admi:/ >ls -l /unload1
total 7595680
-rw-rw-rw- 1 root other 2147483647 Jun 4 23:17 cptmvt.unl
drwx------ 2 root root 8192 May 26 16:22 lost+found
-rw-rw-rw- 1 root other 1739576372 Jun 4 21:52 tiemvt.unl
admi:/ >wc -l /unload1/*unl
7383874 /unload1/cptmvt.unl
8312979 /unload1/tiemvt.unl
15696853 total
admi:/ >isql apare - <<OEF
select count(*) from cptmvtOEF
(count(*))
13254573 ===> some rows are already added at this time
1 row(s) retrieved.
admi:/ >ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 256
vmemory(kbytes) unlimited
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Art Kagel
Sent: donderdag 22 mei 2008 14:54
To: ids@iiug.org
Subject: Re: dbimport : symbolic links to xxx.unl files [12186]
Yes.
Art
On Thu, May 22, 2008 at 8:46 AM, Lapeire, Jacques <
jacques.lapeire@siemens.com> wrote:
> Thanks for your reply Art,
>
> so to be sure I understand correctly :
>
> - I do not need to give onmode -BC 1
> - after the upgrade to 9.40 , dbexport will unload tables > 2 Gb
> - the dbimport with symbolic links will work
>
> Thx and best regards
> Jacques
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: donderdag 22 mei 2008 14:40
> To: ids@iiug.org
> Subject: Re: dbimport : symbolic links to xxx.unl files [12182]
>
> Yes, that will work fine. The dbexport doesn't need the large chunk
> support
> though, that's independent of the large file support in the tools, so
> you
> can skip that step until later if you want to rebuild the instance
with
> larger chunks.
>
> On Thu, May 22, 2008 at 7:59 AM, JACQUES LAPEIRE <
> jacques.lapeire@siemens.com> wrote:
>
> > Hi guys, anyone has experience on this ?
> >
> > I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an
> > upgrade
> > to IDS 9.40 and afterwards a complete reorganisation of the
databases.
>
> >
> > First question :
> >
> > In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and
> execute
> > the
> > onmode -BC 1 command to allow big chunks. After that I suppose I can
> use
> > dbexport to unload the data. (I will test to unload a table >2 Gb).
> >
> > Second question :
> >
> > I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and
1
> x 21
> > Gb).
> > The database contains about 40 Gb, so during the dbexport I will
move
> the
> > files already written to the second filesystem.
> > Now to do the dbimport, several files will be located on the second
> > filesystem
> > instead of on the one indicated in the xxx.sql file
> >
> > If I create symbolic links in the first filesystem, pointing to the
> xxx.unl
> > files located in the second filesystem, will dbimport work fine ?
> >
> > Thanks for any replies.
> >
> > Jacques Lapeire
> >
> >
> >
> >
>
************************************************************************
> *******
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Art S. Kagel
> Oninit (www.oninit.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, Oninit, the IIUG, nor any other
> organization
> with which I am associated either explicitely or implicitely. Neither
do
>
> those opinions reflect those of other individuals affiliated with any
> entity
> with which I am affiliated nor those of the entities themselves.
>
>
************************************************************************
> *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
************************************************************************
*******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.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, Oninit, the IIUG, nor any other
organization
with which I am associated either explicitely or implicitely. Neither do
those opinions reflect those of other individuals affiliated with any
entity
with which I am affiliated nor those of the entities themselves.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
Hi Jacques,
I'm not a specialist of Solaris but I think you could have limitation with
your file-system.
For example, I had the same problem on an old AIX 32 bits with a JFS
(Journalized File System) created with default parameters.
Try to create a big file on your file system with a Unix tool like dd.
________________________________
"Lapeire, Jacques" <jacques.lapeire@siemens.com>
Sent by: ids-bounces@iiug.org
05/06/2008 10:15
Please respond to
ids@iiug.org
To
ids@iiug.org
cc
Subject
RE: dbimport : symbolic links to xxx.unl files [12316]
Hi Art,
sorry, but this time I have some doubts.
Yesterday evening I upgraded from 9.21 to 9.40 and did not yet give the
"onmode -BC 1" command.
admi:/var/adm >onstat -d
IBM Informix Dynamic Server Version 9.40.UC7 -- On-Line -- Up
13:35:04 -- 315392 Kbytes
.. . . . . .. . . . . .
Expanded chunk capacity mode: disabled
As a test (before we start the reorganisaton in a couple of weeks) I
tried to unload a big table
with the following command :
isql apare - << OEF
unload to /unload1/cptmvt.unl select * from cptmvtOEF
The table contained 13 254 335 rows and after 7 383 874 rows the unload
failed.
Write failed. 7383874 rows unloaded (check ulimit or disk space).
1380: Write failed. rows unloaded (check ulimit or disk space).
See error -852.
Error in line 1
Near character position 30
As you can see below the size of the unload file is exactly the 2 Gb
limit, the filesystem is not full yet
and the ulimit command indicates unlimited for the file-size on
OS-level. (Solaris 8 on sparc)
So I think there must be a relationship anyway between the 'onmode -BC"
and the tools ?
I fear that the dbexport will not work either.
I think I will give the "onmode -BC 1" and try the unload again, or is
there something else I'm missing ?
Best regards,
Jacques Lapeire
admi:/var/adm >df -k /unload1
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t1d48s6 11531755 3809297 7607141 34% /unload1
admi:/ >ls -l /unload1
total 7595680
-rw-rw-rw- 1 root other 2147483647 Jun 4 23:17 cptmvt.unl
drwx------ 2 root root 8192 May 26 16:22 lost+found
-rw-rw-rw- 1 root other 1739576372 Jun 4 21:52 tiemvt.unl
admi:/ >wc -l /unload1/*unl
7383874 /unload1/cptmvt.unl
8312979 /unload1/tiemvt.unl
15696853 total
admi:/ >isql apare - <<OEF
select count(*) from cptmvtOEF
(count(*))
13254573 ===> some rows are already added at this time
1 row(s) retrieved.
admi:/ >ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 256
vmemory(kbytes) unlimited
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Art Kagel
Sent: donderdag 22 mei 2008 14:54
To: ids@iiug.org
Subject: Re: dbimport : symbolic links to xxx.unl files [12186]
Yes.
Art
On Thu, May 22, 2008 at 8:46 AM, Lapeire, Jacques <
jacques.lapeire@siemens.com> wrote:
> Thanks for your reply Art,
>
> so to be sure I understand correctly :
>
> - I do not need to give onmode -BC 1
> - after the upgrade to 9.40 , dbexport will unload tables > 2 Gb
> - the dbimport with symbolic links will work
>
> Thx and best regards
> Jacques
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: donderdag 22 mei 2008 14:40
> To: ids@iiug.org
> Subject: Re: dbimport : symbolic links to xxx.unl files [12182]
>
> Yes, that will work fine. The dbexport doesn't need the large chunk
> support
> though, that's independent of the large file support in the tools, so
> you
> can skip that step until later if you want to rebuild the instance
with
> larger chunks.
>
> On Thu, May 22, 2008 at 7:59 AM, JACQUES LAPEIRE <
> jacques.lapeire@siemens.com> wrote:
>
> > Hi guys, anyone has experience on this ?
> >
> > I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an
> > upgrade
> > to IDS 9.40 and afterwards a complete reorganisation of the
databases.
>
> >
> > First question :
> >
> > In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and
> execute
> > the
> > onmode -BC 1 command to allow big chunks. After that I suppose I can
> use
> > dbexport to unload the data. (I will test to unload a table >2 Gb).
> >
> > Second question :
> >
> > I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and
1
> x 21
> > Gb).
> > The database contains about 40 Gb, so during the dbexport I will
move
> the
> > files already written to the second filesystem.
> > Now to do the dbimport, several files will be located on the second
> > filesystem
> > instead of on the one indicated in the xxx.sql file
> >
> > If I create symbolic links in the first filesystem, pointing to the
> xxx.unl
> > files located in the second filesystem, will dbimport work fine ?
> >
> > Thanks for any replies.
> >
> > Jacques Lapeire
> >
> >
> >
> >
>
************************************************************************
> *******
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Art S. Kagel
> Oninit (www.oninit.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, Oninit, the IIUG, nor any other
> organization
> with which I am associated either explicitely or implicitely. Neither
do
>
> those opinions reflect those of other individuals affiliated with any
> entity
> with which I am affiliated nor those of the entities themselves.
>
>
************************************************************************
> *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
************************************************************************
*******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.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, Oninit, the IIUG, nor any other
organization
with which I am associated either explicitely or implicitely. Neither do
those opinions reflect those of other individuals affiliated with any
entity
with which I am affiliated nor those of the entities themselves.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply@
Hi Philippe,
as you can see below, it's no OS-limit, I created a file 'lapj.big' that
passes the 2 Gb limit .
admi:/unload1 >ls -l
total 12109248
-rw-rw-rw- 1 root other 2147483647 Jun 4 23:17 cptmvt.unl
-rw-rw-rw- 1 root other 2309804000 Jun 5 15:54 lapj.big <====== BIG FILE
drwx------ 2 root root 8192 May 26 16:22 lost+found
-rw-rw-rw- 1 root other 1739576372 Jun 4 21:52 tiemvt.unl
Thanks anyway, so I tested this possibility and can eliminate it.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Philippe
Pignon1
Sent: donderdag 5 juni 2008 10:54
To: ids@iiug.org
Subject: RE: dbimport : symbolic links to xxx.unl files [12317]
Hi Jacques,
I'm not a specialist of Solaris but I think you could have limitation with
your file-system.
For example, I had the same problem on an old AIX 32 bits with a JFS
(Journalized File System) created with default parameters.
Try to create a big file on your file system with a Unix tool like dd.
________________________________
"Lapeire, Jacques" <jacques.lapeire@siemens.com>
Sent by: ids-bounces@iiug.org
05/06/2008 10:15
Please respond to
ids@iiug.org
To
ids@iiug.org
cc
Subject
RE: dbimport : symbolic links to xxx.unl files [12316]
Hi Art,
sorry, but this time I have some doubts.
Yesterday evening I upgraded from 9.21 to 9.40 and did not yet give the
"onmode -BC 1" command.
admi:/var/adm >onstat -d
IBM Informix Dynamic Server Version 9.40.UC7 -- On-Line -- Up
13:35:04 -- 315392 Kbytes
... . . . . .. . . . . .
Expanded chunk capacity mode: disabled
As a test (before we start the reorganisaton in a couple of weeks) I
tried to unload a big table
with the following command :
isql apare - << OEF
unload to /unload1/cptmvt.unl select * from cptmvtOEF
The table contained 13 254 335 rows and after 7 383 874 rows the unload
failed.
Write failed. 7383874 rows unloaded (check ulimit or disk space).
1380: Write failed. rows unloaded (check ulimit or disk space).
See error -852.
Error in line 1
Near character position 30
As you can see below the size of the unload file is exactly the 2 Gb
limit, the filesystem is not full yet
and the ulimit command indicates unlimited for the file-size on
OS-level. (Solaris 8 on sparc)
So I think there must be a relationship anyway between the 'onmode -BC"
and the tools ?
I fear that the dbexport will not work either.
I think I will give the "onmode -BC 1" and try the unload again, or is
there something else I'm missing ?
Best regards,
Jacques Lapeire
admi:/var/adm >df -k /unload1
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t1d48s6 11531755 3809297 7607141 34% /unload1
admi:/ >ls -l /unload1
total 7595680
-rw-rw-rw- 1 root other 2147483647 Jun 4 23:17 cptmvt.unl
drwx------ 2 root root 8192 May 26 16:22 lost+found
-rw-rw-rw- 1 root other 1739576372 Jun 4 21:52 tiemvt.unl
admi:/ >wc -l /unload1/*unl
7383874 /unload1/cptmvt.unl
8312979 /unload1/tiemvt.unl
15696853 total
admi:/ >isql apare - <<OEF
select count(*) from cptmvtOEF
(count(*))
13254573 ===> some rows are already added at this time
1 row(s) retrieved.
admi:/ >ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 256
vmemory(kbytes) unlimited
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Art Kagel
Sent: donderdag 22 mei 2008 14:54
To: ids@iiug.org
Subject: Re: dbimport : symbolic links to xxx.unl files [12186]
Yes.
Art
On Thu, May 22, 2008 at 8:46 AM, Lapeire, Jacques <
jacques.lapeire@siemens.com> wrote:
> Thanks for your reply Art,
>
> so to be sure I understand correctly :
>
> - I do not need to give onmode -BC 1
> - after the upgrade to 9.40 , dbexport will unload tables > 2 Gb
> - the dbimport with symbolic links will work
>
> Thx and best regards
> Jacques
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: donderdag 22 mei 2008 14:40
> To: ids@iiug.org
> Subject: Re: dbimport : symbolic links to xxx.unl files [12182]
>
> Yes, that will work fine. The dbexport doesn't need the large chunk
> support
> though, that's independent of the large file support in the tools, so
> you
> can skip that step until later if you want to rebuild the instance
with
> larger chunks.
>
> On Thu, May 22, 2008 at 7:59 AM, JACQUES LAPEIRE <
> jacques.lapeire@siemens.com> wrote:
>
> > Hi guys, anyone has experience on this ?
> >
> > I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an
> > upgrade
> > to IDS 9.40 and afterwards a complete reorganisation of the
databases.
>
> >
> > First question :
> >
> > In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and
> execute
> > the
> > onmode -BC 1 command to allow big chunks. After that I suppose I can
> use
> > dbexport to unload the data. (I will test to unload a table >2 Gb).
> >
> > Second question :
> >
> > I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and
1
> x 21
> > Gb).
> > The database contains about 40 Gb, so during the dbexport I will
move
> the
> > files already written to the second filesystem.
> > Now to do the dbimport, several files will be located on the second
> > filesystem
> > instead of on the one indicated in the xxx.sql file
> >
> > If I create symbolic links in the first filesystem, pointing to the
> xxx.unl
> > files located in the second filesystem, will dbimport work fine ?
> >
> > Thanks for any replies.
> >
> > Jacques Lapeire
> >
> >
> >
> >
>
************************************************************************
> *******
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Art S. Kagel
> Oninit (www.oninit.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, Oninit, the IIUG, nor any other
> organization
> with which I am associated either explicitely or implicitely. Neither
do
>
> those opinions reflect those of other individuals affiliated with any
> entity
> with which I am affiliated nor those of the entities themselves.
>
>
************************************************************************
> *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
************************************************************************
*******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Onini
Jacques, Have you tried using the HPL to do your unload/load? Rob Beal of IBM did a presentation about it at the IIUG conference. Norma Jean ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================
This is a classic problem. There has always been a limitation to "unload"
command on the 2GB file size of the unload file through dbaccess (don't know
if this gets fixed in the later versions).
To get around this, the unload outputs to a pipe instead of a regular file
while the pipe is gzip'd to the archive file. The reverse is used to load the
data.
This is an example of how to do it:
UNLOAD:
1. mknod unload.pipe p
2. chmod 660 unload.pipe
3. gzip < unload.pipe > archivefile.dmp.gz &
4. from dbaccess: unload to unload.pipe select...
Hope this helps.
Kern --
----- Original Message ----
From: "Lapeire, Jacques" <jacques.lapeire@siemens.com>
To: ids@iiug.org
Sent: Thursday, June 5, 2008 9:58:50 AM
Subject: RE: dbimport : symbolic links to xxx.unl files [12322]
Hi Philippe,
as you can see below, it's no OS-limit, I created a file 'lapj.big' that
passes the 2 Gb limit .
admi:/unload1 >ls -l
total 12109248
-rw-rw-rw- 1 root other 2147483647 Jun 4 23:17 cptmvt.unl
-rw-rw-rw- 1 root other 2309804000 Jun 5 15:54 lapj.big <====== BIG FILE
drwx------ 2 root root 8192 May 26 16:22 lost+found
-rw-rw-rw- 1 root other 1739576372 Jun 4 21:52 tiemvt.unl
Thanks anyway, so I tested this possibility and can eliminate it.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Philippe
Pignon1
Sent: donderdag 5 juni 2008 10:54
To: ids@iiug.org
Subject: RE: dbimport : symbolic links to xxx.unl files [12317]
Hi Jacques,
I'm not a specialist of Solaris but I think you could have limitation with
your file-system.
For example, I had the same problem on an old AIX 32 bits with a JFS
(Journalized File System) created with default parameters.
Try to create a big file on your file system with a Unix tool like dd.
________________________________
"Lapeire, Jacques" <jacques.lapeire@siemens.com>
Sent by: ids-bounces@iiug.org
05/06/2008 10:15
Please respond to
ids@iiug.org
To
ids@iiug.org
cc
Subject
RE: dbimport : symbolic links to xxx.unl files [12316]
Hi Art,
sorry, but this time I have some doubts.
Yesterday evening I upgraded from 9.21 to 9.40 and did not yet give the
"onmode -BC 1" command.
admi:/var/adm >onstat -d
IBM Informix Dynamic Server Version 9.40.UC7 -- On-Line -- Up
13:35:04 -- 315392 Kbytes
.... . . . . .. . . . . .
Expanded chunk capacity mode: disabled
As a test (before we start the reorganisaton in a couple of weeks) I
tried to unload a big table
with the following command :
isql apare - << OEF
unload to /unload1/cptmvt.unl select * from cptmvtOEF
The table contained 13 254 335 rows and after 7 383 874 rows the unload
failed.
Write failed. 7383874 rows unloaded (check ulimit or disk space).
1380: Write failed. rows unloaded (check ulimit or disk space).
See error -852.
Error in line 1
Near character position 30
As you can see below the size of the unload file is exactly the 2 Gb
limit, the filesystem is not full yet
and the ulimit command indicates unlimited for the file-size on
OS-level. (Solaris 8 on sparc)
So I think there must be a relationship anyway between the 'onmode -BC"
and the tools ?
I fear that the dbexport will not work either.
I think I will give the "onmode -BC 1" and try the unload again, or is
there something else I'm missing ?
Best regards,
Jacques Lapeire
admi:/var/adm >df -k /unload1
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t1d48s6 11531755 3809297 7607141 34% /unload1
admi:/ >ls -l /unload1
total 7595680
-rw-rw-rw- 1 root other 2147483647 Jun 4 23:17 cptmvt.unl
drwx------ 2 root root 8192 May 26 16:22 lost+found
-rw-rw-rw- 1 root other 1739576372 Jun 4 21:52 tiemvt.unl
admi:/ >wc -l /unload1/*unl
7383874 /unload1/cptmvt.unl
8312979 /unload1/tiemvt.unl
15696853 total
admi:/ >isql apare - <<OEF
select count(*) from cptmvtOEF
(count(*))
13254573 ===> some rows are already added at this time
1 row(s) retrieved.
admi:/ >ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 256
vmemory(kbytes) unlimited
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Art Kagel
Sent: donderdag 22 mei 2008 14:54
To: ids@iiug.org
Subject: Re: dbimport : symbolic links to xxx.unl files [12186]
Yes.
Art
On Thu, May 22, 2008 at 8:46 AM, Lapeire, Jacques <
jacques.lapeire@siemens.com> wrote:
> Thanks for your reply Art,
>
> so to be sure I understand correctly :
>
> - I do not need to give onmode -BC 1
> - after the upgrade to 9.40 , dbexport will unload tables > 2 Gb
> - the dbimport with symbolic links will work
>
> Thx and best regards
> Jacques
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: donderdag 22 mei 2008 14:40
> To: ids@iiug.org
> Subject: Re: dbimport : symbolic links to xxx.unl files [12182]
>
> Yes, that will work fine. The dbexport doesn't need the large chunk
> support
> though, that's independent of the large file support in the tools, so
> you
> can skip that step until later if you want to rebuild the instance
with
> larger chunks.
>
> On Thu, May 22, 2008 at 7:59 AM, JACQUES LAPEIRE <
> jacques.lapeire@siemens.com> wrote:
>
> > Hi guys, anyone has experience on this ?
> >
> > I'm running IDS 9.21 on Solaris 8 sparc platform and I need to do an
> > upgrade
> > to IDS 9.40 and afterwards a complete reorganisation of the
databases.
>
> >
> > First question :
> >
> > In 9.21 I still have the 2gb limit, so I will upgrade to 9.40 and
> execute
> > the
> > onmode -BC 1 command to allow big chunks. After that I suppose I can
> use
> > dbexport to unload the data. (I will test to unload a table >2 Gb).
> >
> > Second question :
> >
> > I have 2 filesystems at my disposal for the dbexport (1 x 26 Gb and
1
> x 21
> > Gb).
> > The database contains about 40 Gb, so during the dbexport I will
move
> the
> > files already written to the second filesystem.
> > Now to do the dbimport, several files will be located on the second
> > filesystem
> > instead of on the one indicated in the xxx.sql file
> >
> > If I create symbolic links in the first filesystem, pointing to the
> xxx.unl
> > files located in the second filesystem, will dbimport work fine ?
> >
> > Thanks for any replies.
> >
> > Jacques Lapeire
> >
> >
> >
> >
>
************************************************************************
> *******
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@i
Related threads
- IDS 10 table-level restore
- Informix Development Webinar December 11, 2007
- ontape -p/r with changed ROOTPATH
- Migrate from HP PA-RISC to HP ITANIUM by ontape