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.
In this article, the second Build step of the CI workflow will be described. The Build step is a step in which a database is built using the latest changes in the source control repository and once the build process is finished, a feedback of success/failure is provided to developers.
More often than not, a top level requirement for all SQL Server DBAs is to have mechanisms to capture who changed what and when and to have stored audit information available for further investigation. In order to achieve this, database auditing needs to be set up using various mechanisms. One of those mechanisms is a trigger-based auditing.
This article will be about how to include Data model diagrams in the documentation generated by ApexSQL Doc. With this feature it’s possible to see graphically display database tables and their relationships.
Having a SQL database being version controlled locally, by storing all changes in a repository on a local machine can be quite handy. In the context of team based database development, it is necessary to establish the environment where changes can be tested locally, specific revisions reverted from the commit history, and doing such things before pushing changes to the remote repository where the rest of the team will be able to review them, and apply against a local database copy.
Performing regular database back-ups is a crucial part of any disaster recovery plan. There are many aspects that should be taken into consideration when planning long term backup strategies. It is necessary to choose the backup type and backup location and to plan how frequently to perform the backups. Additionally, the processes of verification or encryption could also be included into the plan.
Nowadays, it’s quite common that database changes are made several times a day and that a number of developers are making changes against the same database. Due to these often changes, a certain “process” has to be followed in order to avoid any potential problems in the later stages of development (Quality Assurance (QA), Staging, User Acceptance Test (UAT)) and at the end in production. When talking about the Continuous integration (CI) for SQL databases today, it’s often referred to a process of several steps:
The essence of each source control system is the ability to easily review the history of committed revisions. In addition, to comparing revisions, a user needs to get a specific revision and apply it against a database. Each revision should have a unique timestamp and should carry the information about the user who did the commit. Such system ensures that it is easy to determine who committed what and when, and in some way provide a complete auditing trail of committed revisions.
Running and maintaining multiple SQL Server instances can often be a formidable challenge, especially if these instances run on multiple servers. It is easy enough to set up a SQL Server agent job for each server to automate the backups, but what happens if there are 20, 30, or 100 servers that need maintenance? In this scenario, configuring agents on each server would take forever, and monitoring the entire setup would prove to be a nightmare for any administrator. Of course, there are several solutions for this scenario: