7
Oracle9iAS Portal Best Practices

This chapter describes Oracle9iAS Portal best practices. It features the following sections:

In addition to the following, more Oracle9iAS Portal best practices can be found at:

http://portalcenter.oracle.com

On that Web page, click on Product Information

7.1 Performance Best Practices

This section describes performance best practices. It features the following topics:

7.1.1 Use Appropriate Caching Strategy Depending on Page Content

Oracle9iAS Portal provides two different mechanisms of caching to improve performance. These include out-of-the-box integration with Oracle's award winning in-memory cache solution, Oracle9iAS Web Cache, and a persistent file-based cache.

The file-based cache is always maintained at the same time as Web cache, providing redundant cover should the in-memory solution fail. It is also useful for things like persistent sessions. In the future, persistent content may be used for cache warming of Web cache. Further, file-cache performance improvements can be achieved by locating the cache on a RAM Disk.

By default, Oracle9iAS Portal issues dynamic caching instructions to Oracle9iAS Web Cache, to allow caching of default content (e.g. page). The page designer can use the different cache options (whole page, page definition, or none) to ensure that the correct balance is maintained between speedy delivery of cached content and avoiding the delivery of stale content. It is, however, important that the page or portlet designer understand that the degree of dynamism of a web page is inversely proportional to its cachability. Understanding validation, expiration, and invalidation-based caching will help the designer select the most appropriate cache method.

For superior performance, Oracle9iAS Web Cache should be deployed on a dedicated machine - by default, it is installed, configured, and co-located with the Oracle9iAS Portal middle-tier. Review the Oracle9iAS Web Cache best practices for further details.

7.1.2 Use Web and Database Providers Judiciously

There are two different types of providers: web provider and database provider. Database providers are implemented in Java or PL/SQL and executed as stored procedures within the Oracle database. The Oracle9iAS Portal middle-tier communicates with these providers in two ways: through mod_plsql, if the provider resides in the local portal database; or by SOAP over HTTP, if the provider resides in a remote database. (In Oracle9iAS Portal 3.0.x, Net8 connections were used in both cases. SOAP over HTTP allows easier communication with remote database providers through firewalls.) Note that execution in the database does not place any restrictions on the functionality of a portlet; database facilities allow for external communication in many ways, including HTTP connections to external content. Database providers are particularly appropriate for portlets that require significant interaction with the database and in situations where the development team has extensive Oracle PL/SQL development experience.

Web providers are implemented in any Web deployment environment (e.g. Java, ASP, Perl) and executed as an application external to Oracle9iAS Portal. Oracle9iAS Portal also communicates with these providers using SOAP over HTTP. Web providers are most appropriate for external information sources (e.g. Internet news/business information) and in environments where developers have experience using Java and other Web development languages.

7.1.3 Improve Availability and Scalability by Having Multiple OC4J_Portal Instances

Oracle9iAS Portal provides a parallel page engine (PPE) stateless servlet that fetches the page meta data, assembles the page, and manages the cache. This is a key component, and its stateless nature allows it to be deployed across multiple OC4J instances.

By default, Oracle9iAS is installed with a single OC4J_Portal instance where this PPE servlet is deployed. From a scalability perspective, it is highly recommended to have at least one other (if not more) OC4J instance with this PPE servlet deployed. Alternatively, you can increase the number of OC4J processes dedicated to this instance. Oracle HTTP Server load balance routing will distribute requests across the multiple instances or processes, providing better scalability for the system.

7.1.4 Scale Oracle9iAS Portal Better by Tuning Oracle9iAS Infrastructure Database Optimally

Oracle9iAS Infrastructure provides important functionality to Oracle9iAS Portal: all the metadata, database providers, etc. reside in the database. Hence, conventional database tuning (e.g. putting portal Indexes on a separate disk) is important. However, it is not recommended to analyze the schema for further fine tuning since this has already been done and CBO (Cost Based Optimizer) used where appropriate.

