Process multiple destinations far что это
Paste files to multiple destinations
I get into this situation quite often but haven’t found a solution. I have a group of CSS files in the clipboard that I need to paste + replace into several different destination folders. My folder structure is similar to
There’s a pattern: I want to paste to all CSS folders whose container ends in _11 but not any of the others.
The content of the destination folders doesn’t matter, I just need to replace them with the new files. Is there a simple way to paste these files into multiple destinations at once? It could also be an Automator flow or Terminal command.
2 Answers 2
As requested, here’s a workable solution as we’ve discussed in the comments thread. Currently, the situation is that you have multiple files on the clipboard that need to be pasted into multiple destination folders. These destination folders are all called «CSS» and reside inside a set of parents folders (names ending «_11» ) that you are able to select en masse.
After doing that, you can run the following Automator service, either from the right-click context menu and selecting it under Services (or the Mojave equivalent); or by assigning it a keyboard shortcut in System Preferences, and triggering the service with the press of a hotkey.
The Automator service in question looks like this:
The AppleScript code used in the Run AppleScript action is below. The AppleScript reads the list of files contained on the clipboard; isolates the «CSS» subfolders in each of the selected parent folders that were passed into the service (the «CSS» folder is created if it doesn’t already exist); and then duplicates the files from the clipboard into the «CSS» directories.
If the clipboard does not contain any files, you’ll hear a beep and no further action is taken.
One source to multiple destinations with Robocopy
Is there a specific combination of command switches that permits Robocopy to copy files and folders from a single source to multiple destinations, at the same time?
I’m seeing alot of scripts suggesting to just include a Robocopy command line for each destination which means the copy would be sequential.
What I’m looking for is to be able to start a copy job to send the source files to two shares at the same time.
You can do a batch file to tell robocopy to copy the same source to multiple locations. It would look like this:
Sadly it would run the command for source to first destination, once completed it would move to copy the same source to the second destination and so on. It could be slow the first time the sync happens if you have a large amount of data.
I can only think of one other way to speed this up. With powershell you can spawn jobs (it’s a way of multi threading) so that you could spawn all the jobs at once to copy the one source to all the destinations. The only problem with this would be the IOPS of the source drive. It won’t necessarily be on the same bit of the same file at the same time, so the hard drive would be seeking all over the place (if it’s a spinning disk) If the source drive is flash, it might be good to do this method.
8 Replies
Get your ROBOMOJO on.
Thanks for the suggestion! Is RoboMojo completely GUI or does it also have command-line switches so that scheduled tasks can be created?
Thanks for the suggestion! Is RoboMojo completely GUI or does it also have command-line switches so that scheduled tasks can be created?
The newest version of robomojo has command line support. http://robomojo.codeplex.com/ but yes robomojo is just a GUI overlay for robocopy to allow you to setup tasks and schedule them.
You can do a batch file to tell robocopy to copy the same source to multiple locations. It would look like this:
Sadly it would run the command for source to first destination, once completed it would move to copy the same source to the second destination and so on. It could be slow the first time the sync happens if you have a large amount of data.
I can only think of one other way to speed this up. With powershell you can spawn jobs (it’s a way of multi threading) so that you could spawn all the jobs at once to copy the one source to all the destinations. The only problem with this would be the IOPS of the source drive. It won’t necessarily be on the same bit of the same file at the same time, so the hard drive would be seeking all over the place (if it’s a spinning disk) If the source drive is flash, it might be good to do this method.
Thanks for the tips and the code.
I’m going to try just creating two robocopy sessions (5 minutes apart) to the respective destinations and see how the performance is.
Appreciate your input.
Thanks for the tips and the code.
I’m going to try just creating two robocopy sessions (5 minutes apart) to the respective destinations and see how the performance is.
Appreciate your input.
You could set 5 minutes spaces in your task schedules. But what if one runs longer than 5 minutes? you would then run into the IOPS problem again (assuming you would hit the IOPS limit if it’s a spinning disk)
I created two robocopy tasks to run 10 mins apart and so far everything seems to be fine; no IOPs issues that I can see at the moment.
Thanks for all the suggestions from this thread.
Process multiple destinations far что это
An Oracle Data Guard far sync instance is a remote Oracle Data Guard destination that accepts redo from the primary database and then ships that redo to other members of the Oracle Data Guard configuration.
A far sync instance manages a control file, receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs, but that is where the similarity with standbys ends. A far sync instance does not have user data files, cannot be opened for access, cannot run redo apply, and can never function in the primary role or be converted to any type of standby database.
Far sync instances are part of the Oracle Active Data Guard Far Sync feature, which requires an Oracle Active Data Guard license.
A far sync instance consumes very little disk and processing resources, yet provides the ability to failover to a terminal destination with zero data loss, as well as offload the primary database of other types of overhead (for example, redo transport).
All redo transport options available to a primary when servicing a typical standby destination are also available to it when servicing a far sync instance. And all redo transport options are available to a far sync instance when servicing terminal destinations (for example, performing redo transport compression, if you have a license for the Oracle Advanced Compression option).
Many configurations have a primary database shipping redo to a standby database using asynchronous transport at the risk of some data loss at failover time. Using synchronous redo transport to achieve zero data loss may not be a viable option because of the impact on the commit response times at the primary due to network latency between the two databases.
See the following topics:
Creating a Far Sync Instance
Creating a far sync instance is similar to creating a physical standby except that data files do not exist at the far sync instance.
Therefore, on a far sync instance there is no need to copy data files or restore data files from a backup. Once the far sync instance has been created, the configuration is modified to send redo synchronously from the primary database to the far sync instance in Maximum Availability mode and the far sync instance then forwards the redo asynchronously in real time. Lastly, the original asynchronous standby (referred to as the terminal standby) is configured to act as the alternate to the far sync instance in the event that communication with the far sync instance is interrupted.
In a configuration that contains a far sync instance, there must still be a direct network connection between the primary database and the remote standby database. The direct connection between the primary and the remote standby is used to perform health checks and switchover processing tasks. It is not used for redo transport unless the standby has been configured as an alternate destination in case the far sync instance fails and there is no alternate far sync configured to maintain the protection level.
Creating and Configuring a Far Sync Instance
Take the following steps to create a far sync instance:
Because the LOG_FILE_NAME_CONVERT parameter was specified on the far sync instance (see Example 5-1), the standby redo logs are created automatically when redo transport begins from the primary, if they were created on the primary as described in Configure the Primary Database to Receive Redo Data.
Standby redo log files used at the far sync instance cannot be shared with other databases. Therefore, all relevant considerations discussed in Standby Database Directory Structure Considerations for standby redo log files also apply at the far sync instance.
After the far sync instance is created and running you can change the STARTMODE to auto to enable automatic startup of the far sync instance
The ORADIM utility automatically determines the username for which this service should be created and prompts for a password for that username (if that username needs a password). See Oracle Database Platform Guide for Microsoft Windows for more information about using the ORADIM utility.
As of Oracle Database 12 c Release 2 (12.2.0.1), when a password file is manually updated at a far sync instance, the redo containing the same password changes from the primary database is automatically propagated to any standby databases that are set up to receive redo from that far sync instance. The password file is updated on the standby when the redo is applied.
On the far sync instance system, use Oracle Net Manager to create a network service name for the primary ( chicago ) and the terminal standby ( boston ) to be used by redo transport services.
The Oracle Net service name must resolve to a connect descriptor that uses the same protocol, host address, port, and service that you specified when you configured the listeners for the primary database, the far sync instance, and the terminal standby database. The connect descriptor must also specify that a dedicated server be used.
See the Oracle Database Net Services Administrator’s Guide for more information about service names.
For information about validating a configuration after you create a far sync instance, see Validating a Configuration.
Supported Protection Modes for Far Sync Instances for more information about far sync and protection modes
Oracle Data Guard Protection Modes for more information about configuring different data protection modes
Example 5-1 Some of the Initialization Parameters Used for Far Sync Instances
Primary Database chicago
Far Sync Instance chicagoFS
Physical Standby boston
Alternate Destinations
After you perform the steps in Creating and Configuring a Far Sync Instance, the far sync instance provides zero data loss capability for the configuration by forwarding the redo to the terminal standby at a remote site over the WAN. For the configuration to remain protected in the event the far sync instance is not reachable, you must configure alternate redo transport paths to the standby databases. This is accomplished using the GROUP and PRIORITY attributes of the LOG_ARCHIVE_DEST_ n parameter. (As of Oracle Database 12 c Release 2 (12.2.0.1), the GROUP and PRIORITY attributes have replaced the ALTERNATE attribute for remote redo destinations.)
The number of possible alternate remote destinations has been increased with the concept of log archive destination groups. A log archive destination group specifies multiple archive destinations that can be used to distribute redo to multiple destinations, either from a far sync instance or through cascading. The destinations in the group can then be prioritized so that only one destination is active at a time on the primary database. Other destinations are available to become active if the active destination becomes unavailable. To expand the number of possible archive destinations for your database, you can specify multiple groups.
Using the ALTERNATE Attribute to Configure Remote Alternate Destinations for information about configuring alternate remote destinations using the old ALTERNATE syntax.
Assigning Log Archive Destinations to a Group
Use the GROUP attribute of the LOG_ARCHIVE_DEST_ n initialization parameter to assign log archive destinations to groups.
If log archive destination groups are used, then as long as at least one destination within the group remains available, at least one destination remains enabled and active. Log archive destinations that are not assigned to a group behave the same as log archive destinations did prior to Oracle Database 12 c Release 2 (12.2.0.1).
There can be up to 30 log archive destinations in a group. Log archive destination groups are referenced by their group number, which is assigned when the group is created. Groups are numbered from 1 through 8. A log archive destination group contains a set of remote ( SERVICE= …) destinations. (Local archival ( LOCATION= …) destinations are not supported in log archive destination groups and must use the ALTERNATE attribute for alternate local archiving locations. See ALTERNATE.
One log archive destination in the group is always active and the others are available for use in the event of a failure of the active log archive destination. When a failed destination again becomes available it becomes eligible if the currently active destination fails, but it does not become active immediately, unless all other group members are also unavailable. For example, the following declaration can be used to specify three far sync instances as members of the same group and having the same priority (Priority within a group is described in the next section). These are example parameter definitions and do not contain all the necessary attributes. Do not use them verbatim. In this example only the first destination is active with the second destination available to take over if destination 1 becomes unavailable.
Because log archive destination groups replace the LOG_ARCHIVE_DEST_ n ALTERNATE attribute, use of the ALTERNATE attribute with log archive destinations that are not in the default group (where GROUP is specified as 1 to 8) is not allowed.
Assigning Priorities to Log Archive Destinations in a Group
Using the PRIORITY attribute of the LOG_ARCHIVE_DEST_ n initialization parameter to assign destination preferences within a log archive destination group allows you to control the fail back mechanism, especially with multiple members within a group.
In the previous section, the two far sync instance destinations did not have a priority, which means that when the alternate destination is activated after a failure of the first destination it remains as the active destination until it fails. The priority is used to determine which log archive destination within a group to make active when the database or far sync instance is started or when a destination fails. Log archive destinations become active in the following cases: The primary database is opened in read/write mode, a far sync instance is mounted, or a standby database is mounted or opened in read-only mode. The same priority value can be assigned to more than one log archive destination in a group. The priority value is an integer in the range of 1 through 8. Lower numbers indicate higher priorities. The default priority is 1 (the highest priority).
The priority comes into play when a previously failed destination becomes available again. A set of log archive destinations assigned to the same group have the same priority, by default. Therefore, if one destination fails then a failover occurs to another member of the set. When the failed destination becomes available again, it does not become the active destination since both destinations have the same priority. If the second destination fails after the first destination has again become available, then the database fails over to the first destination or to another destination in the group at the same priority. This cycle can repeat indefinitely, provided that another destination is always available before the active destination fails.
Continuing with the previous example, priorities can be added to the log archive destinations to control when a destination might become active. In the following example, a third far sync instance is added, but at a lower priority:
This declaration results in the following behavior:
The primary ships redo to the first of two preferred far sync instances, chicagoFS
If chicagoFS becomes available again, no fail back occurs. It becomes the alternate to chicagoFS1 because the priority is the same.
If both chicagoFS and chicagoFS1 become unavailable, then the primary ships to chicagoFS2 (in this case via the ASYNC redo transmission mode).
Shipping to Multiple Active Destinations in a Group
You can also use the PRIORITY attribute to configure a group so that it ships to multiple destinations if a preferred destination fails.
This declaration results in the following behavior:
If chicagoFS is unavailable, then the primary ships directly to both terminal standbys boston and newyork in ASYNC mode.
Using Multiple Log Archive Destination Groups
Multiple log archive destination groups can be used for site-specific high availability considerations or to distribute service over large cascaded (reader farm) configurations.
The following declaration sets up multiple log archive destination groups with chicagoFS and chicagoFS1 in group 1 and chicagoFS3 and chicagoFS4 in group 2:
Determining the Availability Status of Log Archive Destinations
Oracle Data Guard keeps track of the current status of available but inactive destinations in log archive destination groups by periodically polling configured destinations to determine their availability.
The information used to determine availability is derived from the MAX_FAILURE attribute which specifies the consecutive number of times redo transport services attempt to reestablish communication and transmit redo data to a failed destination before the primary database gives up on the destination. The default value for MAX_FAILURE is 1 when the GROUP and PRIORITY attributes are used.
The behavior of the MAX_FAILURE attribute is different between Oracle Database 12 c Release 1 (12.1) and Oracle Database 12 c Release 2 (12.2). It is important to understand the differences.
Configuring Alternate Destinations
Far sync instance configurations can be set up to provide varying levels of data protection.
The following topics expand on the examples provided in the previous section and provide examples of two additional far sync instance configurations that provide better data protection when you use far sync instances.
Reduced Protection After a Far Sync Failure
With all far sync instance configurations it is important that redo continues to ship to the terminal standbys to continue to provide protection of the primary database.
In the simplest configuration there is one far sync instance ( chicagoFS ) and one terminal standby database ( boston ).
Example 5-2 Configuring for Single Destination Failover
Primary Database chicago
This declaration causes the primary database to ship redo directly to the terminal standby if the far sync instance chicagoFS fails. If the far sync instance becomes available again, then it becomes the active destination and redo transmission goes to the far sync instance.
If the far sync instance had multiple terminal standby databases, then you would use PRIORITY=8 to ensure that all of those destinations received redo directly from the primary database if the far sync instance failed.
Example 5-3 Configuring for Multiple Standby Database Redo Destination Failover
Primary Database chicago
As in the previous example, modify the log archive destination on the primary database for the far sync instance to add it to a group with a Priority of 1 and then add a new log archive destination for each standby the far sync instance services at Priority 8 in ASYNC mode.
This declaration causes the primary database to ship redo directly to both terminal standby databases if the far sync instance chicagoFS fails. If the far sync instance becomes available again, then it becomes the active destination and redo transmission goes to the far sync instance.
Far Sync Instance High Availability
Configuring an alternate far sync instance keeps the protection level of the configuration at the configured protection level of Maximum Availability if the preferred far sync instance fails for some reason.
In both of the preceding examples the protection level of the configuration would fall out of Maximum Availability because redo is no longer being shipped in SYNC mode. For more protection from system or network failures, an additional far sync instance can be configured that provides high availability for the active far sync instance. In this configuration one is the preferred active far sync instance and the other is the alternate far sync instance.
The primary automatically starts shipping to the alternate far sync instance if it detects a failure at the preferred far sync instance. In these types of configurations, the primary uses only one far sync instance to redistribute redo at any given time.
The high availability far sync instance would be created using the same steps as given in Creating and Configuring a Far Sync Instance, and configured to forward redo to the terminal standby boston.
Example 5-4 Parameters Used to Set Up the High Availability Far Sync Instance
Primary Database chicago
Maintaining Protection After a Role Change
These examples describe how to maintain data protection after a role change.
The configuration described in the preceding sections works well to keep the configuration running at Maximum Availability until all far sync instances fail and redo is shipped to the standby database directly. But it would be inappropriate after a role transition where boston becomes the primary database and chicago becomes the terminal standby. The far sync instances chicagoFS and chicagoFS1 would be too remote for boston to use as a synchronous destination because the network latency between two sites is sufficiently large that it would impact commit response times. To maintain the protection level of Maximum Availability for zero data loss, a second far sync instance configuration close to boston must be established, in readiness for a future role transition event.
Example 5-5 Parameters Used to Set Up Protection After a Role Change
Primary Database boston
Primary Database chicago
Supported Protection Modes for Far Sync Instances
A far sync instance is supported in either maximum performance or maximum availability mode.
Far Sync Instances in Maximum Availability Mode Configurations
In maximum availability mode, the far sync instance is relatively close to the primary database to minimize network latency, and the primary services the far sync instance using SYNC transport.
Both SYNC/AFFIRM and SYNC/NOAFFIRM semantics are supported on the LOG_ARCHIVE_DEST_ n established at the primary for the far sync instance. See Oracle Data Guard Protection Modes for information about the trade-offs of using each one.
When a primary services a far sync instance using SYNC transport, all committed redo resides on disk at the far sync instance. This allows the far sync instance to use one of the terminal standby destinations for a no data loss failover if the primary database is lost.
The far sync instance uses ASYNC transport to ship the incoming redo to terminal standbys that can be much farther away. This extends no data loss protection to destinations that are too far away for a primary database to feasibly service directly with SYNC transport because of the degradation in transaction throughput that would result. This is a case where a far sync instance is beneficial even if there is only one standby destination in the configuration.
Far Sync Instances in Maximum Performance Mode Configurations
In maximum performance mode, the primary database services the far sync instance destination using ASYNC redo transport.
This is true regardless of the physical distance between the primary and the far sync instance because high network latencies do not affect transaction throughput when a destination is serviced with ASYNC transport.
In maximum performance mode, a far sync instance can benefit Oracle Data Guard configurations that manage more than one remote destination. Although each ASYNC destination has a near-zero effect on primary database performance, if there are many remote destinations (for example, multiple Oracle Active Data Guard standbys that form a reader farm), then the effect can become measurable. When a far sync instance is used, there is zero incremental effect for each remote destination added to the configuration. Additionally, redo transport compression can also be offloaded to the far sync instance. When a far sync instance is used, the primary only has to service the far sync instance, which then services the rest of the configuration; the greater the number of destinations, the greater the performance benefit.