![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Hi All, I'm upgrading to Ingres10 on an installation with lots of distributed databases. First gotcha was that upgradedb -all really bitched at the distributed databases. It was pretty convinced only the database owner should do upgradedb on those. Second Gotcha was the database owner needed to be an ingres super user toget the necessary permission level to run upgradedb.... E_SC034F_NO_FLAG_PRIV User 'lust' attempted to specify invalid flag/option 'Createdb IIDBDB application code' while connecting to Ingres. Gotcha number three was when finally I got the upgradedb to start...it promptly locks itself up on iistatistics when processing front end objects. I decided to simply drop all the distributed databases and recreate them..... Gotcha number 4...can't drop the database as its not the right version! At which point the air around me turned blue. So I have to upgrade the database in order to drop it, only I cant do that upgrade completely as it locks up. In the end I was forced to run upgradedb on the distributed databases, wait for it to lock up and delete the upgrade out of the server. The databaseversion was however upgraded by that point. Ergo I was able to then destroy the distributed database and recreate it using my maintenance scripts. Not Happy. Martin Bowes |
#3
| |||
| |||
|
#4
| |||
| |||
|
|
Hi All, I'm upgrading to Ingres10 on an installation with lots of distributed databases. First gotcha was that upgradedb -all really bitched at the distributed databases. It was pretty convinced only the database owner should do upgradedb on those. Second Gotcha was the database owner needed to be an ingres super user to get the necessary permission level to run upgradedb.... E_SC034F_NO_FLAG_PRIV User 'lust' attempted to specify invalid flag/option 'Createdb IIDBDB application code' while connecting to Ingres. Gotcha number three was when finally I got the upgradedb to start...it promptly locks itself up on iistatistics when processing front end objects. I decided to simply drop all the distributed databases and recreate them.... Gotcha number 4...can't drop the database as its not the right version! At which point the air around me turned blue. So I have to upgrade the database in order to drop it, only I cant do that upgrade completely as it locks up. In the end I was forced to run upgradedb on the distributed databases, wait for it to lock up and delete the upgrade out of the server. The database version was however upgraded by that point. Ergo I was able to then destroy the distributed database and recreate it using my maintenance scripts. Not Happy. Martin Bowes |
#5
| |||
| |||
|
|
Would that be the Australian Cricket Team which just dismissed England for 187? Marty -----Original Message----- From: michaelnewp... (AT) yahoo (DOT) com [mailto:michaelnewp... (AT) yahoo (DOT) com] Sent: 16 December 2010 16:51 To: info-ing... (AT) kettleriverconsulting (DOT) com Subject: Re: [Info-Ingres] upgradedb on distributed databases...locked up.. On Dec 16, 2:02�pm, Martin Bowes <martin.bo... (AT) ctsu (DOT) ox.ac.uk> wrote: Hi All, I'm upgrading to Ingres10 on an installation with lots of distributed databases. First gotcha was that upgradedb -all really bitched at the distributed databases. It was pretty convinced only the database owner should do upgradedb on those. Second Gotcha was the database owner needed to be an ingres super user to get the necessary permission level to run upgradedb.... E_SC034F_NO_FLAG_PRIV User 'lust' attempted to specify invalid flag/option 'Createdb IIDBDB application code' while connecting to Ingres. Gotcha number three was when finally I got the upgradedb to start...it promptly locks itself up on iistatistics when processing front end objects. I decided to simply drop all the distributed databases and recreate them.... Gotcha number 4...can't drop the database as its not the right version!At which point the air around me turned blue. So I have to upgrade the database in order to drop it, only I cant do that upgrade completely as it locks up. In the end I was forced to run upgradedb on the distributed databases, wait for it to lock up and delete the upgrade out of the server. The database version was however upgraded by that point. Ergo I was able to then destroy the distributed database and recreate it using my maintenance scripts. Not Happy. Martin Bowes ...well, if you ever get tired of db's, there are some vacancies in the Oz cricket team....;-)) |
#6
| |||
| |||
|
|
Would that be the Australian Cricket Team which just dismissed England for 187? Marty -----Original Message----- From: michaelnewp... (AT) yahoo (DOT) com [mailto:michaelnewp... (AT) yahoo (DOT) com] Sent: 16 December 2010 16:51 To: info-ing... (AT) kettleriverconsulting (DOT) com Subject: Re: [Info-Ingres] upgradedb on distributed databases...locked up. On Dec 16, 2:02�pm, Martin Bowes <martin.bo... (AT) ctsu (DOT) ox.ac.uk> wrote: Hi All, I'm upgrading to Ingres10 on an installation with lots of distributed databases. First gotcha was that upgradedb -all really bitched at the distributed databases. It was pretty convinced only the database owner should do upgradedb on those. Second Gotcha was the database owner needed to be an ingres super user to get the necessary permission level to run upgradedb.... E_SC034F_NO_FLAG_PRIV User 'lust' attempted to specify invalid flag/option 'Createdb IIDBDB application code' while connecting to Ingres. Gotcha number three was when finally I got the upgradedb to start...it promptly locks itself up on iistatistics when processing front end objects. I decided to simply drop all the distributed databases and recreate them.... Gotcha number 4...can't drop the database as its not the right version! At which point the air around me turned blue. So I have to upgrade the database in order to drop it, only I cant do that upgrade completely as it locks up. In the end I was forced to run upgradedb on the distributed databases, wait for it to lock up and delete the upgrade out of the server. The database version was however upgraded by that point. Ergo I was able to then destroy the distributed database and recreate it using my maintenance scripts. Not Happy. Martin Bowes ...well, if you ever get tired of db's, there are some vacancies in the Oz cricket team....;-)) |
#7
| |||
| |||
|
|
Gee they've gone pretty quiet now.... |
#8
| |||
| |||
|
|
Gee they've gone pretty quiet now.... |
#9
| |||
| |||
|
|
One day a rooster, next day a feather duster! |
![]() |
| Thread Tools | |
| Display Modes | |
| |