Pages

Friday, May 22, 2015

Column Alias and CTE

One of the most annoying limitations of T-SQL is the restriction of column alias to be only used in the ORDER BY clause. It cannot be reused in SELECT, cannot be used in WHERE or GROUP BY. Take a look at the following example:
USE AdventureWorks2008;
GO
SELECT   YEAR = year(OrderDate),
         MONTH = month(OrderDate),
         OrderTotal = sum(LineTotal)
FROM     Sales.SalesOrderHeader h
         JOIN Sales.SalesOrderDetail d
           ON h.SalesOrderID = d.SalesOrderID
GROUP BY year(OrderDate),
         month(OrderDate)
ORDER BY YEAR DESC,
         MONTH DESC
GO
/* Partial results

YEAR  MONTH OrderTotal
2004  7     50840.630000
2004  6     5364840.179338
2004  5     5194121.522904
*/
Column alias "Year" cannot be used in the group by but in the order by. More than just annoyance: more complicated, harder-to-maintain code with potential source for bugs. Though this is a standard SQL feature, it is very different from other application programming languages. The likelyhood is very tiny that alias handling will be streamlined in the near future at least.
In SQL 2000 we could have tried to use derived tables to introduce a structure to isolate the detail info from the group by:
SELECT   YEAR,
         MONTH,
         OrderTotal = sum(OrderAmount)
FROM     (SELECT YEAR = year(OrderDate),
                 MONTH = month(OrderDate),
                 OrderAmount = LineTotal
          FROM   Sales.SalesOrderHeader h
                 JOIN Sales.SalesOrderDetail d
                   ON h.SalesOrderID = d.SalesOrderID) a
GROUP BY YEAR,
         MONTH
ORDER BY YEAR DESC,
         MONTH DESC
It looks more controlled, but does not appear to be simpler. Derived tables in SQL2K actually belonged to the domain of expert database coders, casual database developers were terrified by the seemingly illogical construct.
In SQL Server 2005 and SQL Server 2008, we can magically change the derived table into a CTE:
WITH cteOrderDetail
     AS (SELECT YEAR = year(OrderDate),
                MONTH = month(OrderDate),
                OrderAmount = LineTotal
         FROM   Sales.SalesOrderHeader h
                JOIN Sales.SalesOrderDetail d
                  ON h.SalesOrderID = d.SalesOrderID)
SELECT   YEAR,
         MONTH,
         OrderTotal = sum(OrderAmount)
FROM     cteOrderDetail
GROUP BY YEAR,
         MONTH
ORDER BY YEAR DESC,
         MONTH DESC
Indeed, this is the simplest structure. Simple but powerful. This is why CTEs have been declared the vehicle to increase SQL development productivity. Simpler structure is easier to create and maintain. The Year and Month column aliases declared only at one place and used in three places: SELECT, GROUP BY and ORDER BY.
While on the topic of column aliases, string literals (within single quotes) can be used for column aliases as well.
SELECT ProductNumber, 'ProductName' = Name, StandardCost,
      'Color'=coalesce(Color, 'N/A')
FROM AdventureWorks2008.Production.Product
ORDER BY 'ProductName'
GO
/* ProductNumber  ProductName       StandardCost      Color
AR-5381     Adjustable Race         0.00              N/A
ST-1401     All-Purpose Bike Stand  59.466            N/A
CA-1098     AWC Logo Cap (XL)       6.9223            Multi
BE-2349     BB Ball Bearing         0.00              N/A
BA-8327     Bearing Ball            0.00              N/A   .....*/

Friday, May 15, 2015

How to prevent parameter sniffing?

When the database engine compiles a stored procedure, it may use the actual parameters supplied to prepare an execution plan. If the parameters are atypical, the plan may be slow for typical parameters. For consistent stored procedure (sproc) performance parameter sniffing should be eliminated.
A telltale sign of parameter sniffing when suddenly a stored procedure executes in 7 minutes, as an example, instead of the usual 15 seconds.
 -- SOLUTION 1 - Remap input parameters to local variables
