What comes first – The Chicken or the Egg? What happens first – Update Statistics or Re-Compilations ?

The Statistics life cycle

As a regular process of our DB life, data in our tables changes and hence statistics become less accurate. After a certain amount of changes (which I will discuss later in this post), SQL Server marks statistics to be non-valid.

This process marks the statistics as non-valid but doesn’t actually update them. Only when a query is compiled will SQL Server update the relevant statistics (if auto update statistics is on of course). After the statistics are updated, all the queries that rely on these statistics will be marked for re-compilation.

So actually the process is:

1. Many Changes (updates/ inserts/deletes) –> Causes Non Valid Statistics

2. Query Compilation (happens Independently) –> Causes Update Statistics –> Causes All related queries to be re-compiled

When are Statistics marked as non-valid

After how many changes to the table are Statistics marked as non-valid?

After running the following Script you’ll find out that SQL Server marks statistics as non-valid if more than 20% of the rows were changed (counting changes only on columns related to the statistics).

Trace Flag 2371

20% of row changes sounds crazy high if the table has a lot of rows !

Consider for instance, a table containing data from the past 7 years. It would demand to wait a whole 1.4 year of new data to have the statistics updated ! (assuming only inserts are done and same amount of inserts per year). So if you don’t update your statistics manually and have very large tables, you should have a close look at Trace Flag 2371. It actually changes the 20% threshold to be smaller according to the amount of rows in the table. The following chart shows the new thresholds:

The new Trace Flag is currently available on SQL Server 2008 R2 SP1 and on SQL Server 2012.

I recommend reading 2 very interesting posts on Update Statistics:

1. Filtered indexes and filtered stats might become seriously out-of-date (Kimberly L. Tripp)

2. Changes to automatic update statistics in SQL Server – traceflag 2371 (Juergen Thomas)

Look at the following 3 scripts:

-- 1. Hardcoded
SELECT
    *
FROM
    Sales.Orders
WHERE
    DateAndTime < '19900101'

-- 2. Variable
DECLARE @FilterDate DATETIME = '19900101'
SELECT
    *
FROM
    Sales.Orders
WHERE
    DateAndTime < @FilterDate

-- 3. Stored Procedure
CREATE PROCEDURE Sales.GetOrders
    @FilterDate DATETIME2(0)
AS

    SELECT
        *
    FROM
        Sales.Orders
    WHERE
        DateAndTime < @FilterDate
GO
EXECUTE Sales.GetOrders '19900101'

All three run the same query : The first uses a hard coded filter value, the second uses a variable, and the third uses a Stored Procedure.

Same logical process but they are compiled in a very different way leading to huge different performance outcomes.

What is parameter sniffing?

When a query is compiled, the optimizer doesn’t know the value of variables. This is very important, so I’ll add some exclamation points !!!!!! 

For instance, in the following query:

-- 2. Variable
DECLARE @FilterDate DATETIME = '19900101'
SELECT
    *
FROM
    Sales.Orders
WHERE
    DateAndTime < @FilterDate

the optimizer doesn’t know the value of @FilterDate. Only after compilation is finished and the execution plan is be executed, will SQL Server calculate the value of @FilterDate.

However, there are a few exclusions to the above rule (that the optimizer doesn’t know the value of variables) for instance: Stored Procedures, sp_executesql and a parameterized query.

In these special cases, SQL Server knows (sniffs) the values of the input parameters and uses these values when compiling the statements ! This process is called parameter sniffing.

For example, in the following query:

-- Stored Procedure
CREATE PROCEDURE Sales.GetOrders
    @FilterDate DATETIME2(0)
AS

    SELECT
        *
    FROM
        Sales.Orders
    WHERE
        DateAndTime < @FilterDate
GO
EXECUTE Sales.GetOrders '19900101'

the optimizer at compile time knows @FilterDate = '19900101'.

What happens if we run later on the Stored Procedure with a different input? For example:

EXECUTE Sales.GetOrders '20000101'

This leads us to our second rule:

When parameter sniffing is applied, the same execution plan is used regardless of the input values. Therefore, the first run of a Stored Procedure is critical, the input parameters of the first run will dictate the values used at compile time and hence on the outcome execution plan which stays in cache for future run !! So in our case, SQL Server will use the same execution plan compiled for the first run and won’t create a new plan for the following runs.

