3

We have a SYBASE IQ database running on Solaris using raw devices as underlying storage for the database. We would like to migrate this environment from Solaris to Linux. Is it possible to just reassign the SAN disks used as raw devices by SYBASE to our new Linux deployment, so that SYBASE would just pick those up and manage to access all of its old data?

I am concerned that since the 2 operating systems use different disk-labeling techniques SYBASE might be unable to detect it's previous data blocks. We wouldn't want to do a database export and import operation out of size requirements consideration. Running the two system in parallel is not an option.

Was anybody successful in achieving this, and if so, what were the obstacles encountered?

Improve this question
3
  • Given that you should be paying Sybase for support wouldn't it be better idea to ask them? How hard would it be to try it out with a small test database (which you should do regardless of the source of advice)? I suspect that endian-ness and other data format issues will be more of an issue than volume labels.
    – symcbean
    Jun 28, 2012 at 14:13
  • We're migrating from Solaris x86 to Linux x86 so endianness isn't a concern. There is no definite plan in motion, we're just trying to find the best solution to our problem, thinking we might come across people that have already done this, hence the question. Nevertheless, thanks for your feedback.
    – user126330
    Jun 28, 2012 at 14:17
  • Although my question is related to Sybase, people with similar experiences with other database systems (ex: Oracle) are welcomed to contribute.
    – user126330
    Jun 28, 2012 at 14:26

2 Answers 2

Reset to default
2

We proofed this exact scenario within the last two months here. This is an overview of what we did.

Solaris

[ 1 ] We are running Sybase IQ 15.2 on raw devices.

[ 2 ] All Luns on Solaris X86 system were created with an fdisk and Solaris EFI vtoc label. The SAN was a Clariion CX4

: fdisk -W - /dev/rdsk/c3t600601604E402D002C5763C4D3F8E011d0p0

  • /dev/rdsk/c3t600601604E402D002C5763C4D3F8E011d0p0 default fdisk table
  • Dimensions:
  • 512 bytes/sector
  • 63 sectors/track
  • 255 tracks/cylinder
  • 62660 cylinders *
  • systid:
  • 1: DOSOS12
  • :
  • :
  • 190: X86BOOT
  • 191: SUNIXOS2
  • 238: EFI_PMBR

  • 239: EFI_FS *

  • Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect 238 0 255 63 1023 255 63 1023 1 1006632958

: prtvtoc /dev/rdsk/c3t600601604E402D002C5763C4D3F8E011d0s2

  • /dev/rdsk/c3t600601604E402D002C5763C4D3F8E011d0s2 partition map *
  • Dimensions:
  • 512 bytes/sector
  • 1006632959 sectors
  • 1006632892 accessible sectors *
  • Flags:
  • 1: unmountable
  • 10: read-only *
  • Unallocated space:
  • First Sector Last
  • Sector Count Sector
  • 34 94 127 *
  • First Sector Last
  • Partition Tag Flags Sector Count Sector Mount Directory 0 4 00 128 1006616414 1006616541 8 11 00 1006616542 16384 1006632925

[ 3 ] We had allocated the /dev/rdsk/c3t600601604E402D002C5763C4D3F8E011d0s0 to Sybase IQ as well as other LUNs address by 's0' partition. EG.

main_1.iq -> /dev/rdsk/c3t6006016077202F00BC2278C54FA6E111d0s0 main_2.iq -> /dev/rdsk/c3t6006016077202F00C47489D74FA6E111d0s0 iq_system_main.iq -> /dev/rdsk/c3t6006016077202F00A89E624050A6E111d0s0 temp_1.iqtmp -> /dev/rdsk/c3t6006016077202F00FA57AD1750A6E111d0s0 temp_2.iqtmp -> /dev/rdsk/c3t6006016077202F0028B79B0050A6E111d0s0

RHEL 6.2

[ 1 ] We imported the LUNs to Linux server.

[ 2 ] The LUNS are presented in Linux as follows:

multipath -ll

