Hi all, does somebody backup Navision with HotCopy and has a large database (> 15 GB)? Our problem is, that HotCopy is so slow, that you could perfectly say, that it’s not working at all. The database is 24 GB and contains about 17 GB data. The server-machine is well built for a C/Side-db and performs pretty good. To copy the database via explorer takes about 30 minutes. To backup the database through the navision-client takes about 50 minutes. To backup the database with hotcopy on the server is running about 2,5 days. No network is involved. After setting cc (consistency check) to no, it’s still slow. After 6,5 hours 32% are done. And it’s getting even slower. After 9,25 hours 39% and after 25 hours 77% are done. Anybody with experience with HotCopy out there ? Btw. - we run 3.10A. Edited by - rmotzer on 2002 Jul 28 10:25:30
Strange. We’re running HotCopy at one of our clients with a 10Gb database. Approx 30 minutes is a normal time for the backup and we do not have any problems at all. We have 1Gb RAM and 600Mb cache allocated for Navision. Is it possible that You have a lot of swapping involved? //Lars
Hi Lars, i’m going to check out if any swapping is involved - but i don’t think so. What release of Attain do you run ? Our NTR also tested HotCopy and it took them about 3 hours to backup a 5 GB database… Maybe you could describe the setup of your customer-installation in short ? Thank you very much Richard
Funny story … On a small testmachine i now did the following: Celeron 1 GHz 256 MB RAM 1 * 40 GB IDE W2000 Server 3.10A Server and Client Standard-Database expanded to 5 GB A batch created 5 Mio G/L-Entries → now the database contains about 4 GB data All performance-killing options for HotCopy (cc, dbtest) were disabled. First attempt: Worked o.k. until 8%. Server-CPU was 100% until 8%. Server.exe took constantly about 98 %. Then - at 8% - the server.exe went sleep (about 2% Activity left). After 20 Minutes i killed the hotcopy-process. Second attempt: almost the same - i reached 9 % then the show was over. CPU went to sleep. No further progress. Btw. in the W2000-application log occured a warning from the server (error 18 in module 244). But only one time … Next try → now it’s running o.k. → within 25 Minutes almost 50% are done. CPU is permanently 100%. Hotcopy really makes my day 
We’re running 3.10A. The database consists of 4 files in an RAID-1 array. The disks are 15000rpm’s and the controller is brand new from IBM, so we have quite good performance. The backup stores the files on the same server on a separate disk that we use only for this purpouse, so there isn’t any read/write on the same disk for the HotCopy. We also use the Consistency check. One thing about the consistency check though: I think it only checks the file. Not the same type of check that is made by DB-Test or by the normal backup. Could someone please verify this. I don’t know if there is so much more to tell regarding HotCopy in this patricular installation, but if there’s anything else You wan’t to know. just let me know. //Lars
Hi Richard, I could probably explain the error 18 in module 244, but have no clue about the rest. This is caused by the fact that when you killed hotcopy the (database)engine still wanted to send messages to hotcopy. Hotcopy can be considered in fact as being a “dummy” client. Since the connection was closed the engine issued the warning. It is still strange what you are telling. A 5 GB database shouldn’t take more than 5 minutes to complete. Regards Kalman
Hi Lars, You are right cc means consistency regarding the integrity of the database file considered as a file. Basically a signature(crc) is computed on each source databasefile and then verified on the target. Dbtest should check the consistency of the database. Regards Kalman
quote:
Originally posted by rmotzer: Next try → now it’s running o.k. → within 25 Minutes almost 50% are done. CPU is permanently 100%.
Hi Richard. The CPU is constantly at 100% in our case also, but it doesn’t affect the users. It seems like the DBMS gets the CPU it needs to do it’s work. HoCopy seems to have a lower priority. //Lars
Hi Lars, our customers installation seems to quite similar to the installation you described. So i’m still looking for the reason of the poor performance there. It’s running for hours… And for the clients the server is too slow to work with during hotcopy. On my tiny testmachine (desktop PC/one ATA-Hdd/256 MB/Cel900/5GB database/4 GB data) hotcopy performs quite good. Without cc and dbtest the backup takes about 50 minutes for the 5 GB database. CPU is on 100% and like you said → it does not affect performance too much. But … this is only true if it’s running at all. Sometimes (i have no clue why) it simply stops to proceed with the backup. The percentage does not increase. The server.exe does not take more than 2% CPU-time then. After killing hotcopy and starting again, most times it’s running through without a problem ??? Alberes are you sure ? 5 GB in 5 Minutes ? The error 18 in Module 244 did not occur anymore. Like you said - the manual killing of the backup-process semmed to be the reason for that. Thanks both
Hi Richard, Certainly I was exagerating. I just wanted to emphasize that it shouldn’t take so much to accomplish the backup. Sorry for that. On my testmachine(21,7 Pentium, 120 SCSI + 1*60 IDE HDD + 768 MB RAM) it took 15 minutes to complete the same backup. The server used 60-70 % CPU. The extensive CPU usage is a default behaviour when using hotcopy and should not interfere with other tasks of the DBMS. It is caused by some CPU intensive computation while copying the database blocks. Have you tried splitting the database in two or more physical files and doing the backup that way? I would restart the server too after killing hotcopy too many times. Regards Kalman
Finally we found the problem … 
thanks to our NTR that passed a very useful hint from Navision Denmark to us. As written in a manual we created the .txt-file that contains the source-database-filenames and the destination-path for the copies. As written in the manual we used the full path to the files including the the computername (//mycomputer/U$/…). Doing that, wuring the whole backup a part of the network-controller seemed to be engaged - although everything worked locally. Using simply the drivenames (U:…) Hotcopy worked like it should. Before that, the backup took us one time 4 hours and one time 8 hours or more. And sometimes it freezed completly, until somebody rattled with the mouse on the window in which Hotcopy ran The after changing Hotcopy did the backup of a 24 GB-database with about 16 GB data within 20 minutes. And that during the day. Performance now was only dependend on the performance of the destination-drives. Thanks all. Richard