Cons and Pros of Parameter sniffing:

Pro #1:

The obvious and most definite pro of parameter sniffing is that only one compilation is needed to serve a whole range of values – we’re saving so many compilations!

Con #1:

That’s the con as well ! One compilation means one execution plan for any value passed. So we’re actually reusing the same execution plan without optimizing it for that specific value. Yes, in most cases it’s OK but sometimes that’s really bad!

Look at the following scenario:

Suppose the Orders table contains many orders from 2007 till 2011. The first run of the Stored Procedure (from above): Sales.GetOrders will dictate the execution plan. So let’s first run it with a very selective value (very few rows are returned):

EXECUTE Sales.GetOrders '20000101'

You can see in the Execution Plan that the optimizer estimated correctly that almost no rows would return.

However, when running the following:

EXECUTE Sales.GetOrders '20120101'

The optimizer uses the same execution plan and therefore estimates miss correctly that 1 row would return. As you can see, the estimated number of rows is very different than the actual number of rows – causing the optimizer to use Lookup for many rows – a very destructive plan!

Con #2:

When an input parameter value is changed inside the Stored Procedure, the optimizer isn’t aware of the change and refers to the original value prior to the change. Look at the following code:

ALTER PROCEDURE Sales.GetOrders
    @FilterDate DATETIME2(0)
AS

    IF (@FilterDate IS NULL)
        SET @FilterDate = SYSDATETIME()

    SELECT
        *
    FROM
        Sales.Orders
    WHERE
        DateAndTime < @FilterDate
GO
EXECUTE Sales.GetOrders NULL

At compile time, the optimizer isn’t aware of the change to @FilterDate. Therefore, when running the Stored Procedure with NULL, the optimizer compiles the SELECT statement evaluating @FilterDate to be NULL and not SYSDATETIME(). You can see in the Execution Plan, the optimizer estimates no rows to return although the whole table is returned.

Of course, there are many ways to surmount these cons, I’ll go over them in my next post.

Happy New Year !

Hi Everybody,

Congratulation to Yair Gutman who won a free ticket to the Advanced Programming in SQL Server 2008 R2 Course !

Here’s the answer to the Quiz:

Let’s first analyze the query without DATEADD:

SELECT

  Orders.Id ,

  Orders.DateAndTime ,

  OrderStatusId

FROM

  Sales.Orders AS Orders

WHERE

  Orders.DateAndTime > SYSDATETIME()

Since SYSDATETIME is a known value at compile time, the estimated number of rows is correct.

Let’s analyze the effect of DATEADD on a fixed expression:

SELECT

  Orders.Id ,

  Orders.DateAndTime ,

  OrderStatusId

FROM

  Sales.Orders AS Orders

WHERE

  Orders.DateAndTime > DATEADD (YEAR , -2 , '20110801 22:47')

You can see again that SQL Server calculates correctly the value of the DATEADD and thus estimates correctly the amount of rows.

However, when DATEADD is combined with SYSDATETIME(), as in the Quiz, SQL Server has a bug and estimates this expression to be SYSDATETIME() and ignores the DATEADD. This bug isn’t applied when GETDATE() is used.

If you need the DATETIME2 precision, a workaround this bug can be achieved by first calculating the value of the DATEADD function and then running the query with a Dynamic execution, here’s an example:

DECLARE

    @ThresholdDate DATETIME2 = DATEADD (YEAR , -2 , SYSDATETIME())

 EXECUTE sp_executesql N'

    SELECT

      Orders.Id ,

      Orders.DateAndTime ,

      OrderStatusId

    FROM

      Sales.Orders AS Orders

    WHERE

      Orders.DateAndTime > @ThresholdDate', N'@ThresholdDate DATETIME2', @ThresholdDate

As a result of our Quiz, Erland Sommarskog, has added the bug to connect:

https://connect.microsoft.com/SQLServer/feedback/details/685903/incorrect-estimate-when-sysdatetime-appear-in-a-dateadd-expression

Please vote, so Microsoft quickly fixes it!

I would like to thank Guy Glantser and Haim Fishner for their great contribution in finding this bug !

