Carl Rosa Opera: The Pirates of Penzance

Saw a fantastic production of The Pirates of Penzance.

I like Musical and Gilbert and Sullivan is great fun - I know this has been out of fashion for some time but maybe it's on its way back!?

This production was fantastic, the costumes, the make-up, great comic timing, the orchestra and most of all the singing!

I think I first saw Gilbert and Sullivan aged 15, as an amateur production done at the local all girls private school (my mother taught physics their). I remember being really impressed - I think they teamed up with local boys private school. This was elite schooling at it best, teenagers doing something quite remarkable.

Today's production was cracking again - I was really impressed with the Carl Rosa Opera company! Mabel (lead soprano) trilled beautifully, a soaring wonderful voice. Samuel was sung by a well-rounded and deeply comfortable voice.

This is sung nearly perfectly by a very talented ensemble, complemented by some excellent individual performers, including two members of the original cast of Phantom of the Opera. Everyone sang well with brilliantly clear diction too, something so very necessary in getting across the full humour and cleverness of the lyrics. Rosie Ashe as pirate wench Ruth was superb, dexterously handling her exposition-heavy lyrics yet still hitting all the right comedic notes; Barry Clark’s Major General and Bruce Graham’s Police Sergeant were both nicely bumptious and Katy Batho impressed with a piercingly clear voice, hitting those top notes with a beautiful sound.

http://www.thepublicreviews.com/pirates-of-penzance-theatre-royal-brighton/

Music Hall - a most capacious form of performance

The following usage of capacious had me reaching for my dictionary:

It [Music Hall] was a most capacious form of performance - people would come up and perform a turn... acting, comedy, song...

I like the idea of free space it conveys!

It also makes me think of one favourite books - Tipping The Velvet by Sarah Waters. This is a wonderful tale of closeted Victorian society. I love the lesbian and gay characters, it is shocking in parts and deeply romantic too.

capacious |kəˈpā sh əs|

adjective

having a lot of space inside; roomy : she rummaged in her capacious handbag.

DERIVATIVES

capaciously |kəˈpeɪʃəsli| adverb

capaciousness |kəˈpeɪʃəsnəs| noun

ORIGIN early 17th cent.: from Latin capax, capac- ‘capable’ + -ious .

Another great tla film: Latter Days

This is a truly amazing gay love story. 100% drama, 100% romantic and 100% gay and so so sweet.

Not only is this a wonderful tail of true love with a very well paced plot but it has a serious side.. it is easier to forget the insanity and sinister side of religion.

I'm not sure why gay and lesbians are attract to spiritual movements? However I will be staying clear of the Mormons:

Having grown up a Mormon and grappled with the church's bigotry towards Blacks (they were not allowed to hold the church's priesthood when I was a member) -- I wasn't aware of the organizations policy of excommunicating gay men and women until after I left the church in 1966 -- (I was 20.) I was stunned when I learned that friends who were gay were excommunicated even after serving on missions. LATTER DAYS exposes the Mormon's persecution of gay members. The film is LONG overdue. It does an excellent job of showing how the two lead males come to terms with one another, while managing to grow up and develop more fully as individuals. LATTER DAYS has great heart, wonderful original music and an added touch of class from Jacqueline Bisset. The film brilliantly tells the story of an individual who leaves behind the confines of organized religion and reclaims his very soul.

62 out of 75 people found the following review useful:
Heartwarming Story; Long Overdue, 22 November 2004

http://www.imdb.com/title/tt0345551/usercomments

Demotic Street Language - The Telegraph on the Money?

I stumbled across the following blog post, and while I rarely agree with The Telegraph's view on the world (rather to conservative/establishment-friendly for my taste), this "Telegraph blog post" makes a very interesting point/parallel:

Call me old-fashioned but should the Leader of Her Majesty’s Opposition in the run-up to an election (or at any other time for that matter) say that people are “gagging for change”? As we all know only too well, Dave has had the advantage of one of the finest educations money can buy. Is it too much to expect that somewhere along the way he may have acquired a vocabulary that would allow him to make a trenchant political point without reaching into the demotic depths?

