RE: Dbspace question

IDS 11.50.FC5 Solaris 10 What is the command again, to see what dbspaces a database is using? Larry

Dbschema -ss will report the dbspaces for any object not in the database's default space. Pass the partnum of systabl especially into dbinfo ( 'space', partnum) to find the default. Art On Aug 2, 2012 2:04 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > IDS 11.50.FC5 > Solaris 10 > > What is the command again, to see what dbspaces a database is using? > > Larry > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340ffb7f0bc004c64c645e

Another question: Previously, we have used unload and onunload to copy a database from one instance to another on the same server. I believe that the database has been spread across two dbspaces, whereas previously all the tables were located in only one dbspace. The command that we used to use to load the database was onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1 The reason that we had to move some of the tables to a different dbspace is that some of the tables were so large, they were running out of extents and we had to create a dbspace with a larger page size. So, my question is, what is an equivalent command to copy this database now that it occupies two dbspaces on the target? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Larry Sorensen Sent: Thursday, August 02, 2012 12:04 PM To: ids@iiug.org Subject: RE: Dbspace question [27906] IDS 11.50.FC5 Solaris 10 What is the command again, to see what dbspaces a database is using? Larry **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

You could use dbexport with the -ss option then dbimport or for a faster copy use my dbexport/dbimport replacement utilities myexport & myimport. With the -E option these scripts use external tables to move the data about twice as fast as dbexport & dbimport. There is also a parallel mode option (-p) to unload the entire database in parallel which is often even faster. You will need the packages myexport and utils2_ak (for my dbschema replacement utility myexport that has schema support for dbexport/dbimport and myexport/myimport). Another alternative would be to use my dbcopy utility (also in utils2_ak) along with the mkdbcopy.awk script in the package utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema or myschema output file to copy the entire database directly from one server instance to the other without the intermediate disk file(s) by using dbcopy. Dbcopy is very fast and if you add in the time savings of not having to write the export files and read them back in, it is usually faster even than that. 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > Another question: > > Previously, we have used unload and onunload to copy a database from one > instance to another on the same server. I believe that the database has > been > spread across two dbspaces, whereas previously all the tables were located > in only one dbspace. The command that we used to use to load the database > was > > onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1> > The reason that we had to move some of the tables to a different dbspace is > that some of the tables were so large, they were running out of extents and > we had to create a dbspace with a larger page size. > > So, my question is, what is an equivalent command to copy this database now > that it occupies two dbspaces on the target? > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Larry > Sorensen > Sent: Thursday, August 02, 2012 12:04 PM > To: ids@iiug.org > Subject: RE: Dbspace question [27906] > > IDS 11.50.FC5 > Solaris 10 > > What is the command again, to see what dbspaces a database is using? > > Larry > > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae934037169d5c104c64d29de

OK. I am under the gun here to get this done today. What you are telling me is that I can no longer use onload, now, because I have two dbspaces. Your utilities sound attractive, but there will be quite a learning curve, I am afraid. Do you have any documentation for doing this and setting everything up on a Solaris server? Are there any other suggestions for just getting me by today? Thank you for your help. Larry -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Thursday, August 02, 2012 1:10 PM To: ids@iiug.org Subject: Re: Dbspace question [27909] You could use dbexport with the -ss option then dbimport or for a faster copy use my dbexport/dbimport replacement utilities myexport & myimport. With the -E option these scripts use external tables to move the data about twice as fast as dbexport & dbimport. There is also a parallel mode option (-p) to unload the entire database in parallel which is often even faster. You will need the packages myexport and utils2_ak (for my dbschema replacement utility myexport that has schema support for dbexport/dbimport and myexport/myimport). Another alternative would be to use my dbcopy utility (also in utils2_ak) along with the mkdbcopy.awk script in the package utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema or myschema output file to copy the entire database directly from one server instance to the other without the intermediate disk file(s) by using dbcopy. Dbcopy is very fast and if you add in the time savings of not having to write the export files and read them back in, it is usually faster even than that. 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > Another question: > > Previously, we have used unload and onunload to copy a database from > one instance to another on the same server. I believe that the > database has been spread across two dbspaces, whereas previously all > the tables were located in only one dbspace. The command that we used > to use to load the database was > > onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1> > The reason that we had to move some of the tables to a different > dbspace is that some of the tables were so large, they were running > out of extents and we had to create a dbspace with a larger page size. > > So, my question is, what is an equivalent command to copy this > database now that it occupies two dbspaces on the target? > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Larry Sorensen > Sent: Thursday, August 02, 2012 12:04 PM > To: ids@iiug.org > Subject: RE: Dbspace question [27906] > > IDS 11.50.FC5 > Solaris 10 > > What is the command again, to see what dbspaces a database is using? > > Larry > > > ********************************************************************** > ****** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > **************************************************************************** *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae934037169d5c104c64d29de **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

