Sponsored Content
Special Forums Hardware Storage migration from VMAX to VNXHe Post 302923490 by admin_db on Monday 3rd of November 2014 10:02:25 AM
Old 11-03-2014
Storage migration from VMAX to VNXHe

Hello,

We are considering storage migration for RAC database servers(using ASM) from VMAX to VNX?

Any good/bad pointers in this regards please.


Best regards,
Vishal
 

4 More Discussions You Might Find Interesting

1. Solaris

Veritas Storage Question (Data Migration)

Using Solaris 10 with Veritas Storage Foundation running. I want to copy all contents from DISKA LUN1 to DISKB LUN2. What would be the command syntax to do this? (0 Replies)
Discussion started by: soupbone38
0 Replies

2. Solaris

Storage Migration on Solaris server

Hi All, I need your help urgently. Below I have given the brief description of the Architecture and the Problem. The brief details of the architecture: We have 5 Containers(Non-Global Zones) running on one T5220 Box. The Global Zone is running Solaris 10. The Non-global Zones are... (6 Replies)
Discussion started by: kamaldeep1986
6 Replies

3. Solaris

Storage migration: zones and metasets

Hi all, I'm in a situation which i need to understand the best way of doing a migration of storage involved in a zone.Elements involved are solaris 10 (Generic_144488-08), metasets. I need to provision more storage to the said non-global zone and not aware of the "best practices" from the ... (2 Replies)
Discussion started by: ossupport55
2 Replies

4. AIX

AIX - FC Switch migration, SAN Migration question!

I'm New to AIX / VIOS We're doing a FC switch cutover on an ibm device, connected via SAN. How do I tell if one path to my remote disk is lost? (aix lvm) How do I tell when my link is down on my HBA port? Appreciate your help, very much! (4 Replies)
Discussion started by: BG_JrAdmin
4 Replies
nisping(1M)                                                                                                                            nisping(1M)

NAME
nisping - send ping to NIS+ servers SYNOPSIS
/usr/lib/nis/nisping [-uf] [-H hostname] [-r | directory] /usr/lib/nis/nisping -C [-a] [-H hostname] [directory] In the first line, the nisping command sends a ``ping'' to all replicas of an NIS+ directory. Once a replica receives a ping, it will check with the master server for the directory to get updates. Prior to pinging the replicas, this command attempts to determine the last update "seen" by a replica and the last update logged by the master. If these two timestamps are the same, the ping is not sent. The -f (force) option will override this feature. Under normal circumstances, NIS+ replica servers get the new information from the master NIS+ server within a short time. Therefore, there should not be any need to use nisping. In the second line, the nisping -C command sends a checkpoint request to the servers. If no directory is specified, the home domain, as returned by nisdefaults(1), is checkpointed. If all directories, served by a given server, have to be checkpointed, then use the -a option. On receiving a checkpoint request, the servers would commit all the updates for the given directory from the table log files to the data- base files. This command, if sent to the master server, will also send updates to the replicas if they are out of date. This option is needed because the database log files for NIS+ are not automatically checkpointed. nisping should be used at frequent intervals (such as once a day) to checkpoint the NIS+ database log files. This command can be added to the crontab(1) file. If the database log files are not checkpointed, their sizes will continue to grow. If the server specified by the -H option does not serve the directory, then no ping is sent. Per-server and per-directory access restrictions may apply; see nisopaccess(1). nisping uses NIS_CPTIME and NIS_PING (resync (ping) of replicas), or NIS_CHECKPOINT (for checkpoint). Since the NIS_PING operation does not return a status, the nisping command is typically unable to indicate success or failure for resyncs. -a Checkpoint all directories on the server. -C Send a request to checkpoint, rather than a ping, to each server. The servers schedule to commit all the transactions to stable storage. -H hostname Only the host hostname is sent the ping, checked for an update time, or checkpointed. -f Force a ping, even though the timestamps indicate there is no reason to do so. This option is useful for debugging. -r This option can be used to update or get status about the root object from the root servers, especially when new root replicas are added or deleted from the list. If used without -u option, -r will send a ping request to the servers serving the root domain. When the replicas receive a ping, they will update their root object if needed. The -r option can be used with all other options except with the -C option; the root object need not be checkpointed. -u Display the time of the last update; no servers are sent a ping. -1 No servers were contacted, or the server specified by the -H switch could not be contacted. 0 Success. 1 Some, but not all, servers were successfully contacted. Example 1: Using nisping This example pings all replicas of the default domain: example% nisping Note that this example will not ping the org_dir and groups_dir subdirectories within this domain. This example pings the server example which is a replica of the org_dir.foo.com. directory: example% nisping -H example org_dir.foo.com. This example checkpoints all servers of the org_dir.bar.com. directory. example% nisping -C org_dir.bar.com. NIS_PATH If this variable is set, and the NIS+ directory name is not fully qualified, each directory specified will be searched until the directory is found. See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Availability |SUNWnisu | +-----------------------------+-----------------------------+ crontab(1), nisdefaults(1), nisopaccess(1), nislog(1M), nisfiles(4), attributes(5) NIS+ might not be supported in future releases of the SolarisTM Operating Environment. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment. For more information, visit http://www.sun.com/directory/nisplus/transition.html. 12 Dec 2001 nisping(1M)
All times are GMT -4. The time now is 07:32 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy