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:
Having a good recovery plan that ensures database backups are being taken on a regular basis and safely stored on specific or multiple storage drives greatly increases database safety and recovery options when a disaster or accident occurs. Nevertheless, creating regular full database backups doesn’t provide full point-in-time recovery, since restoring the latest full backup will restore a database to a proper state at the time a backup was created, but all changes, both schema and data, which have occurred after the last full backup will be practically lost.
SSAS is a powerful and popular feature in the SQL Server ecosystem. That’s why ApexSQL Doc has implemented support for automating SSAS cube documentation so you can have full documentation of your database in no time. We have created this article so you can see how easy it is to create an automated process which will generate documentation with ApexSQL Doc.
Wouldn’t it be a neat trick if you could document a database with a double click? With this article, we’ll demonstrate a few simple steps to allow you to make a script file which will run a process that generates documentation for your database. After that you can just execute it to repeat the process with just two mouse clicks or even set up a job to run it automatically every night. In this article you will learn how to create this automated process of database documentation by using ApexSQL Doc.
Imagine a scenario where you want to get your database into source control quickly and easily, including all schema objects and data from certain code tables that won’t change aka Static data. Then, once you have ported your database successfully to source control, to be able to update the repository nightly with any and all changed objects. In this way, you’ve fully and automatically source-controlled your database, without having to worry about direct integration, check ins, check outs etc. essentially providing much of the “gain” of database source control integration, with little of the “pain”. This article will describe how to build this “poor man’s” SQL database source control integration system using a 3rd party tool, ApexSQL Script
Recovering work after SQL Server Management Studio crashes
Imagine a situation of working in SSMS, and suddenly the power goes out, the system gets crashed, SSMS gets crashed or your work session was abruptly terminated for any other reason, which causes the loss of unsaved work on various SQL scripts. In this situation SSMS provide prompt dialog window for recovered data after restarting:
In this article we will explain how to create a simple batch file to automatically synchronize database schema changes with a source control repository from any individual objectchanges detected in the database.
Imagine if you could decrypt and pump all the wealth of transactional information and details contained in the SQL Server transaction log, in human readable format, and then store this as data directly in SQL Server tables, ensuring it wasn’t lost when the log was truncated, and such that data could be queried, reported on etc. using T-SQL.