Deleting Orphaned data

If you have a page for which users have Priveleged user rights then then can customize/ personalize that page. When any of the user does that the portal server will create a private page and store that information in customization database domain(The actual page layout is stored in the RELEASE database domain). Now when you delete that page the main page would get deleted from RELEASE database domain( either immediately or at the time of schedule cleanup) but the personalized page that is stored in the CUSTOMIZATION domain wont be deleted. This page would be included in your database backup. You can delete the private page from the CUSTOMIZATION database domain by following these steps.


  • First create a Private demo page like this. Make sure to assign Privileged User role to All Authenticated Portal Users.


  • Now login with some other user except wpsadmin and customize the Private page by say rearranging the portlets on Private page. Also create com.wpcertification.privatepage.child as child page of the private page.


  • Go to the Portal Admin Console and delete the Private page.

  • Now create Full Export of the portal that includes Orphan data by executing this XMLAccess command

    C:\WebSphere\PortalServer\bin>xmlaccess -user wasadmin -password wasadmin -url h
    ttp://localhost:10040/wps/config -in c:\WebSphere\PortalServer\doc\xml-samples\E
    xportIncludingOrphanedData.xml -out c:\temp\ExportIncludingOrphanDataResult.xml

    If you open the ExportIncludingOrphanDataResult.xml you will notice that it does not have com.wpcertification.privatepage but it does have the com.wpcertification.privatepage.child with value of parentref attribute equal to orphan like this

    <web-app action="update" objectid="ORPHANED_DATA_CONTAINER_OID">
    <portlet-app action="update" objectid="ORPHANED_DATA_CONTAINER_OID"/>
    </web-app>
    <content-node action="update" active="true" allportletsallowed="true" content-parentref="orphaned" create-type="explicit" domain="cust" objectid="6_6RUKKSU31OL4D0IG4BACKN00K5" ordinal="100" type="page" uniquename="com.wpcertification.privatepage.child">
    <supported-markup markup="html" update="set"/>
    <localedata locale="en">
    <title>Child of test private page</title>
    </localedata>
    <parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
    <parameter name="com.ibm.portal.bookmarkable" type="string" update="set"><![CDATA[Yes]]></parameter>
    <parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA[0]]></parameter>
    <parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter>
    <access-control auth-level="default" externalized="false" owner="uid=sunil,o=defaultwimfilebasedrealm" private="true"/>
    </content-node>


  • Now find the candidates for deletion by executing the following command

    slcheckertool.bat --find-candidates -s c:\temp\ExportIncludingOrphanDataResult.xml -d c:\temp\findcandidate.xml -domain cust

    This will create an .xml file containing all the orphaned resources. In my case com.wpcertification.privatepage.child is the only child resource that it is able to find so it will create an xml file with one resource element the oid of this element is equal to the oid of the private child page and the value of type is content-node since it is a content node. If you had any other orphan data you would see additional nodes here.

    <orphaned-resource-candidates export-origin="IBM WebSphere Portal/6.1.0.1 build wp6101_115_01 exported on Sat May 09 11:59:40 PDT 2009 from sunpatil-wxp/192.168.2.103">
    <resource oid="6_6RUKKSU31OL4D0IG4BACKN00K5" type="content-node"/>
    </orphaned-resource-candidates>


  • Next step would be to identify the orphan data, this step is more useful if you have multiple lines of production. In that case you would have entered set of files that are generated by find-candidates command from each production line. This command would look through all of them and create one candidate file. This is the command that you will have to execute

    slcheckertool.bat --identify-orphans -s c:\temp\findcandidate.xml -d c:\temp\identifycandidates.xml

    This file will generate an output file like this

    <orphaned-resources>
    <export-origins>
    <export-origin value="IBM WebSphere Portal/6.1.0.1 build wp6101_115_01 exported on Sat May 09 11:59:40 PDT 2009 from sunpatil-wxp/192.168.2.103"/>
    </export-origins>
    <resource oid="6_6RUKKSU31OL4D0IG4BACKN00K5" type="content-node"/>
    </orphaned-resources>


  • Next step is to use slcchecker tool to generate an xmlaccess file that can be used to actually delete the orphan data. Execute this command to do that

    slcheckertool.bat --delete-orphans -s c:\temp\identifycandidates.xml -d c:\temp\deleteorphans.xml

    It will produce an xmlaccess output file like this

    <?xml version="1.0" encoding="UTF-8"?>
    <!--
    This is a generated file. Do not edit!

    ATTENTION: Assure that all production lines were considered creating this file before xmlaccess is invoked with this file.

    For the generation of this file the following full exports were used:
    IBM WebSphere Portal/6.1.0.1 build wp6101_115_01 exported on Sat May 09 11:59:40 PDT 2009 from sunpatil-wxp/192.168.2.103

    -->
    <request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SLChecker_1.0.xsd">
    <portal action="remove-orphaned-data">
    <content-node action="delete" objectid="6_6RUKKSU31OL4D0IG4BACKN00K5"/>
    </portal>
    </request>


  • Now last step is to execute xmlaccess script to actually delete the orphan data. Execute this command to do that

    xmlaccess.bat -user wasadmin -password wasadmin -url http://localhost:10040/wps/config -in c:\temp\deleteorphans.xml -out c:\temp\
    deleteorphanresult.xml


No comments:

Post a Comment