Monthly Archives: July 2017

Configure SAP HANA Logs Cut and Past Backup configuration with Netbackup

Posted on by
Reply

Configuration from Netbacup Side

Create New policy for logs backup as below

install netbackup agent in hana server
update host file with netbackup master and media server name
Type :- Standard , User Archive
Add client in selection list
No need to add selection as it is user driven
SAP HANA

1. Create file on hana node
Create file with vi
#more /usr/openv/netbackup/hana_log_list

Add Logs location Logs file location
/hana/shared/HD12/HDB10/backup/log/XX/
/hana/shared/HD12/HDB10/backup/log/XX2/
/hana/shared/HD12/HDB10/backup/log/XX3/
/hana/shared/HQ13/HDB20/backup/log/DB_BQ1
/hana/shared/HQ13/HDB20/backup/log/SYSTEMDB

Create script with vi
#more /usr/openv/netbackup/hana_log_backup.sh
Add below command in above script
/usr/openv/netbackup/bin/bparchive -p (policyname) -s UserArchive -s (Netbackupmasterservername) -f /usr/openv/netbackup/hana_log_list

give full permission

Chmod 777 hana_log_backup.sh
schedule to run every 4 hours
Crontab –e -0 0,4,8,16,20 * * * /usr/openv/netbackup/db2_archive_log_backup.sh

 

To manully start backup run below command
/usr/openv/netbackup/bin/bparchive -p (policyname) -s UserArchive -s (Netbackupmasterservername) -f /usr/openv/netbackup/hana_log_list

After rebooting newly implemented vcenter 5.1, vcenter services are failed to start

Posted on by
Reply

Issue: –  Vcenter server service is failed to start

Error Logs: –   

vpxd logs

 

TCP:172.16.2.181:7444>; cnx: (null), error: class Vmacore::SystemException(No connection could be made because the target machine actively refused it. )

Line 1176: 2017-07-04T03:03:49.903-07:00 [02208 error ‘HttpConnectionPool-000001’] [ConnectComplete] Connect failed to <cs p:000000000b4fc720, TCP:172.16.2.181:7444>; cnx: (null), error: class Vmacore::SystemException(No connection could be made because the target machine actively refused it. )

Line 1179: 2017-07-04T03:04:00.948-07:00 [02208 error ‘HttpConnectionPool-000001’] [ConnectComplete] Connect failed to <cs p:000000000b4fc720, TCP:172.16.2.181:7444>; cnx: (null), error: class Vmacore::SystemException(No connection could be made because the target machine actively refused it. )

Line 1182: 2017-07-04T03:04:11.961-07:00 [02208 error ‘HttpConnectionPool-000001’] [ConnectComplete] Connect failed to <cs p:000000000b4fc720, TCP:172.16.2.181:7444>; cnx: (null), error: class Vmacore::SystemException(No connection could be made because the target machine actively refused it. )

Line 1185: 2017-07-04T03:04:22.990-07:00 [02208 error ‘HttpConnectionPool-000001’] [ConnectComplete] Connect failed to <cs p:000000000b4fc720, TCP:172.16.2.181:7444>; cnx: (null), error: class

Event viwer 

The description for Event ID 1000 from source VMware VirtualCenter Server cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

Findings: – 

  • Open CMD à netstat –ano  à port 7444 was not in listening list
  • Open SQL configuration manager à TCP/IP à IP all à dynamic port is configured by default which causes issue after rebooting vcenter server

Action taken to resolve the issue: –

  • Stop the SSO service
  • Removed port in Dynamic Ports and type 1433 in TCP port
  • From a CMD prompt go to: C:\Program Files\VMware\Infrastructure\SSOServer\utils
  • Then run the following command:
  •   ssocli configure-riat -a configure-db –database-host WIN-srv1 –database-port 1433 -m SSO Master password
  • Vcenter Server host name
  • Port Number
  • SSO master password
  • Open config.properties file, located at SSO_Install_Directory\webapps\lookupservice\WEB-INF\classes, using a text editor.
  • Locate the line db.url= and replace the port number with the new value.
  • Start the vCenter Single Sign-On service.
  • Open CMD à netstat –ano  à now I can see port 7444 is listening list
  • Start the vcenter server service and now it working fine and able to access vcenter management console.

 

SQL Server High Availability Options

Posted on by
Reply

I need to implement a high availability solution for one of my SQL Server databases, but I’m not sure of which option to implement to satisfy my company’s needs.  Check out this tip to learn about the five native SQL Server High Availability options.

Finding the right high availability option can be tricky.  The decision really depends on these items:

  • Needs
  • Budget
  • Scope
  • SQL Server version
  • Level of automation
  • Team level support
  • etc.

At a high level, there are five main high availability options including a new feature set to be release with SQL Server 2012:

  • Replication
  • Mirroring
  • Log Shipping
  • Clustering
  • AlwaysON