We are opening another class of the "Advanced Programming in SQL Server 2008 R2" course on 28/08. You can find all the details here.

Here is an interesting "advanced programming" puzzle. The first one to solve the puzzle will win a free ticket to the course.

Are you ready? Let's go…

Let’s first create a table and populate some data in it:

CREATE SCHEMA
 Sales;
 GO
CREATE TABLE
 Sales.Orders
 (
 Id              INT             NOT NULL   IDENTITY(1,1) ,
 DateAndTime     DATETIME2(7)    NOT NULL ,
 OrderStatusId   TINYINT         NOT NULL ,
CONSTRAINT
 pk_Orders_nc_Id
 PRIMARY KEY NONCLUSTERED
 (Id ASC)
 )
 GO
CREATE NONCLUSTERED INDEX
 ix_Orders_nc_nu_DateAndTime
 ON
 Sales.Orders (DateAndTime ASC);
 GO
INSERT INTO
 Sales.Orders WITH (TABLOCK)
 (
 DateAndTime,
 OrderStatusId
 )
 SELECT TOP (10000)
 DateAndTime     = DATEADD (MINUTE , - ABS (CHECKSUM (NEWID ())) % (60 * 24 * 365 * 5) , SYSDATETIME ()),
 OrderStatusId   = ABS (CHECKSUM (NEWID ())) % 8 + 1
 FROM
 sys.all_columns t1
 CROSS JOIN
 sys.all_columns t2
 ORDER BY
 NEWID () ASC;
 GO

Let’s do a very common task as returning a subset of the data filtered according to the date. In these 2 examples I selected all the rows from the past 2 years. The only difference between the two SELECT statements is that the first uses SYSDATETIME whereas the second uses GETDATE.

SELECT
 Orders.Id ,
 Orders.DateAndTime ,
 OrderStatusId
 FROM
 Sales.Orders AS Orders
 WHERE
 Orders.DateAndTime > DATEADD (YEAR , -2 , SYSDATETIME ());
 GO
SELECT
 Orders.Id ,
 Orders.DateAndTime ,
 OrderStatusId
 FROM
 Sales.Orders AS Orders
 WHERE
 Orders.DateAndTime > DATEADD (YEAR , -2 , GETDATE ());
 GO

Now check out the actual execution plan for these two statements. The optimizer estimates the first query to return only one row:

While in the second query, the optimizer has no problem estimating a very close amount to the actual number of rows:

The question is: why the hell is there a difference between the estimated number of rows in the two statements?

You are invited to send me your answers either by replying to this post or by emailing to (noam AT madeira.co.il). The first one to send the correct answer will win a free ticket to our Advanced Programming in SQL Server 2008 R2 course. In the course we are going to solve this puzzle as well as many other interesting programming techniques.

Good luck!

לא מכבר, נתבקשנו על ידי לקוח לערוך בדיקה מקיפה של ה Database-ים שברשותו. המטרה העיקרית של הבדיקה הייתה לזהות קונפיגורציות בשרת שאינן אופטימליות, ובכך להביא לשיפור ביצועים משמעותי במערכת. כחלק מהבדיקה עברנו על השאילתות הנמצאות ב Query Plan Cache , ולהלן חלק מהשאילתות שנשלפו: 

SELECT ClientId
FROM clients
WHERE (StateId = 2) and (TransactionId = 5)

SELECT ClientId
FROM clients
WHERE (StateId = 2) and (TransactionId = 6)

SELECT ClientId
FROM clients
WHERE (StateId = 2) and (TransactionId = 7)

SELECT ClientId
FROM clients
WHERE (StateId = 2) and (TransactionId = 8)

זהו תרחיש פופולרי מאוד.  אותה השאילתא מורצת פעמים רבות עם ערכים שונים.  כפי שניתן לראות בדוגמא, ה- Query Optimizer  לא מזהה שמדובר באותו מבנה שאילתה ולכן מקמפל כל שאילתא מחדש.  אולם, קיימת חלופה ובה ה Query Optimizer  ממיר את הערכים לפרמטרים, ובכך השאילתא הופכת לכללית ואין צורך לקמפל אותה כל פעם מחדש. חלופה זו נקראית  Parameterization, שכן הערכים מוחלפים בפרמטרים.  במקרה שבדוגמא השאילתא הכללית נראתה כך:           