Dbexport/dbimport are documented in the Migration Guide which you can download or look at online. That will be slower than onunload/onload, but it will get the job done with a minimum of fuss. Don't forget the -ss option to dbexport so that the dbspace IN clauses for each object not in the default dbspace will be included in the schema output dbimport will use. Utils2_ak is documented in the package itself. If you have gcc and Gnu Make on your Solaris system you can build it right out of the box just by running make. If you don't, you need to make a few simple changes to the makefiles (Makefile.nognumake & myschema.d/myschema.mk.norcs.nognumake) which are documented in comments in the makefiles and in the readme files (README.1st, BUILDING, & myschema.README) then run "make -f Makefile.nognumake". The dbcopy utility, like most of my utilities, is self documenting, just run it with no arguments and it will printout extensive usage notes, but if you are using it with the mkdbcopy.awk script, no worries since the awk script takes care of the dbcopy commandline for you. Myexport/myimport are self documenting. Just run without arguments. However, they are basically run the same way as dbexport & dbimport but have extra options and do not support tape. Myexport and myimport are fully compatible with dbexport & dbimport BTW. Output directories from either export utility can be used with the other import utility (except if you myexport with the -m option - in that case you would have to run the index/constraint creation script manually after the dbimport completes). The scripts in utils4_ak are all awk scripts that read dbschema and myschema output and produce scripts that operate on an entire database. They are meant as examples of how to do it, but some, like the mkdbcopy.awk script, are immediately useful. Just run: awk -f mkdbcopy.awk mydatabase.sql >dbcopy_mydatabase.ksh The resulting shell script is self-documenting. 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, Aug 2, 2012 at 3:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > OK. I am under the gun here to get this done today. What you are telling me > is that I can no longer use onload, now, because I have two dbspaces. Your > utilities sound attractive, but there will be quite a learning curve, I am > afraid. Do you have any documentation for doing this and setting everything > up on a Solaris server? Are there any other suggestions for just getting me > by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a faster > copy use my dbexport/dbimport replacement utilities myexport & myimport. > With the -E option these scripts use external tables to move the data about > twice as fast as dbexport & dbimport. There is also a parallel mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for dbexport/dbimport > and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in utils2_ak) > along with the mkdbcopy.awk script in the package utils4_ak. Mkdbcopy.awk > will generate a shell script from a dbschema or myschema output file to > copy > the entire database directly from one server instance to the other without > the intermediate disk file(s) by using dbcopy. Dbcopy is very fast and if > you add in the time savings of not having to write the export files and > read > them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> > wrote: > > > Another question: > > > > Previously, we have used unload and onunload to copy a database from > > one instance to another on the same server. I believe that the > > database has been spread across two dbspaces, whereas previously all > > the tables were located in only one dbspace. The command that we used > > to use to load the database was > > > > onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1> > > > The reason that we had to move some of the tables to a different > > dbspace is that some of the tables were so large, they were running > > out of extents and we had to create a dbspace with a larger page size. > > > > So, my question is, what is an equivalent command to copy this > > database now that it occupies two dbspaces on the target? > > > > -----Original Message----- > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > > Larry Sorensen > > Sent: Thursday, August 02, 2012 12:04 PM > > To: ids@iiug.org > > Subject: RE: Dbspace question [27906] > > > > IDS 11.50.FC5 > > Solaris 10 > > > > What is the command again, to see what dbspaces a database is using? > > > > Larry > > > > > > ********************************************************************** > > ****** > > *** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > **************************************************************************** > *** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --14dae934037169d5c104c64d29de > > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340e1b1cc8a304c64db134

continue using onunload and onload, it should work as long as your target instance has identical or similar dbspace layout. Why don't you test it out, it should take 15 min and you'll know the answer. For example, generate a schema of your source database but modify or comment out extent sizes (to save space). On the target instance, recreate the same database with this schema. Now run onunload, drop the database, then onload On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > OK. I am under the gun here to get this done today. What you are telling me > is that I can no longer use onload, now, because I have two dbspaces. Your > utilities sound attractive, but there will be quite a learning curve, I am > afraid. Do you have any documentation for doing this and setting everything > up on a Solaris server? Are there any other suggestions for just getting me > by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a faster > copy use my dbexport/dbimport replacement utilities myexport & myimport. > With the -E option these scripts use external tables to move the data about > twice as fast as dbexport & dbimport. There is also a parallel mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for dbexport/dbimport > and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in utils2_ak) > along with the mkdbcopy.awk script in the package utils4_ak. Mkdbcopy.awk > will generate a shell script from a dbschema or myschema output file to copy > the entire database directly from one server instance to the other without > the intermediate disk file(s) by using dbcopy. Dbcopy is very fast and if > you add in the time savings of not having to write the export files and read > them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > >> Another question: >> >> Previously, we have used unload and onunload to copy a database from >> one instance to another on the same server. I believe that the >> database has been spread across two dbspaces, whereas previously all >> the tables were located in only one dbspace. The command that we used >> to use to load the database was >> >> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>> >> The reason that we had to move some of the tables to a different >> dbspace is that some of the tables were so large, they were running >> out of extents and we had to create a dbspace with a larger page size. >> >> So, my question is, what is an equivalent command to copy this >> database now that it occupies two dbspaces on the target? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Larry Sorensen >> Sent: Thursday, August 02, 2012 12:04 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27906] >> >> IDS 11.50.FC5 >> Solaris 10 >> >> What is the command again, to see what dbspaces a database is using? >> >> Larry >> >> >> ********************************************************************** >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > **************************************************************************** > *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --14dae934037169d5c104c64d29de > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

So, what you are thinking is that, if I do not use onload -d dbspace (the -d option), it will just use the same dbspaces as the unload came from rather than the rootdbs, which I was worried it might? Larry -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Sent: Thursday, August 02, 2012 2:42 PM To: ids@iiug.org Subject: Re: Dbspace question [27913] continue using onunload and onload, it should work as long as your target instance has identical or similar dbspace layout. Why don't you test it out, it should take 15 min and you'll know the answer. For example, generate a schema of your source database but modify or comment out extent sizes (to save space). On the target instance, recreate the same database with this schema. Now run onunload, drop the database, then onload On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > OK. I am under the gun here to get this done today. What you are > telling me is that I can no longer use onload, now, because I have two > dbspaces. Your utilities sound attractive, but there will be quite a > learning curve, I am afraid. Do you have any documentation for doing > this and setting everything up on a Solaris server? Are there any > other suggestions for just getting me by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Art Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a > faster copy use my dbexport/dbimport replacement utilities myexport & myimport. > With the -E option these scripts use external tables to move the data > about twice as fast as dbexport & dbimport. There is also a parallel > mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for > dbexport/dbimport and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in > utils2_ak) along with the mkdbcopy.awk script in the package > utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema > or myschema output file to copy the entire database directly from one > server instance to the other without the intermediate disk file(s) by > using dbcopy. Dbcopy is very fast and if you add in the time savings > of not having to write the export files and read them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > >> Another question: >> >> Previously, we have used unload and onunload to copy a database from >> one instance to another on the same server. I believe that the >> database has been spread across two dbspaces, whereas previously all >> the tables were located in only one dbspace. The command that we used >> to use to load the database was >> >> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>> >> The reason that we had to move some of the tables to a different >> dbspace is that some of the tables were so large, they were running >> out of extents and we had to create a dbspace with a larger page size. >> >> So, my question is, what is an equivalent command to copy this >> database now that it occupies two dbspaces on the target? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Larry Sorensen >> Sent: Thursday, August 02, 2012 12:04 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27906] >> >> IDS 11.50.FC5 >> Solaris 10 >> >> What is the command again, to see what dbspaces a database is using? >> >> Larry >> >> >> ********************************************************************* >> * >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > ********************************************************************** > ****** > *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --14dae934037169d5c104c64d29de > > ********************************************************************** > ****** > *** > 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.