SQL Server Replication Overview

At a high level, replication involves a publisher and subscriber, where the publisher is the primary server and the subscriber is the target server. Replication’s main purpose is to copy and distribute data from one database to another. There are four types of replication that we will outline:

  • Snapshot replication
  • Transactional replication
  • Merge replication
  • Peer to Peer replication

Snapshot: Snapshot replication occurs when a snapshot is taken of the entire database and that snapshot is copied over to the subscriber. This is best used for data that has minimal changes and is used as an initial data set in some circumstances to start subsequent replication processes.

Transactional: Transactional replication begins with a snapshot of the primary database that is applied to the subscriber. Once the snapshot is in place all transactions that occur on the publisher will be propagated to the subscriber. This option provides the lowest latency.

Merge: Merge replication begins with a snapshot of the primary database that is applied to the subscriber. Changes made at the publisher and subscriber are tracked while offline. Once the publisher and subscriber are back online simultaneously, the subscriber synchronizes with the publisher and vice versa. This option could be best for employees with laptops that leave the office and need to sync their data when they are back in the office.

Peer to Peer: Peer to Peer replication can help scale out an application.  This is because as transactions occur they are executed on all of the nodes involved in replication in order to keep the data in sync in near real time.

Pros and Cons for SQL Server Replication

Pros

Cons

Can replicate to multiple servers

Manual failover

Can access all databases being replicated

Snapshot can be time consuming if you have a VLDB

Replication can occur in both directions

Data can get out of sync and will need to re-sync

Related tips:

SQL Server Database Mirroring Overview

Database Mirroring involves a principal server that includes the principal database and a mirror server that includes the mirrored database. The mirror database is restored from the principal with no recovery leaving the database inaccessible to the end users. Once mirroring is enabled, all new transactions from the principal will be copied to the mirror. The use of a witness server is also an option when using the high safety with automatic failover option. The witness server will enable the mirror server to act as a hot standby server. Failover with this option usually only takes seconds to complete. If the principal server was to go down the mirror server would automatically become the principal.

Pros and Cons for Mirroring

Pros

Cons

Automatic failover (with witness server)

Limited to two servers

Fairly easy to setup

Mirrored database is set to restore mode (Can’t access)

Fast failover

Rumored to be replaced by AlwaysOn in SQL Server 2012

Related tips:

SQL Server Log Shipping Overview

Log shipping involves one primary server, one monitor server (optional), and can involve multiple secondary servers. The secondary database(s) is restored from the primary database with no recovery leaving the database inaccessible to end users. The process of log shipping begins with the primary server taking a transaction log backup and moving the transaction log to a backup share on the secondary server by using the SQL Server Agent and job schedules at a set time interval. The secondary server will then restore the transaction log using the SQL Server Agent and job schedules at a set time interval. While it’s nice that log shipping supports multiple secondary servers, it’s probably the least used for HA because before the failover can occur, the secondary database must be brought fully up to date by manually applying unrestored log backups.

Pros and Cons for Log Shipping

Pros

Cons

Can log ship to multiple servers

Failover is only as good as your last log backup

Secondary database will be read only for reporting

Manual failover

Does not require SQL Server Enterprise

Related tips:

SQL Server Clustering Overview

Clustering involves at least two servers and is more of a server level high availability option compared to a database level option.Clustering will allow one physical server to take over the responsibilities of another physical server that has failed. This is crucial in environments that need close to 100% uptime. When a server’s resources fail, the other server will automatically pick up where the failed server left off causing little or no downtime. The two types of clustering we will discuss are Active/Active and Active/Passive.

Active/Active: When running in Active/Active mode, SQL Server is actually running on both servers.  If one of the SQL Server’s fail then the other SQL Server will failover meaning that two instances will be running on one server which could potentially cause performance issues if not sized appropriately.

Active/Passive: When running in Active/Passive mode, SQL Server runs on one server while the other server waits in case of a failure. This is the most popular choice because it doesn’t affect performance; however, you will need a server just sitting there with nothing running on it which could be perceived as expensive.

Pros and Cons for Clustering

Pros

Cons

Can cluster multiple servers

Complex setup

Automatic failover

Risk of purchasing hardware that never gets used

Server level failover compared to DB level

Not necessarily data protection

Related tips:

SQL Server AlwaysON Overview

AlwaysON is a new feature shipping with SQL Server 2012 and is an alternative to database mirroring. AlwaysON uses groups called Availability Groups, which are groups that contain selected databases that will fail over together if a failure should occur. Since AlwaysOn is such a new feature there is not a lot of production environment usage yet. I have installed and configured this option on a few test servers, however, and think it’s by the far the coolest HA option to date.

Related tips:

  • Stay tuned for some upcoming installation and configuration tips

Next Steps

From <https://www.mssqltips.com/sqlservertip/2482/sql-server-high-availability-options/>