Microsoft is working hard on pushing a SharePoint server and integrating every reporting aspect in it, from the new PivotTable to PerformancePoint server. Yet, in the same sentence, they claim that SharePoint is for medium to enterprise organizations.  What if you don’t work for an enterprise size organization and you don’t install software you don’t have the licenses for?

Well, I don’t work for an enterprise size company and we really don’t have a use for the entire SharePoint server features we ate just looking for a tool to share our report, which leaves me with original reporting application that bundles with SQL Server – SSRS (SQS Server Reporting Services).

Building reports in SSRS for SSAS has never been a straight forward task, especially if you want to integrate parameters and conditional execution.  It seems that with every version, the connection between SSRS and SSAS is getting stronger, yet even with report builder 3, building a report that slices the information using dimension members or sets is still a confusing task.

To successfully build an SSAS report using parameters, you should forget the work flow used for building T-SQL reports, the process must be broken into several building blocks and at the end “manually” connect between them.  I have broken down the development process to the following building blocks:

• Data Source – the connection to the SSAS server
• Data Set –
  • Filed list- a list of fields returned by the query used to bind the results of the query to the report form.
  • Parameters – parameters are usually used to slice the results of the query. There are two major types: filters using dimension members that are presented as a checkbox tree on the report form and regular parameters such as date ranges that will be presented as text fields or datetime pickers.
  • Query – the actual query running the query.  Due to the limitation of the query builder, you will probably have to replace it using your own MDX code.
• Report designing – the actual report page displaying the results.

Creating a Data Source is very similar to a creating a SQL Data Source, I strongly suggest you create a shared connection that will be reused by all the reports in the same project. If you want to use the active directory security feature to limit the viewed data or the actual report, change the connection string on the production server to use the current user credential.  While developing, either use your own user or set an admin privilege user.  Also using the query designer (will be explained later) takes a considerable amount of time creating connection to the DB server and retrieving the data, so while developing I work with my development SSAS server located in the same network as my development desktop.

Report designing is also pretty straight forward and very similar to creating a T-SQL report. When you have reached the final stage of designing the report, and you find that you need to add a new calculated field, it is easier to add it to grid than to go through all the steps for adding a new field in the query designer.

The trick in the process is creating a dynamic Data Set. I usually launch the process with the query designer, using it to create all three groups.  Afterwards I manually manipulate them to add the missing features and join them back together. I will create a simple report presenting the revenue of my demo publisher per month, then I will manipulate the Dataset turn it into a dynamic report that will allow the user to select the time span, certain publishers and specific countries.

Right click the Data Set folder and click add DataSet.  Select the DataSource and click the query designer button (see image1). In the query designer popup window, build your query by dragging and dropping from the left side menu (presenting the SSAS DB objects).  The queries designer is limited compared to what you can do with an MDX query.  We will take care of that in one of the next steps; just make sure the fields you want to display in the report are selected. When you are done, click the OK button. Saving the query will create the field list that we will use later in the report. In the image below I have selected one measure revenue and two dimension member’s month and publisher from two different dimensions.  The result you see is the revenue of our Demo account.  Since I aim to build a dynamic report, I will use the query builder to add the dimension based parameters by dragging the dimension to the filter section and setting them as parameters using the parameter check box. Marking the parameter check box is creating the parameter and a hidden Dataset that will retrieve the values for the parameter check list form the dimension in the SSAS. At this point we are missing the date slicing parameters, you can add a manual parameter at this step, yet the query designer does not recognize a parameter defined outside the query designer. I will add parameters manually in one of the next steps.

After clicking OK, you will go back to the Dataset Properties window.  In the Field tab you will see the list of the fileds we have selected in our query design (see image 2).

In the parameter tab, you will see two new parameters (see image 3) bound to our query.  The parameters get their names from a dimension structure.  I always change them to something more useful and readable. Click OK to close the window and save the definition.

My next step will be to add two new parameters: FromDate and ToDate.  These are two regular date-picker parameters.  Close the Dataset properties window and right click the parameters folder on the reports data window (left side menu).  Select ‘add new’ and set the required properties.  Set the name, type and default value and don’t forget the ‘never refresh’ in the advance tab.  At the end, we can see a list of four parameters (see image 4).

Now, back in the Dataset properties window, we will bind them to our query.  In the parameter tab, click ‘add’.  Select the parameter from the dropdown menu and set a corresponding name (see image 5).