Say, your database (source) created in dbs1 but all your tables are in dbs2, when you do onload (to target), of course, you must specify -d dbs1 (it is where the database is in), but all your tables are automagically onloaded to dbs2 -- as far as I remember. HOWEVER, I must mention this issue based on my past experience involving onunload/onload with older version of IDS (9.4?) was that if you have created dbspaces with different page sizes, onunload of database level appears to work but then onload will fail -- I have not tried with the latest version so I do not know if IBM has fixed this bug. I encourage you to test all these out to see for yourself. ________________________________ From: Larry Sorensen <lsorensen25@msn.com> To: ids@iiug.org Sent: Thursday, August 2, 2012 4:46 PM Subject: RE: Dbspace question [27914] So, what you are thinking is that, if I do not use onload -d dbspace (the -d option), it will just use the same dbspaces as the unload came from rather than the rootdbs, which I was worried it might? Larry -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Sent: Thursday, August 02, 2012 2:42 PM To: ids@iiug.org Subject: Re: Dbspace question [27913] continue using onunload and onload, it should work as long as your target instance has identical or similar dbspace layout. Why don't you test it out, it should take 15 min and you'll know the answer. For example, generate a schema of your source database but modify or comment out extent sizes (to save space). On the target instance, recreate the same database with this schema. Now run onunload, drop the database, then onload On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > OK. I am under the gun here to get this done today. What you are > telling me is that I can no longer use onload, now, because I have two > dbspaces. Your utilities sound attractive, but there will be quite a > learning curve, I am afraid. Do you have any documentation for doing > this and setting everything up on a Solaris server? Are there any > other suggestions for just getting me by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Art Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a > faster copy use my dbexport/dbimport replacement utilities myexport & myimport. > With the -E option these scripts use external tables to move the data > about twice as fast as dbexport & dbimport. There is also a parallel > mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for > dbexport/dbimport and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in > utils2_ak) along with the mkdbcopy.awk script in the package > utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema > or myschema output file to copy the entire database directly from one > server instance to the other without the intermediate disk file(s) by > using dbcopy. Dbcopy is very fast and if you add in the time savings > of not having to write the export files and read them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > >> Another question: >> >> Previously, we have used unload and onunload to copy a database from >> one instance to another on the same server. I believe that the >> database has been spread across two dbspaces, whereas previously all >> the tables were located in only one dbspace. The command that we used >> to use to load the database was >> >> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>> >> The reason that we had to move some of the tables to a different >> dbspace is that some of the tables were so large, they were running >> out of extents and we had to create a dbspace with a larger page size. >> >> So, my question is, what is an equivalent command to copy this >> database now that it occupies two dbspaces on the target? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Larry Sorensen >> Sent: Thursday, August 02, 2012 12:04 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27906] >> >> IDS 11.50.FC5 >> Solaris 10 >> >> What is the command again, to see what dbspaces a database is using? >> >> Larry >> >> >> ********************************************************************* >> * >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > ********************************************************************** > ****** > *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --14dae934037169d5c104c64d29de > > ********************************************************************** > ****** > *** > 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. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Thank you. I will try it. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Doe Sent: Thursday, August 02, 2012 3:09 PM To: ids@iiug.org Subject: Re: Dbspace question [27915] Say, your database (source) created in dbs1 but all your tables are in dbs2, when you do onload (to target), of course, you must specify -d dbs1 (it is where the database is in), but all your tables are automagically onloaded to dbs2 -- as far as I remember. HOWEVER, I must mention this issue based on my past experience involving onunload/onload with older version of IDS (9.4?) was that if you have created dbspaces with different page sizes, onunload of database level appears to work but then onload will fail -- I have not tried with the latest version so I do not know if IBM has fixed this bug. I encourage you to test all these out to see for yourself. ________________________________ From: Larry Sorensen <lsorensen25@msn.com> To: ids@iiug.org Sent: Thursday, August 2, 2012 4:46 PM Subject: RE: Dbspace question [27914] So, what you are thinking is that, if I do not use onload -d dbspace (the -d option), it will just use the same dbspaces as the unload came from rather than the rootdbs, which I was worried it might? Larry -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Sent: Thursday, August 02, 2012 2:42 PM To: ids@iiug.org Subject: Re: Dbspace question [27913] continue using onunload and onload, it should work as long as your target instance has identical or similar dbspace layout. Why don't you test it out, it should take 15 min and you'll know the answer. For example, generate a schema of your source database but modify or comment out extent sizes (to save space). On the target instance, recreate the same database with this schema. Now run onunload, drop the database, then onload On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > OK. I am under the gun here to get this done today. What you are > telling me is that I can no longer use onload, now, because I have two > dbspaces. Your utilities sound attractive, but there will be quite a > learning curve, I am afraid. Do you have any documentation for doing > this and setting everything up on a Solaris server? Are there any > other suggestions for just getting me by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Art Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a > faster copy use my dbexport/dbimport replacement utilities myexport & myimport. > With the -E option these scripts use external tables to move the data > about twice as fast as dbexport & dbimport. There is also a parallel > mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for > dbexport/dbimport and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in > utils2_ak) along with the mkdbcopy.awk script in the package > utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema > or myschema output file to copy the entire database directly from one > server instance to the other without the intermediate disk file(s) by > using dbcopy. Dbcopy is very fast and if you add in the time savings > of not having to write the export files and read them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > >> Another question: >> >> Previously, we have used unload and onunload to copy a database from >> one instance to another on the same server. I believe that the >> database has been spread across two dbspaces, whereas previously all >> the tables were located in only one dbspace. The command that we used >> to use to load the database was >> >> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>> >> The reason that we had to move some of the tables to a different >> dbspace is that some of the tables were so large, they were running >> out of extents and we had to create a dbspace with a larger page size. >> >> So, my question is, what is an equivalent command to copy this >> database now that it occupies two dbspaces on the target? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Larry Sorensen >> Sent: Thursday, August 02, 2012 12:04 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27906] >> >> IDS 11.50.FC5 >> Solaris 10 >> >> What is the command again, to see what dbspaces a database is using? >> >> Larry >> >> >> ********************************************************************* >> * >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > ********************************************************************** > ****** > *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --14dae934037169d5c104c64d29de > > ********************************************************************** > ****** > *** > 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. **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum. **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

