SQL Server 2008, SQL Server 2005, SQL Server 2003, SQL Azure, Oracle Tutorials

Change page: < 1 2 3 4 5 6 7 8 9 10 11 > | Displaying page 6 of 11, items 151 to 180 of 308.

SQL Server 2008 R2 : Transaction Logging and the Recovery Process (part 1) - The Checkpoint Process

During recovery, SQL Server examines the transaction log for each database and verifies whether the changes reflected in the log are also reflected in the database. In addition, it examines the log to determine whether any data changes that were written to the data were caused by a transaction that didn’t complete before the system failure.

SQL Server 2008 R2 : Transactions and Locking, Coding Effective Transactions

SQL Server issues and holds on to locks for the duration of a transaction to ensure the isolation and consistency of the modifications. Data modifications that occur within a transaction acquire exclusive locks, which are then held until the completion of the transaction.

Protecting SQL Server Data : HONEYCOMBING A DATABASE - Creating an Alert for Notification, Creating a Notification

Once the operator has been created, we are ready to create our Alert. An Alert monitors the database for events. When an event occurs, a notification is sent to the Operators that are assigned to the Alert.

Protecting SQL Server Data : HONEYCOMBING A DATABASE - Creating an Operator for Notification

The first step in creating a SQL Server alert is to create an Operator. An Operator is the person, or people, who will receive an alert when one is raised. We create an operator by executing the sp_add_operator system stored procedure in Management Studio.

My SQL : Logging Statements (part 7) - Nontransactional Changes and Error Handling

A specialty of MySQL is the provisioning of nontransactional storage engines. This can offer some speed advantages, since the storage engine does not have to administer the transactional log that the transactional engines use, and it allows some optimizations on disk access.

My SQL : Logging Statements (part 6) - Stored Functions

Stored functions share many similarities with stored procedures and some similarities with triggers. Similar to both stored procedures and triggers, stored functions have a DEFINER clause that is normally (but not always) used when the CREATE FUNCTION statement is written to the binary log.

My SQL : Logging Statements (part 5) - Stored Procedures

Stored functions, stored procedures, and events are known by the common name stored routines. Since the server treats stored procedures and stored functions very differently, stored procedures will be covered in this section and stored functions in the next section.

My SQL : Logging Statements (part 4) - Triggers, Events, and Stored Routines

A few other constructions that are treated specially when logged are stored programs—that is, triggers, events, and stored routines (the last is a collective name for stored procedures and stored functions).

My SQL : Logging Statements (part 3) - Binary Log Filters

It is possible to filter out statements from the binary log using two options: binlog-do-db and binlog-ignore-db (which we will call binlog-*-db collectively).

My SQL : Logging Statements (part 2) - LOAD DATA INFILE Statements

The LOAD DATA INFILE statement makes it easy to fill tables quickly from a file. Unfortunately, it is dependent on a certain kind of context that cannot be covered by the context events we have discussed: files that need to be read from the filesystem.

My SQL : Logging Statements (part 1) - Logging Queries

For statement-based replication, the most common binlog event is the Query event, which is used to hold a statement executed on the master. In addition to the actual statement executed, the event contains some additional information necessary for execution of the statement.

My SQL : The Binary Log - Structure of the Binary Log

Conceptually, the binary log is a sequence of binary log events (also called binlog events or even just events when there is no risk of confusion). The binary log actually consists of several files, as shown in Figure 1, that together form the binary log.

Oracle Database 11g : Connecting to Oracle - Use the Oracle Net Listener

The Oracle Net Listener (listener) listens on a network port (listening endpoints) for incoming database requests. A listening endpoint defines the protocol addresses the listener is defined to listen on. L

Oracle Database 11g : Connecting to Oracle - Define Connections

A connect descriptor is used to define the service name and the location of the database. The address component of a connect descriptor defines the protocol, host name, and port number.

SQL Server 2008 R2 : Transactions and Triggers (part 2) - Triggers and Multistatement Transactions, Using Savepoints in Triggers

Although BEGIN TRAN statements are not recommended within a trigger, you can set a savepoint in a trigger and roll back to the savepoint. This technique rolls back only the operations within the trigger subsequent to the savepoint.

SQL Server 2008 R2 : Transactions and Triggers (part 1) - Triggers and Transaction Nesting