Now we are at the final step, where we manually change our query and combine the new parameters.  We cannot use the query designer for the next step it will ignore our manual settings  a return the configuration to the state.  I have to write my own MDX query (yes, there are IT guys that know SQL Server at a DBA level, build reports in SSRS, Cubes in SSAS and knows how to write MDX queries).  In order to accomplish that in the Query tab, I will edit the query by clicking the FX button (marked in red in image 6).  Explaining the DMX syntax is out of the scope of this post.  I simply added the following code to include the usage the date parameters:

FROM (   SELECT ( STRTOMEMBER( "[TimeH].[YQMDH].[Date].&[" + Format(@FromDate, "yyyy-MM-dd") + "T00:00:00]" , CONSTRAINED)                 :  STRTOMEMBER( "[TimeH].[YQMDH].[Date].&[" + Format(@ToDate, "yyyy-MM-dd") + "T00:00:00]", CONSTRAINED) ) ON COLUMNS FROM …..

After changing the query and adding parameters, you cannot update the field list. The Dataset properties window can’t cope with the manual changes, so if you are asked to update the list.  Choose the cancel button; you can always do it manually later.

Now you are ready to build your report.  Select the table component, then drag and drop the fields from the field list.  When you execute the report, the new parameter will appear at the top of the report.

These are the basic try adding fields into the field list, adding custom set and members. Ping me if you like to hear more.

Guy  R

In the first part of the post, I talked about how statistics are used to mislead in ads and commercials. In this post I will show you that we make the same mistakes unknowingly on our own.

From time to time, I run into news articles describing fascinating research results.  One that caught my attention was a research claiming that “having sex at least twice a week will improve your appearance”!   Since I didn’t have accesses to the actual research, I’m not going to refute the validity of the claim, but the first thing that came to my mind was that it might be the other way around “better looking people tend to have more sex”.  The same claim in the world of web applications will be something along these lines “A higher percent of clients from UK and US tend to complete our survey than clients from Asia”!  Could it be related to the language in which the survey is written in? This is one of the more common mistakes I run into during planning, implementing and analyzing tests.  When you get to the point of analyzing your results, split the viewings to distinct groups, based on demographic data of the users, and analyses within the group, or set the test to eliminate the influence of user demographics (for example: translate your survey to several languages and display the survey according to user settings).

A few months ago, my wife told me on her way out the door: “I haven’t bought shoes in the last three months; I’m going to buy a new pair of boots”!  As a guy, I can’t see why you need so many pairs of shoes, but I said “ok”, like I have any say in the matter, and right away I run a damage report in my head: a pair of shoes costs about 300 NIS.  She hasn’t bought one in the last 3 month, so it will cost me about 900 NIS. Well, you will be amazed to know that it cost 1500 NIS and my wife claimed that it was a steal, and that I was “lucky”. And by the way, she was right…  What was wrong with my analysis and prediction? Actually, everything it was based on two assumptions in area I’m far from being an expert in:
A)     Reasonable cost of women's shoes is 300 NIS.
B)     Shoes and boots cost just about the same.

I based the “damage” on my experience with men’s shoes.  It is the same as when integrating a new client into your system and building an income prediction.  The prediction is based on past data collected in your system; yet selecting the correct past clients to base the prediction on is the whole trick.  Chose the base clients and carefully match them to the new client demographic, as closely as you can. Income from North American clients will not match European clients and a client in the gaming verticals has a different behavior than client in the MP3 verticals.

Whenever I talk on the phone and drive, my grandmother reminds me that “the majority of car accidents occur in the five kilometer radios from home”. This statistical fact is actually correct, but it has no real significance on the chances I might be involved in an accident.  Think about it! Every car ride you take, starts or ends at your home and most of the car rides are to local destinations: kids school, after hours activities, your gym, grocery store, library or work place.  The five kilometer radios will cover more than 30% of your total mileage or more. This is exactly like saying “more deposits are done in the first week of the user life span”.  Could it be related to the fact that most users’ life span is one to two weeks?  A better analysis would be to check the number of deposits with the relation to number of user in certain life span, even better would be to check the time it takes a user to deposit new funds after reaching zero bankroll event along his life span.  Actually, I built the later test for a company I worked at, and the finding helped them distinguish between the different client groups in their application. Based on that distinction, they ran a different bonus plan for second time depositors.

Longevity studies are one of the hottest issues in the medical and insurance verticals; they have a direct influence on our pension plans and life style.  Surprisingly, it is also a hot issue around the women section of the family dinner table (I named that part of the conversation the “Yachne story tellers”). It always ends with a conviction along these lines “more people die of cancer or hurt attacks than 80 years ago”. Again, the fact is actually true, but by pure chance I read an article, in a medical magazine, explaining the issue. The article simply stated that improvement in the medical world:

a)      Allows us to recognize the death causes that once were considered death of old age.

b)      Adding 20 years to the longevity of an average person allows certain old age disease to manifest.

And that statistical information should be based on data gathered only in the last 10 years of the 80 mentioned above.  A few years ago, I took part in analyzing test results, based on conclusions originated form an analysis of user base holding records of several years. The analysis did show improvement, but it was not meeting the expectation. At the end we concluded that the changes in internet world, the application feature and the client expectation, had changed so drastically from in the last years that only data from the last 6 months was relevant.

So when you design your tests remember:

1)      Select your data or design your test in fashion that negates influence of preset variables, such as languages holidays and past experience.

2)      Base your prediction only on relevant data.

3)     When designing the test integrate an expert or someone with experience in the field.

Working as an operation manager and DBA often requires me to examine and produce statistical reports and devise actions based on them. I had my fair chances at seeing miss interpretations of statistical data resulting in very harmful actions. A former work colleague of mine suggested reading two books: Analytical Thinking and How to Lie with Statistics. Both books were very useful in designing statistical tests, explaining and analyzing statistical reports. It changed the way I look at statistical research, which I encounter in my day to day life. I will try to explain some of the errors in the planning and analyzing of data, which we all encounter in our day to day life.

Often statistics are used for promotion and sales: The ten minute commercial breaks are annoying, and like most people, I usually switch to a different channel when they start. The time span for a single commercial sometimes dictates the content that will promote sales, but might have poor connection to the actual product. Lately, I can see more and more commercials citing statistical information, but if you read the small writing, you will start to wonder..

• Statement: “According to a survey, voted the best insurance policy” or “According to a survey, voted the safest car for 2009”. Small letters: “according to public opinion survey taken by….”.  Are you kidding me? What does the public know about car safety, or insurance policies (do you understand the small letters in your policy?)?  Last time my sunglasses went missing from my bag, the insurance representative told me that since I wasn’t robbed (you know, "put your hands in the air" robbed) I'm not eligible for any compensation and then he pointed to page 3 paragraph 13- section 4!!
• Statement: “Voted the best product of the year”… Small letters: “According to a survey taken in 2007 by…“. Are you kidding me? In the last 3 years new companies and technologies have entered the market! Wake up! It’s 2010.
• Statement: “Voted the best car 2009”… Small letters: “according to a survey taken in Italy … “. I’m not sure, but the last time I checked in Italy, most cars have a manual gearbox. In Israel, on the other hand, most cars have automatic gearboxes, and, the last time I bought a French car, after three visits to mechanic and some unnecessary oil and part changes, they found that the radiator heat plug did not match the Israeli hot desert weather, but the European cold winter. So guys, please try at least to quote a relevant statistical survey.
• When someone like Milla Jovovich is “selling” me that “applying this mascara will increase your eyelash up to 30%” or “using this moisturizer will remove your..”, I ask myself: could being beautiful to begin with has an effect on results of applying cosmetics products?..

So what is the relevance of the issues I have mentioned above:

• Expertise in your field.
• Select relevant data.
• Use demographic analysis and slicing.
• What comes first? Chicken or the Egg? Select the subject group so it will not affect the result of the test.

In every test you design or analyze, when planning the test you must consider carefully the place and influence of these issues on the test.

In my next post I will try to show you the same issues in your day to day life and the design of your test.

Guy

If your company is planning on using the Azure platform and SQL Azure for a high load OLTP application, you should change the way you think about application and database design.

The limitation on SQL Azure described in my former post, will force you to think differently regarding scaling your applications. Application wise, you must take into consideration that long running queries will be disconnected by the SQL Azure server and connections which are open for a long period over the internet, tend to disconnect due to network issues. To limit the effect of these issues you should implement the following:

• Connection polling in your application (built-in feature using .Net), will reduce the load on the database server. Connection polling also saves resources on creation and reduces the latency of creating a connection over the internet.
• Use short transactions\batches, open the connection in the last second, execute the query commit and close the connection as soon as possible.
• Implement a retry mechanism in the events, so you don’t get disconnected or unable to create the connection over the internet.

When you considering scaling options, since you don’t have any control over the hardware resources, scaling out is your only option. You have several options for scaling out, depending on your application.  All of them will require a logic method in your application that will select the appropriate connection string, or in other words: your application must be partition aware.

