If none of you knows something about MC/ServiceGuard, may be someone
could help us about DB2 V9 in a cluster HA environment (HACMP, or
whatever...)

Please help!!!!!

Bruno LIVERNAIS a écrit :

I dont know anything about MC/ServiceGuard, but have you checked out
what the help suggests?

[lelle@53dbd181 lelle]$ db2 "? SQL1092N"

SQL1092N "<authorization-ID>" does not have the authority to
          perform the requested command.

Explanation:

 Possible causes are:

1.    The user attempted to execute a command or operation without
    having the proper authority for that command or operation.

2.    You are using Kerberos authentication in a Windows
    environment, and have attempted to log on to the machine with
    an account which is not a domain account.  Only domain users
    can use Kerberos authentication in a Windows 2000
    environment.

3.    If you are using LDAP support, the userid you are using or
    the DB2 Connect gateway might not have the authority to
    perform the CATALOG DATABASE, NODE and DCS DATABASE
    commands.

4.    If in a Windows environment, the DB2 Server logon userid,
    DB2_GRP_LOOKUP setting, and other group enumeration settings
    might not be configured properly, preventing you from gaining
    access using "<authorization-ID>".  The following is a
    very common sample scenario:

    -   You are attempting to connect to the DB2 Server using a
        domain userid.

    -   The logon userid for the DB2 Server instance is LocalSystem
        or a local account.

    -   Groups (SYSCTRL, SYSADM, SYSMAINT) are defined to be domain
        groups.

    -   DB2_GRP_LOOKUP is not set.  As a result, an attempt is made
        to enumerate the groups at the location where
        "<authorization-ID>" is defined.  This fails
        because the DB2 Server instance is running under the
        context of LocalSystem or the local account, and so
        cannot access the network resources required to do so.

    -   To fix this problem change the logon userid for the DB2
        Server instance to be a domain account and add this
        domain account to the local Administrators group.  If DB2
        Extended Security is enabled, then the domain account
        must also be added to the DB2ADMNS group or its
        equivalent.

5.    If in a Windows environment running with DB2 Extended
    Security enabled, the userid "<authorization-ID>" might
    be attempting to use or modify a database resource, while not
    a member of the local DB2USERS or DB2ADMNS group.  This is
    not allowed.  The command cannot be processed.

 The command cannot be processed.

 Federated system users: this situation can also be detected by
the data source.

User Response:

 Solutions to problem causes described above are:

1.    Log on as a user with the correct authority and retry the
    failed command or operation.  Correct authorities may include
    SYSADM, SYSCTRL, SYSMAINT, and DBADM.  DBADM is granted on
    databases and all other authorities are determined by
    membership in the groups defined in the database manager
    configuration (eg. if sysctrl_group in the database manager
    configuration file is defined as 'beatles', then you must
    belong to the group 'beatles' to have SYSCTRL authority).
    Refer to the Command Reference or the SQL Reference for the
    listing of required authorities for the attempted command or
    operation.

2.    Log on to the machine with an account which is a domain
    account.

3.    Invoke the command "UPDATE DBM CFG USING CATALOG_NOAUTH YES"
    at the client or the gateway to correct the problem.

4.    Make appropriate configuration settings changes.  For more
    information on Windows OS security and groups, search the DB2
    Information Center
    (http://publib.boulder.ibm.com/infocenter/db2luw/v9) using
    phrases such as "db2_grp_lookup" and "Windows authentication"
    .

5.    Add the userid "<authorization-ID>" to the local windows
    security groups DB2USERS or DB2ADMNS using the Windows Computer
    Management tool.  A workaround is to disable Extended Security but
    this is not recommended.

 Federated system users: if necessary isolate the problem to the
data source rejecting the request (see the problem determination
guide for procedures to follow to identify the failing data
source) and ensure that the authorization id specified has the
proper authority on that data source.

 Contact the System Administrator for authority request
assistance.  Do not attempt to execute the command without
appropriate authorization.