I dropped the database in the target instance. (It has other databases as well) When I try to do the onload, I receive the message Error allocating extent pages. ISAM error: no more extents There should be room in the dbspace because I deleted the previous database that I was going to refresh and I am getting nowhere near completion of the onload. Any ideas? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Larry Sorensen Sent: Thursday, August 02, 2012 3:36 PM To: ids@iiug.org Subject: RE: Dbspace question [27916] Thank you. I will try it. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Doe Sent: Thursday, August 02, 2012 3:09 PM To: ids@iiug.org Subject: Re: Dbspace question [27915] Say, your database (source) created in dbs1 but all your tables are in dbs2, when you do onload (to target), of course, you must specify -d dbs1 (it is where the database is in), but all your tables are automagically onloaded to dbs2 -- as far as I remember. HOWEVER, I must mention this issue based on my past experience involving onunload/onload with older version of IDS (9.4?) was that if you have created dbspaces with different page sizes, onunload of database level appears to work but then onload will fail -- I have not tried with the latest version so I do not know if IBM has fixed this bug. I encourage you to test all these out to see for yourself. ________________________________ From: Larry Sorensen <lsorensen25@msn.com> To: ids@iiug.org Sent: Thursday, August 2, 2012 4:46 PM Subject: RE: Dbspace question [27914] So, what you are thinking is that, if I do not use onload -d dbspace (the -d option), it will just use the same dbspaces as the unload came from rather than the rootdbs, which I was worried it might? Larry -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Sent: Thursday, August 02, 2012 2:42 PM To: ids@iiug.org Subject: Re: Dbspace question [27913] continue using onunload and onload, it should work as long as your target instance has identical or similar dbspace layout. Why don't you test it out, it should take 15 min and you'll know the answer. For example, generate a schema of your source database but modify or comment out extent sizes (to save space). On the target instance, recreate the same database with this schema. Now run onunload, drop the database, then onload On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > OK. I am under the gun here to get this done today. What you are > telling me is that I can no longer use onload, now, because I have two > dbspaces. Your utilities sound attractive, but there will be quite a > learning curve, I am afraid. Do you have any documentation for doing > this and setting everything up on a Solaris server? Are there any > other suggestions for just getting me by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Art Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a > faster copy use my dbexport/dbimport replacement utilities myexport & myimport. > With the -E option these scripts use external tables to move the data > about twice as fast as dbexport & dbimport. There is also a parallel > mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for > dbexport/dbimport and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in > utils2_ak) along with the mkdbcopy.awk script in the package > utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema > or myschema output file to copy the entire database directly from one > server instance to the other without the intermediate disk file(s) by > using dbcopy. Dbcopy is very fast and if you add in the time savings > of not having to write the export files and read them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > >> Another question: >> >> Previously, we have used unload and onunload to copy a database from >> one instance to another on the same server. I believe that the >> database has been spread across two dbspaces, whereas previously all >> the tables were located in only one dbspace. The command that we used >> to use to load the database was >> >> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>> >> The reason that we had to move some of the tables to a different >> dbspace is that some of the tables were so large, they were running >> out of extents and we had to create a dbspace with a larger page size. >> >> So, my question is, what is an equivalent command to copy this >> database now that it occupies two dbspaces on the target? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Larry Sorensen >> Sent: Thursday, August 02, 2012 12:04 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27906] >> >> IDS 11.50.FC5 >> Solaris 10 >> >> What is the command again, to see what dbspaces a database is using? >> >> Larry >> >> >> ********************************************************************* >> * >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > ********************************************************************** > ****** > *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --14dae934037169d5c104c64d29de > > ********************************************************************** > ****** > *** > 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. ********************************************