mpathe (36006016077202f00a89e624050a6e111) dm-7 DGC,RAID 1 size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw |-+- policy='round-robin 0' prio=1 status=active | - 0:0:0:1 sdd 8:48 active ready running -+- policy='round-robin 0' prio=0 status=enabled `- 1:0:0:1 sdi 8:128 active ready running

mpathd (36006016077202f00bc2278c54fa6e111) dm-5 DGC,RAID 10 size=805G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw |-+- policy='round-robin 0' prio=1 status=active | - 1:0:0:2 sdj 8:144 active ready running -+- policy='round-robin 0' prio=0 status=enabled `- 0:0:0:2 sde 8:64 active ready running

mpathc (36006016077202f0028b79b0050a6e111) dm-2 DGC,RAID 1 size=403G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw |-+- policy='round-robin 0' prio=1 status=active | - 1:0:0:4 sdl 8:176 active ready running -+- policy='round-robin 0' prio=0 status=enabled `- 0:0:0:4 sdg 8:96 active ready running

mpathg (36006016077202f00c47489d74fa6e111) dm-6 DGC,RAID 10 size=805G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw |-+- policy='round-robin 0' prio=1 status=active | - 0:0:0:3 sdf 8:80 active ready running -+- policy='round-robin 0' prio=0 status=enabled `- 1:0:0:3 sdk 8:160 active ready running

mpathf (36006016077202f00fa57ad1750a6e111) dm-8 DGC,RAID 1 size=403G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw |-+- policy='round-robin 0' prio=1 status=active | - 0:0:0:5 sdh 8:112 active ready running -+- policy='round-robin 0' prio=0 status=enabled `- 1:0:0:5 sdm 8:192 active ready running

ls -l /dev/mapper/mpath*

lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathc -> ../dm-2 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathcp1 -> ../dm-3 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathcp9 -> ../dm-4 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathd -> ../dm-5 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathdp1 -> ../dm-9 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathdp9 -> ../dm-10 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathe -> ../dm-7 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathep1 -> ../dm-13 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathep9 -> ../dm-14 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathf -> ../dm-8 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathfp1 -> ../dm-15 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathfp9 -> ../dm-16 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathg -> ../dm-6 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathgp1 -> ../dm-11 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathgp9 -> ../dm-12

[ 3 ] We presented the RAW devices to Sybase IQ, by creating raw devices manually and binding them to the p1 partitions of the above listed LUNS:

ls -l /dev/mapper/mpath?p1

lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathcp1 -> ../dm-3 lrwxrwxrwx. 1 root root 7 Jul 4 17:47 /dev/mapper/mpathdp1 -> ../dm-9 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathep1 -> ../dm-13 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathfp1 -> ../dm-15 lrwxrwxrwx. 1 root root 8 Jul 4 17:47 /dev/mapper/mpathgp1 -> ../dm-11

raw -qa

/dev/raw/raw1: bound to major 253, minor 13 /dev/raw/raw2: bound to major 253, minor 9 /dev/raw/raw3: bound to major 253, minor 11 /dev/raw/raw4: bound to major 253, minor 3 /dev/raw/raw5: bound to major 253, minor 15

ls -l /dev/dm-3 /dev/dm-9 /dev/dm-13 /dev/dm-15 /dev/dm-11

brw-rw----. 1 root disk 253, 11 Jul 4 17:47 /dev/dm-11 brw-rw----. 1 root disk 253, 13 Jul 4 17:47 /dev/dm-13 brw-rw----. 1 root disk 253, 15 Jul 4 17:47 /dev/dm-15 brw-rw----. 1 root disk 253, 3 Jul 4 17:47 /dev/dm-3 brw-rw----. 1 root disk 253, 9 Jul 4 17:47 /dev/dm-9

[ 4 ] We created the same links to the corresponding devices on Linux:

main_1.iq -> /dev/raw/raw2 main_2.iq -> /dev/raw/raw3 iq_system_main.iq -> /dev/raw/raw1 temp_1.iqtmp -> /dev/raw/raw4 temp_2.iqtmp -> /dev/raw/raw5

[ 5 ] Copied over the database .db and .log files and started the database.

Improve this answer
0

when you say "raw devices", are you talking "raw devices" or "raw partitions"?

raw devices will just work.

if you're using raw partitions, then if the disk format is something that linux can understand (GPT, MBR, etc.) you're fine.

depending on the capabilities of your SAN, you could take a snapshot and mount the snapshot on a linux box to test with.

Improve this answer

You must log in to answer this question.