Moreover, there are also standard ongoing jobs that re-tune the schema based on collected statistics on a regular basis.

Another aspect of tuning is the SQL*NET tuning between the mod_plsql (i.e. Oracle HTTP Server) machine and the database itself. You should also consider Real Application Clusters (RAC) as an option for the availability and scalability of the Oracle9iAS Portal database.

7.1.5 mod_plsql Tuning Directly Impacts Oracle9iAS Portal Performance

mod_plsql maintains it's own connection pool thus negating the need in most cases for the use of MTS. There are, however, some tuning parameters that can be adjusted to give optimal mod_plsql performance and ensure that processes are not shut down heavily:

To reduce latch contention, ensure that the DAD setting for Session Management Type is set to STATELESS_FAST_RESET.
Set MaxClients=MaxSpareServers=average system load.
Set MaxRequestPerchild=10000
Set MinSpareServer=1
Set KeepAlive to off for heavily loaded sites.

Tuning these parameters will affect the performance of Oracle HTTP Server with respect to nonmod_plsql requests. Therefore, if you wish to service other types of requests with the same installation, you can employ a dual listener strategy where you start two Apache listeners, one tuned for standard content requests and one tuned for mod_plsql content requests. Further information about this approach and other factors can be read in the mod_plsql section of the Oracle9i Application Server Performance Guide.

7.1.6 Leverage Web Provider Session Caching

When registering a web provider, it is possible (by selecting a checkbox) to request that session specific information such as session id and user login time be cached for each request. Whilst this is a mandatory requirement for web providers who rely on session information to ensure the validity of atomic transactions, those providers who do not rely on session level information should turn this option off as it improves the portlet cache hit rate.

7.1.7 Increase Execution Speed of Slowest Portlet to Increase Page Assembly Speed

Portlet execution speed is the average time required to execute all uncached portlets on a page. Since portlets execute in parallel, this measure will be equal to the execution speed of the slowest portlet, plus page assembly overhead.

The portlet execution speed will differ from site to site since each site will have a different mix of content and applications in their portal. Estimating this number will require running your own benchmark tests (if you already have applications that you plan to expose through portlets, you will already have a sense of the execution times). In general, the speed of page assembly will be limited by the execution speed of the slowest portlet on the page (when the portlet output is not cached).

7.1.8 Reduce Page Complexity to Improve Cachability

Page security and the number of tabs and portlets on a page will affect the time it takes to generate page metadata. The number of portlets on a page will affect page assembly times in the middle tier especially if each portlet must be contacted for a validity check or content refresh.

Page complexity, a function of page security and the number of tabs, items, and portlets on a page, affects throughput by increasing the amount of metadata that needs to be generated as well as the number of security and validity checks. Page complexity does not affect page assembly time in the middle-tier but may affect the time it takes to validate and refresh portlet content.

7.1.9 Measure Tuning Effectiveness Regularly to Improve Performance

One of the ways to evaluate whether the practices mentioned here or elsewhere are effective is to measure the resulting performance, and use the measurements to further fine tune the system.

To get granular results from system internals, append &_DEBUG=1 to the end of the portal page URL you wish to measure performance for. The resultant output is a report from the parallel page engine. It will provide details of performance of each component on the page, whether a cache miss or hit occurred and how long page loading took.

Periodic monitoring of this information will help keep the system fine-tuned for better performance.

7.2 Content Management and Publishing Best Practices

This section describes content management and publishing best practices. It features the following topics:

7.2.1 Use a Single Page Group for Unrestricted Copying, Multiple Page Groups for Delegating Administration

Oracle9iAS Portal allows portal pages to be organized within page groups. The default and easiest way to get started is with a single page group. This has the advantage of being able to easily copy or move content elements across pages within the group.

However, in a larger environment, you may want different people to administer different areas of the site - and this delegation of administration is easier if you separate your site into multiple page groups. Currently, it is not possible to copy or move content elements between page groups, or to use templates, styles, and metadata elements (categories, perspectives, attributes, and item types) owned by one page group in another page group.

