Wednesday, April 25, 2007

moving essbase system pag and ind files off of a drive

I have come across many occasions where the essbase system files have to be moved off of one drive onto another.

Some instances are:

  • The typical situation is where you need more drive space on your server and additional drives have been purchased. To get to use these new drives the old drives will have to go away.
  • SAN configuration- for some reason they need to get your data off and onto a new drive share.
While there are cases where IT claims they can do this for you this is a task you can handle yourself (assuming your a designer for the app in question). I've seen more than once where someone thought they could do something with the SAN but when it came time to doing it, things didn't quite work out so rosy.

The steps are below:

  1. go into the database settings and remove the drive spanning settings for the drive you want to move the data from
  2. perform an application stop
  3. perform an application start
  4. go back into the database settings screen and add drive spanning for the drive you want to move the data to
  5. initiate a dense restructure. One way of doing this is by adding or taking away a member of a dense dimension then save and keep all data. (warning: dense restructures can tie up the server for an extended period of time depending on how large the page file is)

This is also illustrated via a screencam movie at

http://www.john-assoc.com/2000_Cams/Remove%20Spanned%20Drive%20from%20Essbase.html

2 comments:

Anonymous said...

Is there any way to move database files from one drive to another, with zero time penalty except the file transfer time and some admin tasks? Example: calc on a super fast hard disk, and move the final files to a much slower, but much more capable SAN?

Howard Johnson said...

I'm sure this can be done with the assistance of your IT. You'd probably want to span your index and pag files to a special drive letter (doesn't have the system essbase files on it). Then work with your IT to make another drive, copy these contents over, and remap on the operating system. Perform processing, copy files, remap drive.
What does the more capable san drive statement mean? San's are generally faster than local drives if tuned properly. The space allocation can be performed dynamically meaning hopefully you'll never run out of space.
Your san folks could easily handle this drive switching for you and the software (essbase) would never know the difference.
Are you having performance issues relating to allocations within a fully calced block storage cube?
It sounds like maybe your san has not been configured properly. I'd run a comparison between running on local drives and the san. If the san is slower then raise this as an issue.
hj