http://blogs.telegraph.co.uk/news/davidhughes/100032397/demotic-dave-cameron-should-mind-his-language-and-remember-kinnock/

I like his usage of the term demotic - 100% correct but a very old fashioned formal term for Street Language.

I think politician should avoid try to be cool or expressing too much emotion, they will need to stay calm and focused under intense pressure, winning the general election is only the beginning not the finish line!

demoticadjectiveKnox picked up her demotic style of writing when she worked for a newspaper in Madison popular, vernacular, colloquial, idiomatic, vulgar, common;informal, everyday, slangy. antonym formal.

70-432 : Fixed server and database roles

For the 70-432 exam you must understand the difference between the server and the database within the server.

You will need to under the fixed server-level and fixed database-level plus the associated stored procedures.

I found the following very useful summary:

Fixed server roles: These are server-wide roles. Logins can be added to these roles to gain the associated administrative permissions of the role. Fixed server roles cannot be altered and new server roles cannot be created. Here are the fixed server roles and their associated permissions in SQL Server 2000:

Fixed server role	Description
sysadmin	Can perform any activity in SQL Server
serveradmin	Can set server-wide configuration options, shut down the server
setupadmin	Can manage linked servers and startup procedures
securityadmin	Can manage logins and CREATE DATABASE permissions, also read error logs and change passwords
processadmin	Can manage processes running in SQL Server
dbcreator	Can create, alter, and drop databases
diskadmin	Can manage disk files
bulkadmin	Can execute BULK INSERT statements

Here is a list of stored procedures that are helpful in managing fixed server roles:

sp_addsrvrolemember	Adds a login as a member of a fixed server role
sp_dropsrvrolemember	Removes an SQL Server login, Windows user or group from a fixed server role
sp_helpsrvrole	Returns a list of the fixed server roles
sp_helpsrvrolemember	Returns information about the members of fixed server roles
sp_srvrolepermission	Returns the permissions applied to a fixed server role

Fixed database roles: Each database has a set of fixed database roles, to which database users can be added. These fixed database roles are unique within the database. While the permissions of fixed database roles cannot be altered, new database roles can be created. Here are the fixed database roles and their associated permissions in SQL Server 2000:

Fixed database role	Description
db_owner	Has all permissions in the database
db_accessadmin	Can add or remove user IDs
db_securityadmin	Can manage all permissions, object ownerships, roles and role memberships
db_ddladmin	Can issue ALL DDL, but cannot issue GRANT, REVOKE, or DENY statements
db_backupoperator	Can issue DBCC, CHECKPOINT, and BACKUP statements
db_datareader	Can select all data from any user table in the database
db_datawriter	Can modify any data in any user table in the database
db_denydatareader	Cannot select any data from any user table in the database
db_denydatawriter	Cannot modify any data in any user table in the database

Here is a list of stored procedures that are helpful in managing fixed database roles:

sp_addrole	Creates a new database role in the current database
sp_addrolemember	Adds a user to an existing database role in the current database
sp_dbfixedrolepermission	Displays permissions for each fixed database role
sp_droprole	Removes a database role from the current database
sp_helpdbfixedrole	Returns a list of fixed database roles
sp_helprole	Returns information about the roles in the current database
sp_helprolemember	Returns information about the members of a role in the current database
sp_droprolemember	Removes users from the specified role in the current database

http://vyaskn.tripod.com/sql_server_security_best_practices.htm

Another blog which also covers the above is http://articles.techrepublic.com.com/5100-10878_11-1061781.html. This article had the advantage of several screenshots show how to administer security via SQL Server Management Studio (SSMS) but I just don't like an example where you allocate db_accessadmin to guest - this is just to counter intuitive!

70-432 : Index usage (sys.dm_db_index_usage_stats)