Templates, styles, and metadata that need to be used across page groups can be placed in the supplied Shared Object Page Group. In addition, any page can be published as a portlet, which allows the content on that page to be viewed on any other page in any page group.

7.2.2 Research Taxonomy Before Committing to the Pages

There are several different ways to organize the set of content that your portal needs to provide to its end users. This organization is referred to as a taxonomy.

You can create a physical taxonomy consisting of pages and sub-pages. You can also create virtual taxonomies consisting of categories and perspectives. Users can browse a taxonomy, which appears as a hierarchy of pages. Each category and perspective page is built dynamically by searching for content belonging to the selected category or perspective when the page is rendered.

Reorganizing the physical taxonomy is easy and can be done by moving pages around within a page group and by moving items between pages (however, pages and items cannot be moved between page groups, as described above). Currently, it is not possible to reorganize categories and perspectives. While content can be reassigned to a different category or perspective, this can be a cumbersome process if you have a large number of items or pages.

Therefore, carefully plan your category and perspective hierarchies before you start to add content to your pages.

7.2.3 Always Use Page Templates Instead of Directly Creating Pages

Creating pages with Oracle9iAS Portal is easy, and it may be tempting to start adding pages quickly at the onset of your portal development project without first defining page templates. To ensure a consistent look-and-feel to your site and to minimize maintenance effort, it is recommended that you always base your pages on page templates. A template cannot be applied to a page once the page has been created.

It is also a good idea to manage your templates in the Shared Objects page group, as templates cannot be promoted from another page group to Shared Objects.

This also implies that you should define your templates before you create your content page groups, as you will want the root page for your page group to use one of your standard templates. The root page of a page group is automatically created, and you cannot replace the root page with another page.

7.2.4 Separate Template Content From Layout

A page template defines the layout (the placement of item and portlet regions) for pages. A template can also contain content, in the form of portlets and items that you want to appear on all its pages. However, changes made to a template are seen immediately in its dependent pages. Making changes to the content on a template will take some period of time (minutes or even hours, depending on the extent of the changes). During this time, the pages themselves will be in a state of flux as the template is modified. This can have an undesirable impact on your portal users and may require that the affected pages be unavailable while performing template maintenance.

This situation can be avoided by managing template content on navigation pages. For example, use a navigation page to contain the banner for your template, including such elements as the page name smart text, company logo, and various smart links such as the "Customize" icon and the "Home Page" link. When you want to modify the banner, copy the navigation page and make changes to the copy. When you are satisfied with the changes, replace the original banner navigation page portlet on the template with the modified copy. This can be done very quickly and will have minimal impact on portal users. The same recommendation applies to navigation bars, page footers, and other content that you want to include on the template.

7.2.5 Understand the Difference Between Attributes, Categories, and Perspectives

One of the big advantages of Oracle9iAS Portal is the ability to define and associate metadata with any content. Oracle9iAS Portal provides three types of metadata:

Categories - "what is it?"
Perspectives - "who is the audience?"
Attributes for any other descriptive information.

It is important to understand the characteristics of these metadata elements in terms of their impact on content organization, maintenance, presentation, and search. For example, they all aid in searching for content but have different styles for search submission and for presentation in search results. There are also important differences in terms of how content contributors assign metadata values to content and in how these elements are presented on pages.

The following Table 7-1 summarizes the characteristics of the metadata elements:

Table 7-1 Metadata Elements

