Blogs by Ashwin

  To read part 1 please click  here To read part 3 please click  here SQL Server Backups SQL Server backup to URL (Azure Storage) If you want to implement SQL Server Backup to URL, then, you have to use the following methods: Back Up Task in SQL Server Management Studio- A database can be backed up to URL via the Back Up task in SQL Server Management Studio using an SQL Server Credential. SQL Server Backup to URL Using Maintenance Plan Wizard- The Maintenance Plan Wizard in SQL Server Management Studio includes URL as one of the destination options, and the other supporting objects required to backup to Windows Azure storage like the SQL Credential. Transact-SQL , PowerShell or C#- These options should create a striped backup set, an SQL Server file-snapshot backup, or an SQL credential using Shared Access token. SQL Server Automated Backup v2 for Azure VMs The Managed Backup can be automatically configured by Automated Backup v2 to Microsoft Azure for all existing and ne...

  To read part 2 please click  here To read part 3 please click  here Backup & Restore of Azure VMs If you want to backup Azure VM, then Azure Backup can easily install an extension on the VM agent running on the machine. To install the VM agent manually, you have to use the following OS-specific instructions: Windowshttps://docs.microsoft.com/azure/virtual-machines/extensions/agent-windows Linuxhttps://docs.microsoft.com/azure/virtual-machines/extensions/agent-linux After the installation of the agent, Azure Backup will install the backup extension while enabling the backup which can also update and patch the extension without any user intervention. Azure VMs can be backed up with the help of following methods: Single Azure VM- directly from the VM settings in the Azure portal. Multiple Azure VMs- You can setup a Recovery Services Vault and configure backup for multiple Azure VMs.  Application-consistent backup of Azure Linux VMs Application consistency refers t...

  To read part 1 please click  here Remote Management of SAP HANA on Azure (Large Instances) Connecting to Azure HANA on Azure (Large Instances) from Azure VMs & from on-premises locations As we all know that, by default, the transitive routing between HANA Large Instance units and on-premises doesn't work, hence you can connect to HANA Large Instances from the same virtual network that hosts the application Azure VMs or you can also allow transitive routing with the help of following methods: A reverse proxy to route data, to and from SAP HANA on Azure (Large Instances) which can be for example, F5 BIG-IP or NGINX with Traffic Manager deployed in the Azure virtual network. IPTables rules in a Linux VM can be used to enable routing between on-premises locations and HANA Large Instance units, or between HANA Large Instance units in different regions. But, the VM size should be accordingly, so that the network throughput of the VM is appropriate for the expected network traf...

  To read part 2 please click  here Remote Management of Azure VMs The two basic methods for connecting into Azure VMs: Connect through public endpoints on a Jumpbox VM. Connect through a VPN or Azure ExpressRoute. These connections are also required for non-production scenarios that feed into production scenarios where SAP software is being used. Azure Automation It provides the desired state configuration functionality via a cloud-based, managed DSC Pull Server in the Azure Cloud offeSAring rich reports while informing you of important events. The machine configuration can also be updated and monitored automatically across physical and VMs, Windows or Linux, in the cloud or on-premises. Azure Automation also provides a built-in solution that can start and stop Azure VMs on user-defined schedules. SAP Landscape Management (LaMa) SAP LaMa is used by the customers to operate, monitor, and refresh their SAP landscape. As by default SAP LaMa 3.0 SP05 can easily ship with a connec...

  Migration Monitoring In a VLDB migration, some of the important components are monitoring, logging, and diagnostics that can be configured during Development, Test as well as "dry run" migrations. It is essential for optimizing the migration and planning production cutover as it will help in achieving safe, repeatable, consistent as well as low downtime migrations with the guarantee of no data loss. You have monitor the following aspects while running OS/DB migration: OS level parameters on DB and R3load hosts- CPU per thread, Kernel time per thread, Free Memory (GB), Page in/sec, Page out/sec, Disc I/O reads/sec, Disc I/O write/sec, Disk read KB/sec, Disk write KB/sec. DB level parameters on SQL Server target- BCP rows/sec, BCP KB/sec, Transaction Log %, Memory Grants pending, Locks, Lock memory, locking/blocking. Network monitoring is generally handled by network team while its configuration is totally depended on customer specific situation. VLDB Migration Do's &...

  Source System Optimizations For the Source Export of VLDB systems, you have to perform the following tasks: Purge Technical Tables and Unnecessary Data. You have to separate the R3load processes from the DBMS server if you want to maximize the export performance. You should run R3load on fast new Intel CPU instead of UNIX servers for better performance as 128 GB RAM of two-socket commodity Intel servers will cost little saving days or weeks of tuning/optimization or consulting time. 10 GB high Speed Network with minimal network ideally jumps between the source DB server and the Intel R3load servers. Usage of physical servers is highly recommended for the R3load export servers as virtualized R3load servers did not offer good performance or reliability at some customers sites at an extremely high network throughput. Sequence larger tables to the start of the Orderby.txt. Configure Semi-parallel Export/Import using Signal Files.  Unsorted Export is profitable for Large exports ...

  One-step Migration - DMO with System Move Option Steps for DMO with System Move to Microsoft Azure: Firstly, you should confirm that the connectivity to Azure is available via ExpressRoute (which is highly recommended as well as with greater speed connectivity) or Virtual Private Network (VPN) into Azure. You have to provision the target infrastructure in Azure including the SAP NetWeaver and SAP HANA database servers while the Azure infrastructure can be deployed fast by simply using the predefined templates. SUM is started on the on-premises source SAP application server. Uptime activities can be performed from the on-premises SAP application server while the shadow repository is created. In the downtime phase, export files are generated on the source system and then transferred to Azure through ExpressRoute or VPN. File transfer can usually occur in "Sequential Data Transfer" or "Parallel Data Transfer" mode. Sequential Data Transfer Mode: In this mode, all the...