Do a couple of checkpoints. From: "Larry Sorensen" <lsorensen25@msn.com> To: ids@iiug.org, Date: 08/02/2012 06:04 PM Subject: RE: Dbspace question [27917] Sent by: ids-bounces@iiug.org I dropped the database in the target instance. (It has other databases = as well) When I try to do the onload, I receive the message Error allocating extent pages. ISAM error: no more extents There should be room in the dbspace because I deleted the previous data= base that I was going to refresh and I am getting nowhere near completion of= the onload. Any ideas? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of L= arry Sorensen Sent: Thursday, August 02, 2012 3:36 PM To: ids@iiug.org Subject: RE: Dbspace question [27916] Thank you. I will try it. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of K= ern Doe Sent: Thursday, August 02, 2012 3:09 PM To: ids@iiug.org Subject: Re: Dbspace question [27915] Say, your database (source) created in dbs1 but all your tables are in dbs2, when you do onload (to target), of course, you must specify -d dbs1 (it= is where the database is in), but all your tables are automagically onload= ed to dbs2 -- as far as I remember. HOWEVER, I must mention this issue based on my past experience involvin= g onunload/onload with older version of IDS (9.4?) was that if you have created dbspaces with different page sizes, onunload of database level appears to work but then onload will fail -- I have not tried with the latest version so I do not know if IBM has fixed this bug. I encourage you to test all these out to see for yourself. ________________________________ From: Larry Sorensen <lsorensen25@msn.com> To: ids@iiug.org Sent: Thursday, August 2, 2012 4:46 PM Subject: RE: Dbspace question [27914] So, what you are thinking is that, if I do not use onload -d dbspace (t= he -d option), it will just use the same dbspaces as the unload came from rat= her than the rootdbs, which I was worried it might? Larry -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of K= ern Sent: Thursday, August 02, 2012 2:42 PM To: ids@iiug.org Subject: Re: Dbspace question [27913] continue using onunload and onload, it should work as long as your targ= et instance has identical or similar dbspace layout. Why don't you test it= out, it should take 15 min and you'll know the answer. For example, generate a schema of your source database but modify or comment out extent sizes (to save space). On the target instance, recreate the = same database with this schema. Now run onunload, drop the database, then on= load On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrot= e: > OK. I am under the gun here to get this done today. What you are > telling me is that I can no longer use onload, now, because I have tw= o > dbspaces. Your utilities sound attractive, but there will be quite a > learning curve, I am afraid. Do you have any documentation for doing > this and setting everything up on a Solaris server? Are there any > other suggestions for just getting me by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of= > Art Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a > faster copy use my dbexport/dbimport replacement utilities myexport &= myimport. > With the -E option these scripts use external tables to move the data= > about twice as fast as dbexport & dbimport. There is also a parallel > mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for > dbexport/dbimport and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in > utils2_ak) along with the mkdbcopy.awk script in the package > utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema > or myschema output file to copy the entire database directly from one= > server instance to the other without the intermediate disk file(s) by= > using dbcopy. Dbcopy is very fast and if you add in the time savings > of not having to write the export files and read them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > >> Another question: >> >> Previously, we have used unload and onunload to copy a database from= >> one instance to another on the same server. I believe that the >> database has been spread across two dbspaces, whereas previously all= >> the tables were located in only one dbspace. The command that we use= d >> to use to load the database was >> >> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>> >> The reason that we had to move some of the tables to a different >> dbspace is that some of the tables were so large, they were running >> out of extents and we had to create a dbspace with a larger page siz= e. >> >> So, my question is, what is an equivalent command to copy this >> database now that it occupies two dbspaces on the target? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf O= f >> Larry Sorensen >> Sent: Thursday, August 02, 2012 12:04 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27906] >> >> IDS 11.50.FC5 >> Solaris 10 >> >> What is the command again, to see what dbspaces a database is using?= >> >> Larry >> >> >> ********************************************************************= * >> * >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > *********************************************************************= * > ****** > *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --14dae934037169d5c104c64d29de > > *********************************************************************= * > ****** > *** > Forum Note: Use "R