DECLARE @a, @b int;

SELECT ClientId
FROM clients
WHERE (StateId = @a) and (TransactionId = @b);

  את הפוסט הנוכחי אחלק, כמו כל דבר בצבא , לשלושה חלקים:           

1. דיון קצר אודות שתי החלופות: קימפול מחדש לכל שאילתא בנפרד אל מול  Parameterization.
2. הגדרות Parameterization ב Database – יתרונות וחסרונות של כל אחת מהאופציות.
3. לבסוף, אחשוף דרכים לקביעה פרטנית של הגדרת הפרמטרזיציה לשאילתא מסוימת אשר נרצה שלא תפעל לפי ההגדרה ב Database.     

Parameterization – בעד ונגד           

במבט ראשון, נראה כי פרמטריזציה רק יכולה להועיל ולהטיב עם ביצועי המערכת, שכן עבור שאילתות בעלות מבנה זהה, מתבצע קימפול אחד במקום קימפול מחדש עבור כל שאילתא בנפרד. אולם, עלינו להבין את ההשלכות של פרמטריזציה לפני שנקבע מסקנות פזיזות אלו. קימפול השאילתא משמעו גם קביעת Execution Plan. האם באמת ה- Plan שנקבע עבור שאילתא בעלת פרמטר הוא בהכרח הטוב ביותר עבור כל הערכים של הפרמטר?           

למעשה, קיימים מצבים בהם ה- Execution Plan האופטימלי משתנה על פי הערכים שבשאילתא, להלן מספר דוגמאות:           

1. מקרה בו עבור ערך מסוים של השאילתא, ה- Execution Plan  האופטימלי ישתמש ב- Indexed View אשר כלל לא מכיל את שאר הערכים עליהם אנו מבצעים את השאילתא.
2. שאילתא על טבלה בעלת Partitions גם יכולה להניב Execution Plan מאוד שונה עבור ערכים הנמצאים ב Partitionים שונים.
3. בנוסף, ייתכן מצב בו ערך מסוים של השאילתא מחזיר כמות קטנה של רשומות וה-Query Optimizer יעדיף שלא להשתמש ב Index, ועבור ערך אחר מוחזר אוסף גדול של רשומות אשר עבורו עדיף להשתמש ב Index.
4. כמובן שגם במצב של Filtered Index ה Execution Plan עלול להיות שונה מאוד פר ערך הפרמטר.

הגדרת Parameterization ב Database           

כפי שראינו, לא תמיד נרצה לבצע פרמטריזציה של השאילתות ועל כן קיימות שתי רמות של פרמטריזציה אשר ניתן לבחור מהן בDatabase . יש לציין שלא ניתן לבטל לחלוטין שימוש בפרמטריזציה. שתי האופציות הן:           

1. Simple Parameterization – זוהי ההגדרה הדיפולטיווית בעת יצירת Database. הרעיון הוא לבצע פרמטריזציה לשאילתות כל עוד מובטח שבחירת ה Execution Plan לא נפגעת כתוצאה מהפרמטריזציה. בנוסף, התנאים לכך שתתקיים פרמטריזציה הם:
2. Forced Parameterization – כפי שניתן לראות, התנאים בהם מתקיימת פרמטריזציה תחת Simple Parameterization מחמירים מאוד, ולמעשה מעט שאילתות מקיימות תנאים אלו. לכן קיימת אופציה של Forced Parameterization אשר רחבה הרבה יותר ומכסה הרבה יותר שאילתות, אך מאידך החיסרון שבה הינו האפשרות שייבחר Plan מוצלח פחות עקב הפרמטריזציה. לכן חשוב מאוד לבדוק ששינוי הקונפיגורציה מ Simple ל Forced אכן מיטיב עם המערכת. גם ב Forced Parameterization יש תנאים בהם הפרמטריזציה לא מתקיימת, את הרשימה של תנאים אלו ניתן למצוא ב: http://technet.microsoft.com/en-us/library/ms175037.aspx

DECLARE @statement nvarchar(max);
DECLARE @parameters nvarchar(max);

EXEC sp_get_query_template
N'SELECT ClientId FROM clients WHERE (StateId = 2) and (TransactionId = 8)',
               @statement OUTPUT,
                @parameters OUTPUT;   

EXEC sp_create_plan_guide N'ForceParameterizationPlanGuide', 
    @statement, 
    N'TEMPLATE',
    NULL,
    @parameters, 
    N'OPTION(PARAMETERIZATION FORCED)';  

SqlCommand command = new SqlCommand(String.Empty, connection);  

// Instead of id = 4, use parameterization: id = @id  
string query = "SELECT Name, DateTaken FROM Test Where id = @id;";
command.CommandText = query

// Enter value for parameter @id  
command.Parameters.Add("@id", SqlDbType.Int).Value = 4;
command.ExecuteReader();

כהנמן וטברסקי, שני חוקרים מאוד ידועים בפסיכולוגיה וכלכלה, קיבלו פרס נובל עבור עבודתם פורצת הדרך בתחום קבלת החלטות שאינן רציונליות. במחקר שלהם, בין היתר, הם מאפיינים מצבים בהם אנו, בני האדם, מקבלים החלטות דרך קיצורי דרך ומבלי שהתבססנו על כל הנתונים שבידינו, וכל זאת שלא במודע כמובן. הרעיון פשוט וכה גאוני: המוח שלנו קצר במשאבים (CPU, RAM) ועל כן קיימים מצבים בהם המוח מעדיף להסתמך על חלק מהמידע שברשותו תוך דגימה חלקית ועל בסיסה לקבל את ההחלטה. רגע, זה מזכיר לכם משהו מוכר? אה.. נכון, זה ממש דומה לתהליך בו ה Optimizer דוגם חלק מהמידע ועל בסיס כך בוחר את ה Execution Plan. אך על כך אפרט בפוסט אחר. הפעם, ברצוני להתמקד במה שהכי חשוב בתחום מערכות המידע, שהוא כמובן ה-DBA   .

לעבודת המחקר של כהנמן וטברסקי גם השלכה חשובה עלינו. כאשר אנו באים לבחון פתרון לבעיה, פעמים רבות מבלי להיות מודעים, אנו עושים קיצורי אשר אמורים לעזור במציאת פתרון מהיר, אך לא בהכרח לפתרון הנכון! עקב קיצורי דרך אלו יכולים להווצר מצבים בהם שעות רבות מושקעות במאמץ רב למציאת הפתרון, אך לא בכיוון הנכון. כולכם בוודאי מכירים את התופעה, שעות של עבודה כשהפתרון בכלל נמצא במקום בו לא חיפשנו. אז מה עושים ? הנה כמה טיפים:

1. תזכרו שהסיבה לקיצורי הדרך הינה חוסר במשאבים. אם תתנו למוח לנוח, אפילו לזמן קצר, תהיה באפשרותו לאגור כוחות לעבר מציאת כיוונים חדשים לפתרון הבעיה. לדוגמא, עשו הפסקת קפה, לכו לשירותים, תשלחו ס.מ.ס לאהובכם ותזכירו לו כמה הוא חשוב לכם (טוב, אולי נסחפתי קצת, זה לא מדור לייעוץ זוגי ). העיקר שהבנתם את הרעיון. המוח צריך מנוחה, תאמינו לי – זה עובד !
2. דבר נוסף שיכול לעזור מאוד הינו שיחה עם אדם בסביבה. כמובן ששיחה על הבעיה עצמה עשויה להניב רעיונות חדשים ואולי אפילו את הפתרון עצמו. אך גם שיחת חולין תוכל לעזור על ידי שיחרור משאבים ומנוחה למוח.
3. כתיבה או שרטוט של הבעיה. גם למוח מגבלה בכמות הזכרון, ובטח ובטח מגבלה בזכרון העבודה (לפי המחקרים, זהו הזיכרון אשר בעזרתו אנו עושים עיבוד מחשבתי, והוא מוגבל ב 5 עד 7 פריטים בלבד). לכן תעשו Download מהמוח לדף ובכך תאפשרו לשחרר מקום לנתונים נוספים שיעזרו בעיבוד ובקבלת ההחלטה.
4. במחקרם, כהנמן וטברסקי גם גילו כי הדגימה של המידע אינה מקרית (כפי שאולי היינו מצפים). קיימים מספר פרמטרים לפיהם המוח קובע איזה מידע לדגום. פרמטר מעניין הינו זמן. ככל שהאירוע קרה בזמן האחרון כך סיכויו להכנס ל pool  גבוהיים יותר. משמעות הדבר היא שאנחנו מאוד מושפעים מאירועים שקרו בימים האחרונים על דרכנו במציאת פתרון לבעיות וקבלת החלטות. לכן, תנסו לפשפש במוחיכם ולהיזכר מה קרה בימים האחרונים ולראות האם יכול להיות שאתם מושפעים מבעיה אחרת אשר חוסמת את מציאת הפתרון.

ואם כל זה לא עזר לכם ועדיין לא מצאתם פתרון לבעיה, פנו אלינו ל Madeira! אנו כקבוצת מומחים בעלי ניסיון רב, נוכל לעזור ולספק לכם את התשובות.

כהנמן מקבל את פרס הנובל בשמו ובשם טברסקי ז"ל

 

 

 

 

 

This question sounds really easy! The query performance depends essentially on the execution plan, which in its turn isn't dependent on the client. Therefore, theoretically, running a query through two different clients (i.e. ASP.Net and SQL Server Management Studio) should reveal similar performances.

But before we start answering this question, I would like to share with you the scenario which led me to deal with this question. A client of ours asked for Madeira's help to deal with their very slow web site. We first used Profiler to identify the source of the problem. Our conclusions were clear but at the same time very confusing. The website (written in ASP.Net 2.0) called often a specific query which took almost a minute to return the data. However, running the same query directly through SQL Server Management Studio took only 15 seconds!

Let's try and analyze the different stages that lead from the client and until the Database engine returns the data in order to find the cause of our problem. As you all know clients don’t connect directly to the server, they use a provider to do so. Performance can change from one provider to another or even from two different versions of the same provider. Remember, for better resource management and performance, it's a good idea to use the latest versions of your provider. But yet, is it possible that two different clients running the same query and using the same provider would result with different performance?

