nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

Deploying Catalog to Oracle Analytics Server (OAS) 5.9 from OBIEE 12.2.1.3

Joe_obieeoas

Hi All,

Finished setting up OAS environment. Now need to deploy RPD and catalog from a working OBIEE 12c environment.

Already deployed RPD using "uploadrpd" command.

Please share how about the catalog so we can access all reports/dashboards of OBIEE within OAS.

Thanks.

Find more posts tagged with

Accepted answers

All comments

Gianni Ceresa

Fairly sure the doc covers this.

Migrations go through the BAR: export a BAR from your 12c, import the BAR (or the pieces of it you care about) in OAS:

[Deleted User]

What Gianni said. Look at the documentation. Officially 12.2.1.3 is not supported as a starting point for an OAS migration.

https://docs.oracle.com/en/middleware/bi/analytics-server/migrate-upgrade-oas/starting-points-migration-and-upgrade.html

You can import the BAR file - which is the correct way of doing things - but again officially you're doing something that's not supported.

Joe_obieeoas

Thanks Chris, but in the Oracle doc you quoted they did not explicitly mentioned any path for my scenario as below.

Source system --- OBIEE 12.2.1.3 and Windows Server

Target system --- OAS 5.9 and RHEL 7.

There is no section which mentions migration path for the combo -- (source system -- "OBIEE 12c releases earlier than 12.2.1.4.0" and Target system "New server, or different operating system, or newer version of operating system for Oracle Analytics Server".

So at this point BAR file is the only path for me to migrate ----- you say this is not officially supported

upgrade OBIEE from 12.2.1.3 to 12.2.1.4 and then go with the "exportarchive.sh" command. --- its supported.

Please correct if my understanding is wrong.

Also wondering what's the risk factor if i go with the BAR approach, will there be breaking of any functionality ? loss of features ? (skipping OBIEE upgrade process to 12.2.1.4)

Thanks.

Gianni Ceresa

A change in OS or OS version only means out-of-place migration is required.

OBIEE/OAS content is "above" the OS level, and therefore OS independent. That's why it is mandatory to use the OBIEE/OAS tools for moving content, because these tools will work above the OS level and not bring along issues related to the OS (could be encoding etc.).

Like in any upgrade, there can be problems with your old content for various reasons (the same apply if you were upgrading on the same OS/version).

Try and go through logs to see what happen. Like in any upgrade you are supposed to have a process defined to validate the result of the migration.

For the missing or breaking functionality, this mainly depends on what you are migrating: the cleaner your source is, the cleaner your target will be, the messier your source is, the more chances to have weird things or disabling some new functionality you have.

Joe_obieeoas

Thanks Gianni, so keeping OS aspect aside, do you mean go with the "supported" path which is first upgrade OBIEE 12.2.1.3 to 12.2.1.4 and then migrate to OAS 5.9

12.2.1.3 to OAS 5.9 is just fine ?

using BAR approach in both cases.

Asking this because you might have noticed Oracle Analytics implementations at many customers and some of them have taken this "not supported" path as well, wonder if they faced serious disruptions in using their newer upgraded environments or if they managed with work arounds like patching etc..

[Deleted User]

Gianni beat me to it, but OS pretty much plays zero role.

What I think he means is "just give it a try and see what comes out". If your 12.2.1.3 wasn't filled with dirty legacy config that already should not have been there in 12c or 11g anyways (but was there because no dev standards were followed), then it will work just fine.

Personally I've migrated from several 11 and 12 versions which aren't on the official list without using BAR precisely because the originating config was messed up and wouldn't have made it through the migratio-too.jar or BAR process anyways.

Gianni Ceresa

I really meant what Christian said: "just give it a try and see what comes out" ;-)

some of them have taken this "not supported" path as well, wonder if they faced serious disruptions in using their newer upgraded environments or if they managed with work arounds like patching etc..

As said earlier and by Christian too: it all depends what you are starting with. And only you right now are seeing what the source system is like. There is little to no way to have a general statement about the result of a migration without doing it first, mainly because there so many things that could have been done wrong in the source system, and new the version will now behave differently with that wrong thing.

That's why you should have a validation process: as long as you are happy with your validation process and your new environment pass it, you can call it a successful migration. Maybe in 6 months you will discover that some legacy config or content is behaving weird with something new, you will fix it in 6 months as your validation process didn't point out any issue during migration...

(An environment can work badly or weirdly and not exactly as it has been built for, but as long as that's what you want, is that a problem? Not really, it's weird but not really a problem....)

Joe_obieeoas

Thanks Chris/Gianni.