remember I've mentioned about commenting out the extent specifications? The idea is to NOT use On Aug 2, 2012, at 7:01 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > I dropped the database in the target instance. (It has other databases as > well) When I try to do the onload, I receive the message > > Error allocating extent pages. > ISAM error: no more extents> > There should be room in the dbspace because I deleted the previous database > that I was going to refresh and I am getting nowhere near completion of the > onload. > > Any ideas? > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Larry > Sorensen > Sent: Thursday, August 02, 2012 3:36 PM > To: ids@iiug.org > Subject: RE: Dbspace question [27916] > > Thank you. I will try it. > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern > Doe > Sent: Thursday, August 02, 2012 3:09 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27915] > > Say, your database (source) created in dbs1 but all your tables are in dbs2, > when you do onload (to target), of course, you must specify -d dbs1 (it is > where the database is in), but all your tables are automagically onloaded to > dbs2 -- as far as I remember. > > HOWEVER, I must mention this issue based on my past experience involving > onunload/onload with older version of IDS (9.4?) was that if you have > created dbspaces with different page sizes, onunload of database level > appears to work but then onload will fail -- I have not tried with the > latest version so I do not know if IBM has fixed this bug. > > I encourage you to test all these out to see for yourself. > > ________________________________ > From: Larry Sorensen <lsorensen25@msn.com> > To: ids@iiug.org > Sent: Thursday, August 2, 2012 4:46 PM > Subject: RE: Dbspace question [27914] > > So, what you are thinking is that, if I do not use onload -d dbspace (the -d > option), it will just use the same dbspaces as the unload came from rather > than the rootdbs, which I was worried it might? > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern > Sent: Thursday, August 02, 2012 2:42 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27913] > > continue using onunload and onload, it should work as long as your target > instance has identical or similar dbspace layout. Why don't you test it out, > it should take 15 min and you'll know the answer. > For example, generate a schema of your source database but modify or comment > out extent sizes (to save space). On the target instance, recreate the same > database with this schema. Now run onunload, drop the database, then onload > > On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > >> OK. I am under the gun here to get this done today. What you are >> telling me is that I can no longer use onload, now, because I have two >> dbspaces. Your utilities sound attractive, but there will be quite a >> learning curve, I am afraid. Do you have any documentation for doing >> this and setting everything up on a Solaris server? Are there any >> other suggestions for just getting me by today? >> >> Thank you for your help. >> >> Larry >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Art Kagel >> Sent: Thursday, August 02, 2012 1:10 PM >> To: ids@iiug.org >> Subject: Re: Dbspace question [27909] >> >> You could use dbexport with the -ss option then dbimport or for a >> faster copy use my dbexport/dbimport replacement utilities myexport & > myimport. >> With the -E option these scripts use external tables to move the data >> about twice as fast as dbexport & dbimport. There is also a parallel >> mode option >> (-p) to unload the entire database in parallel which is often even faster. > >> You will need the packages myexport and utils2_ak (for my dbschema >> replacement utility myexport that has schema support for >> dbexport/dbimport and myexport/myimport). >> >> Another alternative would be to use my dbcopy utility (also in >> utils2_ak) along with the mkdbcopy.awk script in the package >> utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema >> or myschema output file to copy the entire database directly from one >> server instance to the other without the intermediate disk file(s) by >> using dbcopy. Dbcopy is very fast and if you add in the time savings >> of not having to write the export files and read them back in, it is > usually faster even than that. >> >> 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> > wrote: >> >>> Another question: >>> >>> Previously, we have used unload and onunload to copy a database from >>> one instance to another on the same server. I believe that the >>> database has been spread across two dbspaces, whereas previously all >>> the tables were located in only one dbspace. The command that we used >>> to use to load the database was >>> >>> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>>> >>> The reason that we had to move some of the tables to a different >>> dbspace is that some of the tables were so large, they were running >>> out of extents and we had to create a dbspace with a larger page size. >>> >>> So, my question is, what is an equivalent command to copy this >>> database now that it occupies two dbspaces on the target? >>> >>> -----Original Message----- >>> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >>> Larry Sorensen >>> Sent: Thursday, August 02, 2012 12:04 PM >>> To: ids@iiug.org >>> Subject: RE: Dbspace question [27906] >>> >>> IDS 11.50.FC5 >>> Solaris 10 >>> >>> What is the command again, to see what dbspaces a database is using? >>> >>> Larry >>> >>> >>> ********************************************************************* >>> * >>> ****** >>> *** >>> Forum Note: Use "Reply" to post a response in the discussion forum. >>> >>> >>> >>> >> ********************************************************************** >> ****** >> *** >>> Forum Note: Use "Reply" to post a response in the discussion forum. >>> >>> >> >> --14dae934037169d5c104c64d29de >> >> ********************************************************************** >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >>

I did a couple of checkpoints. Successful. Now what? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Madison Pruet Sent: Thursday, August 02, 2012 5:13 PM To: ids@iiug.org Subject: RE: Dbspace question [27918] Do a couple of checkpoints. From: "Larry Sorensen" <lsorensen25@msn.com> To: ids@iiug.org, Date: 08/02/2012 06:04 PM Subject: RE: Dbspace question [27917] Sent by: ids-bounces@iiug.org I dropped the database in the target instance. (It has other databases = as well) When I try to do the onload, I receive the message Error allocating extent pages. ISAM error: no more extents There should be room in the dbspace because I deleted the previous data= base that I was going to refresh and I am getting nowhere near completion of= the onload. Any ideas? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of L= arry Sorensen Sent: Thursday, August 02, 2012 3:36 PM To: ids@iiug.org Subject: RE: Dbspace question [27916] Thank you. I will try it. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of K= ern Doe Sent: Thursday, August 02, 2012 3:09 PM To: ids@iiug.org Subject: Re: Dbspace question [27915] Say, your database (source) created in dbs1 but all your tables are in dbs2, when you do onload (to target), of course, you must specify -d dbs1 (it= is where the database is in), but all your tables are automagically onload= ed to dbs2 -- as far as I remember. HOWEVER, I must mention this issue based on my past experience involvin= g onunload/onload with older version of IDS (9.4?) was that if you have created dbspaces with different page sizes, onunload of database level appears to work but then onload will fail -- I have not tried with the latest version so I do not know if IBM has fixed this bug. I encourage you to test all these out to see for yourself. ________________________________ From: Larry Sorensen <lsorensen25@msn.com> To: ids@iiug.org Sent: Thursday, August 2, 2012 4:46 PM Subject: RE: Dbspace question [27914] So, what you are thinking is that, if I do not use onload -d dbspace (t= he -d option), it will just use the same dbspaces as the unload came from rat= her than the rootdbs, which I was worried it might? Larry -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of K= ern Sent: Thursday, August 02, 2012 2:42 PM To: ids@iiug.org Subject: Re: Dbspace question [27913] continue using onunload and onload, it should work as long as your targ= et instance has identical or similar dbspace layout. Why don't you test it= out, it should take 15 min and you'll know the answer. For example, generate a schema of your source database but modify or comment out extent sizes (to save space). On the target instance, recreate the = same database with this schema. Now run onunload, drop the database, then on= load On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrot= e: > OK. I am under the gun here to get this done today. What you are > telling me is that I can no longer use onload, now, because I have tw= o > dbspaces. Your utilities sound attractive, but there will be quite a > learning curve, I am afraid. Do you have any documentation for doing > this and setting everything up on a Solaris server? Are there any > other suggestions for just getting me by today? > > Thank you for your help. > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of= > Art Kagel > Sent: Thursday, August 02, 2012 1:10 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27909] > > You could use dbexport with the -ss option then dbimport or for a > faster copy use my dbexport/dbimport replacement utilities myexport &= myimport. > With the -E option these scripts use external tables to move the data= > about twice as fast as dbexport & dbimport. There is also a parallel > mode option > (-p) to unload the entire database in parallel which is often even faster. > You will need the packages myexport and utils2_ak (for my dbschema > replacement utility myexport that has schema support for > dbexport/dbimport and myexport/myimport). > > Another alternative would be to use my dbcopy utility (also in > utils2_ak) along with the mkdbcopy.awk script in the package > utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema > or myschema output file to copy the entire database directly from one= > server instance to the other without the intermediate disk file(s) by= > using dbcopy. Dbcopy is very fast and if you add in the time savings > of not having to write the export files and read them back in, it is usually faster even than that. > > 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > >> Another question: >> >> Previously, we have used unload and onunload to copy a database from= >> one instance to another on the same server. I believe that the >> database has been spread across two dbspaces, whereas previously all= >> the tables were located in only one dbspace. The command that we use= d >> to use to load the database was >> >> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>> >> The reason that we had to move some of the tables to a different >> dbspace is that some of the tables were so large, they were running >> out of extents and we had to create a dbspace with a larger page siz= e. >> >> So, my question is, what is an equivalent command to copy this >> database now that it occupies two dbspaces on the target? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf O= f >> Larry Sorensen >> Sent: Thursday, August 02, 2012 12:04 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27906] >> >> IDS 11.50.FC5 >> Solaris 10 >> >> What is the command again, to see what dbspaces a database is using?= >> >> Larry >> >> >> ********************************************************************= * >> * >> ****** >> *** >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > *********************************************************************= * > ****** > *** >> Forum Note: Use "Reply" to post a r

