No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Huawei Server Maintenance Manual 09

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
HANA

HANA

A User Requires to Change a Slave Node into a Standby Node After FusionCube SAP HANA Is Set Up

Problem Description
Table 5-260 Basic information

Item

Information

Source of the Problem

FusionCube troubleshooting

Intended Product

FusionCube V100R002C02SPC100

Release Date

2018-05-28

Keyword

FusionCube, HANA, standby, slave

Symptom

The user requires to change a slave node into a standby node after FusionCube SAP HANA is set up.

Key Process and Cause Analysis

The performance test requires a lot of working nodes, so no standby node is configured. However, the subsequent reliability test requires some slave nodes to be changed into standby ones. A manual operation is needed, because the script for FusionCube SAP HANA does not support an automatic change.

Conclusion and Solution

Solution

  1. Back up the database before the operation to prevent database exceptions.

  2. Click the Hosts tab on the Landscape page, select a host that is to be changed to a standby node, and right-click Remove Hosts. The table is then transferred to other database nodes by the system.

    After the table is successfully transferred, the removal status of the node is REORG FINISHED.

  3. Use SSH to log in to the slave node that is to be changed to a standby node and remove the node from the HANA cluster.

    cd /hana/shared/<sid>/global/hdb/install/bin

    ./hdbremovehost

  4. Add the removed node to the cluster as a standby node.

    cd /hana/shared/<sid>/global/hdb/install/bin

    ./hdbaddhost --role=standby --password=<your password> --sid=<sid> --sapmnt=/hana/shared/

    The following figure shows that hana003 has changed to a standby node.

Experience

None

Indicator of the sapstartsrv Service in SAP HANA Studio Is Always Yellow

Problem Description
Table 5-261 Basic information

Item

Information

Source of the Problem

FusionCube troubleshooting

Intended Product

FusionCube V100R002C02, FusionCube V100R002C30

Release Date

2018-05-28

Keyword

FusionCube, HANA, sapstartsrv

Symptom

The host name resolution information of the SAP HANA node is not configured on the Studio node.

Key Process and Cause Analysis

None

Conclusion and Solution

Solution

Configure the host name resolution information of the SAP HANA node on the Studio node. If the Studio node runs the Windows OS, modify the C:\Windows\System32\drivers\etc\hosts file. If it runs the Linux OS, modify the /etc/hosts file. Add the host name resolution to the bottom of the file and save the modification. The format is as follows:

::1 localhost ipv6-localhost ipv6-loopback

fe00::0 ipv6-localnet

ff00::0 ipv6-mcastprefix

ff02::1 ipv6-allnodes

ff02::2 ipv6-allrouters

ff02::3 ipv6-allhosts

127.0.0.1 localhost

172.21.36.31 DB01.site DB01

172.21.36.32 DB02.site DB02

Experience

None

Log Collection in the FusionCube SAP HANA Database Scenario

Problem Description
Table 5-262 Basic information

Item

Information

Source of the Problem

FusionCube troubleshooting

Intended Product

FusionCube SAP HANA database scenario

Release Date

2018-05-28

Keyword

Log collection

Symptom

Troubleshooting the FusionCube SAP HANA database involves a lot of components. Therefore, you need to collect logs of multiple components.

Key Process and Cause Analysis

None

Conclusion and Solution

Solution

  1. Collect FusionStorage logs.
    1. Collect logs of versions earlier than FusionCube C60.

      The directory for storing FusionStorage logs is /var/log/dsware. Use WinSCP to download logs generated within 12 hours before and after the fault occurs.

      The root user cannot directly download the logs because the security of the storage node is hardened. Therefore, you need to copy the logs to the /tmp directory and run the chown command to change the owner of the log files to user fc2 or dsware. Then, download the logs as user fc2 or dsware.

    2. Collect logs of FusionCube C60 and later versions.

      Log in to the FusionCube Center management portal, choose System > System Maintenance > Log Collection, select the node whose logs need to be collected, adjust the collection range, and click Collect Log.

      It takes a long time to collect logs if the collection time range is longer than one day. After the collection is complete, click Download to save the logs to the local PC.

  2. Collect OS logs.

    Run the supportconfig command to collect system logs.

  3. Collect database logs.
    1. Collect logs of the graphical user interface (GUI).

      Log in to the HANA Studio portal, double-click HANA SID, select Diagnosis Files, click Diagnosis Information, and select Collect.

      The default collection time range is 7 days. A large number of error logs are generated when the HANA system is faulty. You are advised to select logs generated one day before and after the fault occurs.

      After the collection is complete, click Diagnosis Information and select list.

      Select the collected logs and click the Download Collection button to download them to the local PC.

    2. Manually collect the logs of each node.

      Go to the directory /hana/shared/ANA/HDB42/dbn01/trace of each HANA node and collect daemon, indexserver, and nameserver logs. ANA indicates the SID, HDB42 indicates the instance ID, and dbn01 indicates the host name.

    3. Run a command to collect logs.

      Switch to the sidadm account of the HANA system and run the HDBSettings.sh fullSystemInfoDump.py command to obtain logs of the HANA cluster.

      After the collection is complete, the system displays the default path for saving logs.

  4. Collect IB logs.

    Log in to any compute node and run a command to obtain the following information:

    1. Network topology information

      Run the iblinkinfo > iblinkinfo.info command to collect the iblinkinfo.info file.

    2. Network diagnosis information

      Run the ibdiagnet -r -pc --pm_pause_time 1200 -P all=1 command to collect all files in the /var/tmp/ibdiagnet2/ directory.

