|
|
| SQL server 2008 : Managing Security - Users |
| Users are database-level principals that are created in order to access resources within a database. Database Users are typically mapped to a login, certificate, or asymmetric key.
|
|
| SQL server 2008 : Managing Security - Roles |
| Like Windows groups, SQL Server provides two roles, server- and database-level roles into which logins and users can be added. Server-level roles are fixed roles that have a serverwide permission scope. Each built-in role serves a specific purpose and have the required permissions associated with them.
|
|
| SQL Server 2008 : Managing Remote Servers |
| Remember that remote servers are supported in SQL Server 2008 for backward compatibility only. (Remote servers are being deprecated!) By definition, a remote server is a server you access as part of a client process without opening a separate, distinct, and additional direct client connection. SQL Server can manage the communication between servers using Remote Procedure Calls (RPCs).
|
|
| Linked Servers |
| All these configuration options can also be done very easily with SQL Server Management Studio. The following sections occasionally describe that capability but focus on the SQL commands method because you will usually use this method in real-life production systems.
|
|
| Adding, Dropping, and Configuring Linked Servers |
| All these configuration options can also be done very easily with SQL Server Management Studio. The following sections occasionally describe that capability but focus on the SQL commands method because you will usually use this method in real-life production systems.
|
|
| Mapping Local Logins to Logins on Linked Servers |
| For a user to gain access to a linked server, the linked server must validate the user for security reasons. The requesting server (that is, the local server) provides a login name and password to the linked server on behalf of the local server user
|
|
|
|
|
|
|
|
| Encryption basics for SQL Server : Cryptographic Keys |
| The main character on the cryptographic stage is the key. A key contains the algorithm, the sequences of instructions which is used in the various cryptographic functions that SQL Server provides to encrypt and decrypt data.
|
|
| Encryption basics for SQL Server : Key Maintenance |
| Cryptographic keys and passwords that protect keys are not a "set-it-and-forgetit" feature of securing sensitive data; they require periodic maintenance to ensure that the items that are protected remain at their highest level of security.
|
|
| Encryption basics for SQL Server : Key Algorithms |
| Keys use a set of instructions that dictate how their cryptographic functions are to be performed. These instructions are called algorithms. There are several algorithms available in SQL Server and selecting the optimal algorithm can be a daunting task, with the high complexity of the mathematical equations that define these algorithms simply adding to the challenge
|
|
| SQL Server 2005 : Performing Database Backups |
| Backups are an important part of any maintenance strategy. In a SQL Server 2005 environment, you can perform backups through the SQL Server Management Studio interface, by using T-SQL code, by using a customized application, or via third-party tools.
|
|
| SQL Server 2005 : Restoring Data from a Backup |
| When disasters occur and you need to get the data back to a known state, you need to perform a restore operation. At other times, you might want to restore data, such as when preparing for log shipping or copying data from one server to another. You can also use the RESTORE command to validate backups or read the catalog information from an existing media set.
|
|
| SQL Server 2005 : Using Database Snapshots |
| Database snapshots, which are new in SQL Server 2005, are available only in the Enterprise Edition. All recovery models previously discussed support the use of database snapshots. A database snapshot is a read-only, static view of a database captured at a specific time
|
|
| SQL Server 2005 : Automating Maintenance with Job Scheduling |
| Many of the maintenance features discussed so far in this chapter are important, but they can be time-consuming. However, that doesn’t necessarily have to be the case. Essentially any task that can be performed from SQL Server Management Studio or through the use of a T-SQL query can be automated through the creation of a job or a schedule.
|
|
|
|
|
|
| SQL Server 2005 : Managing XML Data (part 1) |
| In general, XML is a data storage format that can be used to define and store data. An XML document is a data storage medium that lays out the data into elements and attributes in much the same way that a database has rows and columns
|
|
| SQL Server : Removing Unwanted Data |
| Over time, data becomes obsolete and needs to be removed. You remove data by using the DELETE statement. It is extremely important to provide a condition when performing data deletions because it is easy to remove all data if you do not exercise caution.
|
|
| SQL Server : Changing What Is Already Stored |
| You alter data through the use of UPDATE. Just as with the input of data, any alterations made to the data are subject to the rules and constraints defined in the table schema. Any data modifications made that do not meet these defined standards result in errors that the front-end application may have to trap and control.
|
|
| Using System Tables and Views |
| SQL Server tracks information and maintains data about every object in the system. This information is maintained in system tables that can be queried like any other tables
|
|
|
|
| SQL Dependency Reporting |
| Another issue that you face when administering SQL Server instances across an organization is determining object dependencies between servers and databases. If you have to make changes to objects in a database, it is hard to establish a list of items that may be affected (especially if the referencing objects are on another server)
|
|
| The Overall Disaster Recovery Process |
| In general, a handful of things need to be put together (that is, defined and executed upon) as the basis for an overall disaster recovery process or plan.
|
|
|
|
| How to Approach Disaster Recovery |
| Often, disaster recovery specialists refer to a seven-tier disaster recovery paradigm. These tiers start at the bottom of the disaster recovery food chain—Tier 0 (no offsite data—possibly no recovery) and progress up to the highest level of disaster recovery possible—Tier 7 (zero to near-zero data loss with highly automated recovery).
|
|
| SQL Server 2008 : Database Mirroring |
| The technique of database mirroring can be summed up very simply: It's the practice of keeping two separate copies of your database in synchronization with each other so that if you lose one copy, you can continue work with the other.
|
|
| Creating and Using a SQL Azure Database |
| Let’s start by creating a SQL Azure database and playing with it a bit. SQL Azure’s signup process and development experience are slightly different from the rest of the Windows Azure storage services.
|
|