How do you not use extent specification in an onload? Is there some file somewhere with the schema for the onunload that you can edit? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Sent: Thursday, August 02, 2012 5:27 PM To: ids@iiug.org Subject: Re: Dbspace question [27919] remember I've mentioned about commenting out the extent specifications? The idea is to NOT use On Aug 2, 2012, at 7:01 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > I dropped the database in the target instance. (It has other databases > as > well) When I try to do the onload, I receive the message > > Error allocating extent pages. > ISAM error: no more extents> > There should be room in the dbspace because I deleted the previous > database that I was going to refresh and I am getting nowhere near > completion of the onload. > > Any ideas? > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Larry Sorensen > Sent: Thursday, August 02, 2012 3:36 PM > To: ids@iiug.org > Subject: RE: Dbspace question [27916] > > Thank you. I will try it. > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Kern Doe > Sent: Thursday, August 02, 2012 3:09 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27915] > > Say, your database (source) created in dbs1 but all your tables are in > dbs2, when you do onload (to target), of course, you must specify -d > dbs1 (it is where the database is in), but all your tables are > automagically onloaded to > dbs2 -- as far as I remember. > > HOWEVER, I must mention this issue based on my past experience > involving onunload/onload with older version of IDS (9.4?) was that if > you have created dbspaces with different page sizes, onunload of > database level appears to work but then onload will fail -- I have not > tried with the latest version so I do not know if IBM has fixed this bug. > > I encourage you to test all these out to see for yourself. > > ________________________________ > From: Larry Sorensen <lsorensen25@msn.com> > To: ids@iiug.org > Sent: Thursday, August 2, 2012 4:46 PM > Subject: RE: Dbspace question [27914] > > So, what you are thinking is that, if I do not use onload -d dbspace > (the -d option), it will just use the same dbspaces as the unload came > from rather than the rootdbs, which I was worried it might? > > Larry > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Kern > Sent: Thursday, August 02, 2012 2:42 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27913] > > continue using onunload and onload, it should work as long as your > target instance has identical or similar dbspace layout. Why don't you > test it out, it should take 15 min and you'll know the answer. > For example, generate a schema of your source database but modify or > comment out extent sizes (to save space). On the target instance, > recreate the same database with this schema. Now run onunload, drop > the database, then onload > > On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > >> OK. I am under the gun here to get this done today. What you are >> telling me is that I can no longer use onload, now, because I have >> two dbspaces. Your utilities sound attractive, but there will be >> quite a learning curve, I am afraid. Do you have any documentation >> for doing this and setting everything up on a Solaris server? Are >> there any other suggestions for just getting me by today? >> >> Thank you for your help. >> >> Larry >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Art Kagel >> Sent: Thursday, August 02, 2012 1:10 PM >> To: ids@iiug.org >> Subject: Re: Dbspace question [27909] >> >> You could use dbexport with the -ss option then dbimport or for a >> faster copy use my dbexport/dbimport replacement utilities myexport & > myimport. >> With the -E option these scripts use external tables to move the data >> about twice as fast as dbexport & dbimport. There is also a parallel >> mode option >> (-p) to unload the entire database in parallel which is often even faster. > >> You will need the packages myexport and utils2_ak (for my dbschema >> replacement utility myexport that has schema support for >> dbexport/dbimport and myexport/myimport). >> >> Another alternative would be to use my dbcopy utility (also in >> utils2_ak) along with the mkdbcopy.awk script in the package >> utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema >> or myschema output file to copy the entire database directly from one >> server instance to the other without the intermediate disk file(s) by >> using dbcopy. Dbcopy is very fast and if you add in the time savings >> of not having to write the export files and read them back in, it is > usually faster even than that. >> >> 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> > wrote: >> >>> Another question: >>> >>> Previously, we have used unload and onunload to copy a database from >>> one instance to another on the same server. I believe that the >>> database has been spread across two dbspaces, whereas previously all >>> the tables were located in only one dbspace. The command that we >>> used to use to load the database was >>> >>> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>>> >>> The reason that we had to move some of the tables to a different >>> dbspace is that some of the tables were so large, they were running >>> out of extents and we had to create a dbspace with a larger page size. >>> >>> So, my question is, what is an equivalent command to copy this >>> database now that it occupies two dbspaces on the target? >>> >>> -----Original Message----- >>> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf >>> Of Larry Sorensen >>> Sent: Thursday, August 02, 2012 12:04 PM >>> To: ids@iiug.org >>> Subject: RE: Dbspace question [27906] >>> >>> IDS 11.50.FC5 >>> Solaris 10 >>> >>> What is the command again, to see what dbspaces a database is using? >>> >>> Larry >>> >>> >>> ******************************************************************** >>> * >>> * >>> ****** >>> *** >>> Forum Note: Use "Reply" to post a response in the discussion forum. >>> >>> >>> >>> >> *****************************************

