When to use tail-log backups?

Recently a colleague of mine asked me about tail-log backups. I seldom used tail-log backups so I didn’t pay attention to this type of backup. After reading several blogs and articles, I want to share some of my findings on this type of backups. In most cases, under the full or bulk-logged recovery models, SQL Server 2005 and later versions require that you back up the tail of the log to capture the log records that have not yet been backed up. A log backup taken of the tail of the log just before a restore operation is called a tail-log backup.
 
SQL Server 2005 and later versions usually require that you take a tail-log backup before you start to restore a database. The tail-log backup prevents work loss and keeps the log chain intact. When you are recovering a database to the point of a failure, the tail-log backup is the last backup of interest in the recovery plan. If you cannot back up the tail of the log, you can recover a database only to the end of the last backup that was created before the failure.
 
Not all restore scenarios require a tail-log backup. You do not have to have a tail-log backup if the recovery point is contained in an earlier log backup, or if you are moving or replacing (overwriting) the database and do not need to restore it to a point of time after the most recent backup. Also, if the log files are damaged and a tail-log backup cannot be created, you must restore the database without using a tail-log backup. Any transactions committed after the latest log backup are lost.
Advertisements

Software Made Simple with Team Foundation Server

Today while reading Poh Sze’s blog, I found something very interesting in her blog. A comic that really describes the problems encountered by different team members in a typical software development lifecycle. Hee hee! Here you go…
 
 
 
Does this looks familiar to you? To explore what Team Foundation Server can help you and your organization do join us for the upcoming February 2009 gathering. The following are the details of the gathering:
 
Date:  13 Feb 2009
Time: 4.00pm – 7.30pm
Venue: 29th Floor, Tower 2, KLCC
 
myVSTS is one of the participating communities. myVSTS is a community group for Visual Studio Team System enthusiasts in Malaysia. You can join the group through the following URL:
 

myVSTS Jan’09 Gathering Slides

Last few days I delivered a session on Team Foundation Version Control. Glad to see that there are some crowds. My topic title is "Learn, Implement, and Deploy Team Foundation Version Control". In the session I gave an overview of Team Foundation version control which includes managing multiple revisions during development of source code, documents, work items, and other critical information that is being worked on by your team. Typically, the session covers check-ins for a group of items or for single changes, branching and merging, shelving, and check-in policies.
 
If you need to download my slides, here is the URL:
 
Thanks for taking the trouble to come after work for the event. My sincere apologies for all the hassles that some of the attendees experienced during the event. Hope to see you again in the next gathering……
 
Happy Chinese New Year!!!!

What can you do if a file in TFS is locked by someone else?

This is another question that one of the attendees asked me during my talk. After some investigations, I found a workaround. To reproduce such scenario, I used two instances of Visual Studio 2008, namely instance1 (logged on as TFSSETUP) and instance2 (logged on as Administrator). I have a team project called TicTacToe. In instance1, I locked a file called Cell.cs.


Figure 1: To lock Cell.cs: Screenshot 1 of 2


Figure 2: To lock Cell.cs: Screenshot 2 of 2


Figure 3: To launch another instance of Visual Studio as Administrator


Figure 4: Attempt to unlock Cell.cs from the second instance of Visual Studio (launched as Administrator): Screenshot 1 of 2


Figure 5: Attempt to unlock Cell.cs from the second instance of Visual Studio (launched as Administrator): Screenshot 2 of 2

As shown in Figure 5, we are not able to unlock Cell.cs. To unlock Cell.cs on instance2, I perform the following steps:

If you still have the username of the person, you can simply do something like this:

1. Open up Visual Studio command prompt (Start -> Programs -> Microsoft Visual Studio 2008 -> Visual Studio Tools -> Visual Studio 2008 Command Prompt)
2. Run the following command:
tf lock /lock:none /workspace:WorkspaceName;USERNAME /recursive $/


Figure 6: To unlock Cell.cs using TF command (Note: You can ignore the error messages. As of now, we have successfully unlock Cell.cs. The error messages state files that we could not unlock.)

Now I attempt to check-in from the second instance of Visual Studio.


Figure 7: To check-in from the second instance of Visual Studio: Screenshot 1 of 2


Figure 8: To check-in from the second instance of Visual Studio: Screenshot 2 of 2

To get the list of workspaces for a user, just run the following command from the same prompt:

tf workspaces /owner:username


Figure 9: To list all workspaces for a specific user

Migrating Source Code to Team Foundation Server from Visual Source Safe

Today, I delivered a session for myVSTS user group at Microsoft auditorium at KLCC. One of the attendees asked me on the way to migrate source code from Visual SourceSafe to Team Foundation Server. I’ll blog on the summary of steps needed for such a migration.

Summary Overview of Steps