USE AdventureWorks; 
GO 
 
CREATE PROC uspSuppliersByLocation 
          @pStateProvinceName NVARCHAR(50) 
AS 
  BEGIN 
    /**** REMAP parameter to prevent Parameter Sniffing ****/ 
    DECLARE  @StateProvinceName NVARCHAR(50) 
    SET @StateProvinceName = @pStateProvinceName 
    /**** END OF REMAP                                  ****/ 
    SELECT V.VendorID, 
           V.Name  AS Vendor, 
           A.AddressLine1, 
           A.AddressLine2, 
           A.City, 
           SP.Name AS State, 
           CR.Name AS Country 
    FROM     Purchasing.Vendor AS V 
             INNER JOIN Purchasing.VendorAddress AS VA 
               ON VA.VendorID = V.VendorID 
             INNER JOIN Person.Address AS A 
               ON A.AddressID = VA.AddressID 
             INNER JOIN Person.StateProvince AS SP 
               ON SP.StateProvinceID = A.StateProvinceID 
             INNER JOIN Person.CountryRegion AS CR 
               ON CR.CountryRegionCode = SP.CountryRegionCode 
    WHERE    SP.Name = @StateProvinceName 
    GROUP BY V.VendorID, 
             V.Name, 
             A.AddressLine1, 
             A.AddressLine2, 
             A.City, 
             SP.Name, 
             CR.Name 
    ORDER BY V.VendorID; 
  END
GO
-- Execute stored procedure
EXEC uspSuppliersByLocation 'California'
VendorIDVendorAddressLine1AddressLine2CityStateCountry
4Comfort Road Bicycles7651 Smiling Tree CourtSpace 55Los AngelesCaliforniaUnited States
8Continental Pro Cycles2 Lion CircleNULLLong BeachCaliforniaUnited States
10Trey Research1874 Valley Blvd.NULLPalo AltoCaliforniaUnited States
11Anderson's Custom Bikes9 Guadalupe Dr.NULLBurbankCaliforniaUnited States
14Light Speed298 Sunnybrook DriveNULLSpring ValleyCaliforniaUnited States
15SUPERSALES INC.9443 OaxacaNULLLakewoodCaliforniaUnited States

------------
 -- SOLUTION 2 - OPTIMIZE FOR query hint
-- Create stored procedure with OPTIMIZE FOR query hint
-- Washington state is typical based on the distribution of states 

CREATE PROC sprocSuppliersByLocation 
          @StateProvinceName NVARCHAR(50) 
AS 
  BEGIN 
    SELECT V.VendorID, 
           V.Name  AS Vendor, 
           A.AddressLine1, 
           A.AddressLine2, 
           A.City, 
           SP.Name AS State, 
           CR.Name AS Country 
    FROM     Purchasing.Vendor AS V 
             INNER JOIN Purchasing.VendorAddress AS VA 
               ON VA.VendorID = V.VendorID 
             INNER JOIN Person.Address AS A 
               ON A.AddressID = VA.AddressID 
             INNER JOIN Person.StateProvince AS SP 
               ON SP.StateProvinceID = A.StateProvinceID 
             INNER JOIN Person.CountryRegion AS CR 
               ON CR.CountryRegionCode = SP.CountryRegionCode 
    WHERE    SP.Name = @StateProvinceName 
    GROUP BY V.VendorID, 
             V.Name, 
             A.AddressLine1, 
             A.AddressLine2, 
             A.City, 
             SP.Name, 
             CR.Name 
    ORDER BY V.VendorID
  OPTION (OPTIMIZE FOR(@StateProvinceName = 'Washington')); ; 
  END 
