Yes, although I would install Agile 9330 on another server altogether so you have a valid 9310 environment until you get everything done.
 The Agile installation documents for 9330 are :
Security Guide                                E39280-01  reviews firewall/DMZ considerations for protecting the Agile servers.
Capacity Planning Guide             E29278-01  discusses how big of a server you might want to use, given  data and user estimates.
Application Installation Guide    E39279-01  leads you through installing Agile on both Windows and Linux
Database Upgrade Guide               E39282-01  reviews how to use AUT to upgrade a database to the 9330 schema
Database Install Guide                   E39281-01  guides you through installing Oracle for your Agile application

 You could also look for E50306_04 as the overall documentation set for Agile 9330. It contains all of the above, and a lot more.

Kevin

Here is what was in the script file that somehow got screwed up :

— DIRECTIONS :
— 1) Open an SQL*Plus session and log into the Agile schema account
— 2) Create a spool/log file for the script results SQL> SPOOL <directory>/RestoreKeystore.sql
— 3) Run this script SQL> START <directory>/GenerateRestoreKeystore.sql.txt
— 4) Close the spool/log file SQL> SPOOL OFF
— 5) Exit the SQL*Plus session SQL> EXIT
— 6) Put the “RestoreKeystore.sql” file in the Agile import directory (<ORACLE_HOME>adminagile9createagile)
— and also save it to a separate safe place

set pagesize 0
set linesize 1000
set trimspool on

spool RestoreKeystore.sql
prompt — Restores Agile keystore and administrator passwords
SELECT ‘UPDATE propertytable SET value=’||CHR(39)||value||CHR(39)||’ WHERE parentid=5004 AND propertyid=1008;’ FROM propertytable WHERE parentid=5004 AND propertyid=1008;

prompt — admin user
SELECT ‘UPDATE agileuser SET login_pwd=’||CHR(39)||login_pwd||CHR(39)||’ WHERE id=704;’ FROM agileuser WHERE id=704;
SELECT ‘UPDATE agileuser SET login_pwd=’||CHR(39)||login_pwd||CHR(39)||’ WHERE loginid=”superadmin”;’ FROM agileuser WHERE loginid=’superadmin’;
SELECT ‘UPDATE agileuser SET login_pwd=’||CHR(39)||login_pwd||CHR(39)||’ WHERE loginid=”ifsuser”;’ FROM agileuser WHERE loginid=’ifsuser’;
SELECT ‘UPDATE agileuser SET login_pwd=’||CHR(39)||login_pwd||CHR(39)||’ WHERE loginid=”agileuser”;’ FROM agileuser WHERE loginid=’agileuser’;

prompt commit;;
spool off;
quit

Doesn’t the UPK (User Productivity Kit) provide this?????
 I have not been involved with a project that customized this, but I know it has been done. Oracle provides an OOTB setup, but it can then be customized for each client/site.

http://www.oracle.com/technetwork/middleware/upk/overview/index.html

2 cents??  Having worked at Agile for 7 years, and then at Oracle for 5 more, can I give a dime’s worth??

 Although I doubt Oracle would ever “acknowledge” MyAgilePLM, I am also certain that they know it is here. No idea on how one would approach them to discuss having Oracle publish an article about what this site is and how it can help people. Or if they would even be open to doing something like that. Believe me, things changed after Oracle bought Agile Software. Agile was a one-stop shop for everything, whereas Oracle doesn’t necessarily want to do implementations or consulting, just sell the software. I would prefer this website stay out of the clutches of Oracle.

 That said, I suspect that this site will gain recognition more by word of mouth from folks who use it than by anything that Oracle can/would do. I have recommended to a client that they come here, and I know others who have also recommended such. Given that neither Agile nor Oracle has ever published anything about the database schema, and that the installation documentation assumes that things will always go correctly, a site like this is invaluable. But just as important is making it accessible and easy to use, and I think that it has done so quite well (although it does occasionally scramble attached files).

 Note that I am also on the WRAU (Western Regional Agile Users) email list, which has been around since forever ( I first heard about it in 2003?). But I prefer this website, both for ease of use and much more accessible content.

