Mam bazę danych SQL Server 2008 R2 Express z uruchomionym programem Kaspersky Security Center i nie mam pojęcia, w jakich okolicznościach nastąpiła instalacja, ale baza danych wydaje się myśleć, że jest replikowana i nie zwolni miejsca w dzienniku transakcji. na przykład:
USE master;
SELECT
name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled
FROM
sys.databases
WHERE
name = 'KAV';
SELECT DATABASEPROPERTYEX('KAV', 'IsPublished');
zwroty:
name | log_reuse_wait | log_reuse_wait_desc | is_cdc_enabled
-----|----------------|---------------------|---------------
KAV | 6 | REPLICATION | 0
DATABASEPROPERTYEX('KAV', 'IsPublished')
----------------------------------------
0 [not published]
Również nic nie jest wymienione w Replication
sekcji w SSMS.
Do tej pory wypróbowałem kilka stwierdzeń uzyskanych z wyników Google:
USE KAV;
EXEC sp_repldone null, null, 0,0,1;
EXEC sp_removedbreplication KAV;
Ale nie miałem szczęścia, żeby ten DB przestał myśleć, że jest replikowany.
Pełna sys.databases
informacja:
+-----------------------------------+------------------------------------------------------------+
| name | KAV |
| database_id | 5 |
| source_database_id | NULL |
| owner_sid | 0x0105000000000005150000004EB006B0C3554AB049CEA01BE8030000 |
| create_date | 2013-07-04 10:31:28.947 |
| compatibility_level | 90 |
| collation_name | Latin1_General_CI_AS |
| user_access | 0 |
| user_access_desc | MULTI_USER |
| is_read_only | 0 |
| is_auto_close_on | 0 |
| is_auto_shrink_on | 0 |
| state state_desc | ONLINE |
| is_in_standby | 0 |
| is_cleanly_shutdown | 0 |
| is_supplemental_logging_enabled | 0 |
| snapshot_isolation_state | 1 |
| snapshot_isolation_state_desc | ON |
| is_read_committed_snapshot_on | 1 |
| recovery_model | 1 |
| recovery_model_desc | FULL |
| page_verify_option | 2 |
| page_verify_option_desc | CHECKSUM |
| is_auto_create_stats_on | 1 |
| is_auto_update_stats_on | 1 |
| is_auto_update_stats_async_on | 0 |
| is_ansi_null_default_on | 1 |
| is_ansi_nulls_on | 1 |
| is_ansi_padding_on | 1 |
| is_ansi_warnings_on | 1 |
| is_arithabort_on | 1 |
| is_concat_null_yields_null_on | 1 |
| is_numeric_roundabort_on | 0 |
| is_quoted_identifier_on | 1 |
| is_recursive_triggers_on | 0 |
| is_cursor_close_on_commit_on | 0 |
| is_local_cursor_default | 1 |
| is_fulltext_enabled | 1 |
| is_trustworthy_on | 0 |
| is_db_chaining_on | 0 |
| is_parameterization_forced | 0 |
| is_master_key_encrypted_by_server | 0 |
| is_published | 0 |
| is_subscribed | 0 |
| is_merge_published | 0 |
| is_distributor | 0 |
| is_sync_with_backup | 0 |
| service_broker_guid | 19C05AF5-8686-4C27-BF7E-93E240DA953B |
| is_broker_enabled | 0 |
| log_reuse_wait | 6 |
| log_reuse_wait_desc | REPLICATION |
| is_date_correlation_on | 0 |
| is_cdc_enabled | 0 |
| is_encrypted | 0 |
| is_honor_broker_priority_on | 0 |
+-----------------------------------+------------------------------------------------------------+
Również:
DBCC OPENTRAN;
No active open transactions.
DBCC SQLPERF(LOGSPACE);
KAV 171066 99.55339 0
EXEC sp_replcounters;
KAV 0 0 0 0x00000000000000000000 0x00000000000000000000
Właśnie wykonałem pełne kopie zapasowe danych i dzienników.
Natknąłem się na kilka postów w bardzo podobnych sytuacjach, a rozwiązaniem było skonfigurowanie publikowania i dystrybucji replikacji, a następnie usunięcie go ponownie. Ponieważ jednak jest to Express Edition, te opcje nawet się dla mnie nie pojawiają.
Jesteśmy przede wszystkim sklepem z Linuksem i jest to jedyna instancja SQL Server, którą mamy. Jeśli wszystko inne nie powiedzie się, uzyskanie prawdziwej licencji może być naszym jedynym rozwiązaniem: przywrócenie kopii zapasowej w instancji innej niż Express i próba instalacji, a następnie usunięcie Publikacji, a następnie przywrócenie z powrotem do Express.