Danke für den Hinweis!
Mittlerweile habe ich doch tatsächlich auch eine Antwort von VMware erhalten.
Der Übeltäter (wenn man es überhaupt so nennen kann) ist die Rechtestruktur am Oracle Server. Um die Installation durchzuführen werden Prozeduren auf dem Datenbankserver gestartet. Das darf wohl nicht einmal der DBA sondern nur der SYS user. Der muss dann auch die entsprechenden Oracle Rechte setzen.
Hier die originale Mitteilung von Anna (VMWare):
Dear Klaus,
Thank you for your Support Request.
My name is Anna and I will be assisting you with this Support Request.
PLS-00201: identifier 'DBMS_LOCK' must be declared
Looks like this would be the cause:
The schema used to manage the VirtualCenter objects must be able to use
Oracle's DBMS_LOCK built-in package, which means it requires execute
privileges on the package. Prior to installing the VirtualCenter upgrade on
an existing system, you (or your Oracle Database administrator (DBA)) must
log on to the Oracle Database server as the sysdba and grant the privilege,
as follows:
sqlplus system/<password>@<systemname> as sysdba
grant execute on dbms_lock to vpxadmin;
Note that the [@<systemname>] is relevant for a remote database host
connection only. For example, assuming a database instance installed on the
same host as the VirtualCenter Server system, the session might look as
follows:
C:\oracle\product\10.2.0\10gR2_Home\BIN>sqlplus system/techpubs as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Jan 5 10:01:51 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> grant execute on dbms_lock to vpxadmin;
Grant succeeded.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 -
Production
With the Partitioning, OLAP and Data Mining options
C:\oracle\product\10.2.0\10gR2_Home\BIN>
For a fresh install of VirtualCenter on an existing Oracle Database Server,
you must create the schema and grant it the appropriate privileges prior to
VirtualCenter installation. Here's an example of a SQL*Plus schema-creation
session for an Oracle Database Server 10gR2 instance, from a Windows console:
sqlplus system/<password>[@<systemname>] as sysdba
CREATE SMALLFILE TABLESPACE "VIRTUALCENTER"
DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TECHPUBS\virtualcenter'
SIZE 500M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
ALTER DATABASE DEFAULT TABLESPACE "VIRTUALCENTER";
CREATE USER "VPXADMIN" PROFILE "DEFAULT"
IDENTIFIED BY "*******"
DEFAULT TABLESPACE "VIRTUALCENTER"
TEMPORARY TABLESPACE "TEMP"
ACCOUNT UNLOCK;
GRANT "CONNECT" TO "VPXADMIN";
GRANT "RESOURCE" TO "VPXADMIN";
GRANT "CREATE VIEW" TO "VPXADMIN";
GRANT "EXECUTE ON DBMS_LOCK" TO "VPXADMIN";
After these (the update or clean part) has been run on the db, try the update
VC again.
If that would fail again, please include the full log. And if the install
succeeds after this, let me know.
Looking forward to hearing from you.
Kind regards,
Anna
Mit diesem Problem war ich sicherlich nicht alleine, und der eine oder andere könnte von Annas Mail ja auch profitieren ....
Ach ja, ein witziger Effekt noch:
Nach erfolgreicher Installation (es wurde überigens nicht gefragt ob die die Datenbank weiternutzen oder plattmachen will) habe ich mich am VC angemeldet und erstmal einen Schreck bekommen. Alle ESX Server ausgegraut!
Allerdings wurden in der Taskliste Agentenupdates für alle Server angezeigt die gerade erst bei 80% waren. Nach kurzer Zeit waren die Agenten dann aktualisiert und die Server wieder administrierbar (schwarz).