Subject | Largish update - system limits |
---|---|
Author | Aage Johansen |
Post date | 2004-07-26T19:39:14Z |
In the process of converting a varchar field (MERKNAD) to a blob
(KOMMENTAR) I had created the new field and was ready to move the
(non-empty) values:
update PERSON
set KOMMENTAR = MERKNAD
where MERKNAD is not Null and MERKNAD <> ''
It had worked nicely on another table (of about 1 mill records - about
200.000 was changed, I think), this table (PERSON) has about 6.5 mill
records, where about 1 mill were going to be changed.
Well, after a short while access to databases on the server became next to
impossible. I just let it run, but the next morning the server (Win2k)
complained about "low on virtual memory" - I didn't check actual values. I
guess I shouldn't be surprised... A server reboot was done. (I've later
used a program to do the updates, committing every 1000 records)
Now, how can I know the (approx.) limits of the system before doing such an
operation (big update)?
This is Fb/1.0.3 (I believe) running on Win2k/SP2 with 512MB RAM. The
update was run from IB_SQL on a pc.
--
Aage J.
(KOMMENTAR) I had created the new field and was ready to move the
(non-empty) values:
update PERSON
set KOMMENTAR = MERKNAD
where MERKNAD is not Null and MERKNAD <> ''
It had worked nicely on another table (of about 1 mill records - about
200.000 was changed, I think), this table (PERSON) has about 6.5 mill
records, where about 1 mill were going to be changed.
Well, after a short while access to databases on the server became next to
impossible. I just let it run, but the next morning the server (Win2k)
complained about "low on virtual memory" - I didn't check actual values. I
guess I shouldn't be surprised... A server reboot was done. (I've later
used a program to do the updates, committing every 1000 records)
Now, how can I know the (approx.) limits of the system before doing such an
operation (big update)?
This is Fb/1.0.3 (I believe) running on Win2k/SP2 with 512MB RAM. The
update was run from IB_SQL on a pc.
--
Aage J.