SQL Server 2008 provides two types of Data Manipulation Language (DML) triggers: AFTER and INSTEAD OF. INSTEAD OF triggers perform their actions before any modifications are made to the actual table the trigger is defined on.

SQL Server 2008 R2 : Transactions and Stored Procedures

Because SQL code in stored procedures runs locally on the server, it is recommended that entire transactions be completely encapsulated within stored procedures to speed transaction processing.

Protecting SQL Server Data : HONEYCOMBING A DATABASE - Creating a Database Audit Specification, Reviewing the Windows Application Log

A Database Audit Specification is a member of the Server Audit and collects specific information about the database-level events on which the Server Audit reports. The CREATEDATABASEAUDITSPECIFICATION method is executed in SSMS to create a Database Audit Specification.

Protecting SQL Server Data : HONEYCOMBING A DATABASE - Implementing a Honeycomb Table, Creating a Server Audit

In order to capture the activity of would-be data thieves on our honeycomb table, we need to implement the auditing feature of SQL Server 2008. The first step in this process is to create a ServerAudit object, which allows us to monitor a collection of actions that might occur on the target table, and record this activity in a file, typically the Windows Application log file.

Protecting SQL Server Data : LAYERING SOLUTIONS

At the highest level, we would want to consider the protection of our database files, including the database backups. In the SQL Server 2005 world, native options for protecting our physical database files, transaction logs and TempDB system database are non-existent.

MySQL for Python : Simple Insertion - Changing insertion values dynamically

Just because user input is not valid, it does not mean we should scrap it and ask the user for a new input. Rather, we can accept an entire statement, assign what values will fit and come back to the user to correct data that will not.

MySQL for Python : Simple Insertion - Using metadata

On February 23, 2006, an American B-2 bomber crashed shortly after take-off in Guam due to bad data being fed to the airplane's flight control computers. A lack of data checking resulted in the loss of a $2.1 billion plane. As with any user interaction in programming, it is foolish to trust data without validating its integrity first.

SQL Server : Enforcing Data Integrity in Constraints (part 4) - Problems with UDFs wrapped in CHECK constraints

Some complex business rules are difficult or impossible to implement via regular constraints. In such cases, it seems intuitive to develop a scalar UDF and wrap it in a CHECK constraint.

SQL Server : Enforcing Data Integrity in Constraints (part 3) - Understanding disabled, enabled, and trusted constraints

Note that only CHECK constraints and FOREIGN KEY constraints can be disabled. Under the hood PRIMARY KEY and UNIQUE constraints are implemented as UNIQUE indexes. As such, neither PRIMARY KEY nor UNIQUE constraints can be disabled, and will always be trusted.

SQL Server : Enforcing Data Integrity in Constraints (part 2) - Foreign key constraints and NULLs

It is a common misconception that foreign keys always prevent orphan rows, that is, rows in the child table that do not have corresponding rows in the parent table. In fact, if the columns involved in the foreign key constraint are nullable, then we may have orphan rows.

SQL Server : Enforcing Data Integrity in Constraints (part 1) - Handling nulls in CHECK constraints

Logical conditions in CHECK constraints work differently from logical conditions in the WHERE clause. If a condition in a CHECK constraint evaluates to "unknown," then the row can still be inserted, but if a condition in a WHERE clause evaluates to "unknown," then the row will not be included in the result set.

SQL Server : Common Problems with Data Integrity - Enforcing Data Integrity in the Application Layer

At some later point, we are asked to develop a query that returns all the boxes with at least one dimension that is greater than 4 inches. With our new business rule in place we know that the longest dimension of any box is the length, so all we have to do in our query is check for boxes with a length of more than 4 inches.

Oracle Coherence 3.5 : Implementing object serialization (part 3) - PortableObject or PofSerializer, Collection serialization with POF

One of the reasons you should choose custom PofSerializer implementation is what we discussed previously—when you have complex creational logic for your objects and need to have complete control over their instantiation.

Oracle Coherence 3.5 : Implementing object serialization (part 2) - Implementing serialization code

The methods defined by the PortableObject interface return no value and accept a single argument that allows us to read the indexed attributes from the POF stream, in the case of readExternal, or to write attributes into the POF stream in writeExternal.

Oracle Coherence 3.5 : Implementing object serialization (part 1) - POF basics, POF context

POF is an extremely compact, platform-independent binary serialization format. It can be used to serialize almost any Java, .NET, or C++ object into a POF value.