never mind what I said, I was thinking you were running a test. Again, the target db should reside in the same dbspace as the source and the you should also have the same dbspace layout as the source in terms of names and sizes. Sorry Larry, I'm away from my computer now and won't be avail until next hour or so... On Aug 2, 2012, at 7:39 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > How do you not use extent specification in an onload? Is there some file > somewhere with the schema for the onunload that you can edit? > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern > Sent: Thursday, August 02, 2012 5:27 PM > To: ids@iiug.org > Subject: Re: Dbspace question [27919] > > remember I've mentioned about commenting out the extent specifications? The > idea is to NOT use > > On Aug 2, 2012, at 7:01 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: > >> I dropped the database in the target instance. (It has other databases >> as >> well) When I try to do the onload, I receive the message >> >> Error allocating extent pages. >> ISAM error: no more extents>> >> There should be room in the dbspace because I deleted the previous >> database that I was going to refresh and I am getting nowhere near >> completion of the onload. >> >> Any ideas? >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Larry Sorensen >> Sent: Thursday, August 02, 2012 3:36 PM >> To: ids@iiug.org >> Subject: RE: Dbspace question [27916] >> >> Thank you. I will try it. >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Kern Doe >> Sent: Thursday, August 02, 2012 3:09 PM >> To: ids@iiug.org >> Subject: Re: Dbspace question [27915] >> >> Say, your database (source) created in dbs1 but all your tables are in >> dbs2, when you do onload (to target), of course, you must specify -d >> dbs1 (it is where the database is in), but all your tables are >> automagically onloaded to >> dbs2 -- as far as I remember. >> >> HOWEVER, I must mention this issue based on my past experience >> involving onunload/onload with older version of IDS (9.4?) was that if >> you have created dbspaces with different page sizes, onunload of >> database level appears to work but then onload will fail -- I have not >> tried with the latest version so I do not know if IBM has fixed this bug. >> >> I encourage you to test all these out to see for yourself. >> >> ________________________________ >> From: Larry Sorensen <lsorensen25@msn.com> >> To: ids@iiug.org >> Sent: Thursday, August 2, 2012 4:46 PM >> Subject: RE: Dbspace question [27914] >> >> So, what you are thinking is that, if I do not use onload -d dbspace >> (the -d option), it will just use the same dbspaces as the unload came >> from rather than the rootdbs, which I was worried it might? >> >> Larry >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Kern >> Sent: Thursday, August 02, 2012 2:42 PM >> To: ids@iiug.org >> Subject: Re: Dbspace question [27913] >> >> continue using onunload and onload, it should work as long as your >> target instance has identical or similar dbspace layout. Why don't you >> test it out, it should take 15 min and you'll know the answer. >> For example, generate a schema of your source database but modify or >> comment out extent sizes (to save space). On the target instance, >> recreate the same database with this schema. Now run onunload, drop >> the database, then onload >> >> On Aug 2, 2012, at 3:22 PM, "Larry Sorensen" <lsorensen25@msn.com> wrote: >> >>> OK. I am under the gun here to get this done today. What you are >>> telling me is that I can no longer use onload, now, because I have >>> two dbspaces. Your utilities sound attractive, but there will be >>> quite a learning curve, I am afraid. Do you have any documentation >>> for doing this and setting everything up on a Solaris server? Are >>> there any other suggestions for just getting me by today? >>> >>> Thank you for your help. >>> >>> Larry >>> >>> -----Original Message----- >>> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >>> Art Kagel >>> Sent: Thursday, August 02, 2012 1:10 PM >>> To: ids@iiug.org >>> Subject: Re: Dbspace question [27909] >>> >>> You could use dbexport with the -ss option then dbimport or for a >>> faster copy use my dbexport/dbimport replacement utilities myexport & >> myimport. >>> With the -E option these scripts use external tables to move the data >>> about twice as fast as dbexport & dbimport. There is also a parallel >>> mode option >>> (-p) to unload the entire database in parallel which is often even > faster. >> >>> You will need the packages myexport and utils2_ak (for my dbschema >>> replacement utility myexport that has schema support for >>> dbexport/dbimport and myexport/myimport). >>> >>> Another alternative would be to use my dbcopy utility (also in >>> utils2_ak) along with the mkdbcopy.awk script in the package >>> utils4_ak. Mkdbcopy.awk will generate a shell script from a dbschema >>> or myschema output file to copy the entire database directly from one >>> server instance to the other without the intermediate disk file(s) by >>> using dbcopy. Dbcopy is very fast and if you add in the time savings >>> of not having to write the export files and read them back in, it is >> usually faster even than that. >>> >>> 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, Aug 2, 2012 at 2:22 PM, Larry Sorensen <lsorensen25@msn.com> >> wrote: >>> >>>> Another question: >>>> >>>> Previously, we have used unload and onunload to copy a database from >>>> one instance to another on the same server. I believe that the >>>> database has been spread across two dbspaces, whereas previously all >>>> the tables were located in only one dbspace. The command that we >>>> used to use to load the database was >>>> >>>> onload -s 419400000 -d dbs1 -t /dev/rmt/1 database1>>>> >>>> The reason that we had to move some of the tables to a different >>>> dbspace is that some of the tables were so large, they were running >>>> out of extents and we had to create a dbspace with a larger page size. >>>> >>>> So, my question is, what is an equivalent command to copy this >>>> database now that it occupies two dbspaces on the target? >>>> >>>> -----Original Message----- >>>> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf >>>> Of