Data recovery trouble shooting scenarios
I've organized the various type of data recovery scenarios I want to teach you how to troubleshoot into system database recovery, user database inaccessible, BACKUP/RESTORE failures, runtime consistency errors, and CHECKDB errors. Each section is self-contained so that you can focus on the area you are most interested in.
System Database Recovery
In most cases, recovering your database is your primary concern, because it contains the data that supports your application and business. However, understanding how to recover system databases can be important even though it occurs less often. This is because in most cases, a problem with a system database can mean SQL Server cannot start. The exception in this chapter is the MSDB database, but this too can be critical if you rely on it for its capability to run SQLAgent jobs.
There are two possible scenarios where SQL Server cannot access any database including master or your user database:
- A resource problem opening database or log files.
- Recovery fails, causing the database to become SUSPECT.
A resource problem means that the engine encountered an error when trying to open a database or log file.
Scenario 1: Failure to Open the Master Database File (master.mdf)
Let's consider this scenario first. The master database is a unique database because it is the single database used to bootstrap the execution of the engine. Server-wide information is only stored in the master database, such as the registration of all other databases, login accounts, configuration values, error messages, and linked server information. When the engine first starts, it must first open the master database to read the server-wide configuration information. At this point, if the master database file (master.mdf) cannot be opened, SQL Server does not start. The ERRORLOG would look something like this:
2006-01-28 11:07:37.06 Server Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 Copyright (c) 1988-2005 Microsoft Corporation Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 2) 2006-01-28 11:07:37.06 Server (c) 2005 Microsoft Corporation. 2006-01-28 11:07:37.06 Server All rights reserved. 2006-01-28 11:07:37.06 Server Server process ID is 4036. 2006-01-28 11:07:37.06 Server Logging SQL Server messages in file 'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLLOGERRORLOG'. 2006-01-28 11:07:37.06 Server This instance of SQL Server last reported using a process ID of 2952 at 1/26/2006 5:04:21 PM (local) 1/26/2006 11:04:21 PM (UTC). This is an informational message only; no user action is required. 2006-01-28 11:07:37.06 Server Registry startup parameters: 2006-01-28 11:07:37.06 Server -d C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmaster.mdf2 2006-01-28 11:07:37.06 Server -e C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLLOGERRORLOG 2006-01-28 11:07:37.06 Server -l C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmastlog.ldf 2006-01-28 11:07:37.07 Server Error: 17113, Severity: 16, State: 1. 2006-01-28 11:07:37.07 Server Error 2(The system cannot find the file specified.) occurred while opening file 'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmaster.mdf2' to obtain configuration information at startup. An invalid startup option might have caused the error. Verify your startup options, and correct or remove them if necessary.
You can see that Msg 17113 indicates a problem trying to read the configuration information from the master database file.
Look at the error information right after the 17113 message. In this case, it says this:
2006-01-28 11:07:37.07 Server Error 2(The system cannot find the file specified.) occurred while opening file 'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmaster.mdf2'
Error 2 is the Windows error returned from the Windows API CreateFile call. The text description follows the error number.
Determine the cause of the Windows error. In this case, error 2 means that the filename SQL Server passed to CreateFile does not exist. This means the path is wrong or the file does not exit. Check the full name of the path in the message. The standard name for the master database file is master.mdf, not master.mdf2.
If this is true, why does the engine think the name is master.mdf2? Because the master database is the bootstrap database, the engine has to get the location of the master database files from a source other than a database. It uses program parameters to do this. -d is used to specify the location of the master database file, and -l for the master transaction log file. Because SQL Server is normally run as a service, it must get the default startup parameter values from the registry.
Rather than edit the registry directly, use the SQL Server Configuration Manager. This is a good time to point out that any startup parameter setting or service configuration option (such as the startup account for SQL Server) should be done using the SQL Configuration Manager. Figure 2-3 shows what the interface looks like to change startup parameters for SQL Server.
Figure 2-3 Changing startup parameters for SQL Server
One tip when using this dialog box. The Startup Parameters is a single text field. To add a new parameter, you need to add it to the end of the parameters delimited by a semicolon.
Even though a failure to open the transaction log file can be resolved using the same technique, the errors reported in the ERRORLOG are slightly different:
2006-02-04 17:25:15.37 spid5s Error: 17207, Severity: 16, State: 1. 2006-02-04 17:25:15.37 spid5s FCB::Open: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmastlog.ldf2'. Diagnose and correct the operating system error, and retry the operation. 2006-02-04 17:25:15.40 spid5s Error: 17204, Severity: 16, State: 1. 2006-02-04 17:25:15.40 spid5s FCB::Open failed: Could not open file C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmastlog.ldf2 for file number 2. OS error: 2(The system cannot find the file specified.). 2006-02-04 17:25:15.48 spid5s Error: 5120, Severity: 16, State: 101. 2006-02-04 17:25:15.48 spid5s Unable to open the physical file "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmastlog.ldf2". Operating system error 2: "2(The system cannot find the file specified.)".
Scenario 2: Master Database Recovery Failure
Like any user database, if recovery fails, the database is marked SUSPECT. However, one major difference is that the server shuts down when it detects that recovery has failed. Consider a situation where SQL Server attempts to start but fails. You look at the ERRORLOG and see the following:
2006-03-19 22:35:02.14 Server Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 Copyright (c) 1988-2005 Microsoft Corporation Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 2) 2006-03-19 22:35:02.14 Server (c) 2005 Microsoft Corporation. 2006-03-19 22:35:02.14 Server All rights reserved. 2006-03-19 22:35:02.14 Server Server process ID is 2040. 2006-03-19 22:35:02.14 Server Logging SQL Server messages in file 'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLLOGERRORLOG'. 2006-03-19 22:35:02.15 Server This instance of SQL Server last reported using a process ID of 3628 at 3/19/2006 10:32:33 PM (local) 3/20/2006 4:32:33 AM (UTC). This is an informational message only; no user action is required. 2006-03-19 22:35:02.15 Server Registry startup parameters: 2006-03-19 22:35:02.15 Server -d C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmaster.mdf 2006-03-19 22:35:02.15 Server -e C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLLOGERRORLOG 2006-03-19 22:35:02.15 Server -l C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmastlog.ldf 2006-03-19 22:35:02.18 Server SQL Server is starting at normal priority base (=7). This is an informational message only. No user action is required. 2006-03-19 22:35:02.18 Server Detected 1 CPUs. This is an informational message; no user action is required. 2006-03-19 22:35:02.56 Server Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. This is an informational message only. No user action is required. 2006-03-19 22:35:02.56 Server Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required. 2006-03-19 22:35:02.59 Server The Microsoft Distributed Transaction Coordinator (MS DTC) service could not be contacted. If you would like distributed transaction functionality, please start this service. 2006-03-19 22:35:02.59 Server Database Mirroring Transport is disabled in the endpoint configuration. 2006-03-19 22:35:02.59 spid5s Starting up database 'master'. 2006-03-19 22:35:04.34 spid5s Error: 824, Severity: 24, State: 2. 2006-03-19 22:35:04.34 spid5s SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:506; actual 39321:-1717986919). It occurred during a read of page (1:506) in database ID 1 at offset 0x000000003f4000 in file 'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmaster.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online. 2006-03-19 22:35:04.34 spid6s Error: 922, Severity: 14, State: 1. 2006-03-19 22:35:04.34 spid6s Database 'master' is being recovered. Waiting until recovery is finished. 2006-03-19 22:35:04.34 spid6s System Task System Task produced an error that was not handled. Major: 9, Minor: 22, Severity:14, State:1 2006-03-19 22:35:04.34 spid5s Error: 3313, Severity: 21, State: 2. 2006-03-19 22:35:04.34 spid5s During redoing of a logged operation in database 'master', an error occurred at log record ID (2017:314:13). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database. 2006-03-19 22:35:04.34 spid5s Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
First, read the errors from the bottom up. You can see that the problem is a recovery problem for master, the error was during the redo of a log operation, and that the cause of that problem is an 824 error on the database page. The 824 error in this case is due to an incorrect page ID on page 1:506.
Because deferred transactions don't apply to the master database, your choices are the following:
- Restore a backup of the master database.
- Rebuild it using the setup program that comes with the installation medium.
Let's address how to restore a backup in this situation. You always have to start SQL Server in single user mode (using the -m startup parameter) to restore master, but in this case, SQL Server cannot be started because of the master recovery failure. Well, a nice trace flag helps you in this situation, trace flag 3607. Trace flag 3607 tells the engine to open just the master database, but don't run recovery on it. It is only to be used in this type of emergency situation, when master database recovery fails.
So the steps are as follows:
- Start SQL Server with -m and -T3607 as startup parameters using the SQL Server Configuration Manager.
- . Restore your backup of the master database.
You see a message indicating SQL Server is being shut down:
Processed 360 pages for database 'master', file 'master' on file 1. Processed 2 pages for database 'master', file 'mastlog' on file 1. The master database has been successfully restored. Shutting down SQL Server. SQL Server is terminating this process.
SQL Server shuts down by design whenever you restore master. It is important to pay attention to the message to the client, because the ERRORLOG will not show a reason why SQL Server was shut down in this situation.
- Remove the -m and -T3607 startup parameters and restart SQL Server.
So if you don't happen to have a backup of the master database, your only choice is to rebuild it. After you rebuild it, you lose any previous information in master. Unfortunately, trace flag 3607 is only helpful to restore master. When you use this trace flag, any attempt to access an object in master results in the following error:
Msg 904, Level 16, State 1, Line 1 Database 32767 cannot be autostarted during server shutdown or startup.
Putting master in emergency mode won't help either, because it is not allowed for the master database. So now that you are faced with the prospect of rebuiding master, how do you go about it? The first step is to find the installation media or source for your install (perhaps a network drive). Why? Because the method to rebuild the master database is contained within the SQL Server Setup program that only comes with the installation media. The steps to use setup to rebuild master are actually well documented in SQL Server Books Online in the section "Rebuilding System Databases, Rebuilding the Registry," so I don't list them here. An important point for you to keep in mind is that after rebuilding master, you must reapply any service packs or hotfixes you have previously installed, because they might have updated catalog information or the resource database.
The third scenario that I didn't call out specifically is simply a need to restore master because of a corruption problem or perhaps a change made that you want undone (for example, dropping some important logins). If the master database is fully available and ONLINE, all you need to do is RESTORE your backup.
Just like the master database, if the model database cannot be started, SQL Server will not start successfully. If the problem was due to a problem with opening the model database file, the ERRORLOG shows entries such as the following:
2006-03-19 23:52:11.06 spid9s Error: 17207, Severity: 16, State: 1. 2006-03-19 23:52:11.06 spid9s FCB::Open: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmodel.mdf'. Diagnose and correct the operating system error, and retry the operation. 2006-03-19 23:52:11.06 Server Server is listening on [ 127.0.0.1
1434]. 2006-03-19 23:52:11.06 spid9s Error: 17204, Severity: 16, State: 1. 2006-03-19 23:52:11.06 spid9s FCB::Open failed: Could not open file C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmodel.mdf for file number 1. OS error: 2(The system cannot find the file specified.). 2006-03-19 23:52:11.06 Server Dedicated admin connection support was established for listening locally on port 1434. 2006-03-19 23:52:11.06 spid9s Error: 5120, Severity: 16, State: 101. 2006-03-19 23:52:11.06 spid9s Unable to open the physical file "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAmodel.mdf". Operating system error 2: "2(The system cannot find the file specified.)". 2006-03-19 23:52:11.12 spid9s Error: 945, Severity: 14, State: 2. 2006-03-19 23:52:11.12 spid9s Database 'model' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details. 2006-03-19 23:52:11.14 spid9s Could not create tempdb. You may not have enough disk space available. Free additional disk space by deleting other files on the tempdb drive and then restart SQL Server. Check for additional errors in the event log that may indicate why the tempdb files could not be initialized.
This is similar to the situation with the master database; just the error numbers have changed. In this case, error 5120 contains the Windows error to explain why the model database file could not be opened. In the preceding scenario, it is Windows error 2, which means the file could not be found. Troubleshoot the same way as master, except the location for where the engine believes the file should exist is stored in the master database rather than in the registry. If I encountered this error, I would check to see whether the file existed in the path. If it did not, I would see if the model.mdf file existed anywhere on the drive. If I found it, I could copy it to the path as listed in the message or change the location where the engine should look for the file.
How do I do this if the engine will not start? Here are the steps:
- . Add the startup parameter -T3608 to start SQL Server. This tells the engine to not start any database except master.
- . Use ALTER DATABASE and the MODIFY FILE option to change the path of the model database file to its correct path.
- . Shut down and restart SQL Server without -T3608 so that all system and user databases can recover.
A more obscure scenario would be for recovery to fail for the model database. I say this because the model database is not changed very often by customers. Customers who do want to add objects to the model database so that every new database will have them usually do this infrequently. But should recovery fail for the model database, you need to use trace flag 3608 again to start the server so that you can restore model from a backup. This was not possible in SQL Server 2000, because the engine would attempt to use tempdb during the RESTORE command. Because tempdb first requires model to be started, the RESTORE command would fail. Now that restriction is removed, and RESTORE should work with trace flag 3608. What about that cool feature I told you about called emergency mode repair with CHECKDB? Is that possible for model? Does it make sense? First of all, it doesn't make sense. You don't want to create new databases based on a possible logically inconsistent model database. But it really doesn't matter anyway, because ALTER DATABASE SET EMERGENCY is not allowed on the model database. (For that matter, it isn't allowed on any system database.)
The msdb database is considered a system database even though it is not required to start SQL Server. One reason that you can consider it a system database is that if you rebuild the master database with setup, you are in effect rebuilding all system databases, including model, MSDB, and the resource database. Furthermore, MSDB (in case you were wondering, MSDB stands for Microsoft System Database) is used to store important information such as backup/restore history and SQL Server Agent jobs. In fact, the SQL Server Agent service will not start if the MSDB database is not available.
The scenarios for problems accessing MSDB are the same as master and model. Either you can encounter a resource problem (such as problems opening the database/log files), or recovery could fail, causing the database to become SUSPECT.
Because MSDB is more like a user database than model, you can use more-conventional techniques to recover it. For example, because SQL Server can start if a problem exists with MSDB, you don't need any special trace flags to restore a backup of MSDB. If the MSDB database becomes SUSPECT, you can just restore from a backup. If you don't have a backup available, you must rebuild the system databases using the same technique as you would rebuild master or model. In previous versions, you could get away with manually running the instmsdb.sql script in the INSTALL directory of SQL Server. Unfortunately, this technique is no longer that simple (the gyrations to make it work are pretty complex, and I don't think they are reliable), so the safest bet is to rebuild system databases.
If the MSDB database or log files cannot be opened, the database state appears as RECOVERY_PENDING, as described in the "Storage Internals" section. The errors you will see in the ERRORLOG look much like the scenario with model:
2006-03-20 18:58:47.71 spid12s Error: 17207, Severity: 16, State: 1. 2006-03-20 18:58:47.71 spid12s FCB::Open: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'c:program filesmicrosoft sql servermssql.1mssqldatamsdbdata.mdf'. Diagnose and correct the operating system error, and retry the operation. 2006-03-20 18:58:47.71 spid12s Error: 17204, Severity: 16, State: 1. 2006-03-20 18:58:47.71 spid12s FCB::Open failed: Could not open file c:program filesmicrosoft sql servermssql.1mssqldatamsdbdata.mdf for file number 1. OS error: 2(The system cannot find the file specified.). 2006-03-20 18:58:47.73 spid12s Error: 5120, Severity: 16, State: 101. 2006-03-20 18:58:47.73 spid12s Unable to open the physical file "c:program filesmicrosoft sql servermssql.1mssqldatamsdbdata.mdf". Operating system error 2: "2(The system cannot find the file specified.)".
In fact, as you will see in the next section on user databases, these errors look the same as if a user database files could not be opened. The difference between this scenario and the model database is that the server is still up and running. You can then try to resolve the problem (perhaps by getting the msdbdata.mdf file in its right location) and simply execute ALTER DATABASE msdb SET ONLINE to start it up. By the way, don't get nervous when doing this in SQL Server Management Studio. If you attempt to connect to Object Explorer for the server in this state, you will get the error shown in Figure 2-4.
Figure 2-4 Error message from attempting to connect to Object Explorer for the server
After you click OK, you won't see anything under the server name from Object Explorer. This is because Object Explorer tries to execute a stored procedure in the msdb database to show properties for SQL Server Agent after it connects. If this fails, it just doesn't show you anything. That's okay. Get MSDB back online, and then right-click the server instance listed. Select Disconnect, which removes the server instance from the screen. Now you can select the Connect drop-down option and reconnect to Object Explorer.
Recovering the Resource Database
You recall the resource database is read-only and "hidden." This means you can't reference this in commands such as ALTER DATABASE. So the techniques to recover from problems with it are different than even other system databases. For example, there is no way to BACKUP the resource database online. But because you can't modify it, there is no need to. The only way to back up the resource database is to back up the files themselves.
This scenario is very much the model database, because the server cannot start if it cannot open the resource database. In fact, the errors are identical to what you see in this situation for model. So look at the Windows error and resolve this to restart SQL Server. There is one big difference from the model situation. Even if you want to start SQL Server with -T3608 to avoid starting the resource database, you really cannot do anything. What I mean is that you can't query any catalog view, because they require the resource database. Furthermore, as I've said, T-SQL commands can't reference the resource database by name. Given this information, the only way to encounter a problem opening the resource database files is something occurring external to SQL Server (for example, someone going into the DATA directory and renaming the mssqlsystemresource.mdf file).
The other scenario could simply be damage to the resource database caused by some external factor (perhaps the portion of the disk containing this database was damaged). Because there is no way to BACKUP the database or RESTORE it, the only method to recover is to copy the resource database files themselves from the proper source. What is the proper source? This is where you have to manage these files a bit. For the RTM version of SQL Server 2005, no problem. These files are on the installation media. You may not have this lying around, which is why I recommend you copy them to some backup source you can get to easily. For any hotfixes or service packs you apply, you should also keep this copy of the files handy to replace.
When you start applying hotfixes or future service packs, you may ask, "How do I know if I've got the correct version to copy?" There is a method to find out the version of the resource database. Remember I told you to think of the resource database as DLL. The problem with versions is that the resource database files are not DLLs, so there is no way with Windows to put in a version value in the property of these files. So, the SQL Server development team built in the version to the resource database and provided you a way to query it:
For the RTM version of SQL Server, this returns the following result:
So how do I know whether this is the "right" version of the resource database? This version matches the engine's build number. And the query to find out the build number is the following:
For the original shipping version of SQL Server 2005 (known internally as the RTM version), this returns the following:
You can ignore the .06 on this version for comparison's sake. This is just an internal number used as part of the final builds for SQL Server 2005 RTM. So if you run these two queries and you receive the same results for the first three numbers separated by the decimal, you have the correct resource database. If they don't match, you have a problem and need to find the correct version. This is why I recommend whenever you apply a hotfix or service pack, you take the resource database files copied to the DATA directory and keep them tucked away in a safe place. What would happen if these two versions differ? For SQL Server 2005 RTM, maybe nothing. The true answer is the behavior of catalog views and system objects in the engine is unpredictable. For future versions of the engine (hint: perhaps in the first service pack of SQL Server 2005), an error may be produced in the ERRORLOG, and the engine might not start.
Failure to Create tempdb
As with previous versions of SQL Server, tempdb is created from scratch each time SQL Server is started. This means recovery is not run for tempdb. This does not mean there won't be problems creating tempdb at server startup. One such problem I've seen as reported by customers is not having enough disk space to create the tempdb files. By default, tempdb is created with a single 8MB database file and 512KB transaction log file. So no matter how large tempdb grows, when SQL Server is restarted, it is re-created with these default sizes. However, you can change these default sizes using ALTER DATABASE or SQL Server Management Studio. In fact, for performance reasons, I highly recommend you not rely on autogrowth of these files and change tempdb to a size that meets the needs of your application. (Unfortunately, I do not get into a recommendation here, but there is a section in Books Online called "Capacity Planning for tempdb.")
Reinstalling the Operating System
One other possible scenario to mention about system databases is reusing them if you have to reinstall the operating system. Consider the scenario where for whatever reason you decide to reinstall the Windows operating system. This will also require you to reinstall SQL Server. But if the drive containing the system database files and your user database files is valid and intact, why should you have to rebuild the system databases? In SQL Server 2000, this was exactly what you had to do. In SQL Server 2005, the setup program is smart enough to detect existing system databases.
When you run the setup for SQL Server, you can specify a path for the DATA directory where system databases will reside. Simply point that DATA directory to the same path where the valid system databases exist. If you do this, you see the dialog box from setup, as shown in Figure 2-5.
Figure 2-5 Dialog box from setup
Just click OK and setup will use your existing system databases. When setup is done, you should be at the same state as you were before reinstalling the operating system (unless you had applied hotfixes or service packs, because they must be reapplied after this).
Use the following table of contents to navigate to chapter excerpts, or click here to view Data corruption and recovery issues in its entirety.
|About the book:|
|In this book, bestselling author and SQL Server guru Ken Henderson has worked with the SQL Server Development team to write "the" troubleshooting SQL Server 2005 book. All of the content comes directly from the creators and developers of SQL Server. Ken has edited each chapter to ensure that the writing is clear and sound. Written by the people who know the product best - the people who built it - SQL Server 2005 Practical Troubleshooting teaches developers and dbas how to troubleshoot and diagnose problems they may encounter with SQL Server. Purchase the book from Addison-Wesley Publishing|
|ABOUT THE AUTHOR:|
|Ken Henderson has been a developer for more than 25 years. He has worked with SQL Server since 1990 and has built software for a number of firms throughout his career, including H&R Block, the Central Intelligence Agency, the U.S. Navy, the U.S. Air Force, Borland International, JP Morgan, and various others. He joined Microsoft in 2001 and is currently a developer in the Manageability Platform group within the SQL Server development team. He is the creator of SQL Server 2005's SQLDiag facility and spends his days working on SQL Server management tools and related technologies. He is the author of eight books on a variety of computing topics, including the popular Guru's Guide series of SQL Server books available from Addison-Wesley. He lives with his family in the Dallas area and may be reached via email at firstname.lastname@example.org.|