Install GC 10.2.0.5.0 on OEL/RHEL5/SLES10 Using Existing Database (11g)_784963.1

rongshiyuan發表於2014-08-05

How to Install Grid Control 10.2.0.5.0 on OEL/RHEL5/SLES10 Using the Existing Database (11g) Option (Doc ID 784963.1)


In this Document

Goal
Solution
References

Applies to:

Enterprise Manager Base Platform - Version 10.2.0.5 to 10.2.0.5 [Release 10.2]
x86 32 bit
Linux x86
Oracle Enterprise Linux 4.0
x86 64 bit
Linux x86-64
Checked for relevance on 28-Aug-2013

Goal

This software-only method of installation is specifically required for installation of Grid Control on Oracle Enterprise Linux 5, Red Hat Enterprise Linux 5 or SLES10 with an existing 11g database for use as a repository database. Version 10.2.0.5.0 is the only supported Grid Control version for these platforms. This example demonstrates one successful scenario.

Note: 
Do NOT use this method to patch or upgrade any existing Grid Control installation.


Note that filepath designations such as .../oms10g and .../agent10g are relative, represent generic locations, are for descriptive use only and indicate that the Parent Directory should be prepended to arrive at a usable filepath value. A descriptive character string such as ".../agent10g" should never be used in an installation exercise. The same is true for .../oraInventory, but in this case, the filepath to be prepended may not be the Parent Directory, rather the actual value should be that described in the /etc/oraInst.loc file.


For this exercise, the following configuration is used in the examples.

10.2.0.1.0 or 10.2.0.3.0 base product install stage: /u02/gc102/
10.2.0.5.0 patchset install stage: /u02/gc10205/
Parent directory for installation: /u01/app/gc/
/oradata/ location for repository database: /u01/app/gc/oradata
/oraInventory location: /u01/app/oraInventory
All OS and DB access passwords, for simplicity: linuxr5
Existing respository database SID: db111
Database Oracle Home filepath: /u01/app/db111
OMS will be unlocked
Existing /etc/oraInst.loc pointing to /u01/app/oraInventory



Values used in response files and command executions must be altered if a different configuration is used.

These values are for demonstration use only and should be adapted to be applicable to the system receiving the installation.

Solution

Operating System Prerequisites:

For this example, Oracle Enterprise Linux 5 was installed with the preparation described in:

Note.815157.1 Operating System Package Prerequisites for 10.2.0.5.0 Grid Control on Linux for 32bit and 64bit.

For SuSE10, use the preparation described in:

Note 826353.1 EM 10g: How To Prepare SuSE 9 and SuSE 10 for Installation of Enterprise Manager Grid Control 10.2.0.5

Database Prerequisites:

All of the requirements of the Grid Control installation with a new database must be met as described in the Oracle?? Enterprise Manager Grid Control Installation Guide, 10g Release 5 (10.2.0.5.0). This document describes general (i.e, enterprise edition with fine grained access control active) and specific (i.e., initialization parameters) requirements for the existing database. Note that a default enterprise edition database installation is not sufficient for use as a Grid Control repository due to these general and specific requirements, but must be configured to meet them.

Additionally, the database must be free of any prior repository contents, whether for Database Control or Grid Control. Use emca, RepManager or the manual procedure (option 4) in Note.278100.1 to remove an existing repository before installing Grid Control with the existing database. Use of the emca utility is described in chapter 1 of Oracle?? Enterprise Manager Advanced Configuration, 10g Release 5 (10.2.0.5). Use of RepManager is described in chapter 9 of the same document, available on the OTN Enterprise Manager documentation site.

Lastly, the database must be a version currently certified for database support and use as a Grid Control repository as shown on the Certify section of My Oracle Support.

See the details in the published documentation:

For general existing repository database requirements:

Oracle?? Enterprise Manager Grid Control Installation Guide
10g Release 5 (10.2.0.5.0)
Part Number E10953-07
Chapter 3 Preinstallation Requirements
Section titled: Oracle Management Repository Software Requirements

URL:
http://download.oracle.com/docs/cd/B16240_01/doc/install.102/e10953/pre-installation_req.htm#CHDGIEAD

For repository database initialization parameters requirements:

Oracle?? Enterprise Manager Grid Control Installation Guide
10g Release 5 (10.2.0.5.0)
Part Number E10953-07
Chapter 7 Installing Enterprise Manager Grid Control
Section titled: Installing Enterprise Manager Grid Control Using an Existing Database/Prerequisites

URL:
http://download.oracle.com/docs/cd/B16240_01/doc/install.102/e10953/installing_em.htm#CHDIIAHHN

 

Network Prerequisites:

See this reference for the basic networking requirements of Grid Control components:

Note.428665.1 Installation Checklist for Testing Networking Configurations Prior to Installing EM Components


Additionally, if IPv6 is configured you can use one of the methods below for Grid Control preparation:

1. Remove the IPv6 configuration from the /etc/hosts file or disable as follows (example):

# IPv4 entries
127.0.0.1 localhost
192.168.1.1 hostname1.us.oracle.com hostname1
192.168.1.2 target1.us.oracle.com target1

# IPv6 entries
#::1 localhost ipv6-localhost ipv6-loopback
#fe00::0 ipv6-localnet
#ff02::1 ipv6-mcastprefix
#ff02::2 ipv6-allrouters
#ff02::3 ipv6-allhosts

2. See the solution in section 10 of this reference:

Note.343085.1 Known Issues Installing 10.2 Grid Control

Known Issues:

Check these documents for any additional conditions that may require attention before proceeding with installation:

 Note 787872.1 Grid Control 10.2.0.5.0 Known Issues

Note 464674.1 Checklist for EM 10g Grid Control 10.2.x to 10.2.0.4/10.2.0.5 OMS and Repository Upgrades

 

Procedure:

To install Enterprise Manager Grid Control 10.2.0.5.0 using an existing 11g database with the silent, software-only method, follow these steps:

A. Install Source Staging and Response File Preparation

Note that the filepath references are relative. If your install source extracts to a different configuration, the examples here should be adapted to the actual filepath values.

1. Place the base product install stage for Linux (10.2.0.1.0 for x86 Linux, 10.2.0.3.0 for x86_64 Linux) in an accessible directory: i.e., /u02/gc102/.

2. Modify the base install response file for the "Grid Control with an existing database" install type, located at: /u02/gc102/Disk1/response/em_using_existing_db.rsp.

Generic filepath form:

/Disk1/response/em_using_existing_db.rsp

3. Alter the following parameters from default as follows (archive this file before alterations):

UNIX_GROUP_NAME="dba"
FROM_LOCATION="/u02/gc102/Disk1/oms/Disk1/stage/products.xml"
BASEDIR="/u01/app/gc"
INSTALLATION_NAME="r5"
s_reposHost="gamma.clspco.adelphia.net"
s_reposPort="1523"
s_reposSID="db111"
s_reposDBAPwd="linuxr5"
s_mgmtTbsName="/u01/app/oradata/db111/mgmt.dbf"
s_ecmTbsName="/u01/app/oradata/db111/mgmt_ecm_depot1.dbf"
s_securePassword="linuxr5"
s_securePasswordConfirm="linuxr5"
b_lockedSelected=false
s_reposPwd="linuxr5"
s_reposPwdConfirm="linuxr5"

 

Notes:

- "dba" must be a valid OS user group
- INSTALLATION_NAME is user selectable, but a value must be provided
- Use the examples in the response file templates to include double quotes ("") or curly braces ({}) where indicated. Omission of these character string conditioners may lead to errors like the listener poirt number being inserted as a null value instead of 1523 (as in the example above), leading to failure which can be difficult to diagnose without detailed log review and a need to start the entire process over.
- The directory portion of the filepaths of the values for "s_mgmtTbsName" and "s_ecmTbsName" must be created before the installation because they will not be created in the installation process. It is convenient to locate these datafiles in the /oradata/ directory of the database being used for the repository, so this filepath should used from the node hosting the repository database. Note that the default location will be in the oms directory structure, which is not satisfactory.
- The following is the statement from the installation manual that addresses the selection of passwords for the database:

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value, one lowercase letter, and one uppercase letter.

Note that the complexity requirements for the database may be more stringent, so password compatible with the Grid Control installer should be chosen for the installation exercise, but the user may wish to change it in the database at the earliest convenience with a consequent change in the GC configuration, if necessary.

.
4. Place the 10.2.0.5.0 Grid Control patchset in a different staging location, i.e., /u02/gc10205