Step 1 – Back Up Your VSS Database
Step 2 – Analyze Your VSS Database to Resolve Data Integrity Issues
Step 3 – Analyze Your Projects in VSS
Step 4 – Prepare to Migrate Your Projects
Step 5 – Migrate Your Projects

Step 1 – Back Up Your VSS Database

Prior to performing a migration, start by creating a backup copy of the VSS database you want to migrate.

   1. Ask all users to check in their files and then log off the VSS database. Ask the users to close both the Visual Studio Integrated Development Environment (IDE) and VSS Explorer.
      Important: Checked-out files are not migrated to TFS.
   2. Check that no one is currently logged into the database.
   3. Make sure that no analyze jobs are scheduled to run against the database.
   4. Copy the following folders (located beneath your VSS install directory) to your backup location:
       \DATA
      \Temp
      \USERS
   5. Copy the following files to your backup location:
      User.txt
      Srcsafe.ini
      By default, you can find these files in the following folder: \Program Files\Microsoft Visual Studio\VSS

Step 2 – Analyze Your VSS Database to Resolve Data Integrity Issues

In this step, you use the Visual SourceSafe Analyze utility to locate and fix data integrity issues in the database.

   1. Open a Command prompt and run Analyze.exe to search for database corruption or database errors. Use the following command:

           analyze "<sourcesafe data directory>"
          
      Use the -I option for unattended execution. This command reports potential problems.

   2. If there are permissions problems, "unable to checkout files" errors, "losing checkout status" errors, or any other errors that refer to the Status.dat file or to the Rights.dat file, run the Ddconv.exe program or the Ddconvw.exe program. These programs update a VSS database from an older format to the current format. By default, these programs are installed in the \Admin subdirectory.

Step 3 – Analyze Your Projects in VSS

In this step, you determine which projects you want to migrate and then run the TFS command-line tool VSSConverter.exe to analyze the VSS database for any potential issues that might cause migration problems.

   1. Create an Extensible Markup Language (XML) settings file (named for example, ConversionSettings.xml) as follows:

           <?xml version="1.0" encoding="utf-8"?>
            <SourceControlConverter>
               <ConverterSpecificSetting>
                 <Source name="VSS">
                       <VSSDatabase name="c:\VSSDatabase">
                       </VSSDatabase>
                 </Source>
                 <ProjectMap>
                   <Project Source="$/MyFirstProject"></Project>
                   <Project Source="$/MySecondProject"></Project>
                 </ProjectMap>
               </ConverterSpecificSetting>
            </SourceControlConverter>
          

      In the above example, MyFirstProject and MySecondProject represent the names of the project folders in VSS that you want to migrate. To migrate an entire VSS database, use <Project Source="$/"></Project>.
   2. Run VSSConverter.exe passing in the Analyze switch, from a Visual Studio command prompt to analyze your projects:

      VSSConverter Analyze ConversionSettings.xml

      When prompted, enter the Visual SourceSafe administrator password.

   3. Examine the output report and identify any conversion errors. The conversion tool creates an output report named VSSAnalysisReport.xml.
   4. Map VSS users to TFS users. The VSSConverter tool creates a UserMap.xml file that contains a list of all VSS users who performed at least one operation on the VSS database. Edit the UserMap.xml file and add your associated TFS usernames (Windows accounts). You must specify user names including the domain (MyDomain\MyUserName). The following example shows a Usermap.xml files that contains the VSS user accounts in the From attribute and the associated TFS usernames in the To attribute.

<?xml version="1.0" encoding="utf-8" ?>
<UserMappings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;
  <!–
    This file is automatically created by VSS Converter. You can optionally use the file to map
    a VSS user to a Team Foundation user. For example, <UserMap From="Jane" To="MyDomain\Janep"></UserMap>
    This mapping causes all actions logged by VSS user “Jane” to be changed to Team
    Foundation user “MyDomain\Janep” during migration.
  –>
  <UserMap From="ADMIN" To="Contoso\Administrator" />
  <UserMap From="Dave" To="Contoso\DaveM" />
  <UserMap From="Chris" To="Contoso\ChrisP" />
  <UserMap From="John" To="Contoso\JohnR" />
</UserMappings>

Step 4 – Prepare to Migrate Your Projects

In this step, you use the VSSConverter.exe tool to migrate your VSS projects.

   1. Modify the ConversionSettings.xml file created in Step 3 adding a new <Settings> element containing a <TeamFoundationServer> element as shown here:

          <SourceControlConverter>
             <ConverterSpecificSetting>
             …
             </ConverterSpecificSetting>
             <Settings>
               <TeamFoundationServer name="YourTFSServerName" 
                                  port="PortNumber"
                                  protocol="http">
               </TeamFoundationServer>
                  </Settings>
          ….
          </SourceControlConverter>
         
      Add the <Settings> element directly after </ConverterSpecificSettings> as a child element of <SourceControlConverter>.
   2. Modify the ConversionSettings.xml file you created adding Destination attributes to the <Project> elements as shown below. Set the value of the Destination attributes to the folder location in your TFS Team project to which you want to migrate your files.