GO
-- Execute stored procedure
EXEC sprocSuppliersByLocation 'Colorado'
/* Partial results
Vendor                  AddressLine1            City        State
Green Lake Bike Company 2342 Peachwillow        Denver      Colorado
*/
-- SOLUTION 3 - RECOMPILE each execution
-- Create stored procedure WITH RECOMPILE OPTION
-- Downside: recompile time added to execution time
CREATE PROC sprocSuppliersByLocation 
          @StateProvinceName NVARCHAR(50) 
WITH RECOMPILE

AS 
  BEGIN 
    SELECT V.VendorID, 
           V.Name  AS Vendor, 
           A.AddressLine1, 
           A.AddressLine2, 
           A.City, 
           SP.Name AS State, 
           CR.Name AS Country 
    FROM     Purchasing.Vendor AS V 
             INNER JOIN Purchasing.VendorAddress AS VA 
               ON VA.VendorID = V.VendorID 
             INNER JOIN Person.Address AS A 
               ON A.AddressID = VA.AddressID 
             INNER JOIN Person.StateProvince AS SP 
               ON SP.StateProvinceID = A.StateProvinceID 
             INNER JOIN Person.CountryRegion AS CR 
               ON CR.CountryRegionCode = SP.CountryRegionCode 
    WHERE    SP.Name = @StateProvinceName 
    GROUP BY V.VendorID, 
             V.Name, 
             A.AddressLine1, 
             A.AddressLine2, 
             A.City, 
             SP.Name, 
             CR.Name 
    ORDER BY V.VendorID
  OPTION (OPTIMIZE FOR(@StateProvinceName = 'Washington')); ; 
  END 
GO
------------

Sunday, May 10, 2015

