Microsoft 70-466 Certification Paves the Way to A Top Career

It is an era of competition in every sphere of life. Survival of the fittest is required, and for that, it is essential for all people whether they belong to the field of 70-466 Information Technology or not to stay alert, updated, and proactive so that they can achieve the wanted results.

It is a golden opportunity for the people relating to the folds of information technology that such a leading organization like Microsoft provides now and then not just a new program but also a 70-466 course to understand the plan and work with it.

If you are looking to implement data models and reports using Microsoft SQL Server and gain faster insights on data, this is the ideal skill enhancement tool for you.

Microsoft SQL Server is a relational database management system with the primary purpose of storing and recovering data as requested by other software applications. Being able to tell a story using data is critical for today's growing businesses who want insight into their customers, products, etc.

Professionals seeking comprehensive knowledge of how to harness Microsoft SQL Server to deliver mission-critical performance will significantly benefit from the Microsoft 70-466 Practice Test. This practice test will prepare you to ace the Microsoft 70-466 certification exam confidently.

Who Should Give the 70-466 Exam?

Anyone who does not needs to shy away from the competition and stay ahead of everyone else should give 70-466 exam. After all, it is all about the continuation of the fittest. Those individuals who want to learn whereby to implement data models, make them and get the most out of their skills as IT Professionals.

Also, all those individuals who require to get certified by the leading organization worldwide this is a golden opportunity that should not be missed. The results will be that when he will receive the stamp of endorsement from Microsoft itself and will guarantee that he gets the best job available.

Why Should You Give the 70-466 Certification?

It is essential to understand that, along with time now. Then several new inventions will be practicing birth all around the world coping to make a place for them in the world of information technology. In such a case, your experience and education, no matter how new it is, and your experience no matter how large it is, will cause burning out.

So you need to have on modernizing and brushing up your skills, and for that, such a course is essential. This 70-466 certification course is necessary for implementing data models and getting a suitable SSAS solution as well as going for business intelligence programs.

The exam it aligns with is intended for business intelligence (BI) developers who focus on creating BI solutions that need implementing multi-dimensional data models, implementing and maintaining OLAP cubes, and creating information displays used in business decision making.

Obtaining 70-466 certification implies that you possess the fundamental knowledge to build an analysis services multidimensional database, manage, maintain. And troubleshoot SQL Server Analysis Services database, create a tabular data model, and make a report with SQL Server Reporting Services.

70-466 Certification Preparation Tips Directly from the Experts

Undoubtedly, experts’ tips can change the way you prepare. Therefore, our experts have joined all tips and tricks that helped them qualify for the 70-466 exam.

To get started, pull yourself together, begin organizing and make a planner and try to stick to it.
Secondly, make sure to follow your preparation daily. Also, do not try to do last minute prep. Further, that will only start to confusion and nothing else.

Further, allow yourself to get enroll in either an online or offline training course as well because training will increase your capability to solve the problem in the exam.

Glimpses of Getting the Microsoft 70-466 Certification

Lastly, always keep in mind that developed a clear understanding of all the topics before appearing for the 70-466 exam.

Self-evaluation Time

Make sure you are going through sample tests only after you have gone through the whole syllabus. All the sample test mock tests are designed in such a way that you encounter the real exam environment around you. After making sample tests, you can easily understand the areas you are lacking behind and work upon them. Practice papers can be from different sources. Remember, the more you test yourself, the better you are going to become.

So, START PRACTICING NOW!

Job Opportunities

There is tremendous scope for Microsoft 70-466 certified people in the market. The certification will add value and a strong base to your resume. Big players of the industry always give the accredited people high paying jobs.

After passing this exam, the candidate will have plenty of job options like:

• Microsoft system administrator

• Software developer and architecture

• Network support specialist/network engineer

• System analyst/support engineer

In Conclusion

Certainly, addition a Microsoft certification to your resume will aid you to stand out and get hired. So, if you are aspired to advance your career and motivated to follow your dream, then passing the 70-466 exam will be the last step towards being certified.

In other words, certification exams like the 70-466 exam will not only demonstrate that you have the skills required for the job but will also showcase your responsibility towards your dreams and aspirations. Training and certification do affect your profession undoubtedly in terms of financial benefits too. Not to mention, this will also showcase your dedication towards your dream and aspirations.

So, do not doubt your worth, buckle up!  Gear yourself up with all the resources, along with proper use of your time. With these resources, the 70-466 exam is entirely achievable.

So, take your career to the next level!

Continue reading

Static Data Masking for Azure SQL Database and SQL Server