Let’s review some of the options:

• One Database per client- if you are a SaaS provider, you can open a database per client. This option has a few advantages: privacy and security wise, each client has its own database. Billing wise, you can bill your client just for SQL Azure recourses their database is using (see below: Master DB).
• Configuration Database – if your database holds static information, updated once in a long period of time, you can create multiple copies of your database using Sync Framework to synchronies the changes from the primary one. You will also need to add a round robin method on your application side to select the connection string and distribute the load on the different instances.
• Logical partitioning or Elastic provisioning– what if your application design allows that? You might be able to separate your data according to a natural key. Could be as easy as modulo 10 your client user id or opening a database per country\game\event … in your application. Of course, that too will require changes in the application connection string module logic. One company all ready implementing such a solution is www.ticketdirect.com.  You can read more on Microsoft Case Studies.

I just had the privilege to join a closed Microsoft Connect session on SQL Azure.  It seems that some new exiting features are on the way, which will help with scaling.  Some of the performance execution limitations will be reduced and a new clone feature is being developed to help with instantly creating copies of your database for scale out usage and backup.

To enable the partitioning process, Master DB has changed considerably: it no longer sits at the center of the SQL Server and two new role gateways were added to login operation and logger of usage operations.

The login process uses two tables of sys.sql_logins for the login operation a new table sys.firewall_rules for configuring access to the “DataBase Server”. A successful login must be backed up with valid data in both tables (information about the login process can be found in my former post).

The second role as an activity logger for billing process is back up by two new tables named sys.bandwidth_usage sys.database_usage. By monitoring the values on these tables, you can calculate the operation cost of any single DB and add it to your client billing quote or monitor the operation cost of an event on your system.

SQL Azure is a Microsoft solution for relational database cloud computing.  It comes as part of the Azure platform.  As with the Azure platform in general, in order to implement such a solution, many limitations were placed on the Azure version of SQL server.  The implantation as a technical solution is amazing and requires some IT background to figure the complexity of it out.

The best point to start presenting SQL Azure is with a description of the infrastructure. As a user, you are granted with a token.  This token is used to create all of your databases.  The first DB to be setup is the master DB, very similar the SQL Server master DB (more on the functionality of the Master DB in the next post).  All traffic to the SQL Azure “Server” is routed through a firewall that allows you to limit the accesses to specific sources, using a well designed web interface. Then the connection is routed to a gate that diverts the connection to the current server hosting your database. All SQL server instances which build the SQL Azure platform are installed on cluster machines to support high availability, and data is automatically replicated across different machines. In the case of failure, the gateway will automatically point to the current online database instance. 

Download SQL Azure presentation

