Linq-to-SQL is a great tool, but never ever rely on it to update the schema. Always apply schema changes through upgrade SQL scripts that use DDL CREATE/ALTER/DROP statements to change the deployed schema from the on-disk version to the current version. This way you keep all you schema changes under version control as source text files, you can upgrade from any past version to the current application version and you can easily test all your upgrade paths, including upgrading deployments with very large tables.
The far worse alternative is to use SQL compare tools that can diff your desired schema from your deployed schema, like vsdbcmd. This may work on trivial deployments, but copying and renaming tables of millions of records will quickly show it's ugly downside.
What you absolutely cannot do is rely on the .dbml file as the 'master' copy of your schema. This is a little detail usually omitted by the Linq-to-SQL advocates, one that you discover usually when you attempt to deliver v2 of your application and realize you have no upgrade tool set.