Experience

None

Failed to Start the Cluster by Running the sapcontrol Command After the HANA Database Node Is Restarted

Problem Description
Table 5-263 Basic information

Item

Information

Source of the Problem

FusionCube troubleshooting

Intended Product

FusionCube for SAP HANA

Release Date

2018-05-28

Keyword

sapinit

Symptom

After the OS of the HANA database is restarted, the sapcontrol -nr 42 -function StartSystem ALL command fails to be executed and the following error message is displayed: FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen ().

Key Process and Cause Analysis

An analysis shows that during the startup of the sapinit service, four services need to be started. The startup files of three services out of the four are stored in the local directory. Files of the service that starts abnormally are saved in the HANA shared volume. The HANA shared volume is attached later than the sapinit service. As a result, the sapinit service fails to find the startup files and starts abnormally.

Conclusion and Solution

The shared volume is normally attached about 3 minutes after the OS is started. You are advised to configure the /etc/rc.d/rclocal file to set the startup time of the sapinit service to 5 minutes after the OS is started. This ensures that the shared volume is properly attached before the sapinit service is started.

Experience

None

Network Interruption Caused by HANA Server Restart

Problem Description
Table 5-264 Basic information

Item

Information

Source of the Problem

FusionCube troubleshooting

Intended Product

HANA database scenario

Release Date

2018-05-28

Keyword

Private network

Symptom

The service network restart command occasionally fails to be executed on the HANA appliance. As a result, the system is suspended.

Key Process and Cause Analysis

Key process

  1. Add debugging information to the network.

    Run the sh –x/etc/init.d/network restart command.

    It is found that the network is shut down successfully, but it is suspended at the /sbin/chkpro/sbin/udevd command when being started.

  2. Run the strace command to trace the /sbin/chkpro/sbin/udev command.

    It is found that the chkpro program is suspended at the newfstatat function stored in the /hana/shared/ANA/exe directory.

  3. Check the kernel stack of the /sbin/chkpro command.

    Cause analysis

    Because the NFS cannot work properly when the network is shut down, I/O is suspended when the chkpro program accesses files in the NFS directory during the startup of the network. As a result, the network startup is suspended.

Conclusion and Solution

Before restarting the network service, switch the HANA database to the standby node and disable the HANA sapinit service.

Experience

None

Clearing SCSI-3 Persistent Reservation Locks After the HANA Database Is Stopped Abnormally

Problem Description
Table 5-265 Basic information

Item

Information

Source of the Problem

FusionCube troubleshooting

Intended Product

HANA scenario

Release Date

2018-05-28

Keyword

Persistent reservation locks

Symptom

After the HANA database is shut down abnormally, the HANA database fails to be started and "reservation conflict" is displayed in the system message logs.

Key Process and Cause Analysis

Cause analysis

Register a reservation key with the LUN. After the registration is successful, the client attempts to perform permanent reservation and obtains the LUN operation permission when the reservation is successful. After the HANA system crashes, the persistent reservation lock of the volume to which the HANA system belongs cannot be released. As a result, if the volume is attached to another node, a message is displayed, indicating that a lock conflict occurs and the volume cannot be attached.

Conclusion and Solution

Solution

  1. Run the sg_persist --in --read-reservation -d/dev/sdm command to query any locked VBS.
  2. Run the sg_persist --out --clear --param-rk=123456 -d/dev/sdm command to delete all VBSs.
Experience

None

Note

If persistent reservation locks cannot be cleared by running the clear command, re-register the locks and then clear them again.

sg_persist --out --register --param-sark=123456 -d /dev/sdm

sg_persist --out --clear --param-rk=123456 -d /dev/sdm

A HANA Installation Failure Occurs Because the NFS in SUSE 12 Uses NFSv4 by Default

Problem Description
Table 5-266 Basic information

Item

Information

Source of the Problem

FusionCube troubleshooting

Intended Product

HANA SUSE 12 scenario

Release Date

2018-05-28

Keyword

Private network

Symptom

A crash occurs during the installation of the HANA database. The log shows that the /usr/sap/HT1/HDB43/exe/hdbparam –install command fails to be executed. The command fails to be executed manually, and the alarm information is the same as that displayed on the installation page.

Key Process and Cause Analysis

Cause analysis

The permission to access HANA-related files is nobody: nobody.

Check whether the attaching attribute of the shared volume is nfs_v4.

Conclusion and Solution

The nfs-v4 version used by default in the SUSE 12 version provides a daemon process called rpc.idmapd and uses the /etc/idmapd.conf configuration file. When the nfsv4 requests to be loaded, the daemon processes the mapping between UID and GID. NIS is used by default. If NIS is not used, the daemon automatically maps it as the nobody user.

Change the default mounting attribute of the volume to nfs_v3.

vi /opt/dsware/agent/conf/nas_volume_file

After the modification, manually unmount the shared volume. After the shared volume is automatically mounted, install the database again.

Experience

None

Translation
Download
Updated: 2019-02-25

Document ID: EDOC1000041338

Views: 69140

Downloads: 3767

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next