5. Make a copy of the patchset response file located at:

/u02/gc10205/3731593/Disk1/response/patchset.rsp

generic filepath form:

//3731593/Disk1/response/patchset.rsp

6. Rename the copy in place to oms_patchset.rsp.

Alter the following parameters from default as follows in the oms_patchset.rsp file:

ORACLE_HOME="/u01/app/gc/oms10g"
b_softwareonly=true
s_sysPassword="linuxr5"
sl_pwdInfo={ "linuxr5" }
oracle.iappserver.st_midtier:szl_InstanceInformation={ "linuxr5" }

Additionally, for x86_64, add the following line, if the installer indicates it is necessary:

ORACLE_HOME_NAME="oms10g"


7. Make a copy of the patchset response file located at:

/u02/gc10205/3731593/Disk1/response/patchset.rsp

generic filepath form:

//3731593/Disk1/response/patchset.rsp

8. Rename the copy in place to agent_patchset.rsp.

9. Alter the following parameters from default as follows in the agent_patchset.rsp file:

ORACLE_HOME="/u01/app/gc/agent10g"
b_softwareonly=true
s_sysPassword="linuxr5"
sl_pwdInfo={ "linuxr5" }

Additionally, for x86_64, add the following line, if the installer indicates it is necessary:

ORACLE_HOME_NAME="agent10g"

10. For Oracle Enterprise Linux 5 and Red Hat Enterprise Linux 5 only (not applicable to SuSE SLES10), a link titled "libdb.so.2" must be created by the root user:

ln -s /usr/lib/libgdbm.so.2.0.0 /usr/lib/libdb.so.2

This link must be created in the 32bit library location (i.e., /usr/lib), so the /usr/lib/libgdbm.so.2.0.0 must be present there. If it is not present, then install the gdbm-1.8.0-26.2.1.i386.rpm package and it should be available after that. The /usr/lib64/libgdbm.so.2.0.0 is not used in this case.

11. Verify the 11.1.0.6.0 database characteristics are as specified in this reference, available on OTN:

Oracle?? Enterprise Manager Grid Control Installation Guide, 10g Release 5 (10.2.0.5.0)

Chapter 3 and Chapter 7 show what is required of an existing database for repository use. A default installation of an Enterprise Edition database is not sufficient to support a repository due to these general and specific requirements, and must be configured to meet them.



B. Product and Patchset Installation without Configuration

User Environment:

The operating environment of the user performing the installation should be free of any references to Oracle software installations through values in following parameters, for example:

ORACLE_HOME
ORACLE_SID
ORACLE_BASE
TNS_ADMIN
PATH
LD_LIBRARY_PATH
etc.

Some operating systems come preconfigured for use with Oracle products, so it may be commonplace to find such parameters already set, even though no Oracle software has been installed. Ensure that no such references exist prior to running the installer or configuration script, except where requested by this procedure.

Additionally,  for SLES9/10, you may need to unset the ENV parameter to avoid installer failure.


The oraInventory

In order to direct the installation to the preferred location of oraInventory, as used in this example, the user should configure oraInst.loc as root prior to installation. The oraInventory directory should be created in the location of interest, i.e., the parent directory for the Grid Control installation, and the /etc/oraInst.loc file should be created with this format to point the installer in that direction:

inventory_loc=/oraInventory
inst_group=

Example:

inventory_loc=/u01/app/gc/oraInventory
inst_group=oinstall

These lines are for demonstration only and actual values should be used in practice.

If no such initial oraInst.loc configuration is undertaken, the oraInventory will be created by default in the user's home directory (/home/oracle, for instance, on RHEL/OEL, /opt/oracle, for instance, on SLES).

1. Once the user environment is configured as required and the oraInst.loc is configured as desired, install the base Grid Control product for Linux using the following command:

/u02/gc102/Disk1/runInstaller -noconfig -ignoreSysPrereqs -silent
-responseFile /u02/gc10201/Disk1/response/em_using_existing_db.rsp use_prereq_checker=false b_skipDBValidation=true -force

generic command form:

/Disk1/runInstaller -noconfig -ignoreSysPrereqs -silent -responseFile use_prereq_checker=false b_skipDBValidation=true -force

The "-force" option may be omitted for x86 installations.

 

Notes:

- Do not install into an existing Oracle Home directory