In order to increase scalability of your application and to maintain overall balances of the SQLAzure platform server, your databases are placed across multiple servers.  (i.e., Even though it looks like it, your company databases are not placed physically on one server! what actually happens is that several companies share the same hardware!  So how do you reach a specific database?  The trick is in the login: the connection string must include the destination database.  Your connection undergoes authentication using the login setting saved in the master DB, and then diverted to the requested database that will most likely be located on a different server.

Furthermore, to allow a fair resource distribution between the different databases and SQL Azure clients, several limitations are set on the databases settings and resource utilization.

 A detailed list of the limitation can be found in the following link, and I will give you the highlights:

• The major change is that you can’t manipulates local resources:
  • There is only one file group per database.
  • No partitioning.  
  • No fill factor.
  • No user defined data types.
  • No full text indexes.
  • No memory settings or any other server level settings.
• All tables must include a clustered index.
• Each connection can only function in the boundaries of the database it is connected to.
  • No trace or profiler, due to the fact that when you connect to a specific DB u can interact with the master DB.
  • Can’t use the USE <database> command.
  • Can’t use distributed transactions or queries.
  • Can’t use global temp tables.
  • No service broker
• All logins are SQL server logins, there is no domain support.
• Maximum database size of 10G.
• No SSIS or SSAS support

Connection throttling, to support fair resources distribution, is placed in the form of limitation on:

• Query execution time
• Maximum open connection time
• Limiting long running transactions and extensive resource usage CPU and memory.

These limitations will actively disconnect the client connection and STOP QUERY PROCESSING.  Selecting the 10 GB (Business Edition) version over the 1 GB (Web Edition) version will grant more resources and raise the limitation settings.

It is evident from the description above that SQL Azure is not a straight forward solution for high load OLTP databases or data warehouse implementation. Working tips, scalability, design, considerations and more- on the next blog.

The following technical resources are a good starting point to understand the SQLAzure platform :

• Official Azure Site
• Pricing
• Videos from PDC
• MSDN SQLAzure
• Developer Guide

Guy

זקוקים להרחבה בנושא? פנו אלינו ונשמח לעזור

In the last 12 months, virtualization and cloud computing have become one of the hottest issues in the hosting world.  It started with companies offering Linux based cloud services for Windows, based on cloud servers, and then it expanded to new companies going into elastic computing, such as Rackspace and Opsource. Yet it seems that when it comes to MS-SQL server support and .Net, all current solutions fall short. The major part of the management work ‘falls’ on the user and the cost is far higher compared to Linux solutions. The user is supposed to install anything above the basic OS and to take care of upgrades, monitoring and duplicating resources (servers) on his/her own, for scale out solutions. Some of the solution providers sell their offering as a testing environment platform or as for simulating production environment, reducing client operation costs, compared to purchasing hardware and hosting fees.

Then, a few months ago, a new major player entered the world of cloud computing: Microsoft with Windows Azure.  Microsoft will officially launch their services in January 2010 as a production hosting platform, and new web server farms will be operational all over the world during 2010. They have currently invited every ISV or BizSpark client to use the Windows Azure environment as part of their CTP, allocating them with a limited CPU and Instances Tokens.  The company I work at has uploaded a partial solution (covering 70%) of our application in less than a day’s work.

To solve the versatility of OS configurations and provide an almost instantaneous scale up option, Microsoft Azure takes a different approach than other elastic .Net supporting solutions. Mainly, Windows Azure solution limits the application working environment and physical resources usage and configuration. The most trivial example is that you can’t write to files, writing and saving of local data is done to special blob objects (which by the way can resemble small DBs). The server instances are virtual, and I don’t mean VM or Hyper-V.  The application is running on an AppFabric environment. The Fabric has the ability to run worker-roles that are very close to services and web roles that are very close to web services.  The actual code has to be compiled, especially for the AppFabric environment (a very simple process), but anything that was developed in .Net could be converted to Azure.

The usage bonuses from running on Windows Azure are mind blowing:

• Scale out is performed by changing configuration settings, and deployment to multiple servers takes about 15 minutes (officially one day max).
• Every instance is automatically duplicated and set to standby mode, so if your instance crashes the copy is brought to life in a matter of seconds.
• You can run different versions of your application test performance results, and increase or decrease the number of instances in minutes.
• Pay just for what you use, when prices in comparison to owned and hosted server are very low.
• Fully redundant Hardware solution.
• You can place your farm near your client location.
• Automatic upgrade processes to latest versions.
• Configured security system.

Microsoft has even taken its solution one step forward, and offers the Windows Azure platform for private cloud implementation. Your organization can install the Azure platform as a virtualization solution for internal environments solution such as QA and staging (just think what can be done when it comes to load testing), or as part of your organization SaaS solution, providing a private application environment for different clients, installed on the same hardware.

What Azure is offering for SQL cloud solution- on my next post.
Coming soon …

The following technical resources are a good starting point to understand the Azure platform:

• Official Azure Site
• Pricing
• Videos from PDC
• Developer blog

cloud computing

I love looking at the sky and staring at the clouds, your imagination can run wild and you can invent wonderful stories about the shapes you see in the clouds, but they always seem so far away out of your reach.  For me, as a DBA, it was same with cloud computing.

Cloud computing has been around for a long time, starting with Google Aps and Amazon AWS. Working in medium size companies has limited my exposure to them.  About a year ago I was asked to join a panel discussing “IT for startups”, when one of the most interesting issues raised was ‘should we use the cloud hosting solution’.  My answer then was NO.  Along the last year my view about cloud computing has shifted to favoring cloud computing as a partial solution for startups.

What are the benefits of cloud computing?

1)      Scaling up and down is possible within a matter of hours.  Moreover, you only pay for what use, and on an hourly basis.  Meaning, if a new client comes along, you can palace a request for ten new servers, and within the next day you’ve receives them fully load-balanced and ready to go.
2)      All hardware and OS management are the provider’s responsibility.  No need for highly qualified IT tech that has wide knowledge in networking, security, virtualizations, storage, and FW.
3)      You receive fully monitored OS and hardware services, including reporting and alerts.
4)      You receive a fully redundant solution with an obligation for high availability.
5)      Worldwide location distribution brings the application closer to your clients.
6)      No need to upgrade your hardware every three years.

