The Geeky DBA

My latest project is to move our test instance off of our primary SAN and move it to a cheaper NAS device. This instance is used for testing and quality assurance. We purchased a RaidWeb NAS device last week. It has 2TB when formatted RAID5.

I mounted it up in two shares to drives P: and O: on my test box. I copied all the data file to the two drives. When I tried to create the control database I found that oracle could not authenticate, therefore read the datafiles on the mapped drives. So I next tried UNC paths (i.e. \\hostname\share). This too did not work. I changed my service to run under a privileged user. Still no love.

As a last ditch effort, I changed the hostname in the path to the IP address of the NAS device. Guess what, it worked! Woot! Control file created, on to recovery.

Our system generates quite a bit of redo, about 100GB a day. I don’t want to copy all this locally to recover this test instance. I set the archive log destination to a public share on our hot standby and started recovery. Sure enough, Oracle picked up the files and started blasting through the recovery. I’ll post tomorrow on the results.

I’m curious to see how well the database performs, even though it’s a test instance, over an ethernet connected NAS versus a fiber connected SAN.