Re: Level 0 Restore

On Jul 5, 1:59 pm, Fernando Nunes <s...@domus.online.pt> wrote: > Cats wrote: > > Thanks, was thinking about upgrading the test machine so I could get > > rid of the 2GB limit and import a database much more easily (yes know > > I've swapped between level 0 and import there) but upgrading it to v10 > > would block bringing the level 0 archive over from the live so we'll > > live with it for the time being. Several of the tables are too large > > to fit in 2GB which of course complicates an import. > > Having a different version in development and production is never a good idea. > I'm a bit confused by your problem. A table can have a lot more than 2GB. A > table can spawn several chunks. And you can also fragment it through several > dbspaces. I also don't understand why this is a problem in development and not > in production... Do you have larger tables in development than in production? > Usually it's the other way around... We have tables that are too large to fit in 2GB. Being able to create chunks much larger than 2GB would have simplified the task of getting a second copy of live, that's all - for my purposes one enormous chunk would have sufficed. It would also have acted as a test bed for moving live to 10.x - we won't do that without a test, but obviously will do that on the imported copy of the live db with it's existing configuration. However having 10.x on the test machine would prevent us using a level 0 restore to re-import the live database. > > We'll wait until the current burst of application upgrade activity is > > over and then deal with getting the database up-to-date. > > If you do level 0 restores from production into the development environment you > can (and in fact should do for testing purposes), migrate the development > instance to v10. If all goes well it will take you less than five minutes > (assuming you jump a few steps used for consistency checking). Than you should > test your applications to be sure nothing weird happens when run against v10. That is exactly what we will do in the fullness of time. However at present we have a new set of application programs being developed & tested, so changing it all at once is a bit challenging. Of course ion retrospect it might have been brighter to change the IDS version first! We need 3 database at present - copy of the live for training new users, development for developing (!) and training users on the new programs, and a second development database private for me for me to test the database migration from the current schema to the new one. That last one will be setup with dbexport/dbimport, giving me an easy way to restore my private test db at any time, and it's setting up the initial dbimport for that one that running IDS 10.x would have simplified for my me, and the folks down in IT who set up the chunks and symbolic links for me.