valutazioni - 0, GPA: 0
(
)
)
|
da questo dispositivo ha anche altre istruzioni :
Facilità d'uso
•
Extending storage space to the maximum allowed size fails and displays an error message.
After storage is created in ASM, a size range is displayed that indicates the minimum and maximum
size that the storage space can be extended (for example, 15MB - 272GB). When using the
Allocate Space function to extend storage to the displayed maximum space allowed, the operation
fails and an error message is displayed.
Workaround: Enter a smaller value than the maximum size allowed that is displayed in the ASM
user interface until the operation is successful. This issue will be resolved in a future release.
•
When performing storage tasks such as extending LUNs and deleting LUNs using DiskRAID and
ASM, a VDS application error may be issued.
Workaround: This error can be safely ignored; there is no functionality impact to ASM.
•
Shared folders that have no file system quota assigned to them cause unexpected behavior in
ASM.
The following behavior may be observed in the ASM user interface for shared folders that have
no file system quota:
◦
The properties dialog for a shared folder that was created using ASM or a shared folder that
was created outside ASM but discovered by ASM includes a Warning Threshold tab. If the
shared folder has no file system quota assigned to it, the text on this tab is incorrect. The text
should indicate that a file system quota should be applied to the shared folder.
◦
The Allocate space action will incorrectly display a size of 0 MB for the shared folder and
continuing with the Allocate space action will grow the volume by unexpected amounts.
◦
If a file system previously existed (for example, when the shared folder was created with
ASM and then removed), ASM will continue to display the original quota information.
Workaround: To resolve issues 1 and 2, apply a file system quota to the shared folder. To resolve
issue 3, select the Remove from view action for the shared folder in the ASM user interface.
•
Backup job fails for Exchange storage groups that were manually migrated to the storage system.
Workaround: Manually create another iSCSI virtual hard disk and make it accessible to the
Exchange server:
1.
Use the Exchange Management Console to move the newly created database to the new
volume, leaving the log files, system files, and other databases of the storage group at the
original iSCSI volume.
2.
After modifying the paths in Exchange, click Refresh in the ASM user interface to force a
discovery.
3.
The application area for database will now show an alert. Right click on this area and select
Remove from view.
4.
Another discovery will be performed and ASM will restore the database area into the user
interface with corrected properties, such as the new location on the Exchange server.
For backup jobs from ASM to work properly, each database and the log files/system files must
be on a separate iSCSI volume. For example, if a storage group contains one mail store and one
public folder store, three iSCSI volumes should be used, one for each database, and one for the
log and system files.
•
Restore from backup fails to launch the ASM wizard on a ASM client machine.
Workaround: Install DPX on the client machine:
1.
Install DPX on client machine as a client to DPX running on storage server. When installing
DPX, select the option to add it as a client for a storage domain. The option adds DPX on
the client machine to DPX running on storage server.
2.
When DPX is installed, you can see all jobs running in the DPX installed on storage server.
3.
Run the restore job (this is as same as running the restore job on storage server).
6
Workarounds
...