- Base product installation will be logged in two installActions<>.log files located in:

.../oraInventory/logs/ location (i.e., /u01/app/oraInventory/logs/ )

- In addition, the installActions<>.log for each component is located in:

.../oms10g/cfgtoollogs/oui/
.../agent10g/cfgtoollogs/oui/


These two installActions<>.log files will represent the installations of the oms10g and agent10g Oracle Homes in time sequence. Note that the configuration assistant content normally to be found in the agent installActions<>.log (last in the time sequence) will be missing due to the ???-noconfig??? option used in the runInstaller command.

2. Log in as a root user in a new command session and run the following scripts on the host where the base release of Enterprise Manager Grid Control is installed, when prompted by the installer:

If this is the first Oracle product you just installed on the host (i.e., no /etc/oraInst.loc file exists yet), then run the orainstRoot.sh script from the Central Inventory:

.../oraInventory/orainstRoot.sh

Run the allroot.sh script from the Oracle Home directory of the OMS:

.../oms10g/allroot.sh

3. Certain opmn processes will be running merely as a result of installation, in spite of the fact that no configuration of the OMS Oracle Home has been performed. Stop these OPMN processes by running the following command from the Oracle Home directory of the OMS:

.../oms10g/opmn/bin/opmnctl stopall



4. Apply the 10.2.0.5.0 patchset to OMS Oracle Home:

Note that while the base product installation requires the use of the "-ignoreSysPrereqs" option because it is not loaded with the proper checks, the patchset does have the ability to check for OEL5, RHEL5 and SLES10 prerequisites, so the "ignore" option should not be used for patchset installation.

/u02/gc10205/3731593/Disk1/runInstaller -noconfig -silent 
-responseFile 
/u02/gc10205/3731593/Disk1/response/oms_patchset.rsp

 generic command form:

/3731593/Disk1/runInstaller -noconfig -silent
-responseFile
/3731593/Disk1/response/oms_patchset.rsp

 Logging for the oms patchset application will be in the installActions<>.log for the patchset application found in either of these locations:

.../oraInventory/logs/
.../oms10g/cfgtoollogs/oui/


The installActions<>.log for the OMS patchset application will be later in timestamp than the three files created during installation. Again, no configuration assistant logging will be included due to the -noconfig option used in the runInstaller command.

5. Run the root.sh command:

.../oms10g/root.sh

No feedback will be given on successful execution in this case.

6. Apply 10.2.0.5.0 patchset to the agent Oracle Home:

/u02/gc10205/3731593/Disk1/runInstaller -noconfig -silent 
-responseFile 
/u02/gc10205/3731593/Disk1/response/agent_patchset.rsp

generic form:

/3731593/Disk1/runInstaller -noconfig -silent
-responseFile 
/3731593/Disk1/response/agent_patchset.rsp

 Logging for the agent patchset application will be in the installActions<>.log for the patchset application found in either of these locations:

.../oraInventory/logs/
.../agent10g/cfgtoollogs/oui/

The installActions<>.log for the agent patchset application will be later in timestamp than the three files created during installation or the file created during oms patchset application. Again, no configuration assistant logging will be included in the associated installActions<>.log due to the -noconfig option used in the runInstaller command.

7. Run the root.sh command as root:

.../agent10g/root.sh.


C. Configuring the Grid Control Installation with the ConfigureGC.pl Script

1. Ensure that the .../oms10g/oui/bin/runConfig.sh file has ???execute??? permission.

2. Use the following procedure to preserve (only if it is already set) and set the PERL5IB environment variable:

Make a backup of the PERL5LIB variable value (only suggested if PERL5LIB is in use in the session being used, and it is desired to restore it later):

> setenv PERL5LIB_BACKUP $PERL5LIB

Set PERL5LIB:

export PERL5LIB=.../oms10g/perl/lib/5.6.1

 3. Configure Enterprise Manager Grid Control by running the ConfigureGC.pl script:

.../oms10g/perl/bin/perl .../oms10g/sysman/install/ConfigureGC.pl 
   /u01/app/gc

 generic form:

/perl/bin/perl /sysman/install/ConfigureGC.pl

Logging for this action will start in the:

.../oms10g/cfgtoollogs/oui/configActions<>.log.

 
As the configuration assistants are run through the progress of the script, ORACLE_HOME/cfgtoollogs/cf**/ files will begin to populate with the results of these configuration actions for each Oracle Home in its respective directory (i.e., .../oms10g/ or .../agent10g/). As operational actions (i.e., process start) are taken in the configuration steps, operational logs will be populated in these locations:

.../oms10g/sysman/log/
.../agent10g/sysman/log/
.../oms10g/opmn/logs/
.../oms10g/j2ee/OC4J_EM/log/
.../oms10g/Apache/Apache/logs

among others.

4. The configuration may take around an hour with little command session update at times.
It may be instructive to follow the progress of the configuration in these files, alternative to the command session:

.../oms10g/cfgtoollogs/cf**/CfmLogger<>.log (for the OMS configuration assistants details)
.../oms10g/sysman/log/emrepmgr* (for the progress of the repository upgrade)

Likely failure scenario (Note.602750.1, bug 7483221):

a) The command session may, depending on base product version, eventually issue a failure message, indicating to look in the .../oms10g/cfgtoollogs/cf**/CfmLogger<>.log file.
The .../oms10g/cfgtoollogs/cf**/CfmLogger<>.log file and the emca_repos_drop<>.log will both show error code ORA-01017 logged.  The emca_repos_drop<>.log shows this message, for example:

[20-02-2009 14:25:49] Could not connect to SYS/(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=
(PROTOCOL=TCP)(HOST=gamma.clspco.adelphia.net)(PORT=1523)))(CONNECT_DATA=(SID=db111))):
ORA-01017: invalid username/password; logon denied (DBD ERROR: OCISessionBegin

b) To work around this failure, log in to the repository database as SYS or SYSTEM and issue this update:

alter user SYS identified by "default";

 c) Run the ConfigureGC.pl script again, repeating the syntax used in the first execution (leaving any current operating processes intact):

  .../oms10g/perl/bin/perl .../oms10g/sysman/install/ConfigureGC.pl
   /u01/app/gc

d) The configuration will pick up where it left off, so repository creation will succeed, base OMS configuration will complete, agent configuration will complete and the patchset configuration actions will start. The configuration may again fail, with a command session message to review the new .../oms10g/cfgtoollogs/cf**/CfmLogger<>.log file, which will show the ORA-01017 error again.

 To work around the second failure, log in to the repository database as SYS or SYSTEM and issue this update, using the password value originally configured in the em_using_existing_db.rsp response file (password value shown is only for example):

alter user SYS identified by linux32;

f) Run the configuration script for a third time, repeating the syntax as before (leaving any current operating processes intact):

.../oms10g/perl/bin/perl .../oms10g/sysman/install/ConfigureGC.pl
   /u01/app/gc

5. Successful finish of the configuration script will be denoted by this messaging in the command session (ignore date):

perform - mode finished for action: patchsetConfigure

You can see the log file: /u01/app/gc/oms10g/cfgtoollogs/oui/configActions2009-02-21_07-24-23-AM.log

10.2.0.5 OMS patch configuration done


6. Verify the 10.2.0.5.0 component version for the OMS in any of these ways:

1) "About Oracle Enterprise manager" in the console view.
2) .../oms10g/OPatch/opatch lsinventory
3) OUI "installed Products" view
4) .../oms10g/bin/emctl status oms
5) .../agent10g/bin/emctl status agent (10.2)


7. Verify the OMS' new Application Server version (10.1.2.3.0) in any of these ways:

a) Application Server main target page
b) Home/Deployments Summary view for Application Server Installations in Grid Control
c) Deplyments/Deployments Summary view for Application Server Installations in Grid Control
d) .../oms10g/OPatch/opatch lsinventory
e) OUI "installed Products" view
f) Main page of OMS/AS Application Server Control web site
g) Application Server Control home page for the OMS installation.

8. Verify the 10.2.0.5.0 component version for the agent in any of these ways:

a) Grid Control agent page view.
b) emctl status agent
c) .../agent10g/OPatch/opatch lsinventory
d) OUI "installed Products" view
e) Setup/Agents view in Grid Control

9. Review the post patch requirements of Note 853691.1 "ALERT: Important Upgrade Steps Required for Enterprise Manager Grid Control 10gR5 (10.2.0.5) Upgrades" for the OMS and agent maintenance required of the 10.2.0.5.0 version.


