iSelfSchooling.com  Since 1999     References  |  Search more  | Oracle Syntax  | Free Online Oracle Training

    Home      .Services     Login       Start Learning     Certification      .                 .Share your BELIEF(s)...

 

. Online Accounting        .Copyright & User Agreement   |
    .Vision      .Biography     .Acknowledgement

.Contact Us      .Comments/Suggestions       Email2aFriend    |

 

More Resources by Google:

 

SRDF (W2K)

Summary:

This exercise is designed to lead the student through the initial setup and basic operations of the Symmetrix Remote Data Facility using the EMC Solutions Enabler SYMCLI.  During this exercise operations will be performed from either the host having acess to the source (R1) volumes, or from the host with access to the target (R2) volumes. This exercise will simulate a scenario where data is copied to a remote Symmetrix for backup purposes.

 

Objectives:

a)   Display configured SRDF volumes.

b)   Create SYMCLI Device Groups for SRDF operations.

c)   Suspend and Resume SRDF links.

d)     Display SRDF Volume Status.

e)     Change SRDF operational mode for one or all devices in a Device Group.

 

In this exercise we will configure both the source and target hosts for SRDF and perform basic management functions.  In our lab environment, the local host attached to the source Symmetrix had access to R1 volumes only, and the remote host attached to the target Symmetrix has access to the R2 volumes only.  In reality, the Symmetrixes can be configured with R1 and R2 volumes, and the hosts attached to them can have access to both types of volumes.  SRDF operations may be performed from either host.

1.   Create SYMCLI Device Groups   SRDF operations are performed on a group of one or more Symmetrix devices specified in a device group. For example, if a database tablespace is spread over 10 Symmetrix devices, typically SRDF functions would be performed against all devices that make up the tablespace in a single operation.  So the device group would include all 10 disks.  It may also be appropriate to have several device groups: one for each application or group of SRDF volumes. Multiple device groups will allow you to perform operations against one application or group of disks without affecting others.  How ever, at any given time, a Symmetrix device may belong to only one group.

SYMCLI device group information (name of the group, type, members, and any associations) are maintained in the SYMAPI database.

This and following exercises require two SRDF volumes.  You will create a device group that includes two SRDF volumes.

SRDF operations can be performed from the local host that has access to the source volumes or the remote host that has access to the target volumes. Therefore, both hosts should have device groups defined.  Note: the device group on the local host will be of type RDF1 and can include only the source (R1) volumes, and the device group on the remote host will be of type RDF2 and can include only the target (R2) volumes.

Complete the following steps on both the local and remote hosts.

a)     Identify the SRDF source and target volumes available to your assigned hosts. Execute the following commands on both the local and remote hosts.  It might be helpful to logon to the local host, open a window and rlogin to the remote host.  You could then switch from one window to the other to perform appropriate tasks.

# symrdf list pd  (execute on both local and remote hosts)

                           or

# syminq

 

b)     To view all the RDF volumes configured in the Symmetrix use the following

# symrdf list dev

 

c)      Identify two R1 volumes assigned to you in the output of the syminq command, and complete the table below.

   

d)     Display a synopsis of the symdg command and reference it in the following steps.

# symdg –h

e)     List all device groups that are currently defined.

# symdg list

f)        On the local host, create a device group of the type of RDF1.  On the remote host, create a device group of the type RDF2.  Replace “my” with your initials.

# symdg –type RDF1 create mysrcdg  (on local host )
# symdg –type RDF2 create mytgtdg  (on remote host )

g)     Verify that your device group was added to the SYMAPI database on both the local and remote hosts.

# symdg list

h)      Add your two assigned devices to your device group using the symld command. Again use (–h) for a synopsis of the command syntax.

 

On local host:

# symld –h

# symld –g mysrcdg add dev ###
or
# symld –g mysrcdg add pd Physicaldrive#

On remote host:

# symld –g mytgtdg add dev ###
or
# symld –g mytgtdg add pd Physicaldrive#

 

 

i)        Using the syminq command, identify the gatekeeper device assigned to you. Determine if it is currently defined in the SYMAPI database, if not, define it, and associate it with your device group. While SYMCLI does not require dedicated Gatekeeper devices, it is still recommended that gatekeepers be defined and associated with device groups.

On local host:

# syminq
# symgate  list
  (to determine if it is currently defined in the SYMAPI)
# symgate define pd Physicaldrive#
  (to define)
# symgate  -g mysrcdg associate pd Physicaldrive#
 (to associate)

On remote host:

# syminq
# symgate  list
  (to determine if it is currently defined in the SYMAPI)
# symgate define pd Physicaldrive#
  (to define)
# symgate  -g mytgtdg associate pd Physicaldrive#
 (to associate)

 

j)        Display your device groups. The output is verbose so pipe it to more

On local host:

# symdg show mysrcdg |more

On remote host:

# symdg show mytgtdg  | more


Note the Logical Device Name (LdevName) that is assigned to devices when they are added to a device group. The default LdevName is in the format of DEVXXX where XXX is a sequence number starting with 001.  More descriptive and meaningful names may be assigned if appropriate using the symld command.

i)        Display a synopsis of the symld command.
# symld  -h