The SQL Security team is pleased to share the public preview release of Static Data Masking. Static Data Masking is a data protection feature that helps users sanitize sensitive data in a copy of their SQL databases.

Use cases

Static Data Masking is designed to help organizations create a sanitized copy of their databases where all sensitive information has been altered in a way that makes the copy sharable with non-production users. Static Data Masking can be used for:

◈ Development and testing

◈ Analytics and business reporting

◈ Troubleshooting

◈ Sharing the database with a consultant, a research team, or any third-party

Static Data Masking facilitates compliance with security requirements such as the separation between production and dev/test environments. For organizations subject to GDPR, the feature is a convenient tool to remove all personal information while preserving the structure of the database for further processing.

How Static Data Masking works

With Static Data Masking, the user configures how masking operates for each column selected inside the database. Static Data Masking will then replace data in the database copy with new, masked data generated according to that configuration. Original data cannot be unmasked from the masked copy. Static Data Masking performs an irreversible operation.

In the example below, all entries in the column FirstName have been nullified. The column LastName is made of randomly generated strings. In the EmailAddress column, names have been replaced with randomly generated strings, but the domain extension has been maintained. A similar narrative applies to the Phone column where the area code has been preserved, but not the last 7 digits.

Static Data Masking vs. Dynamic Data Masking

Data masking is the process of applying a mask on a database to hide sensitive information and replace it with new data or scrubbed data. Microsoft offers two masking options, Static Data Masking and Dynamic Data Masking

Static Data Masking	Dynamic Data Masking
Happens on a copy of the database Original data not retrievable Mask occurs at the storage level All users have access to the same masked data	Happens on the original database Original data intact Mask occurs on-the-fly at query time Mask varies based on user permission

How to download Static Data Masking

Static Data Masking ships with SQL Server Management Studio 18.0. The latest preview SQL Server Management Studio 18.0 is available today for download.

Compatibility

Static Data Masking is compatible with SQL Server (SQL Server 2012 and newer), Azure SQL Database (DTU and vCore-based hosting options, excluding Hyperscale), and SQL Server on Azure Virtual Machines.

Continue reading

Introducing SQL Information Protection for Azure SQL Database and on-premises SQL Server!

We are delighted to announce the public preview of SQL Information Protection, introducing advanced capabilities built into Azure SQL Database for discovering, classifying, labeling, and protecting the sensitive data in your databases. Similar capabilities are also being introduced for on-premises SQL Server via SQL Server Management Studio.

Discovering and classifying your most sensitive data, including business, financial, healthcare, and PII, can play a pivotal role in your organizational information protection stature. It can serve as infrastructure for:

◈ Helping meet data privacy standards and regulatory compliance requirements, such as GDPR.
◈ Data-centric security scenarios, such as monitoring (auditing) and alerting on anomalous access to sensitive data.
◈ Controlling access to and hardening the security of databases containing highly sensitive data.

What is SQL Information Protection?

SQL Information Protection (SQL IP) introduces a set of advanced services and new SQL capabilities, forming a new information protection paradigm in SQL aimed at protecting the data, not just the database:

◈ Discovery and recommendations – The classification engine scans your database and identifies columns containing potentially sensitive data. It then provides you an easy way to review and apply the appropriate classification recommendations via the Azure portal.

◈ Labeling – Sensitivity classification labels can be persistently tagged on columns using new classification metadata attributes introduced into the SQL engine. This metadata can then be utilized for advanced sensitivity-based auditing and protection scenarios.

◈ Monitoring/Auditing – Sensitivity of the query result set is calculated in real time and used for auditing access to sensitive data (currently in Azure SQL DB only).

◈ Visibility - The database classification state can be viewed in a detailed dashboard in the portal. Additionally, you can download a report, in Excel format, to be used for compliance and auditing purposes, as well as other needs.

Additional SQL IP capabilities will continue rolling out throughout 2018 – Stay tuned!

How does SQL Information Protection work?

We designed SQL IP with the goal of streamlining the process of discovering, classifying, and labeling sensitive data in your database environment.

Our built-in automated classification engine identifies columns containing potentially sensitive data, and provides a list of classification recommendations, which can be easily applied as sensitivity metadata on top of columns, using new column sensitivity attributes that have been added to the SQL engine. You can also manually classify and label your columns.

Once you classify and label your data, our detailed overview dashboard provides you visibility into the classification state of your database, as well as the ability to export and download a classification report in Excel format:

Once you classify and label your data, our detailed overview dashboard provides you visibility into the classification state of your database, as well as the ability to export and download a classification report in Excel format:

Continue reading

Migrating to Azure SQL Database with zero downtime for read-only workloads

Microsoft uses an internally written service called MSAsset to manage all Microsoft data center hardware around the world. MSAsset is used for tracking Microsoft’s servers, switches, storage devices, and cables across the company and requires 24/7 availability to accommodate break-fix requirements.

Before migrating to Azure SQL Database last year, MSAsset’s data tier consisted of a 107 GB database with 245 tables on SQL Server. The database was part of a SQL Server Always On Availability Group topology used for high availability and the scaling out of read-activity.

The MSAsset engineering team faced the following issues:

◈ Aging hardware was not keeping up with stability and scale requirements.
◈ There was an increase in high severity data-tier incidents and no database administrator on staff to help with troubleshooting, mitigation, root cause analysis and ongoing maintenance.
◈ MSAsset’s database ran on SQL Server 2012. Developers and internal customers were increasingly requesting access to new SQL Server functionality.

After exploring various options and weighing several factors, the MSAsset engineering team decided that Azure SQL Database was the appropriate data tier for their future investment and would address all of their key pain points. With the move to Azure SQL Database, they gained increased scalability, built-in manageability and access to the latest features.

With 24/7 availability requirements, the engineering team needed to find a way to migrate from SQL Server to Azure SQL Database without incurring downtime for read-only activity. MSAsset is a read-heavy service, with a much smaller percent of transactions involving data modifications. Using a phased approach, they were able to move to Azure SQL Database with zero downtime for read-only traffic and less than two hours of down time for read-write activity. This case study will briefly describe how this was accomplished.

The original MSAsset architecture

The original MSAsset application architecture consisted of a web tier with read-write access to the primary database located on a SQL Server 2012 instance. The database was contained within an Always On Availability Group with one synchronous read-only secondary replica and three read-only asynchronous secondary replicas. The application used an availability group listener to direct incoming write traffic to the primary replica. To accommodate the substantial amount of read-only reporting traffic, a proprietary load balancer was used to direct requests across the read-only secondary replicas using a round-robin algorithm.

When planning for a move to Azure SQL Database as with the legacy SQL Server solution, the proposed new solution needed to accommodate one read-write database and depending on the final migrated workload volume and associated Azure SQL Database resource consumption one or more read-only replicas.

Using a phased migration approach

The MSAsset engineering team used a phased incremental approach for moving from SQL Server to Azure SQL Database.  This incremental approach helped reduce the risk of project failure and allowed the team to learn and adapt to the inevitable unexpected variables that arise with complex application migrations.

The migration phases were as follows:

1. Configure hybrid SQL Server and Azure SQL Database read-only activity, while keeping all read-write activity resident on the legacy SQL Server database.

◈ Set up transactional replication from SQL Server to Azure SQL Database, for use in accommodating read-only activity.

◈ Monitor the replication topology for stability, performance, and convergence issues. 

◈ As needed, create up to four active geo-replication readable secondary databases in the same region to accommodate read-only traffic scale requirements.

◈ Once it is confirmed the topology is stable for a sustained period of time, use load-balancing to direct read-only activity to Azure SQL Database, beginning with 25 percent of the read-only traffic. Over a period of weeks, increase to 50 percent, and then 75 percent. For load balancing, the MSAsset engineering team uses a proprietary application-layer library.

◈ Along the way, use Query Performance Insight to monitor overall resource consumption and top queries by CPU, duration, execution count. MSAsset also monitored application metrics, including API latencies and error rates.

◈ Adjust the Azure SQL Database service tiers and performance levels as necessary.

◈ Move or redirect any high-resource consuming unnecessary legacy traffic to bulk access endpoints.

2. After stabilizing in the prior phase of 75 percent read-only activity on Azure SQL Database, move 100 percent of the read-only traffic to Azure SQL Database.

◈ Again, use Query Performance Insight to monitor overall resource consumption and top queries by CPU, duration, execution count. Adjust the Azure SQL Database service tiers and performance levels as necessary and create up to four active geo-replication readable secondary databases in the same region to accommodate read-only traffic.

3. Prior to the final cut-over to Azure SQL Database, develop and fully test a complete rollback plan. The MSAsset team used SQL Server Data Tools (SSDT) data comparison functionality to collect the delta between Azure SQL Database and a  four day old backup and then applied the delta to the SQL Server database.

4. Lastly, move all read-write traffic to Azure SQL Database. In MSAsset’s case, in preparation for the final read-write cutover they reseeded, via transactional replication a new database in Azure SQL Database for read-write activity moving forward. Steps they followed:

5. After the full reseeding, wait for remaining transactions on SQL Server to drain before removing the transactional replication topology.

6. Change the web front-end configuration to use the Azure SQL Database primary database for all read-write activity. Use read-only replicas for read-only traffic.

7. After a full business cycle of monitoring, de-commission the SQL Server environment.

This phased approach allowed the MSAsset team to incur no downtime for read-only activity and also helped them minimize risk, allowing enough time to learn and adapt to any unexpected findings without having to revert to the original environment. 

The final MSAsset architecture uses one read-write Azure SQL Database replica and four active geo-replication readable secondary databases. 

The remaining sections will talk about key aspects and lessons learned from the migration effort.

Creating a read-only Azure SQL Database using Transactional Replication

The first phase involved setting up transactional replication from SQL Server to Azure SQL Database, ensuring a stable replication topology with no introduced performance or convergence issues. 

The MSAsset engineering team used the following process for setting up transactional replication:

◈ They first reviewed the existing SQL Server database against the requirements for replication to Azure SQL Database. These requirements are detailed in the Replication to SQL Database documentation. For example, a small number of the legacy tables for MSAsset did not have a primary key, and so a primary key had to be added in order to be supported for transactional replication. Some of the tables were no longer being used, and so it was an opportunity to clean up stale objects and associated code.

◈ Since the MSAsset publication was hosted on an Always On Availability Group, the MSAsset team followed the steps detailed here for configuration transactional replication: Configure Replication for Always On Availability Groups (SQL Server).

Once transactional replication was configured and fully synchronized, read-only traffic was first directed to both SQL Server and Azure SQL Database with read-write activity continuing to go just against the SQL Server-resident database.

The read-only traffic against Azure SQL Database was incrementally increased over time to 25 percent, 50 percent, and 75 percent, with careful monitoring along the way to ensure sufficient query performance and DTU availability. The MSAsset team used a proprietary load balancing application library to distribute load across the various read-only databases. Once stabilized at 75 percent, the MSAsset team moved 100 percent of read-only activity to Azure SQL Database and continued with the other phases described earlier.

Cleanup opportunities

The MSAsset team also used this as an opportunity to clean up rogue reporting processes. This included in-house Microsoft reporting tools and applications that, while being permitted to access the database had other data warehouse options that were more appropriate for ongoing use than MSAsset. When encountering rogue processes, the MSAsset team reached out to the owners and had them re-route to appropriate data stores. Disused code and objects, when encountered, were also removed.

Redesigning around compatibility issues

The MSAsset team discovered two areas that required re-engineering prior to migration to Azure SQL Database:

◈ Change Data Capture (CDC) was used for tracking data modifications on SQL Server. This process was replaced with a solution that leverages temporal tables instead.

◈ SQL Server Agent Jobs were used for executing custom T-SQL scheduled jobs on SQL Server. All SQL Server Agent Jobs were replaced with Azure worker roles that invoked equivalent stored procedures instead.

Understanding networking and connectivity with Azure SQL Database

With an array of services requiring access to MSAsset’s data tier, the engineering team had to familiarize themselves with Azure SQL Database networking and connectivity requirements as well as fundamentals. Having this background was a critical aspect of the overall effort and should be a core focus area of any migration plan to Azure SQL Database.

Modernizing the platform and unlocking cloud scalability

The original MSAsset SQL Server hardware was powerful, but old. Before moving to Azure SQL Database, the MSAsset engineering considered replacing the servers. But they were concerned about the projected cost and ability for the hardware to keep up with MSAsset’s projected workload growth over the next five years. The MSAsset engineering team was also concerned about keeping up with the latest SQL Server versions and having access to the latest features.

Moving to Azure SQL Database means that the MSAsset team can scale resources much more easily and no longer have to worry about outgrowing their existing hardware. They can also now access new features as they become available in Azure SQL Database without having to explicitly upgrade. They are also now able to leverage built-in capabilities unique to Azure SQL Database like Threat Detection and Query Performance Insight.

Reducing high severity issues and database management overhead

The MSAsset engineering team has no database administrator on staff, so coupled with the support of old hardware and standard DBA maintenance requirements, these factors were a major contributor to increasingly frequent high severity incidents.

Moving to Azure SQL Database, the MSAsset team no longer worries about ongoing database server patching, backups, or complex high availability and disaster recovery topology configuration. Since moving to Azure SQL Database, the MSAsset engineering team has seen an 80 percent reduction in high severity issues for their data tier.

Continue reading