Another approach is to directly update the sysdevices table in the master database however, keep the following in mind:
- while direct updates of system tables are technically doable, said updates are typically not *officially* supported by Sybase (ie, do this at your own risk!)
- always make a backup of the database prior to making any changes to system tables, eg, make a backup of the master database before updating system tables in the master database
- when directly modifying system tables in the master database, make sure you thoroughly understand the steps involved in recovering the master database from a backup/dump file (see the System Admin Guide); you really don't want to find yourself in the position of trying to figure out how to recover a corrupted master database while you've got users/management breathing down your neck, eh
- *ALWAYS* perform updates of system tables within a transaction, and always verify the correctness/validity of your updates *BEFORE* you commit the transaction; it's a lot easier to rollback a screw up than to come up with additional DML statements to get you back to where you were before you committed a screw up
- if you're using ASE as a runtime component/backend for a SAP application, keep in mind that SAP usually frowns on users performing many normal/typical DBA duties directly against the ASE dataserver/databases (ie, they prefer you use the DBA cockpit for such activities), so chances are that if you (directly) modify system tables and you really screw something up there could be some negative ramifications if/when SAP finds out what you did
- if this is the first time you've modified system tables, or you're having second thoughts (sweaty palms?) about modifying master database system tables, consider either a) not performing said system table updates or b) setup a dummy dataserver (with a few devices) that you can run tests against to make sure you can successfully update the system tables (to include bouncing the dataserver afterwards to make sure everything comes up successfully!)
Sooooo, if you're still interested in directly modifying system tables ...
NOTE: All dataserver/database activity will need to be performed with a login that has the sa_role role.
1 - This operation will require that you bounce the dataserver at least once, and possibly a couple times, so you'll need to schedule an outage window with your users.
2 - backup the master database; make sure there are no issues/errors with the dump as you'll need this database dump file if you really screw things up and have to recover the master database
3 - [optional] shutdown and restart the dataserver in single user mode; the primary concern is to minimize any issues that may arise from having a lot of user activity on the dataserver while you're making the changes to the master database system tables; yes, you can skip this step if you've managed to get the users out of the system.
This consists of starting the dataserver with the '-m' option enabled. For unix/linux systems (and windows dataservers started from the batch file) you'll need to add the '-m' option to the runserver file. For windows dataservers started as a service you'll need to add a new string value to the following registry entry:
HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\Server\<dataserver_name>\Parameters
Take the highest 'Arg#' name and add one for the new parameter name (eg, if largest is 'Arg5', then create the new parameter with a name of 'Arg6'). Set the data value to the string: -m
Once you've added the '-m' option to the runserver file (or registry), startup the dataserver and watch the errorlog to verify the dataserver comes up in single user mode.
4 - Update the sysdevices table:
-- enable updates of system tables
sp_configure 'allow updates',1
go
use master
go
-- always update system tables within a transaction !!!!
begin tran
go
-- grab a before snapshot of current values
select * from sysdevices where <WHERE_CLAUSE>
go
-- update sysdevices.phyname rows as you see fit
update sysdevices set phyname = <new_value> where <WHERE_CLAUSE>
/* make sure the number of affected rows make sense, eg, if you're updating 1 row you should see the messaage: '(1 row affected)'; if the message does not match what you expected then rollback and start again!! */
go
/* NOTE: if you are currently using mirrored devices, and you are also moving/changing the location/name of said mirrors, then you'll need to also update sysdevices.mirrorname: */
update sysdevices set mirrorname = <new_value> where <WHERE CLAUSE>
-- again, verify affected row counts are correct
go
-- verify your changes are correct, ie, compare before (above) and after snapshots
select * from sysdevices where <WHERE_CLAUSE>
go
-- if the changes are correct then commit else rollback and try again
?? commit/rollback ??
go
-- disable updates of system tables
sp_configure 'allow updates',0
go
-- make sure all changes are flushed to disk
checkpoint
go
shutdown
go
5 - If your changes to sysdevices included a change to the location of the master device then you'll need to update the '-d' option (path to master device) in the dataserver's runserver file (and registry on windows - see registry key above => update the 'Arg#' entry where the data value starts with '-d').
NOTE: If the master device is currently mirrored, and you're renaming/moving said mirror, make sure you update the '-r' option in the runserver file (and registry => see the 'Arg#' entry where the data values starts with '-r').
6 - Copy/move your physical devices (at the OS level) to their new location.
7 - Startup the dataserver and check the errorlog for any issues during the a) the startup/initialization of *ALL* modified devices and b) make sure all databases residing on said modified devices come online successfully.
NOTE: If a device does not come online properly then a) verify the physical/OS location/name of the device and b) go back to step 4 to correct the entry in sysdevices. [Obviously (?) if you have issues with the master device you'll also need to revisit step 5 to make sure the -d (and -r) options are set properly.] You'll need to shutdown/restart the dataserver for any new changes in sysdevices to be picked up.
8 - [optional] If you had originally bounced the dataserver and brought it up in single user mode (step #3, above), then you'll need to undo this setting:
shutdown
go
Remove the '-m' option from the runserver file (for a windows service delete the 'Arg#/-m' entry from the registry - see registry key above).
Startup the dataserver. Keep any eye on the errorlog to verify no issues
9 - Once you've got your dataserver up and running with the newly modified sysdevices entries, go ahead and make another copy of the master database.
10 - If you got this far: Congratulations grass-hoppa! ;-)