Date Archives November 2018
Intimacy
Intimacy is an intrusion into your lonely lifestyle, a bold invasion of your privacy often with your consent. It just happens to be a very pleasant invasion … most of the time. Intimacy happens when you cross paths with another species of being and find that your numerous plugs fit into their numerous sockets… at least most of them. Intimacy happens when you open up your sockets and extend you plugs to exchange soul by giving and receiving.
Intimacy is an invasion. There are no more gates with this significant other. There are no more barriers. There is so much discomfort in tearing down these barriers and when they are down… they are down. The army raids your inward parts and nothing is hidden anymore. Whatever was in the dark is completely exposed. The fragile emotions, the unseemly habits, the lousy flaws covered in cosmetics in public places. Everything is exposed!
Intimacy is an intrusion. At the beginning it is unpleasant to give in. But when the bombardment becomes unbearable, the walls begin to fall. They crack at first, it hurts yet is thrilling. Why does the thrill hurt so much? Because stone walls are crumbling under heavy fire. The women of the city are on rampage. There is chaos in the inward parts. The boundaries are no longer relevant.
Intimacy is an invasion. Looting is lawful because everything is shared. Nothing is private anymore when two become one. The concept of private property has no meaning in this realm. The other one becomes a disturbance that you cannot live without, a massive cedar tree growing in the centre of your bedroom. Things get missing, personal effects are moved, and permissions are granted without being requested. Everything is shared.
Intimacy is liberation when two become one; that is how we are designed. Intimacy is a relief because that is what we long for. Intimacy is a pedestal which we all reach for so long as we have the capacity to feel. Intimacy is a challenge we find fulfilling to surmount. Intimacy is a trap we would gladly walk into over and over again because we would rather be bound by love than be lost in loneliness.
Intimacy is a seed that can grow for a lifetime. Intimacy is a weed that can become beautiful when nurtured or else entangled to the point of choking itself when left untendered. Intimacy is an experience so sacred and priceless, so profound and engaging, so complex and intricate that it can only be shared with one other at any point in time during a lifetime.
Intimacy is a treasure often so hard to find and so easy to lose that we must depend on neither logic nor appearance to grasp its deepest meaning. A concept so deep that we must spend a lifetime discovering is infinite layers and facets. It is a maze so intricate that we must pay attention to the tiniest detail to preserve it in its finest form. Intimacy … we could go on and on forever and we will.
This article was originally published in July 2012
Angels and Demons
I met a forty-something year old man on my way from work yesterday. I was just a few blocks from my office. He greeted and I responded as nicely as I could, I mean, this is Ghana not Nigeria isn’t it? Well he then asked me where I was going. What?!!! Excuse, me? As in? You know! But why? I repeated his question, adding a second question mark in my tone so he would know I was actually asking “Why are you asking where I am going?” He then mentioned that I work at my workplace and I acknowledged and asked whether he worked there too but he said he just sees me around. Oooopsss! This is a security issue.
After a few seconds I kept moving and I began to recall that he looked quite like a certain man I had given one cedi a week or two previously. Ouch! I began wondering whether I had exposed myself. Well, he had asked for small money for water and I took pity wondering what would make a full grown man lie down on a pavement and ask for water from passers-by. Suspicious!
A few thoughts on this: this able-bodied man recognizes me, knows where I work and wanted to know where I was going. He also knew I was capable of sparing one cedi for a stranger at least. Hmmm. He may have even been trying to find out when I close from work. Of course, he would have failed woefully at that one. He would need several algebraic equations, (simultaneous at that) to find out.
The short experiences raises questions about how a little help offered can seem to backfire so hard that rather than entertaining angels in our attempt to help, some people end up encountering demon-like entities. There are stories of those who got hypnotized and kidnapped in their attempt to respond to someone asking for directions; swindled by those they lent money to, or pick-pocketed while trying to stop a fight! . Sad experience for such people.
Well, I guess we all have to act wisely in our dealings so we don’t expose ourselves to demon-like strangers not forgetting that ‘angels’ are still out there who really need help. Sure, we cannot let these impostors rob us of the joy of meeting angels, can we?
This post was originally published in November 2012
Five SQL Server Management Practices
This article outlines five native SQL Server capabilities you can use to enhance your efficiency as a DBA. It was originally published on SQL Server Central
As organisations seek more cost efficient ways to manage their environments, the demand on IT to deliver and manage shops on a tighter budget is increasing. The typical IT person must think not just about what must be done but how it must be done not only with the least administrative effort but with the least financial cost.
Administrative effort indirectly contributes to financial cost when such factors such as time spent on performing tasks and resources employed in performing such administrative tasks are considered. In this article I have outlined a few areas where DBAs working in moderately sized environments can capitalise on to manage their environments more efficiently and more cost effectively.
1. Use Windows Authentication
SQL Server provides two main authentication modes: mixed mode and Windows Authenticaton. In mixed mode authentication, logins can be created within SQL Server. SQL Server does the authentication and the user must provide both a username and a password when connecting to the instance. Windows logins can also be used.
Windows Authentication mode allows SQL Server to trust a credentials that have already been authenticated by Windows. This credential could be a local OS account or an Active Directory domain account. Typically when using Windows Authentication in a connection string you specify –T (for trust) or the option ‘Integrated Security=true’ (see https://www.connectionstrings.com/ for more details on this). Some developers are typically averse to taking the trouble to use Windows Authentication probably because it appears more straightforward to simply specify a username and password in the connection string.
Windows Authentication has the following advantages:
Much More Secure – Windows Authentication is more secure because a series of encrypted messages are used in the authentication process. When using Windows Authentication mode, SQL Server supports Kerberos through the Windows Security Support Provider Interface (SSPI). It is also worth noting that when you do use SQL Server Logins, passwords are transmitted across the network exposing them to sniffing.
Easier to Manage – In an environment where users every now and then request a password reset or lock their accounts, using Windows Authentication takes the load of trivial tasks such as unlocking account and resetting passwords off the DBA.
Easier for Compliance – Many industry standards such as PCI-DSS demand basic practices such as password expiry, password complexity specifications and so on. Although this can be enabled on SQL Logins with the CHECK_POLICY=ON option, this is done per login. Using Windows Authentication ensures compliance requirements are handled by Windows not SQL Server which is much more efficient.
Easier for Access Management – When you need to manage a variety of departments who access SQL Server directly it will pay to handle access to the SQL Instance as follows:
- Create Windows Security Groups in Active Directory for each Department
- Grant the Windows Security Group Access to the SQL Instance
- Grant the Windows Groups the required privileges (through roles) on SQL Server
- When a new staff joins a particular depart, add him/her to the group on AD
- When a staff leaves the department remove him from the group on AD
- When a staff leave the organisation, remove him from ALL groups on AD
I think the above approach or any variant is much easier than handling individual principals at SQL Server level. In addition, it can help pass Access Management to a non-DBA function entirely who will not need to access SQL Server frequently to do their job.

2. Use Central Management Servers
Central Management Servers (available since SQL Server 2008) allow you to designate an instance as a management server and subsequently add the connection information for other instances as Registered Servers to that instance. You can group Registered servers as you like and run queries on them as groups.
One good example of the usefulness of this utility is documenting your instances (assuming you are not using more advanced methods). You can run one simple query on your Registered Server Group and get output across instances as shown in Fig 2.

Fig 3 also shows how Central Management Servers can be used to perform adhoc maintenance tasks across instances. In Fig 4 we create an account across multiple instance and grant a role to this login within each database of each of the instances we loop through. You will find this useful if you, for example, want to create an account for monitoring or auditing purposes when using third party tools that must connect to the instance.


It is worth noting that when working in an environment where your database servers are behind firewalls, you should ensure that port 1433 (or any other port you have configured your instances to listen on) is open between the Central Management Server and the Registered Servers. The credentials you use to connect from the Central Management Server should have the required accesses on the Registered Servers.
3. Use a Quorum Share Server
In my experience building SQL Server failover clusters, I have always been more inclined to use Node and Disk Majority Quorum configuration simply because that is what I am used to. With the advent of AlwaysOn Availability Groups, we find that quorum configuration options are limited to Node Majority and Node and Fileshare majority.
When configuring AlwaysOn Availability Groups, It will be useful to designate a single low-spec server as your ‘Quorum Share Server’. Create a number of shares on this server and grant permissions on the share to each clusters you install in your environment. You can manage and safeguard this single server from unintended reboots. You can take control of it as the DBA rather than for example depending on a share sitting on a Domain Controller.
4. Take Backups to a Share
For those who do not use or cannot afford enterprise backup solutions, one would often notice DBAs taking backups to a disk on the same server where the SQL instance is sitting. This is to say the least, RISKY. That means risky in UPPER case. It is even more risky if you are not using a SAN.
When in this situation, it would be a good idea to setup a share on a File Share server and grant permissions to the share to the SQL Server Service accounts across your enterprise. When configuring your backup jobs, simply use the share as your backup location. Below is a sample script:
-- Listing 1: Backup ALl Databases to a Share Excluding TempDB and Model
exec sp_MSforeachdb @command1='
DECLARE @backup sysname
SET @backup=N''\10.1.119.45\Backup\?''+convert(nvarchar,getdate(),112)+N''.bak''
USE [?]
IF ''?'' NOT IN ("tempdb","model")
BACKUP DATABASE ? TO DISK = @backup WITH INIT , NOUNLOAD ,
NAME = N''?'', NOSKIP , NOFORMAT'
-- Listing 2: Backup ALL Databases to a Share Excluding TempDB and Model if there has Been No Backup in the Last 24 Hours
exec sp_msforeachdb @command1='
USE ?
DECLARE @backup sysname
DECLARE @db sysname
SET @backup=N''\10.1.119.45\POST_BKP\'' + DB_NAME() + ''_'' + convert(nvarchar,getdate(),112)+N''.bak''
SET @db = DB_NAME()
IF NOT EXISTS (
select bus.database_name, bus.backup_start_date, bus.backup_finish_date,
(((DATEPART(HH,bus.backup_finish_date))- (DATEPART(HH,bus.backup_start_date)))3600) + (((DATEPART(MI,bus.backup_finish_date)) - (DATEPART(MI,bus.backup_start_date)))60) +
(((DATEPART(SS,bus.backup_finish_date)) - DATEPART(SS,bus.backup_start_date))) [backup_time (secs)], bus.backup_size,
bmf.physical_device_name
from msdb..backupset bus
join msdb..backupmediafamily bmf on bus.media_set_id=bmf.media_set_id
where bus.backup_start_date >= (getdate() - 1)
and bus.database_name=''?'')
IF ''?'' NOT IN ("tempdb")
BEGIN
BACKUP DATABASE ? TO DISK = @backup
WITH INIT , NOUNLOAD ,
NAME = N''?_Backup'', NOSKIP , STATS = 10, NOFORMAT
END'