Hi, we had this discussion about 'holes' in devspaces. If we used 'holes' we do not really claim the devspace, but only those clusters that had been accessed. This is fine for writing core dumps, but it is not such a good idea if you cannot trust that the disk space will be available when needed. You can end up with a error situation, where your data cannot be written to the devspaces because there is no space left on disk. This is a crash situation we would like to prevent. Furthermore if the devspace is in a file system the expansion of the file during initializing makes it continous on disk rather than splitted. This reduces seek times during scanning larger sections. Nevertheless the parameter 'FORMAT_DEVSPACE' is still found in coding, but no longer as a tunable parameter (see veo79.c,line 1115 XParam->fFormatDevspace = TRUE;)... CU jrg
> -----Original Message----- > From: JUNG, Christian [mailto:[EMAIL PROTECTED]] > Sent: Montag, 3. Juni 2002 18:24 > To: SAPDB-General (E-Mail) > Subject: AW: Problems with update to 7.3.0.23 > > > > Elke wrote: > > > > Unfortunately I have to tell bad news concerning kernel > > version 7.3.0.23: > > > > We included a new check in this code. But, unfortunately this check > > sometimes > > (depending on the meta data of the database, not the data > > itself) does not > > work > > as it should do. > > > > This check is used ONCE when first restarting the database > > after installing > > 7.3.0.23. > > --> the first try to make your database ONLINE will decide if > > 7.3.0.23 is a > > version > > you can use or not. > > If -9400 or -9111 is returned when trying to make the > > database ONLINE, it > > will be > > returned, no matter how often you will try. > > If you did not have any trouble, then your database should be ok. > > > > Later this afternoon version 7.3.0.24 will be available with > > a check which > > will > > work as it should. > > > > --> Those being on a kernel version < 23 should wait for this > > new one (24) > > to avoid > > double-installing of versions. > > > > Sorry for the inconvenience this version caused. > > Thanks a lot for your help, Elke! > > This problem made/makes a lot of work (recovering and > reconstructing data). > It's pretty hard to defend SAP DB if it's doing such things > (some people > argued with us about the functionality regarding backup and > recovery and in > this case it's hard to find some reasons for SAP DB - shure, > I know, it's > for free and has got a big functional range). As you know if > everything > works fine nobody says something, but if something crashes... > Our database > will be down for one week and this is very bad for the guys > working with > this database. I think it'll be up wednesday or thursday with > all data as it > should be. > > I would appreciate it when the recovery-process could be > improved and speed > up (e.g. SAP DB could check, if a backup can be recovered or > not - if it's > possible). Is it really neccessary to format all devspaces, > when installing > a new instance? Can't you use "holes" in the files when creating the > devspaces? -> It is possible (under *nix) to create files > with "holes" by > jumping behind the file-end when creating a file. These holes > are returned > as a bunch of zeros when reading. Only if you are writing > something in these > holes the system will create blocks on the harddrive. So it's > possible to > create rather huge files without any IO (if there are only > zeros in them). > It took a lot of time to test different recoveries because of > the time we > needed to create a new instance with about 15 to 20 GB data-devspace. > > We've found out, that the described check is also made if > you're installing > a new - rather big - instance (>= 12GB), too. So take care > and update to > 7.3.0.24 which is now available. I didn't have the time to > check this, but > Elke says that this "bug" is fixed. > > OK. Just some ideas and impressions for/of a pretty nice dbms ;-) > > > Greets > Christian Jung > > PS: Do you have somewhere an updated version of the > Error-Messages? "message > not available" ain't a good error-description ;-) > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
