In case of database development, in the same way as for the application development, there are always tasks such as developing a new feature, fixing bugs from the current release, experimenting with code in order to improve performance, usability in any way and so on. Because of all of this, it is essential that any changes that have to be committed, but not immediately, are segregated to an isolated environment, that does not affect the rest of the team or the main code. For instance, when developing a new feature, it may require a lot of changes to be committed, before the feature, or even a functional part of the feature becomes useful, so the rest of the team can apply it on their local copies of a database. Without having the isolation while developing, the team will lack the freedom to code, without having to worry about breaking the existing code base.
In the third part of the continuous integration aka “CI” workflow, the Test step will be described. After the second Build step is successfully finished where a new database is built directly from latest changes in source control, the Test step is initiated. In this step, a built database from the source control repository will be populated with data (both static and transactional), created unit tests will be run, and once all of them are executed, feedback of success/failure will be provided to developers.
DBAs often find themselves tasked with creating custom SQL Server performance counters to meet the increasing complexity of their environments and monitoring requirements.
The AlwaysOn Availability Group was introduced as a new feature in the SQL Server 2012 Enterprise edition, and is designed to ensure a more advanced and reliable option for SQL Server high availability and disaster recovery.
To be in compliance means to be conforming to a specific set of regulations, standards, policies or laws. Many countries worldwide have specific laws or regulations which are imposed to companies and organizations which they have to follow in order to satisfy specific standards or rules – to be and remain in compliance. Organizations that use SQL Server databases to store customer data and other information abide to the compliance requirements. Additionally, even those organizations that are not subject to compliance regulations or laws need to fulfill their own organization policies, hence they tend to introduce their own compliance regulative.
ApexSQL Doc is a tool that is used for SQL Server database documentation as well as SSIS packages, SSRS reports and SSAS cubes. With ApexSQL Doc it’s possible to specify the exact server objects, attributes, database objects and specific object instances that can be generated in the documentation.
One of the main tasks for every database administrator is creating a reliable disaster recovery plan. The plan always includes multiple backup and restore operations. Usually, opting for conventional, single file backups should suffice, but in some cases, resources like disk space, backup time, or both could be the issue. This is usually the case when working with large databases.
One of the most important tasks for any database administrator is to create a foolproof disaster recovery plan. This plan usually includes multiple backup and restore operations. Most of the time, opting for conventional backups should suffice, but in some cases, storing all backups on a single backup device may prove to be a bad idea. As the databases grow with time, the backups become larger, and backup devices less stable due to frequent read/write operations. If the backup device fails, all of the backed up data might be lost. To avoid this scenario, some administrators take multiple copies of their backup files, and store them on different backup devices. There are a few ways to do this:
SQL snippets can be a big boost to productivity when writing T-SQL. First, to use a SQL snippet in a script you do not need to know the syntax, only the purpose of that SQL snippet (e.g. Delete an object, Create a table, etc.). Using snippets also reduces of the lines of code that has to be typed, and thus decreases the potential for errors that could occur from typing.
One of the challenges these days is how to pull the latest changes (of SQL objects) from the source control repository and deploy them into a SQL database. This process is particularly helpful in the CI workflow Build step, when developers want to build a SQL database from the committed changes in the source control repository, so they can test if their changes compromised SQL objects from the source control repository or they will be built successfully.