How to take loan in PLI

  • Loan is admissible on Whole Life Assurance (WLA), Endowment Assurance (EA) and Convertible Whole Life Assurance (CWLA) policies.
  • Currency of policy should be minimum of 3 years in case of EA and CWLA.
  • Currency of policy should be minimum of four years in case of WLA.
  • Policy should be unencumbered/ unassigned.
  • Loan Limit:
    (a) Whole Life Assurance
    Currency of Policy
    Percentage of surrender value onwhich loan is admissible
    More than 4 years to 7 years60%
    More than 7 years to 12 years80%
    More than 12 years90%

    (b) Endowment Assurance and Convertible Whole Life Assurance
    Currency of Policy
    Percentage of surrender value onwhich loan is admissible
    More than 3 years to 5 years60%
    More than 5 years to 10 years80%
    More than 10 years90%

  • Insurant should apply on LI-35 (loan application) and send to DDM (PLI) alongwith policy document and premium receipt book.
  • Second and subsequent loan is admissible after a year if the first loan is fully repaid.
  • Loan interest @ 10% p.a is calculated on six monthly basis.
  • Saturday, May 9, 2015

    PLI PREMIUM CALCULATOR REVISED 31 MAR 2014

    RPLI - INSURANCE PLANS

    RPLI offers following types of plans:
    1. Whole Life Assurance ( GRAMA SURAKSHA)
    2. Convertible Whole Life Assurance (GRAMA SUVIDHA)
    3. Endowment Assurance ( GRAMA SANTOSH)
    4. Anticipated Endowment Assurance  (GRAMA SUMANGAL)
    5. GRAM PRIYA
    6. Scheme for Physically handicapped persons
    The salient features of the Whole Life, Endowment, Convertible Whole Life and Anticipated Endowment Schemes of RPLI are same as the corresponding schemes of PLI except that the minimum Sum Assured is Rs.10,000 and the maximum Sum Assured is Rs.5 lac.  The maximum age limit of entry is 55 years in case of Whole Life and Endowment Assurance but 45 years in case of other plans.
    All the schemes have compulsory medical examination.  For the non-medical policies, the maximum limit of Sum Assured is Rs.25,000/-, and maximum age is 35 years.   In case of  Non-standard age proof for Rural PLI policies, the maximum age limit is 45 years.

    PLI - INSURANCE PLANS

    PLI offers 7 (Seven) types of plans:
    1. Whole Life Assurance  (SURAKSHA)
    2. Convertible Whole Life Assurance (SUVIDHA)
    3. Endowment Assurance  (SANTOSH)
    4. Anticipated Endowment Assurance  (SUMANGAL)
    5. Joint Life Assurance  (YUGAL SURAKSHA)
    6. Scheme for Physically handicapped persons
    7. Children Policy
    WHOLE LIFE ASSURANCE: 
    This is a scheme where the assured amount with accrued bonus is payable to the assignee, nominee or the legal heir after death of the insurant. Minimum Age at entry is 19 years and the maximum Age at entry is 55 years. The minimum Sum Assured is Rs 20,000 and the maximum Sum Assured is Rs 50 lacs. The policy can be converted into an Endowment Assurance Policy after completion of one year and before 57 years of age of the insurant. Loan facility is available after completion of four years and policy can also be surrendered after completion of three years. The policy is not eligible for bonus if surrendered or assigned for loan before completion of 5 years. Proportionate bonus on the reduced sum assured is accrued if the policy is surrendered or assigned for loan.
    ENDOWMENT ASSURANCE
    Under this scheme, the proponent is given an assurance to the extent of the Sum Assured and accrued bonus till he/she attains the pre-determined age of maturity. In case of unexpected death of the insurant, the assignee, nominee or the legal heir is paid the full Sum Assured together with the accrued bonus. The minimum age at entry is 19 years and the maximum Age at entry is 55 years. The minimum Sum Assured is Rs 20,000 and the maximum Sum Assured is Rs 50 lacs. Loan facility is available and policy can also be surrendered after completion of three years. The policy is not eligible for bonus if surrendered  or assigned for loan before completion of 5 years. Proportionate bonus on the reduced sum assured is accrued if the policy is surrendered or assigned for loan.


    CONVERTIBLE WHOLE LIFE ASSURANCE
    The features of this scheme are more or less same as Endowment assurance. Policy can be converted into Endowment Assurance after five years. Age on the date of conversion must not exceed 55 years. If option for conversion is not exercised within 6 years, the policy will be treated as Whole Life Assurance. Loan facility is available. The policy can also be surrendered after completion of three years. The policy is not eligible for bonus if surrendered  or assigned for loan before completion of 5 years. Proportionate bonus on the reduced sum assured is accrued if the policy is surrendered or assigned for loan. The policy is not eligible for bonus if surrendered or assigned for loan before completion of 5 years. Proportionate bonus on the reduced sum assured is accrued if the policy is surrendered or assigned for loan.


    ANTICIPATED ENDOWMENT ASSURANCE:
    It is a Money Back Policy with maximum Sum Assured of Rs 50 lacs.  Best suited to those who need periodical returns. Survival benefit is paid to the insurant periodically. Two types of policies  are available - 15 years term and 20 years term. For the 15 years term policy, the benefits are paid after 6 years (20%), 9 years (20%), 12 years (20%) and 15 years (40% and the accrued bonus). For the 20 years term policy, the benefits are paid after 8 years (20%), 12 years (20%), 16 years (20%) and 20 years (40% and the accrued bonus). Such payments will not be taken into consideration in the event of unexpected death of the insurant and the full sum assured with accrued bonus is payable to the assignee or legal heir.

    JOINT LIFE ASSURRANCE: 
     It is a joint-life Endowment Assurance in which one of the spouses should be eligible for PLI policies. Life insurance coverage is provided to both the spouses to the extent of sum assured with accrued bonus with only one premium. All other features are same as an Endowment policy. 
                All the above schemes have compulsory medical examination. For the non-medical policy of any category (except AEA and Joint Life Assurance for which Medical Examination is compulsory), the maximum Sum Assured is Rs 1 lac.

    LIMITS OF SUM ASSURED IN POSTAL LIFE INSURANCE: 
     Any person who is eligible to the benefit of Post Office Life Insurance Fund under Rule 6, may effect an insurance-Whole Life Assurance, Endowment Assurance, Convertible Whole Assurance, Anticipated Endowment Assurance and Yugal Suraksha Policy or all of them on his life for a sum not less than Rs. 20,000 in each class but not more than an aggregate of Rs. Fifty Lac  (Rs. 50,00,000/-) in respect of one class/all classes of insurance policy (s) taken together. The value of policy shall be taken in multiples of Rs. 10,000/- after minimum limit of Rs.20,000/- i.e. Rs. 20,000/-, Rs.30,000/-,Rs. 50,000/- and so on.

    SCHEME FOR PHYSICALLY HANDICAPPED PERSONS 
    The maximum limit of Insurance for Physically Handicapped persons in PLI is the same as others and he/she  can take any one of the plans.  Medical examination is compulsory under this scheme in order to determine the exact nature and extent of their handicap and its bearing  on the life being insured. Depending upon the nature and extent of handicap, normal or a slightly higher premium is charged.
     CHILDREN POLICY
                The Department has introduced Children Policy under PLI/RPLI, with effect form 20th Jan 2006. The salient features of this scheme are as under:-
    • The Scheme is envisaged to provide Insurance cover to the children of PLI/RPLI policy holders.
    • Maximum two children in family will be eligible to take children policy.
    • Children between the age of 5 and 20 years are eligible and maximum sum assured is Rs 3 lakh or equivalent to the sum assured of the main policy holder which ever is less.
    • The main policy holder should not have attained the age of 45 years.
    • No premium is required to be paid on the children policy on the death of the main policy holder and full sum assured with the accrued bonus shall be paid to the child after the completion of the term of the children policy. On the death of the child/children, full sum assured with the accrued bonus shall be payable to the main policy holder.
    • Main policy holder shall be responsible for payments for the Children Policy. No loan shall be admissible on Children Policy. However, the policy shall have facility for making it paid up provided the premia are paid continuously for 5 years.
    • No Medical examination of the Child is necessary. However, the child should be healthy on the day of proposal and the risk shall start from the date of acceptance of proposal.
    • The policy shall attract bonus at the rate applicable to Endowment Policy. The POIF Rules amended from time to time shall be applicable to Children Policy.

    Postal Life Insurance (PLI)

    Postal Life Insurance (PLI) was introduced on 1st February, 1884 with the express approval of the Secretary of State (for India) to Her Majesty, the Queen Empress of India.  It was essentially a welfare scheme for the benefit of Postal employees in 1884 and later extended to the employees of Telegraph Department in 1888.  In 1894, PLI  extended insurance cover to female employees of  P & T Department at a time when no other insurance company covered female lives.  It is the oldest life insurer in this country.Over the years, PLI has grown substantially from  a few hundred policies in 1884 to 42,83,302 policies as on 31.03.2010.  It now covers employees of Central and State Governments, Central and State Public Sector Undertakings, Universities, Government aided Educational Institutions, Nationalized Banks, Local bodies etc.  PLI also extends insurance cover to the officers and  staff of the Defence services and  Para-Military forces.  Apart from single insurance policies, Postal Life Insurance also manages a Group Insurance scheme for the Extra Departmental Employees (Gramin Dak Sevaks) of the Department of Posts.
    With 1,55,669 branches across the country, the Post Office is India’s  largest retail and financial services provider and is among the most widely recognized and trusted brands in the country, offering a wide range of products and essential services. In India Post, the endeavor is to take advantage of our unique position.


    Rural Postal Life Insurance (RPLI) came into being as a sequel to the recommendation of the Official Committee for Reforms in the Insurance Sector (Malhotra Committee).  The Committee had observed in 1993 that, only 22% of the  insurable population in this country had been insured; life insurance funds accounted for only 10% of the gross household savings.  The Committee had observed:
    “The Committee understands that Rural Branch Postmasters who enjoy a position of trust in the community have the capacity to canvass life insurance business within their respective areas…….”

    The Government accepted this recommendation and permitted Postal Life Insurance to  extend its coverage to the rural areas to transact life insurance business with effect from 24.3.1995, mainly because of the vast network of Post Offices in the rural areas and low cost of operations.  The prime objective of the scheme is to provide insurance cover to the rural public in general and  to benefit weaker sections and women workers of rural areas in particular and also to spread insurance awareness among the rural population.
    The Department of Posts has started this task entrusted by the Central Government with great dedication and sincerity and within a short span of time, made a very positive impact on the rural populace.  Rural Postal Life Insurance, in fact, is meant for anyone who has a rural address.  It is a boon for migrant labour and artisans, and the unorganized sector, who move on to urban areas for employment, but continue  to have a rural base.  Labour migrating overseas are also eligible for a policy. RPLI has now a total of 99,25,103 policies with Sum Assured of Rs. 595,72,59,00,275 as on 31.03.2010

    Who are eligible for obtaining a PLI policy?
    Employees  of the following Organizations are eligible.
    • Central Government
    • Defence Services
    • Para Military forces
    • State Government
    • Local Bodies
    • Government-aided Educational Institutions
    • Reserve Bank of India
    • Public Sector Undertakings
    • Financial Institutions
    • Nationalized Banks
    • Autonomous Bodies
    • Extra Departmental Agents in Department of Posts
    • Employees Engaged/ Appointed an Contract basis by central/ State Government where the contract is extendable
    • Employees of all scheduled Commercial Banks
    • Employees of Credit Co-operative Societies and other Co-operative Societies registered with Government under the Co-operative Societies Act and partly or fully funded from the Central/ State Government/RBI/ SBI/ Nationalized Banks/ NABARD and other such institutions notified by Government
    • Employees of deemed Universities an educational institutes accredited by recognized bodies such a National Assessment and Accreditation council, All India Council of Technical Education,Medical council of india etc
    Whether salaried professionals in Private Sector can join PLI?
    Such categories are not eligible. They can opt for RPLI policies.
    If one spouse is working in a Government organization  but the other is not, is there any scheme in PLI for both?
    We have ‘Yugal Suraksha’ scheme under which both can jointly get a policy, after paying a little more premium. Both can be covered under this assurance scheme.
    Can one continue the policy if one quits the Government Service?
    Yes. One can continue by making payment of premium at any one of the 1,55,000 post offices throughout the country, even after quitting service.
    For Rural Postal Life Insurance any Indian  residing in Rural India can take RPLI.  Rural area is defined as one being outside the limits of a municipality.
    Age Limit: In all policies the age limit is (age as on next birthday):19-55 years. Only in AEA and GRAM Priya in RPLI the maximum age limit is 40 years.

    Friday, May 8, 2015

    SSIS 2012 Projects: Deployment Configurations and Monitoring

    This article aims to go into more detail about the way of configuring the deployed projects to fit different needs and different environments. It will then go on to describe the ways of monitoring and versioning the SSIS Catalog.
    There are two general options for SSIS environments setup:
    • The SSIS projects being deployed to a server which handles SSIS operations and runs the packages towards different environments (TEST and PROD, for example)
    • Or, the SSIS projects can be deployed multiple times – once on every environment (TEST and PROD)

    Configuring SSIS projects hosted on the same server for multiple environments

    In the previous article, we created a project with an SSIS package. This project had a Project parameter calledDatabaseName. The idea behind it was to be able to easily manage the different names of the databases, based on environment (let’s suppose that the database in the TEST environment is called ProjectDeployment_Test and the one in the PROD environment is called ProjectDeployment_Prod).
    To achieve our goal in this case, the Project Deployment model provides us with the means of creating Environments – which is a collection of specific settings that map to the project variables.
    To create an Environment, we have to connect to our SQL Server instance via SQL Server Management Studio (SSMS) and right-click on the ‘Environments’ folder in our deployed project:
    After creating the two environments (Test and Prod), our project will look like this:
    Now we must create a variable in each environment that has the same name as our Project Variable. We double-click each Environment and, in the ‘Variables’ tab, we enter the Variable name and the value for it. Keep in mind that the Variable name is the same, but the value for it will differ, depending on the environment.
    Here is how the Test environment will look:
    And here is how the Prod environment will look:
    Now we have to map the environment variables to our project. Right-click on the deployed project and select ‘Configure…
    Then, in the ‘References tab, add both the Test and Prod environments. After adding them, the screen will look like this:
    Then go to the ‘Parameters’ tab in the same wizard and add the Parameter value:
    In the end, our screen will look like this:
    Now that we have set up the Environments and mapped them to the project, it is time to execute the SSIS package.
    Right-click on the SSIS package and click Execute. Select the appropriate environment and click ‘OK’.
    This execution is just a single test execution. However, the dialog and configuration is very similar when we schedule SSIS packages via the SQL Server Agent.
    In this case, when we have multiple environments configured on the same server, we have to make sure that every time we schedule a package for execution, we have configured the right Environment. I.e. in each SQL Server Agent job we need to make sure that the configuration is correct according to the destination (Test or Prod).
    When we make changes to our BIDS project and when we re-deploy, we do not need to worry about any configurations – the SSIS packages in the project are deployed, but the Environments and the configurations are kept as-is (unless we change the names of the project variables).

    Configuring SSIS projects hosted on multiple environments

    If the SSIS projects are deployed to more than one server, the configuration is a bit different.
    Let’s say we have a server called Test and a server called Prod, and we have to deploy the same project to both environments and configure it accordingly.
    We could, of course, use the same technique as above, where we deploy our project to each server, and then set up one Environment in each server and point the project variable to it.
    We don’t really need to do this, though. Instead, we can just deploy the projects to each server, and then right-click on the project name in the SQL Server instance and click ‘Configure …:
    Then we just need to enter the name of the project parameter:
    When we deploy next time, the settings will remain the same as we have configured them in every server, even though in our project the value for the project variable is different.

    Monitoring of SSIS Packages in the SSIS Catalog

    First of all, when we run a manual test execution of a package in the SSIS Catalog, we are immediately asked whether we would like to navigate to the monitoring page in SSMS:
    If we click ‘Yes’, we are automatically taken to the SSMS Report which shows the execution status of the current package.
    It looks similar to this:
    If we wanted to see what SSIS packages are currently executing on our instance, we would right-click on the SSISDB catalog and select ‘Active Operations.
    The dialog would look similar to this:
    Unfortunately we do not have the option to click on the currently executing package and go directly to the execution statistics report from this tab.
    In order for us to see the package execution statistics and the current execution status, we have to navigate to the reports. One way to do this is to right-click on the SSISDB catalog and select the ‘Integration Services Dashboardreport.
    This report shows an overview of all current and past executions:
    As we can immediately notice, there is a problem with our package execution. In this case, the failure is due to a validation error in my project. I have forgotten to specify the connection for one of my task components.
    This is a great learning opportunity: keep in mind that, in the project deployment model, there may be validation errors and the project can still be deployed even with them. If this happens, the execution of all packages in the project will fail on the server, even though the error is in one of the packages. As I mentioned previously, there is no way to deploy only a single package; we have to deploy the entire project every time we make changes. This is why we have to be extra careful when we deploy with the project deployment.

    Performance monitoring

    Now that we have our project working successfully and we can execute packages, we are concerned with the performance of our packages.
    It is very easy to monitor the performance of an SSIS package on our server. All we have to do is click on the ‘View Performance link in the Package Overview report.
    Then we will see the performance report, which looks similar to this:
    As we can see, there has been some improvement in run duration of the package.