问题标签 [transaction-log]

很少有 shell 脚本使用isql在 Sybase 数据库服务器上执行一些 sql 语句。我在日志中看到几条 Log Suspend 消息，问题是 shell 脚本成功退出。

数据库 MAIN_DB 中的事务日志几乎已满。您的事务将暂停，直到日志中有可用空间。

我需要拦截这些日志挂起消息并报告正确的错误。我该怎么做呢？我不确定如何在这里进行。当它发生时，它无法被清除，并且数据库管理员必须在一段时间后终止 spid，但脚本已经成功退出。因此，数据传输实际上并没有发生并被中止。这是我需要处理的场景。

请让我知道我们如何能够拦截 Log Suspend 并至少等待特定时间？

当 Microsoft 数据库的事务日志已满时，我的 jsp 站点和 asp 站点开始抛出错误消息。所以我进去缩小了日志文件，asp站点开始工作得很好，但是jsp站点仍然抛出关于无法启动新事务的错误。我是 JSP 的新手，所以仍在尝试弄清楚。JSP 站点在 Windows 机器上的 tomcat 服务器上运行。我需要做什么来重置 jsp 站点。我附上了堆栈跟踪：

processloginaction com.ibatis.common.jdbc.exception.NestedSQLException：无法启动事务。原因：com.ibatis.sqlmap.engine.transaction.TransactionException：TransactionManager 无法启动新事务。事务已经开始。原因：com.ibatis.sqlmap.engine.transaction.TransactionException：TransactionManager 无法启动新事务。事务已经开始。在 com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.startTransaction(SqlMapExecutorDelegate.java:728) 在 com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.startTransaction(SqlMapSessionImpl.java:129) 在 com.ibatis.sqlmap.engine .impl.SqlMapClientImpl.startTransaction(SqlMapClientImpl.java:101) at action.ProcessLoginAction.execute(ProcessLoginAction.java:170) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor. TransactionException：TransactionManager 无法启动新事务。事务已经开始。在 com.ibatis.sqlmap.engine.transaction.TransactionManager.begin(TransactionManager.java:46) 在 com.ibatis.sqlmap.engine.transaction.TransactionManager.begin(TransactionManager.java:39) 在 com.ibatis.sqlmap.engine .impl.SqlMapExecutorDelegate.startTransaction(SqlMapExecutorDelegate.java:726) ... 24 更多原因：com.ibatis.sqlmap.engine.transaction.TransactionException：TransactionManager 无法启动新事务。事务已经开始。在 com.ibatis.sqlmap.engine.transaction.TransactionManager.begin(TransactionManager.java:46) 在 com.ibatis.sqlmap.engine.transaction.TransactionManager.begin(TransactionManager.java:39) 在 com.ibatis.sqlmap.engine .impl.SqlMapExecutorDelegate.startTransaction（SqlMapExecutorDelegate.java：

I'm working on a project that requires GAAP accounting conformance for deferred revenue collection. Cash is converted to a proprietary "currency" or credits. These credits may have different values based upon the purchase price at time of conversion (including exchange rate fluctuations).

As each purchase is made, the amount is deducted from the earliest "bucket" of credits until they are exhausted and the next eldest bucket is encountered. The valuation of the credits spent define the total revenue for that particular purchase... so it may differ for each product simply based upon the order of credits and debits / the value of each credit.

My sequential mind sees this as an easy imperative problem. With the data I'm capturing, I can replay the transaction logs and arrive at a daily total for revenue for each customer and each product... that can then be amortized for the services provided. No problem.

My data is in a sharded MongoDB cluster of replica sets. Dumping it and writing a post-processing script is easy, but I'd love to be able to report directly out of it.

I've played with simple MapReduce operations in the past. Is there any way to sequentially process a transaction log? While normal transaction logs can be processed in parallel, and I've done this, I just can't seem to find a way to twist MapReduce (MongoDB or Hadoop) to replay in order. I don't think it can be done. Am I wrong or just a n00b?

My only options at this point are post-processing replay, manipulating currency buckets at time of purchase or utilizing something I've overlooked... perhaps I'm not thinking enough outside the box here.

Any brief insights or pointers are greatly appreciated.

我将 NLog 用于我的简单 C#.Net 应用程序，它运行良好。但是当我将NLog 用于 C#.Net 多线程应用程序时，它会跳过日志消息

我还尝试使用 AsyncWrapper 和 AutoFlushWrapper 配置 NLog.config，但它仍然无法正常工作，但仍然跳过了一些消息。

所以，请任何人告诉我在不跳过任何日志消息的情况下为多线程应用程序配置 NLog 的最佳方法是什么？

我需要尽可能短的最佳方式来处理 SQL Server 事务日志文件，因为我的磁盘将来在保存它们时会出现问题。我不知道如何解决这个磁盘空间不足的问题，因为我的驱动器的可用空间已经在 MB 中。

现在，我不知道如果将日志移动到其他驱动器是否会丢失或影响日志，或者如果磁盘空间已满，是否会影响事务或如何根据以前的事务保存未来的日志. 有人请帮忙！！

我有可以追溯到 6 个月的交易日志文件。我需要从数据库中回滚 2013 年 5 月 20 日之后发生的所有事情。谁能告诉我如何做到这一点？

有谁知道在创建索引时避免膨胀事务日志？

我的问题：我有一个创建大量索引的脚本。运行此脚本时，我的事务日志不会停止增长。有没有办法，如何在创建索引时减少日志记录？

问候

We have a 6 step where we copy tables from one database to another. Each step is executing a stored procedure.

1. Remove tables from destination database
2. Create tables in destination database
3. Shrink database log before copy
4. Copy tables from source to destination
5. Shrink the database log
6. Back up desstination database

during the step 4, our transaction log (ldf file) grows very large to where we now have to consistently increase the max size on the sql server and soon enough (in the far furture) we believe it may eat up all the resources on our server. It was suggested that in our script, we commit each transaction instead of waiting til the end to commit the transactions.

Any suggestions?

首先要提到我搜索了很长时间但得到了 n 个解决方案，所以我没有尝试解决我的具体问题，试图保持简短：

• solr 规范 4.0.0.2012.10.06.03.04.33

• 一主三从

• 索引中有大约 70.000 个文档

• 主人被触发完全导入/生成完整的新索引〜每天一次

• 触发器的命令行选项是：?command=full-import&verbose=false&clean=false&commit=true&optimize=true

• slaves 为新索引触发 master，如果 GEN 增加（如前所述的完全导入 + 硬提交），它们会拉新索引

• 没有设置 autoCommit / autoSoftCommit

问题在于，每次硬提交索引（〜670MB）每天一次写入磁盘，但旧的永远不会被删除。据我所知，solr 保留了足够的 tlogs 来恢复对文档的最后 100 次更改，对吗？

在我的设置中，我确信每天至少有 100 个文档（或源数据库中的数据集）被更改，所以我不明白为什么 solr 从不删除旧的 tlog。

如果有人能指出正确的方向，我会很高兴，目前我不知道下一步该尝试什么。我也没有找到像这样的设置描述有这样的问题。

谢谢 ;）

We are a small division of a larger company and we are required to keep a server at the corporate office as a disaster recovery server. I want to use SQL's (2005) transaction log shipping feature to keep the offsite server up-to-date.

The problem is that Mama Corprorate wants proof that the database is functional. For example, a screenshot of the remote session showing a query of the orders table showing the most recent group of orders (with the order date). Is there a way to satisfy this requirement without breaking the log shipping? I suggested that I give them a screen of the history for the LS Restore job, but they didn't like that idea since "that really isn't telling you that its working" according to them.

Thanks!