<?xml version="1.0" encoding="utf-8"?>
 <SourceControlConverter>
   <ConverterSpecificSetting>
      <Source name="VSS">
          <VSSDatabase name="c:\VSSDatabase">
          </VSSDatabase>
      </Source>
      <ProjectMap>
        <Project Source="$/MyFirstProject"
                 Destination="$/MyTeam_ProjectOne">
        </Project>
        <Project Source="$/MySecondProject" 
                 Destination="$/MyTeam_ProjectTwo">
        </Project>
      </ProjectMap>
   </ConverterSpecificSetting>
   <Settings>
     <TeamFoundationServer name="YourTFSServerName"
                           port="PortNumber"
                           protocol="http">
     </TeamFoundationServer>
   </Settings>
 </SourceControlConverter>

In the <ProjectMap> section, for each VSS folder that you are migrating, replace MyFirstProject with the source VSS folders and replace MyTeam_ProjectOne with the destination folders in TFS source control. Include a <Project> entry for all the folders that you want to migrate.

Step 5 – Migrate Your Projects

Copy your VSS database to a local folder such as C:\VSSDatabases on the computer on which you want to run analysis and migration. Although you can migrate a VSS database to a shared folder on a remote computer, the migration takes much longer to finish.

   1. At the command prompt, type the following.

      VSSConverter Migrate Conversionsettings.xml

   2. Enter Y to confirm the migration. When prompted, enter the password for the Visual SourceSafe admin user.

Additional Considerations

If you used, sharing, branching or pinning in VSS you should be aware of the following issues.

    * Sharing. Team Foundation Server does not support sharing of files. Shared files are migrated by copying the version of the file at the time sharing began to a destination folder. Any subsequent changes made to the shared file are replicated to both the shared and the original copies.
    * Branching. Because branching in VSS uses sharing, the migration of a branched file results in the file being copied to the destination folder in TFS source control. After the branch event, the changes to any branch are migrated to the respective copy in TFS source control.
    * Pinning. Team Foundation Server does not support pinning. To help you locate items in Team Foundation source control that were once pinned in the VSS database, the VSSConverter tool labels any file that was pinned with the “PINNED” label.

SSRS and Domino Database

This week I delivered a 3 days Crystal Reports training to UiTM. UiTM needs to build reports on their Domino database. So out of curiosity, I tried whether I can use Reporting Services (instead of Crystal Reports). 🙂 Yes. We can but you’ll need to install NotesSQL.
 
IBM Lotus NotesSQL is an ODBC (Open Database Connectivity) driver for IBM Lotus Notes and IBM Lotus Domino software. It allows ODBC-enabled data reporting tools, database tools, and application development tools to read, report, and update information that is stored in Domino databases (NSF files). With Lotus NotesSQL, users and application developers can integrate Domino data with their applications using tools such as Crystal Decisions Crystal Reports, Microsoft Visual Basic, Microsoft Access, Brio, and IBM Lotus Approach. Even Internet application development tools that support ODBC can access Domino data. IT professionals can enable their existing ODBC-enabled applications to access data stored in a Domino database.
 
A Domino database is not relational, but with Lotus NotesSQL a Domino database looks like a relational data source to an OBDC-enabled tool. This allows relational database management systems (RDBMS) such as Oracle and IBM DB2 to issue SQL (Structured Query Language) statements to Lotus Domino.
 
System requirements
 
To use Notes data through ODBC, you must have:
 
  • NotesSQL, the Lotus Notes ODBC driver
  • An ODBC Driver Manager version 3.5 or later
  • One of the following:
    • Microsoft Windows 2000 or XP
    • Microsoft Windows 2003 Server Standard Edition or Enterprise Edition
  • One of the following:
    • Lotus Notes Client release 6.0 or later
    • Lotus Domino release 6.0 or later
    • IBM Lotus Domino Designer release 6.0 or later
    • IBM Lotus Domino Off-Line Services release 1.01 or later

Paper accepted

Hmm.. I would say today is a lucky day for me. One of my research papers is accepted. Here is the url:

http://icime.org/accepted.htm

Now I’ll need to complete the procedure for the conference. Ok. This is a good start for me to kick off my fourth research paper. I have been stucked for these few weeks since I need to make sure that I don’t self-plagarise since my fourth research paper is an expanded version of the third research paper which is the paper accepted for presentation in ICIME. So far this is the second research paper which is accepted for publication. You can find my first research paper here:

http://www.scipub.org/scipub/detail_issue.php?V_No=37&j_id=jcs