During the evening of April 23, 2013, the TariffShark team gathered in a conference room at the Links Technology headquarters in order to test our disaster recovery procedures. In the event that our Tier 4 data center experiences an outage that makes the hosted TariffShark servers unavailable, we restore service to a secondary data center. We test these procedures every 6 months as a service to our hosted TariffShark customers.
The test ran successfully in just under two hours.
If you’d like to learn more about Hosted TariffShark, please visit our website or contact sales.
TariffShark databases tend to grow larger and larger over time. If you think about it, this makes perfect sense. Each time an eTariff filing is made, Tariff Record Versions are added as are the filing’s FERC Attachments. Data is constantly being added to a TariffShark database and seldom deleted.
As the size of a database grows, so does the cost of maintaining it. The files that comprise the database require more space on disk and its backups run longer and also require more storage. Therefore, it may be wise to take any steps available to reduce database size. In a TariffShark database, there are opportunities for size reduction, which by and large come from tables in the database that store transient or audit data.
- Audit – All interactions between a TariffShark client and the application server are written to an audit table. The audit table can grow quite large over time. Records in the audit table are seldom if ever needed, but can be helpful when tracking down software issues. In any event, data in the audit table older than a few weeks provides no value.
- TRV Processing Queue – The Tariff Record Version processing queue is used to track and manage the processing of all TRV documents. This is truly transient data in that after a TRV document is processed successfully, the queue data is no longer needed.
- Binary Data – TariffShark stores binary data (Word documents and PDFs, for example) separately from other TariffShark data and seldom deletes table rows that are no longer needed. Over time, unneeded documents can take up quite a bit of space in the database.
Each of these database areas can be cleaned up and, as a result, database size reduced by running a separate administrative stored procedure that ships with TariffShark Hammerhead. If you would like to learn more about these stored procedures so that you can keep your TariffShark database running efficiently, contact TariffShark Support
In an earlier blog article, we described a method for submitting a tariff filing to FERC’s eTariff sandbox, which is helpful for users who don’t have TariffShark Hammerhead. We also posted a screencast that shows how TariffShark Hammerhead has built-in FERC sandbox submission. The purpose of this article is to help you diagnose why your computer may not be able to successfully submit a filing to FERC’s eTariff sandbox.
FERC’s eTariff sandbox is an FTP server. FTP is an acronym for File Transfer Protocol, which provides a means for sending and receiving files over the Internet. Some organizations have configured their corporate networks to block FTP, which also blocks the FERC eTariff sandbox. In addition, some desktop computers are configured to run a software firewall. A software firewall could also be blocking FTP.
When we are asked to diagnose problems sending files to FERC’s eTariff sandbox, we try to isolate the root cause. One trick is to eliminate as many layers of software as possible, which we do by following this handy guide:
If a user is able to connect to FERC’s eTariff sandbox using the procedure above, then the problem is not one of blocked access and we will continue to dig deeper.
If you have questions about using FERC’s eTariff sandbox or run into problems trying to submit a filing to the sandbox, we’d love to hear from you. Please comment below or contact TariffShark Support.