This blog article is aimed at people preparing for 70-432 exam.

This DMV is particularly useful and represents one area where SQLServer appears to be ahead of te Oracle database engine (there is no easy to see which indexes have not been used in the last day / week / month ...)

Starting with the msdn documentation for dm_db_index_usage_stats:

sys.dm_db_index_usage_stats (Transact-SQL)

Returns counts of different types of index operations and the time each type of operation was last performed.

Column name	Data type	Description
database_id	smallint	ID of the database on which the table or view is defined.
object_id	int	ID of the table or view on which the index is defined
index_id	int	ID of the index.
user_seeks	bigint	Number of seeks by user queries.
user_scans	bigint	Number of scans by user queries.
user_lookups	bigint	Number of bookmark lookups by user queries.
user_updates	bigint	Number of updates by user queries.
last_user_seek	datetime	Time of last user seek
last_user_scan	datetime	Time of last user scan.
last_user_lookup	datetime	Time of last user lookup.
last_user_update	datetime	Time of last user update.
system_seeks	bigint	Number of seeks by system queries.
system_scans	bigint	Number of scans by system queries.
system_lookups	bigint	Number of lookups by system queries.
system_updates	bigint	Number of updates by system queries.
last_system_seek	datetime	Time of last system seek.
last_system_scan	datetime	Time of last system scan.
last_system_lookup	datetime	Time of last system lookup.
last_system_update	datetime	Time of last system update.

Remarks

Every individual seek, scan, lookup, or update on the specified index by one query execution is counted as a use of that index and increments the corresponding counter in this view. Information is reported both for operations caused by user-submitted queries, and for operations caused by internally generated queries, such as scans for gathering statistics.

The user_updates counter indicates the level of maintenance on the index caused by insert, update, or delete operations on the underlying table or view. You can use this view to determine which indexes are used only lightly by your applications. You can also use the view to determine which indexes are incurring maintenance overhead. You may want to consider dropping indexes that incur maintenance overhead, but are not used for queries, or are only infrequently used for queries.

The counters are initialized to empty whenever the SQL Server (MSSQLSERVER) service is started. In addition, whenever a database is detached or is shut down (for example, because AUTO_CLOSE is set to ON), all rows associated with the database are removed.

When an index is used, a row is added to sys.dm_db_index_usage_stats if a row does not already exist for the index. When the row is added, its counters are initially set to zero.

http://msdn.microsoft.com/en-us/library/ms188755.aspx