ii)      Rename DEV001 to DBVOL1

On local host:

# symld –g mysrcdg rename DEV001 DBVOL1

On remote host:

# symld –g mytgtdg rename DEV001 DBVOL1

iii)    Display the device group on both the local and remote hosts.

On local host:
# symdg show mysrcdg |more

On remote host:

# symdg show mytgtdg | more

 

2.   Use the SYMCLI to display the status of the SRDF volumes in your device group. This command can be performed from either host.  If performed on the local host, use the device group mysrcdg   If performed on the remote host, use the device group mytgtdg

a)     If on the local host, check the status of your SRDF volumes using the following command:
# symrdf  -g mysrcdg query

What level of access (STATE) does the attached host have to the R1 volumes? _________

What level of access (STATE) does the attached host have to the R2 volumes? _________
Is the Link between the source and target volumes enabled? ______________
Is the mode currently set for Sync or Semi-Sync Operations? _______________

Is Domino Mode enabled or disabled? __________________________________
Is Adaptive Copy enabled or off? ______________________________________

 

3.   Setting SYMCLI_DG environment variable.  If you normally perform operations using a single device group, the SYMCLI_DG environment variable can be set to your default device group.  This will eliminate the requirement of specifying the device group using the –g flag.  The command symcli –env gives information about all the SYMCLI environment variables that can be set.

4.   Set the default device group. You can use the “Environmental Variables” option in the “Advanced” tab of the system applet in Control Panel if you would like the setting to be persistent.
 
# set SYMCLI_DG=mysrcdg (on the local host)

 # set SYMCLI_DG=mytgtdg (on the remote host)

a)     Check the SYMCLI environment.
# symcli –def  (on both the local and remote hosts)

b)     Test to see if the SYMCLI_DG environment variable is working properly by performing a “query” without specifying the device group.
# symrdf query  (on both the local and remote hosts)

 

5.   Changing Operational mode.  The operational mode for a device or group of devices can be set dynamically with the symrdf set mode command.

a)     On the local host, change the mode of operation for one of your SRDF volumes to enable semi-synchronous operations.  Verify results and change back to synchronous mode.
# symrdf set mode semi DBVOL1
# symrdf query
# symrdf set mode sync DBVOL1
# symrdf query

b)  Change mode of operation to enable adaptive copy-disk mode for all devices in the device group. Verify that the mode change occurred and then disable adaptive copy.
# symrdf set mode acp_disk
# symrdf query
# symrdf set mode acp_off
# symrdf query

 

6.   Check the communications link between the local and remote Symmetrix.

a)     From the local host, verify that the remote Symmetrix is “alive”.  If the host is attached to multiple Symmetrixes, you may have to specify the Symmetrix Serial Number (SSN) through the –sid option.
# symrdf ping [ -sid xx ] (xx=last two digits of the remote SSN)

b)     From the local host, display the status of the Remote Link Directors.
# symcfg –RA all list

c)      From the local host, display the activity on the Remote Link Directors. Monitor for 10 seconds and display two samples. Note: There may not be activity on the RDF links at this time.
# symstat  -RA all –i 10 –c 2

 

7.   Create a partition on each disk, format the partition and assign an NTFS filesystem to the partition. Add data on the R1 volumes defined in the mysrcdg device group. Replace “my” with your initials.

 

8.   Suspend RDF Link and add data to filesystem. In this step we will suspend the SRDF link, add data to the filesystem and check for invalid tracks. We will then resume the link and verify that the tracks on the target volume are synchronized.  This step is also performed on the local host.

a)     Check that the R1 and R2 volumes are fully synchronized.
# symrdf query

b)     Suspend the link between the source and target volumes.
# symrdf suspend

c)      Check link status.
# symrdf query

d)     Add data to the filesystems using the Windows Explorer program.

e)     Again, check for invalid tracks using the following command:
# symrdf query
How may invalid tracks are there?  _____________________
Are they R1 or R2 invalids?   __________________________


Are the number of invalid tracks different from what was displayed in step 7.c)? ____
How do you explain the difference? ________________________________
_________________________________________________

f)        Invalid tracks can also be displayed using the symdev show command. Execute the following command on one of the devices in your device group.  Look at the Mirror set information.

On the local host:

# symdev show ###

Do you see invalid tracks?  ________ What mirror position? ____________

g)     From the local host, resume the link and monitor invalid tracks.
# symrdf resume
# symrdf query

 

9.   End of Exercise. This concludes SRDF Lab 1 (W2K). Unless otherwise instructed, please go on to SRDF Lab 2  (W2k), which will explore using SRDF for disaster recovery applications.

 

Exercise Wrap-up:

symdg –type RDF1 ___________________________________________

symdg –type RDF2 ____________________________________________

symld ______________________________________

symgate define ____________________________________________

symgate associate ____________________________________________

symdg show _________________________________

SYMCLI_DG __________________________________

symrdf query _____________________________________________

symrdf set mode _____________________________________________

symrdf ping ______________________________________________

symstat ______________________________________

symrdf suspend _____________________________________________

symrdf resume _____________________________________________

symdev show  

_____________________________________________

 

 

 

 

 


 

 

Google
 
Web web site