What are the problems with cloud computing?

1)      These are not your servers!  Your control on selected OS versions, maintenance and patches is limited.
2)      These are not your servers!  Placing sensitive data from passwords to your core technology is an issue.
3)      These are not your server!  If it crashes, nobody promises you how hard they will try to save the data stored on the hard drives.
4)      These are not your server!  For some reason, I can’t see you passing a credit card company inspection…
5)      These are not your servers!  You will probably have to make changes to your application to fit cloud computing
6)      Windows .net based applications are not native to this environment.  If you want to enjoy the monitoring and management benefits, you will have to use a non .net language.
7)      Database solutions are very limited either in capacity and version or in manageability.

Deciding if to use cloud computing or not is not an easy decision.  It will affect your application design and development environment.  I can give you some point for consideration:

CDN on cloud?

Downloads require a lot of bandwidth.  You will probably want a redundant network (which cost a lot of money), and there is always an issue of being close to your clients (which require multiple locations).
In order to solve these issues, you’re probably using some kind of a CDN solution.  If you’re total download is not in Terabytes, I recommend looking into a cloud solution such as Amazon S3.  Pay per usage has a huge advantage (I’m talking about thousands of dollars per year) over not buying a minimal quota package per month from major CDN providers.

Cloud computing?

If you are a new upcoming company, requiring just a few dedicates server including load balancing, buying and hosting a server, a managed dedicated solution will cost you 1,000-1,500$ per month per server.  Each cloud server is about 200-500$ and you only pay for what you use.
The key benefit is the ability to scale up in a matter of hour and not weeks or days.  And it’s important to place your server close to you client no matter where they are in world.

Database?

If you require a simple DB services with storage requirements lower then 10G, and the number of hits on your server per second is in lower thousands, finding an adequate SQL or MySql solution should not be a problem.  Your solution will enjoy high availability and be redundant.

The actual trigger for writing this blog was SQL Azure but that will be on my next post.  For now, I’m going to stare at the sky and look at the far away clouds.

Guy

A few days ago I was approached by a “Guy” I know (Glantser, that is), who asked if I would like to write a blog on a new SQL Server dedicated web site.  My first reaction was ‘sure, I’d really like to write to a blog and have wanted to do it for years”.  My second thought was “what am I going to write about? A blog about SQL is so boring!  So, while trying to push my luck, I told this “Guy” I would do it, but it won’t be SQL related.  Actually, I’m going to write about the view from my window.  There was a pause.  The response was almost as odd as the request: “It would be nice if you write about SQL Server from time to time, but good luck on your window blog”…

So guys, if you are looking for an SQL code, check out another blog around here.  I’m going to write about what we all experience on a daily basis as DBAs.  And it’s not always pretty.

How did I become a DBA? Actually, by mistake!!

I have been in this business for the last 12 years.  I started as a development team leader in asp and Delphi developing intranet applications.  As no one among my team members agreed to do this “highly glamorous” and simple job, I was personally responsible for the DB development.  So what if the consequences of a single execution could be a whole year of business disappearing?..

(Actually, that happened more than once..  Thank god there is this small thing called ‘Restore to a Point in Time’.  Maybe I’ll tell you about it sometime).

Then, about ten years ago, I went to a job interview in an upcoming .com startup.  Two hours into the interview, I started to feel something was going terribly wrong.  They were asking me about databases related issues all the time and not code development!  But being a DBA is no fun!  So I asked them “guys, why all the DB questions? I’m a developer”.  They simply nodded their heads and ignored me completely…  Four (!) hours after the polite water offering, they said:  “we want you as our DBA.  There are many good developers out there, but not as many DBAs”.

So I started my first job as a DBA and IT manager, help desk, product manager and noc operator. You can do a lot if you work 16 hours a day 6 days in a week..

It seems that it was the point of no return.  I left the startup as Internet OLTP DBA and since then, no one will let me work as a developer.  A few years later, I came to realize that as DBAs, we are placed in a unique position in every company, allowing us to be involved in all aspects of the product development, from product design requirement, through hardware selection to post sale, from online to billing.  Our work (the data) connects between the different applications in the organization and forces us to look at the applications as a whole.  IT Techs are not involved in development, development teams are not concern in production or hardware, and product managers are basically dreamers

All and all, it seems as the immortal words of Mel Brooks still stand: “It’s good to be the DBA”

Guy R.

By the way, I completely forgot about the view from my window…

The View from a DBA’s window