Now the following is a good blog post with an example of how this works in practice and also when you should be checking index usage stats. Not only does the following provide a nice simple of example of usage of the DMV sys.dm_db_index_usage_stats but it also makes a good point about focusing your attention and efforts on defragmentating the key indexes with high usage stats (it is too easy to get side tracked by problems where you can see something is clearly wrong, but you aren't necessarily tackling the key performance problems) :

Whenever I’m discussing index maintenance, and specifically fragmentation, I always make a point of saying ‘Make sure the index is being used before doing anything about fragmentation’.

If an index isn’t being used very much, but has very low page density (lots of free space in the index pages), then it will be occupying a lot more disk space than it could do and it may be worth compacting (with a rebuild or a defrag) to get that disk space back. However, usually there’s not much point spending resources to remove any kind of fragmentation when an index isn’t being used. This is especially true of those people who rebuild all indexes every night or every week.

...

If you're interested in whether an index is being used, you can filter the output. Let's focus in on a particular table - AdventureWorks.Person.Address.

SELECT * FROM sys.dm_db_index_usage_stats

WHERE database_id = DB_ID('AdventureWorks')

and object_id = OBJECT_ID('AdventureWorks.Person.Address');

GO

You'll probably see nothing in the output, unless you've been playing around with that table. Let's force the clustered index on that table to be used, and look at the DMV output again.

SELECT * FROM AdventureWorks.Person.Address;

GO

SELECT * FROM sys.dm_db_index_usage_stats

WHERE database_id = DB_ID('AdventureWorks')

and object_id = OBJECT_ID('AdventureWorks.Person.Address');

GO

Now there's a single row, showing a scan on the clustered index. Let's do something else.

SELECT StateProvinceID FROM AdventureWorks.Person.Address

WHERE StateProvinceID > 4 AND StateProvinceId <>

GO

SELECT * FROM sys.dm_db_index_usage_stats

WHERE database_id = DB_ID('AdventureWorks')

and object_id = OBJECT_ID('AdventureWorks.Person.Address');

GO

And there's another row, showing a seek in one of the table's non-clustered indexes.

http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/20/how-can-you-tell-if-an-index-is-being-used.aspx

70-432 : Locks and Latchs (sys.dm_db_index_operational_stats)

This blog article is aimed at people preparing for 70-432 exam.

The MCTS 70-432 exams introduces some of the dynamic management views (DMVs). I like the ideas of DMVs, as a seasoned Oracle DBA I know many of the key Oracle Instance and Database views well. Once of the advantages of having a SQL view (as opposed to a GUI tool) is that he DMV query can be scheduled to run periodically and log key columns over time (very important for a DBA).

Starting with the msdn documentation for dm_db_index_operational_stats we can that it can capture leaf DML operations plus lock and latch waits:

You can use sys.dm_db_index_operational_stats to track the length of time that users must wait to read or write to a table, index, or partition, and identify the tables or indexes that are encountering significant I/O activity or hot spots.

Use the following columns to identify areas of contention.

To analyze a common access pattern to the table or index partition, use these columns:

• leaf_insert_count
• leaf_delete_count
• leaf_update_count
• leaf_ghost_count
• range_scan_count
• singleton_lookup_count

To identify latching and locking contention, use these columns:

• page_latch_wait_count and page_latch_wait_in_ms
  These columns indicate whether there is latch contention on the index or heap, and the significance of the contention.
• row_lock_count and page_lock_count
  These columns indicate how many times the Database Engine tried to acquire row and page locks.
• row_lock_wait_in_ms and page_lock_wait_in_ms
  These columns indicate whether there is lock contention on the index or heap, and the significance of the contention.

To analyze statistics of physical I/Os on an index or heap partition

• page_io_latch_wait_count and page_io_latch_wait_in_ms
  These columns indicate whether physical I/Os were issued to bring the index or heap pages into memory and how many I/Os were issued.

Column Remarks

The values in lob_orphan_create_count and lob_orphan_insert_count should always be equal.

The value in the columns lob_fetch_in_pages and lob_fetch_in_bytes can be greater than zero for nonclustered indexes that contain one or more LOB columns as included columns. For more information, see Index with Included Columns. Similarly, the value in the columns row_overflow_fetch_in_pages and row_overflow_fetch_in_bytes can be greater than 0 for nonclustered indexes if the index contains columns that can be pushed off-row. For more information, see Row-Overflow Data Exceeding 8 KB.

How the Counters Are Reset

The data returned by sys.dm_db_index_operational_stats exists only as long as the metadata cache object that represents the heap or index is available. This data is neither persistent nor transactionally consistent. This means you cannot use these counters to determine whether an index has been used or not, or when the index was last used. For information about this, see sys.dm_db_index_usage_stats.

The values for each column are set to zero whenever the metadata for the heap or index is brought into the metadata cache and statistics are accumulated until the cache object is removed from the metadata cache. Therefore, an active heap or index will likely always have its metadata in the cache, and the cumulative counts may reflect activity since the instance of SQL Server was last started. The metadata for a less active heap or index will move in and out of the cache as it is used. As a result, it may or may not have values available. Dropping an index will cause the corresponding statistics to be removed from memory and no longer be reported by the function. Other DDL operations against the index may cause the value of the statistics to be reset to zero.

http://msdn.microsoft.com/en-us/library/ms174281(SQL.90).aspx

Next what is the difference between a lock and a latch? A lock (aka "enqueue") is a request for exclusive or shared owner of some data - a row,page or extent (a set of eight contiguous pages makes up an extent). Now for Oracle a latch is lock on an internal data structure in the SGA:

What is the difference between locks, latches, enqueues and semaphores?

A latch is an internal Oracle mechanism used to protect data structures in the SGA from simultaneous access. Atomic hardware instructions like TEST-AND-SET are used to implement latches. Latches are more restrictive than locks in that they are always exclusive. Latches are never queued, but will spin or sleep until they obtain a resource, or time out.

Enqueues and locks are different names for the same thing. Both support queuing and concurrency. They are queued and serviced in a first-in-first-out (FIFO) order.

Semaphores are an operating system facility used to control waiting. Semaphores are controlled by the following Unix parameters: semmni, semmns and semmsl. Typical settings are:

• semmns = sum of the "processes" parameter for each instance (see init.ora for each instance)
• semmni = number of instances running simultaneously;
• semmsl = semmns

http://www.orafaq.com/wiki/Oracle_database_Internals_FAQ#What_is_the_difference_between_locks.2C_latches.2C_enqueues_and_semaphores.3F

while for SQLServer a latch is often described as a "lightweight lock" and again is about protect internal database engine structures like buffers:

Tips for Using SQL Server Performance Monitor Counters

By : Brad McGehee Aug 24, 2005

A latch is in essence a "lightweight lock". From a technical perspective, a latch is a lightweight, short-term synchronization object (for those who like technical jargon). A latch acts like a lock, in that its purpose is to prevent data from changing unexpectedly. For example, when a row of data is being moved from the buffer to the SQL Server storage engine, a latch is used by SQL Server during this move (which is very quick indeed) to prevent the data in the row from being changed during this very short time period. This not only applies to rows of data, but to index information as well, as it is retrieved by SQL Server.

Just like a lock, a latch can prevent SQL Server from accessing rows in a database, which can hurt performance. Because of this, you want to minimize latch time.

SQL Server provides three different ways to measure latch activity. They include:

• Average Latch Wait Time (ms): The wait time (in milliseconds) for latch requests that have to wait. Note here that this is a measurement for only those latches whose requests had to wait. In many cases, there is no wait. So keep in mind that this figure only applies for those latches that had to wait, not all latches.
• Latch Waits/sec: This is the number of latch requests that could not be granted immediately. In other words, these are the amount of latches, in a one second period, that had to wait. So these are the latches measured by Average Latch Wait Time (ms).
• Total Latch Wait Time (ms): This is the total latch wait time (in milliseconds) for latch requests in the last second. In essence, this is the two above numbers multiplied appropriately for the most recent second.

When reading these figures, be sure you have read the scale on Performance Monitor correctly. The scale can change from counter to counter, and this is can be confusing if you don't compare apples to apples.

Based on my experience, the Average Latch Wait Time (ms) counter will remain fairly constant over time, while you may see huge fluctuations in the other two counters, depending on what SQL Server is doing.

http://www.sql-server-performance.com/tips/sql_server_performance_monitor_coutners_p3.aspx

To finish the following query looks useful, a good example of how to use the sys.dm_db_index_operational_stats view:

Tables where the most latch contention is occurring

select object_schema_name(ddios.object_id) + '.' + object_name(ddios.object_id) as objectName,
indexes.name, case when is_unique = 1 then 'UNIQUE ' else '' end + indexes.type_desc as index_type,
page_latch_wait_count , page_io_latch_wait_count
from sys.dm_db_index_operational_stats(db_id(),null,null,null) as ddios
join sys.indexes
on indexes.object_id = ddios.object_id
and indexes.index_id = ddios.index_id
order by page_latch_wait_count + page_io_latch_wait_count desc

http://sqlblog.com/blogs/louis_davidson/archive/2007/08/26/sys-dm-db-index-operational-stats.aspx