You're right, the answer is yes! Let's continue and analyze the chain. The provider passes on the query to the Database Engine which verifies if a compiled version of the query residues in the memory. However, the process of which the Database Engine decides if it can use the compiled version is pretty complex. The motivation is of course to use the compiled version but the Engine must be sure the data returned is perfectly similar in both cases (compiled query and the current query). To do so, a set of criteria have to match in order to be sure the returned data is the same. Among those criteria, are the Session settings (ANSI_NULLS, ARITHABORT etc…) Thus, if a session runs a query with different session settings than the compiled version, the engine will have to recompile the query and maybe use a different execution plan and resulting with a different performance. This is exactly what happened in our case. SQL Server Management Studio has set by default ARITHABORT = 1 and ASP.Net has set ARITHABORT = 0. (for info on arithabort see: http://msdn.microsoft.com/en-us/library/aa259212(SQL.80).aspx). All was left to do in order to fix the problem was to set ARITHABORT = 1 while calling the query through ASP.Net.

P.S
You can check if ARITHABORT = 1 in SQL Server Management Studio's options (Query Execution > SQL Server > Advanced). In the current picture, you can see it's set to 1.

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

במבט ראשון השאלה מעוררת השתאות, אפילו תמיהה, כיצד ניתן לחבר בין נושאים כל כך שונים? ברצוני לנסות ולשכנע אתכם כי אכן קיים קשר שכזה ובעבודתנו כמנהלי מערכות מידע, חשוב להתייחס אליו. בפוסט הנוכחי, אתייחס לשני היבטים שונים: קשרי ה – DBA עם סביבתו וניתוח הזיכרון האנושי במנוחים ידועים ממאגרי מידע. עם הזמן, אמשיך ואוסיף היבטים אחרים ושונים בקשר מעניין זה, אתם מוזמנים לבקר ולהתעדכן. 

קשרי אנוש שבין ה DBA לסביבתו

ציטוט ידוע של פרויד הינו "אנו באים לעולם לבד, ועוזבים אותו לבד", אנו מנהלי מערכות המידע בטח ובטח שלא עובדים לבד. מסביבנו אנשים ממגוון רחב ביותר של תחומים; מנהלים בעלי רקע טכני ולפעמים לאו, מתכנתים, אנשי סיסטם ועוד ועוד.
כאשר אנו באים לבחון בעיה טכנית, לא ניתן להתייחס בלעדית לפן הטכנולוגי. מאחורי כל בעיה קיים לקוח / משתמש אשר מוטרד מהבעיה ומחכה לעדכון. התקשורת עם הלקוח מורכבת תחילה מאפיון ברור של הבעיה והשלכותיה. מחקרים בפסיכולוגיה מזמן הראו כי חוסר אונים הינו מקור לפחד ולתסכול. במקרה דנן ניתן להבין מדוע לקוחות רבים חוששים ואף מתוסכלים כאשר עומדת בפניהם בעיה טכנית. תפקידנו אינו מסתכם במתן פתרון, אלא גם מורכב מליווי הלקוח תוך מתן הסבר מפורט למקור הבעיה, פתרונות אפשריים והצגת לוחות זמנים. אומנם, כל זה נשמע מאוד טריוויאלי אך לא מעט הם המקרים בהם אנשים טכניים לוקים בחסר כאשר מדובר במודעות לסביבתם ובכך אינם נותנים מענה כולל ללקוח.

זיכרון אנושי ומערכות מידע

נשמע אולי מפתיע, אך כבר מיליוני שנים שבני האדם מבצעים מחקר בתחום מערכות המידע. לשם הדיוק, המחקר התבצע ברמת הגנים שלנו ו/או על ידי גורם כל יכול עליון (כל אחד ואמונתו). ברור שכוונתי אינה למערכות מידע ממוחשבות, אלא למערכת הזיכרון הנמצאת במוח של כל אחד ואחד מאיתנו. אורגניזמים חיים מתמודדים בכל רגע נתון עם קלט עצום של מידע ולכן נוצרו פתרונות ומנגנונים מתוחכמים לקידוד, אגירה ושליפה של כמויות עצומות של מידע. אפרט מחקרים אשר שופכים מעט אור על מבנה המנגנון וצורת פעולתו.
בדומה לסווג המוכר במערכות מידע ל OLTP, Data Warehouse ו OLAP קיים במוחנו סיווג לזיכרון סנסורי, לטווח קצר ולטווח הארוך. למשל, מטרת הזיכרון הסנסורי לתת מענה מהיר ביותר לקלט ראשוני של המידע. כמובן שקליטת המידע מבחוץ בהכרח מתבצעת באופן מהיר וללא איבוד של מידע. לצורך השעשוע, דמיונו כיצד היינו מתפקדים במקרה שבו ביצועי הזיכרון הסנסורי היו מדי פעם משתבשים (כפי שקורה לא פעם במערכות מחשוב).
במוחנו קיים גם שימוש דומה ל Data Types. דהיינו, הזיכרון שלנו תומך בסוגי תכנים שונים. למשל: זיכרון סמנטי, אפיזודי,  זיכרון לכישורים מוטוריים, ועוד. חלוקה זו במוחנו עלולה לפעמים לייצור התנהגויות מוזרות אצל בני-אדם. לדוגמא, מקרה מפורסם של חולה בשם HM אשר יכולת הזיכרון האפיזודי שלו נפגעה כתוצאה מתאונה, אך הזיכרון לכישורים מוטוריים לא נפגעה.  חוסר האיזון הזה יצר מצב שכאשר לימדו אותו לשחק שח הוא ידע לשחק למרות שלא זכר כלל שלימדו אותו.
תופעה נוספת ומאוד מעניינת קשורה לשליפה א-סינכרונית. האם קרה לכם פעם שהשתדלתם מאוד להיזכר בשם של מכר ללא הצלחה, ולפתע מספר דקות מאוחר יותר השם קפץ לכם לראש ? אין זה במקרה שהשם לפתע הופיע במודע, הרי המוח המשיך להריץ את השליפה ברקע וכאשר התוצאה נמצאה, המידע הוחזר לחלקים המודעים של המוח.

לסיכום,
המדע ממשיך למצוא מידע מרתק על מערכת הזיכרון האנושית. כולי תקווה שתחום מערכות המידע הממוחשבות יצליח בעתיד ללמוד להפיק מכך תועלת בבניית מערכות חכמות ועמידות יותר.