D. Troubleshooting Failure if EM_DBMS_JOBS are running during configuration

1) The ConfigureGC.pl script will fail if EM_DBMS_JOBS are running, This can be determined from the .../oms10g/cfgtoollogs/oui/configActions<>.log or the .../oms10g/cfgtoollogs/cf**/CfmLogger<>.log.

In this case, refer to the Oracle?? Enterprise Manager Grid Control Installation Guide
10g Release 5 (10.2.0.5.0), available at the Oracle Technology Network web site.


2) Database bug 5345437 may be encountered after patched agent startup. This bug prevents the agent from completing upload at some point, after initial upload success. The agent will continue to operate, but cannot upload further and cannot upload on restart. Applying the 5345437 database bugpatch to the repository database will allow the agent to continue to upload regularly.

3) The ConfigureGC.pl script may fail on RHEL/OEL 5 (x86_64) with this error if the link from section A.10 is not set up properly:

Base Exception:
/apps/oracle/product/11g/grid/oms10g/Apache/Apache/bin/httpd: error while loading shared libraries: libdb.so.2: wrong ELF class: ELFCLASS64

This indicates that the link for /usr/lib/libdb.so.2 has been created to point to /usr/lib64/libgdbm.so.2.0.0, which is inappropriate. Install the gdbm-1.8.0-26.2.1.i386.rpm package, if necessary, to ensure that /usr/lib/libgdbm.so.2.0.0 is available for linking as described in A.10 and run the ConfigureGC.pl script again.

4) If the PERL5LIB environment parameter is not set properly, the following error may be encountered:

Can't locate strict.pm in @INC (@INC contains: /project/ias904/src/src_021106/pdc_perl/bin/Linux/Opt/lib/5.6.1/i686-linux /project/ias904/src/src_021106/pdc_perl/bin/Linux/Opt/lib/5.6.1 /project/ias904/src/src_021106/pdc_perl/bin/Linux/Opt/lib/site_perl/5.6.1/i686-linux /project/ias904/src/src_021106/pdc_perl/bin/Linux/Opt/lib/site_perl/5.6.1 /project/ias904/src/src_021106/pdc_perl/bin/Linux/Opt/lib/site_perl .) at /u01/app/gc/oms10g/sysman/install/ConfigureGC.pl line 488.
BEGIN failed--compilation aborted at /u01/app/gc/oms10g/sysman/install/ConfigureGC.pl line 488.

Correct the PERL5LIB reference (ensure it is referencing the perl library in the OMS Oracle Home and not /usr/bin/perl, for instance) and re-execute the ConfigureGC.pl script.

Published Documentation References:

Oracle?? Enterprise Manager Grid Control Installation Guide
10g Release 5 (10.2.0.5.0)

Oracle?? Enterprise Manager Advanced Configuration
10g Release 5 (10.2.0.5)

Oracle?? Enterprise Manager Grid Control Release Notes for Linux and Microsoft Windows
10g Release 4 (10.2.0.5.0)

References


BUG:5345437 - APPS BUG5286029:ORA-20001: HZ_API_OTHERS_EXCEP: N, ERROR, ORA-01801: DATE FORMAT
BUG:7483221 - CONFIGUREGC.PL IS FAILING WITH INVALID PASSWORD FOR SYS
NOTE:278100.1 - How To Drop, Create And Recreate the Database Control (DB Control) Release 10g and 11g
NOTE:343085.1 - Known Issues Installing 10.2 Grid Control
NOTE:428665.1 - Enterprise Manager: Installation Requirements and a Checklist for Configuring and Testing Network Connections between EM Component Hosts
NOTE:464674.1 - Checklist for EM 10g Grid Control 10.2.x to 10.2.0.5 OMS and Repository Upgrades
NOTE:602750.1 - ConfigureGC.pl Reports - Invalid Username/Password.
NOTE:787872.1 - Installing Enterprise Manager Grid Control 10.2.0.5.0 - Known Issues
NOTE:815157.1 - Operating System Package Prerequisites for 10.2.0.5.0 Grid Control on Linux for 32bit and 64bit

NOTE:853691.1 - Upgrade Grid Control 10.2.0.x to 10.2.0.5 - Important Steps Required




來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/17252115/viewspace-1246128/,如需轉載,請註明出處,否則將追究法律責任。

相關文章