Installing missing Intel I217-V for Debian

This firmware was not included as part of a readily available package within Debian and so needed to be installed from Intel's website:

https://downloadcenter.intel.com/download/15817/Network-Adapter-Driver-for-PCI-E-Gigabit-Network-Connections-under-Linux-

Firstly ensure we have the appropriate kernel headers with:

sudo apt-get install linux-headers-$(uname -r)

So we simply unzip the gzip file:

tar zxvf e1000e-3.2.*

cd e1000e-3.2.4.2

make install 

and then activate the module with:

sudo modprobe e1000e

 Finally confirm the module is installed / in use with lsmod:

lsmod | grep e1000e

Read more

log_reuse_wait: 'Replication' status appearing

After being unable to shrink a specific database log file to a zero (or something near that) I became slightly puzzled why a 30GB log file would only truncate to about 15GB - after some research I found out that sometimes after replication has been turned on and then stopped - the log_reuse_wait value has not changed back to it's default and is still set at '6' - which tells us that the log file witholds some transactions in the log for use with replication.

I ran the following command to retireve log_reuse_wait information for each database:
SELECT name, log_reuse_wait_desc FROM sys.databases

As replicatoin was not currently turned on (although it was at one point) it looks like the termination of the replication went wrong somewhere and so we need to attempt to remove the 'Replication' status:

EXEC sp_removedbreplication my_database;

and then run the following command again to verify the log_reuse-wait is back at '0':

SELECT name, log_reuse_wait_desc FROM sys.databases

Read more

Microsoft Exchange: The properties on this object have invalid data.

Firstly we need to identify what is causing the issue - so we can review the distribution group with something like:

Get-DistributionGroup "Testing(123)" | FL

and ensure there are no invalid objects within that group with something like:

Get-DistributionGroupMember "Testing(123)" | FL

In my event after issuing the first command I was presented with the following warning at the bottom of the output:

WARNING: The object mydomain.int/Users/Alerts has been corrupted, and it's in an inconsistent state. The following validation errors happened: WARNING: Property expression "Testing(123456)" isn't valid. Valid values are: Strings formed with characters from A to Z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ', *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may be embedded in an alias, but each period should be preceded and followed by at least one of the other characters. Unicode characters from U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a best-fit US-ASCII string in the e-mail address, which is generated from such an alias.

It looks like the object had not been upgraded and was orginially created as an older version that accepted the parethnesis in alias names, although Exchange 2010 did not like this.

So to resolve the issue I simply reset the alias with something like:

Set-DistributionGroup "Testing(123)" -Alias "Testing123456"

Read more

How to shrink / truncate a database log file within SQL Server

Firstly ensure that the database recovery model is set too 'Simple':

Right hand click on the database >> Properties >> Options >> Recovery Mode = Simple.

Then right-hand click on the database again and select 'Tasks' >> 'Shrink' >> Files - from here you should ensure that the file type is set to 'Log' and the Shrink action 'Reorganize pages before releasing unused space' is selected and enter a value in MB to shrink the log file too and finally hit OK.

Change if recovery model back to 'Full' (if applicable) and take a full backup of the database.

You can also do all of this via commands as follows:

 ALTER DATABASE MYDATABASE SET RECOVERY SIMPLE

 DBCC SHRINKFILE (MYDATABASE_Log, 1)

 ALTER DATABASE MYDATABASE SET RECOVERY FULL

Read more

Checking / repairing a database or table for consistency errors / corruption with MSSQL

If you encounter consistency errors such as:

The Database ID 5, Page (1:4835927), slot 7 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a data page. Run DBCC CHECKTABLE.

We should firstly find identify the database ID 5 by running:

SELECT DB_NAME(2) AS Database_Name;

(where '5' is the database ID in question.)

DBCC CHECKDB ('MYDATABASE') WITH ALL_ERRORMSGS,NO_INFOMSGS

We can also check an induvidual table with:

USE MYDATABASE
DBCC CHECKTABLE ('YourTable'); WITH ALL_ERRORMSGS,NO_INFOMSGS

If you are not lucky enough to have an available backup to hand you can attempt to repair the databaser with the DBCC CHECKDB command.

Although before we perform this you should ensure that the database is put into single user mode - along with the 'ROLLBACK IMMEDIATE' switch that will rollback any user transactions immidiately so that the DB can drop into single user mode (i.e. all user connections have disconnected) or the 'WITH ROLLBACK AFTER 30' option which allows the users a number of seconds (30 in this case) to complete the transactions.

ALTER DATABASE MYDATABASE SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
BEGIN TRANSACTION;

or

ALTER DATABASE MYDATABASE SET SINGLE_USER WITH ROLLBACK AFTER 30;
BEGIN TRANSACTION;

Now there are two repair levels: 'REPAIR_REBUILD' which is used when the corruption is confined to non-clustered indexes which are redeundent and hence cause no data loss and 'REPAIR_ALLOW_DATA_LOSS' which can potentially cause data loss.

To repair the a single table we can use:

USE MYDATABASE
DBCC CHECKTABLE ('MYTABLE', REPAIR_ALLOW_DATA_LOSS);

or to attempt to repair the whole database:

DBCC CHECKDB ('MYDATABASE', REPAIR_ALLOW_DATA_LOSS);

And finally change the database back to multi-user mode with:

ALTER DATABASE MYDATABASE SET MULTI_USER;

BEGIN TRANSACTION

Read more

Re-building database log files that have been corrupted for MSSQL

Firstly check the database for log corruption with:

Bare in mind that DBCC CHECKDB WITH ALL_ERRORMSGS,NO_INFOMSGS will NOT check the logs and hence will not identify any corruptino in the logs!

You should also check the event log for any hardware or MSSQL related errors such as:

"Description: Executing the query "BACKUP LOG [PCDB_PROD] TO  DISK = E'\\MyDatabase2..." failed with the following error: "BACKUP detected corruption in the database log. Check the errorlog for more information."

and you could also run chkdsk to identify any file system related errors.

The easiest way to remedy this situation is to firstly ensure you have a FULL backup of the database.

There are two methods to remove the courrpt logs - the first can be performed while the database is online and hence not affect downtime:

Firstly run a DBCC CHECKDB WITH ALL_ERRORMSGS,NO_INFOMSGS on the database to look for any errors.

Method 1: which will incur downtime! as described below:

*** You should also ensure there are no transactions pending on the database by using the activity monitor on the SQL server - as if there are the operation of setting the database into recovery mode will hang! ***

Put the database into emergency mode:

ALTER DATABASE <dbname> SET EMERGENCY, SINGLE_USER

Proceed by re-building the log file as follows:




 ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<logical file name>, FILENAME='<full path to new file>')

 Now we can simply bring the database back online, putting it into multi-user mode:

ALTER DATABASE MYDATABASE set ONLINE ONLINE;
ALTER DATABASE MYDATABASE set ONLINE MULTI_USER;

Method 2: requires database downtime and is as follows:

*** You should also be aware that transactions occuring between the backup above and when you detach the database below that they will be lost! ***

Proceed by detaching the database and then renaming (or deleting) the log file assosiated with the database.

We should then attach the database to the SQL server and re-build the logs with:

CREATE DATABASE [mydatabase]
ON (FILENAME=E:\Path\to\database.mdb)
FOR ATTACH_REBUILD_LOG;

Now ensure that the recovery model is set to the appropriate mode!

and then run a integrity check on the database as follows:

DBCC CHECKDB WITH ALL_ERRORMSGS,NO_INFOMSGS

Finally make a full backup of the database.

Sources

http://blogs.msdn.com/b/glsmall/archive/2013/11/14/recovering-from-log-file-corruption.aspx
http://blogs.msdn.com/b/suhde/archive/2009/07/11/database-corruption-part-5-dealing-with-log-file-corruption.aspx

Read more

Checking VM and datastore performance issues with ESXTOP

SSH into the ESXI host and launch ESXTOP:

esxtop

Hit 'v' on the keyboard to display the VM view.

Now hit 'f' and ensure that the 'F', 'G' and 'H' are selected so that the latency stats are displayed.

Hit enter and review LAT/rd and LAT/wr stats.

As a rough baseline typically anything above 20ms is considered poor performance, anything below this should be acceptable in most cases.

You can also view the overall performance of a whole datastore by pressing the 'u' key (and ensuring the appropriate latency fields are included.)

again as a guideline anything above 20ms should be considered poor performance.

Read more