Characteristic	Custom Attribute	Categories	Perspectives
Can be mandatory on Add/Edit item.	Yes	Yes	No
Can be selected for Group By in Region display.	No	Yes	No
Can be arranged in a navigable hierarchy	No	Yes	Yes
Allows multiple values for a single item.	No	No	Yes
Select values from Static List of Values	Yes	Yes	Yes
Select values from Dynamic List of Values (based on SQL Query)	Yes	No	No
Can be associated with an icon.	No	Yes	Yes
Searchable	Yes	Yes	Yes
Can be shown in Item display	Yes	Yes	Yes
Can be shown in Search Results	Yes	Yes	Yes
Can be used to order a custom query (using SQL against the WWSBR_ALL_ITEMS repository view)	No	Yes	No
Translatable	Yes	Yes	Yes
Data Types	Boolean, Date, File, Number, PL/SQL, Text (Single or Multi-Line), URL	Text Only	Text Only

7.2.6 Avoid Using Simple Item Types

Simple Item Types (e.g. Simple Text, Simple File, Simple URL, Simple Image) are very basic item types that contain a minimum number of attributes (the Display Name and the item type's distinguishing attribute, such as the text box for Simple Text and the file upload box for Simple File). Custom item types (including the pre-defined types Text, File, URL, Image, etc.) are based on the simple types but can contain any number of additional attributes and can be modified anytime to add or remove attributes.

While Simple Item Types present a very simple interface for end users to add content, it is important to understand that they cannot be extended to include additional attributes, and you cannot change the type of an item once that item has been created. Therefore, if you anticipate that you will want to add additional attributes to your content, avoid the use of simple item types by following these steps:

If you want to present a simple interface for adding items, create new item types that look like the simple types.
Configure your page groups to hide the Simple Item Types and to make only custom types visible.

Note that items created through the WebDAV interface (Web folders) are always created as Simple File. While WebDAV makes it very convenient to add content from the desktop, that convenience may be offset by the restriction on adding attributes to the Simple File item type. If you need the flexibility associated with a custom item type, create your file items through the Add Item wizard in the browser. Any file item can be edited through WebDAV, even if it belongs to a custom item type. In a future release of Oracle9iAS Portal, you will be able to specify a custom type for items created through WebDAV.

7.3 Best Practices for Oracle9iAS Portal Export/Import

Oracle9iAS Portal provides a set of export/import utilities which enable customers to copy portal content between portal installations. A typical example where these utilities would be used is to copy or update portal page groups and application components between a development instance and a production instance of Oracle9iAS Portal.

The following is a summary of recommendations and best practices developed for Export/Import functionality as provided in Oracle9iAS Portal version 9.0.2.2:

7.3.1 General Guideline/Best Practices for Oracle9iAS Portal 9.0.2.2 Export/Import

If you are not sharing the same Oracle Internet Directory instance between your source and target systems, Oracle recommends the following procedure for export/import:

Develop your portal objects (page groups, content, applications, etc.) on your source/development system.
To simplify the task of export/import, assign users, groups and privileges ONLY on your production system.
Use Export/Import to promote your portal objects to your target/production system.
Apply users and privileges to imported portal objects as needed.

If however, you are able to share a single Oracle Internet Directory instance between your source and target systems, we would recommend the following procedure:

Develop your portal objects (page groups, content, applications, etc.) on your source/development system.
Assign users, groups and privileges from your source system.
Use Export/Import with "Export Security" checkbox enabled to promote your portal objects and privileges to your target/production system.

7.3.2 Best Practices System Checklist Before Performing a Portal Export/Import Operation

Before exporting or importing, ensure that your system meets the minimum system requirements. You will also need to know the following information about your configuration on both your export and import portal environments:

Portal Schema Name
Portal Schema Password
Portal Connect String Information
Portal User Name
Portal User Password
Company Name (used only for hosted portal installations) - leave blank in most cases.

Also, plan to perform the export and import process during non-business hours, and to disable access to Oracle9iAS Portal during the process. To disable access to portal temporarily for all other users, one way is to configure your listener for a different port number during the duration of the export and revert it back to the original port when your export is complete.

Each export or import process sets up a background process. Therefore, verify that the job_queue_processes database parameter is set appropriately.

To check the value of the job_queue_processes parameter, simply perform the following query from SQL*Plus:

select name, value from v$parameter where name='job_queue_processes'

The value for job_queue_processes should be at least 2 to allow toe execution of background jobs.

An alternative way of checking the job_queue_processes parameter is to simply examine the init.ora file in your database's ORACLE_HOME.

Also, for Oracle9iAS Portal version 9.0.2.2, please be sure to download the latest patchset for Export/Import from Metalink. The current patchset as of this writing is patchset 2617359.

7.3.3 Best Practices for Building Transport Sets

Once the minimum requirements are verified, your goal is to create a transport set. Transport sets contain the portal objects that you are planning to export to your destination portal environment. The steps below outline the basic process of creating a transport set for export. Please refer to the online documentation for the precise series of steps.

Mark objects for export (from the Navigator, or search results > Bulk Actions for page groups).
Select either: Export this Transport Set Immediately or Export Later, more objects have to be added.
When all desired objects have been added to your transport set, select Export This Transport Set Immediately.
Check the log in your transport set manager for any errors.
Choose an appropriate export script based on your Operating system, and save the resulting file to the location where you will want to run the export utility (generally this location should be where your export portal resides).
Run the script using -mode export as the option. This script will create a dump file that you will name.
Using FTP, transfer your dump file and export/import script to the machine where your destination Oracle9iAS Portal repository resides.

7.3.4 Best Practices For Configuring Your Portal Content For Maximal Portability for Export/Import Operations

Before exporting/importing, please review Section 4 of the Oracle9iAS Portal 9.0.2 release notes, summarized here below:

User and group privileges for given objects are not exported by default:: For information on exporting users and groups refer to Section 7.3.1, "General Guideline/Best Practices for Oracle9iAS Portal 9.0.2.2 Export/Import" and Section 7.3.7.1, "Export/Import of Objects (With Security) Between Portals Using Different Oracle Internet Directory Servers in 9.0.2".
Web providers: Web Provider registration details are migrated, however, if a web provider with the same name exists in the target, that provider is reused. If one does not exist, then a new web provider is created.
Portal export/import does not provide support for external and partner applications, and password stores: Any object from these placed on a page may not work as expected when the page is migrated from one portal to another. For example, if you have an external applications portlet imported on a portal page from your source system, it will display the external applications native to the target system. As another example, if you have other external applications as portlets, and are having issues on your target system, you may want to remove the external application portlet first from your source system, import the page, and then add it back.
Custom search is reset upon import. These customizations will have to be re-entered.
Custom Item Types - Portal Export/Import of pages overwrites all attribute values of items based on custom item types with custom attributes in the target portal. For this reason, you should create items (based on custom item types) on the source portal only, and migrate them to the target through the export-import process for that page.
Item URL behavior: Item URLs are likely to change after import. To minimize any potential problems, be sure to follow these important guidelines on how to refer to image items via URL.
Page URL behavior: Always use page link item types or direct access URLs when creating links to portal pages. Do NOT use "raw" portal page URLs.

By default, portal page URLs generated by Oracle9iAS Portal contain installation specific ID numbers that change when the object is exported. This causes broken links when pages are imported into a different site.

Here is an example of a URL generated for a page. If the page is imported on another site, this PAGEID will change.

http://my.portal.com/servlet/page?_pageid=47,49&_dad=portalr2&_schema=portal

If you are using URLs such as the above as manually-entered links, we recommend instead the use of Direct Access URLs or Page Link item types instead.

The same page has this direct access URL:

http://my.portal.com/pls/portal/url/PAGE/HRPAGEGROUP/HRHOME/HRBENEFITS

To find the direct access URL for a page, look at the page property sheet. A link to the property sheet can be displayed by adding a Property Sheet Smart Link item to the page.

Also, you can also use a Page Link item type to create a link to a page. The Page Link item type dynamically generates the correct link at runtime.

To ensure that links do not 'break' when pages are imported into a different site, always use Page Link item types or direct access URLs when creating links to pages.

For more information, refer to 'Direct Access URLs' and 'Page Links' in the Oracle9iAS Portal online help.

7.3.5 Best Practices for Exporting/Importing Page Groups and Components

Page groups and their associated components may be moved from development to production via the export/import utilities described in this document. In addition to page groups as a whole, individual components within page groups such as subpages, categories, perspectives, page styles can be migrated individually to the import system, provided that the entire page group has been imported to the import system earlier.

Some considerations and best practices to keep in mind are the following:

The first export to your target system should migrate the entire page group from the source portal to the target portal instance. Subsequent transport sets can then export an individual page, or other page group component on the destination portal installation, all new or existing content on a page will be overwritten when a page of the same name is being re-imported to the destination from elsewhere.
You can only migrate objects within a page group to the same page group of the same name on the destination portal.
After an initial import operation to your target system, if you change the name of the page group on the target system, subsequent import attempts to that page group will fail.

7.3.6 Best Practices for Exporting/Importing Web Providers

In the current Oracle9iAS Portal 9.0.2.2 release, your import operation will fail with a MERGE_FAILED error if your web providers cannot be reached or cannot be registered successfully during import.

Before importing on your target system, all web providers referenced by your transport set must either exist already or be able to be registered successfully during the import on your target system.To ensure successful registration, ensure that your web providers meet the following conditions on your target system:

Ensure that you have connection to your web providers during the import operation. Your web providers must be up during the import operation.
If you are using web proxies on either your import or export portal installations, ensure that your proxies are configured correctly on your import installation before importing.
An alternative to keep in mind is to consider registering your web providers manually in advance of performing your import on the target system to help ensure that your import operation goes smoothly.
If you register your web providers manually, they need to be the same name as the corresponding web provider(s) on your export system.
If you have portal pages that reference database providers (application components), be sure also to import your database providers (application components) either first, or concurrently in the same transport set with your page groups.
Another alternative is to remove offending web provider portlets (for those web providers that may not be contactable/available during the import operation) from pages before exporting, and then to add them back in after importing.

7.3.7 Best Practices for Exporting/Importing Users and Groups

As with the export/import of portal content, the need to export users and groups depends primarily upon whether your Oracle9iAS Portal instances are sharing the same Oracle Internet Directory instance or not.

Review the following topics:

Export/Import of Objects (With Security) Between Portals Using Different Oracle Internet Directory Servers in 9.0.2

7.3.7.1 Export/Import of Objects (With Security) Between Portals Using Different Oracle Internet Directory Servers in 9.0.2

Use Oracle Internet Directory utilities to migrate Users/Groups from source Oracle Internet Directory server to target Oracle Internet Directory server.
In Oracle9iAS Portal, migrate portal objects with "export security" enabled from source portal to target portal.
(MANUAL) For the imported users, set the guid to null (WWSEC_PERSON$.GUID)
(MANUAL) For the imported groups, update the guid using the instructions found in the section below on how to update the GUID.

Please refer to the Oracle Internet Directory documentation on how to migrate users and groups between Oracle Internet Directory servers.

At the end of the 4 step process, you should be able to edit the user or group profile and also see them in the imported objects access list. Keep in mind the order of the process outlined above. All the steps are required and must be carried out sequentially.

7.3.7.1.1 How to update the GUID

First of all you have to use the following steps to determine whether or not the specific group you want to synchronize is a local group:

By default, all local groups are created within the portal group install base. You can find the group install base by running the following commands in the portal schema from SQL*Plus:

set serveroutput on
exec dbms_output.put_line(wwsec_oid.get_group_install_base)

If the tail of the group's distinguished name matches the value thus returned then the group is within the group install base else it is not. For instance, if the group install base is " cn=portal_groups,cn=groups,o=oracle,dc=com " and the group that you want to synchronize has a DN " cn=Supervisors,cn=PORTAL_GROUPS,cn=Groups,o=oracle,dc=com ", then the tail is considered as matching and it is a local group. To confirm whether this is true or not you can try the following in the portal schema from SQL*Plus (please substitute the required group name for <enter_group_name_here>)

select guid, dn from wwsec_group$ where name = upper('<enter_group_name_              
here>');

If you see a row with the GUID and DN values then it is a local group else it is not.

Depending on whether or not it is a group within the portal group install base in Oracle Internet Directory you can use the following steps to synchronize the GUID of a specific group:

For local groups (groups within the portal group install base)

Use the following steps to get the GUID:
- Run the following SQL*Plus command in the portal schema:
```
set serveroutput on
exec dbms_output.put_line(wwsec_oid.get_group_info(p_group_name => 
'<enter_group_name_here>', p_check_local => false).guid)
```
  This will display the GUID for the group.
Use the following steps to update the group entry in the portal schema
- Pass the value of GUID to replace <enter_guid_here> in the next command:
```
update wwsec_group$ set guid = '<enter_guid_here>' where name = 
upper('<enter_group_name_here>'); commit;
```
For non-local groups (groups outside the portal group install base)

You have to know the Oracle Internet Directory host, port, the administrator's DN and password to run the following command. You also have to either know the Distinguished Name of the group or you should be able to determine by looking at a DN whether or not it pertains to the group that you are interested in. Use the following steps to get the GUID:
- Run the following command to find out the GUID of the group:
```
ldapsearch -h <enter_OID_host_name_here> -p <enter_OID_port_number_here> 
-D <enter_OID_admin_DN_here> -w <enter_OID_admin_password_here> -s sub 
-b "<enter_subscriber_DN_here>" 
"(&(objectclass=groupOfUniqueNames)(cn=<enter_group_name_here>))" 
orclguid
```
  Example:
```
ldapsearch -h oid.oracle.com -p 389 -D cn=orcladmin -w welcome1 -s sub 
-b "o=oracle,dc=com" 
"(&(objectclass=groupOfUniqueNames)(cn=Supervisors))" orclguid
```
  This will display a list of all groups under the specified subscriber whose name matches the specified group name. Every group will be displayed in two lines, the first line will have the DN of the group and the second line will have its GUID.
  
  Get the DN and the GUID that you are interested in.
- Use the following steps to update the group entry in the portal schema.
  
  Pass the value of GUID to replace <enter_guid_here> and DN to replace <enter_DN_here> in the next command:
```
update wwsec_group$ set name = '(<enter_guid_here>)', guid = '<enter_
guid_here>' where dn = wwsec_oid.get_normalized_dn('<enter_DN_here>'); 
commit;
```
  For example if the DN and GUID obtained from the previous step are
  
  "cn=Supervisors,cn=OTHER_GROUPS,cn=Groups,o=oracle,dc=com" and the GUID is "A729208AFBCA4C38E0340800208A8B00 " respectively then the above update query will become:
```
 update wwsec_group$ set name = '(A729208AFBCA4C38E0340800208A8B00)', 
guid = 'A729208AFBCA4C38E0340800208A8B00' where dn = wwsec_oid.get_
normalized_dn('cn=Supervisors,cn=OTHER_
GROUPS,cn=Groups,o=oracle,dc=com'); 
commit;
```
These steps should allow you to synchronize a specific group in the portal schema. Repeat this process if there are multiple groups involved.

7.3.8 Best Practices for Troubleshooting Oracle9iAS Portal 9.0.2.2 Export/Import

As mentioned earlier, be sure to review the latest information and FAQs on Oracle9iAS Portal Export/Import located in the Export/Import Migration and Upgrade folder at the following URL:

http://portalcenter.oracle.com

Please be sure to look for FAQs and documentation specific to Oracle9iAS Portal 9.0.2.2, as procedures and best practices for subsequent and prior releases of Oracle9iAS Portal do vary.

7 Oracle9iAS Portal Best Practices