Kevin

Something else to think about is that AUT runs *much* better if you fix all of the Averify errors. So run Averify on your current database, and use the adt_generic script to fix what you can (this may require multiple runs of both).

 If you have errors in your database that the adt_generic script cannot fix (as it does not fix everything), then contact Oracle Support about the specific errors that still exist in your database, and have them help get them fixed. They tend to be fairly responsive if you note that you are going to be upgrading to a newer version of Agile.

 Other than that, do as Carlos says, read the documentation and do your planning. There really aren’t any shortcuts in an upgrade, and going to at least 9350 would be advisable. 9360 has only been out for a few weeks, you can either get in Oracle’s good graces by being one of the first to use it (and risk finding all/some the bugs) or play it a bit safer and use 9350.

Agile 9.3.1.2 is only certified to run on an Oracle 10g or 11g database server. But you can certainly import the database onto an 12c database server and update the Agile configuration to point to it instead of your usual server, and I would expect that it would most likely work just fine. But you may want to inquire at Oracle Support as to what their recommendation is.

Florina is correct in everything she has talked about. But something else to consider, is that it appears that you have 3 distinct destinations defined in ChangeCAST. Note that in TRANSFERRED, each bit is a yes/no (1=Yes, 0=No) as to whether the given change has been processed for the destination environment denoted by that bit. Given that you have a “1” in positions 1, 2 and 3 of the attribute values, it must be processing for 3 different destinations. You should be able to figure out which bit denotes which destination from the ChangeCAST setup. A null value in TRANSFERRED simply means that the change has not been processed by ChangeCAST at all. Weirdly, sometimes it only sets a single bit (where TRANSFERRED = “1”) instead of  setting the full value.
 Thus, if you want a change to not be processed for a given destination, set the correct bit in TRANSFERRED to be “1” in that position :
— this will prevent the change from being processed for destination 1
update change set transferred = ‘1’ || substr(transferred, 2) where change_number = ‘XXXX’;
— this will prevent the change from being processed for destination 3
update change set transferred = substr(transferred, 1, 2) || ‘1’ || substr(transferred, 4) where change_number = ‘XXXX’; 

 To really make the above work, you do need to set TRANSFERRED = ‘00000000000000000000000000000000’ where it is null.

Attached is a zipped version of the file. Doesn’t need the compression, but it should now be correct. Weird, no idea why that happened.
 So you need to install Oracle and Weblogic on the server/cluster, then install Agile on your new server/cluster. As part of that, you create a database along the way that is empty except for a default configuration. Note down the URLs it gves you for the web and java clients. Then run the attached script against the database and make sure you have several copies of the generated script kept in dsafe places.
 And yes, you then export/clone your current database into the new Oracle instance, run the script that was generated by the attached script on that database, and then start Agile. At that point you can start the Java client and make updates to the URLs in the database so that it works correctly.

Treat it just like a new install, except that instead of starting with the default database, you need to import your current 9330 database.
 Except of course, there are the details :
1) Before anything else, get the Keystore value from the database that was created when you installed Agile. Note that if you have not done this, and already imported a database over the database that was created during the installation, you *will* have to install Agile again to get that key value. I have attached an SQL script that will generate a script that you can use any time you import a database for this new server.
2) Import your current database into your new Oracle database server, and once that completes successfully, run the RestoreKeystore script so it has the correct keys to run the application on the new server.
3) Log into the Java client (using the correct URL) and change all of the URL references in the configuration (web client URL, Java client URL, LDAP server (if different), file server, vault location, etc.).

 I am certain there may be a few other wrinkles I am missing, but this should get you up and running to be able to be accessed by most folks.

Oops, forgot the file.   Here it is.